ssh — Cliente de login remoto OpenSSH
SINOPSIS
ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
[-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command [argument ...]]
ssh [-Q query_option]
DESCRIÇÃO
ssh (cliente SSH) é um programa para fazer login em uma máquina remota e para executar comandos em
uma máquina remota. Ele tem como objetivo fornecer comunicações criptografadas seguras entre dois
hosts não confiáveis em uma rede não segura. Conexões X11, portas TCP arbitrárias e sockets de
domínio Unix também podem ser encaminhadas pelo canal seguro.
ssh conecta e faz login no destino especificado, que pode ser especificado como [user@]hostname
ou um URI do formulário ssh://[user@]hostname[:port]. O usuário deve provar sua identidade para
a máquina remota usando um dos vários métodos (veja abaixo).
Se um comando for especificado, ele será executado no host remoto em vez de um shell de login. Uma linha de comando completa pode ser especificada como comando, ou pode ter argumentos adicionais. Se fornecido, os argumentos serão anexados ao comando, separados por espaços, antes de ser enviado para o servidor para ser executado.
As opções são as seguintes:
-4 Força o ssh a usar apenas endereços IPv4.
-6 Força o ssh a usar apenas endereços IPv6.
-A Habilita o encaminhamento de conexões de um agente de autenticação, como ssh-agent(1).
Isso também pode ser especificado por host em um arquivo de configuração.
O encaminhamento do agente deve ser habilitado com cautela. Usuários com a capacidade de ignorar as permissões de arquivo no host remoto (para o socket de domínio Unix do agente) podem acessar o agente local por meio da conexão encaminhada. Um invasor não pode obter material de chave do agente, no entanto, eles podem executar operações nas chaves que permitem que eles se autentiquem usando as identidades carregadas no agente. Uma alternativa mais segura pode ser usar um host intermediário (veja -J).
-a Desabilita o encaminhamento da conexão do agente de autenticação.
-B bind_interface
Vincula ao endereço de bind_interface antes de tentar se conectar ao host de destino.
Isso é útil apenas em sistemas com mais de um endereço.
-b bind_address
Use bind_address na máquina local como o endereço de origem da conexão. Útil apenas em
sistemas com mais de um endereço.
-C Solicita a compressão de todos os dados (incluindo stdin, stdout, stderr e dados para conexões X11, TCP e Unix-domain). O algoritmo de compressão é o mesmo usado por [gzip]({filename}../../gzip)(1). A compressão é desejável em linhas de modem e outras conexões lentas, mas apenas diminuirá a velocidade em redes rápidas. O valor padrão pode ser definido em uma base por host nos arquivos de configuração; veja a opção Compressão em ssh_config(5) para mais informações.
-c cipher_spec
Seleciona a especificação de cifra para criptografar a sessão. cipher_spec é uma lista separada por vírgulas de cifras listadas na ordem de preferência. Veja a palavra-chave Ciphers em ssh_config(5) para mais informações.
-D [bind_address:]port
Especifica uma porta de encaminhamento de nível de aplicativo “dinâmica” local. Isso funciona alocando um socket para escutar na porta do lado local, opcionalmente vinculado ao bind_address especificado. Sempre que uma conexão é feita a esta porta, a conexão é encaminhada através do canal seguro, e o protocolo de aplicativo é então usado para determinar para onde se conectar a partir da máquina remota. Atualmente, os protocolos SOCKS4 e SOCKS5 são suportados, e o ssh atuará como um servidor SOCKS. Apenas o root pode encaminhar portas privilegiadas. Os encaminhamentos de porta dinâmicos também podem ser especificados no arquivo de configuração.
Os endereços IPv6 podem ser especificados colocando o endereço entre colchetes. Apenas o superusuário pode encaminhar portas privilegiadas. Por padrão, a porta local é vinculada de acordo com a configuração GatewayPorts. No entanto, um bind_address explícito pode ser usado para vincular a conexão a um endereço específico. O bind_address de “localhost” indica que a porta de escuta deve ser vinculada para uso local apenas, enquanto um endereço vazio ou ‘*’ indica que a porta deve estar disponível em todas as interfaces.
-E log_file
Anexa logs de depuração ao log_file em vez do erro padrão.
-e escape_char
Define o caractere de escape para sessões com um pty (padrão: ‘\~’). O caractere de escape é reconhecido apenas no início de uma linha. O caractere de escape seguido por um ponto (‘.’) fecha a conexão; seguido por control-Z suspende a conexão; e seguido por ele mesmo envia o caractere de escape uma vez. Definir o caractere como “none” desativa qualquer escape e torna a sessão totalmente transparente.
-F configfile
Especifica um arquivo de configuração alternativo por usuário. Se um arquivo de configuração for fornecido na linha de comando, o arquivo de configuração de todo o sistema (/etc/ssh/ssh_config) será ignorado. O padrão para o arquivo de configuração por usuário é ~/.ssh/config. Se definido como “none”, nenhum arquivo de configuração será lido.
-f Solicita que o ssh vá para o plano de fundo logo antes da execução do comando. Isso é útil se o ssh for solicitar senhas ou frases-senha, mas o usuário quiser que ele fique em segundo plano. Isso implica -n. A maneira recomendada de iniciar programas X11 em um site remoto é com algo como ssh -f host xterm.
Se a opção de configuração ExitOnForwardFailure estiver definida como “sim”, um cliente iniciado com -f aguardará que todas as transferências de porta remota sejam estabelecidas com sucesso antes de passar para segundo plano. Consulte a descrição de ForkAfterAuthentication em ssh_config(5) para obter detalhes.
^ G Faz com que o ssh imprima sua configuração após avaliar os blocos Host e Match e sair.
^ g Permite que hosts remotos se conectem a portas locais encaminhadas. Se usado em uma conexão multiplexada, esta opção deve ser especificada no processo mestre.
^ I pkcs11
Especifica a biblioteca compartilhada PKCS#11 que o ssh deve usar para se comunicar com um token PKCS#11 fornecendo chaves para autenticação do usuário.
^ i identity_file
Seleciona um arquivo do qual a identidade (chave privada) para autenticação de chave pública é lida. Você também pode especificar um arquivo de chave pública para usar a chave privada correspondente que é carregada no ssh-agent(1) quando o arquivo de chave privada não está presente localmente. O padrão é ~/.ssh/id\_rsa, ~/.ssh/id\_ecdsa, ~/.ssh/id\_ecdsa\_sk, ~/.ssh/id\_ed25519 e ~/.ssh/id\_ed25519\_sk. Os arquivos de identidade também podem ser especificados por host no arquivo de configuração. É possível ter várias opções -i (e várias identidades especificadas nos arquivos de configuração). Se nenhum certificado tiver sido explicitamente especificado pela diretiva CertificateFile, o ssh também tentará carregar informações do certificado do nome do arquivo obtido anexando -cert.pub aos nomes dos arquivos de identidade.
^ J destination
Conecte-se ao host de destino fazendo primeiro uma conexão ssh com o host de salto descrito por destination e, em seguida, estabelecendo um encaminhamento TCP para o destino final a partir daí. Vários saltos podem ser especificados, separados por vírgulas. Os endereços IPv6 podem ser especificados colocando o endereço entre colchetes. Este é um atalho para especificar uma diretiva ProxyJump de configuração. Observe que as diretivas de configuração fornecidas na linha de comando geralmente se aplicam ao host de destino e não a quaisquer hosts de salto especificados. Use ~/.ssh/config para especificar a configuração para hosts de salto.
^ K Habilita a autenticação baseada em GSSAPI e o encaminhamento (delegação) de credenciais GSSAPI para o servidor.
^ k Desabilita o encaminhamento (delegação) de credenciais GSSAPI para o servidor.
^ L [bind_address:]port:host:hostport
^ L [bind_address:]port:remote_socket
^ L local_socket:host:hostport
^ L local_socket:remote_socket
Especifica que as conexões para a porta TCP ou socket Unix fornecida no host local (cliente) devem ser encaminhadas para o host e porta fornecidos, ou socket Unix, no lado remoto. Isso funciona alocando um socket para ouvir em uma porta TCP no lado local, opcionalmente vinculada ao bind_address especificado, ou para um socket Unix. Sempre que uma conexão é feita à porta ou socket local, a conexão é encaminhada pelo canal seguro e uma conexão é feita para a porta do host hostport ou o socket Unix remote_socket da máquina remota.
O encaminhamento de portas também pode ser especificado no arquivo de configuração. Apenas o superusuário pode encaminhar portas privilegiadas. Os endereços IPv6 podem ser especificados colocando o endereço entre colchetes.
Por padrão, a porta local é vinculada de acordo com a configuração GatewayPorts. No entanto, um bind_address explícito pode ser usado para vincular a conexão a um endereço específico.
O bind_address de “localhost” indica que a porta de escuta deve ser vinculada para uso local
apenas, enquanto um endereço vazio ou ‘*’ indica que a porta deve estar disponível em todas as
interfaces.
-l login_name
Especifica o usuário para fazer login na máquina remota. Isso também pode ser especificado por host no arquivo de configuração.
-M Coloca o cliente ssh no modo “mestre” para compartilhamento de conexão. Várias opções -M
colocam o ssh no modo “mestre”, mas com confirmação necessária usando ssh-askpass(1) antes de
cada operação que altera o estado de multiplexação (por exemplo, abrir uma nova sessão). Consulte
a descrição de `ControlMaster` em ssh_config(5) para obter detalhes.
-m mac_spec
Uma lista separada por vírgulas de algoritmos MAC (código de autenticação de mensagem), especificados em ordem de preferência. Consulte a palavra-chave MACs em ssh_config(5) para obter mais informações.
-N Não execute um comando remoto. Isso é útil apenas para encaminhar portas. Consulte a
descrição de `SessionType` em ssh_config(5) para obter detalhes.
-n Redireciona stdin de /dev/null (na verdade, impede a leitura de stdin). Isso deve
ser usado quando o ssh é executado em segundo plano. Um truque comum é usar isso para executar programas X11 em uma máquina remota. Por exemplo, ssh -n shadows.cs.hut.fi emacs & iniciará um
emacs em shadows.cs.hut.fi, e a conexão X11 será encaminhada automaticamente por
um canal criptografado. O programa ssh será colocado em segundo plano. (Isso não
funciona se o ssh precisar pedir uma senha ou frase secreta; veja também a opção -f). Consulte
a descrição de `StdinNull` em ssh_config(5) para obter detalhes.
-O ctl_cmd
Controla um processo mestre de multiplexação de conexão ativo. Quando a opção -O é especificada, o argumento ctl_cmd é interpretado e passado para o processo mestre. Os comandos válidos são: “check” (verifique se o processo mestre está em execução), “forward” (solicite o encaminhamento sem execução de comando), “cancel” (cancele o encaminhamento), “proxy” (conecte-se a um
processo mestre de multiplexação em execução no modo proxy), “exit” (solicite ao mestre para sair) e
“stop” (solicite ao mestre para parar de aceitar solicitações de multiplexação adicionais).
-o option
Pode ser usado para fornecer opções no formato usado no arquivo de configuração. Isso é útil para especificar opções para as quais não existe uma flag de linha de comando separada. Para obter detalhes completos sobre as opções listadas abaixo e seus possíveis valores, consulte ssh_config(5).
AddKeysToAgent
AddressFamily
BatchMode
BindAddress
BindInterface
CASignatureAlgorithms
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CertificateFile
ChannelTimeout
CheckHostIP
Ciphers
ClearAllForwardings
Compression
ConnectTimeout
ConnectionAttempts
ControlMaster
ControlPath
ControlPersist
DynamicForward
EnableEscapeCommandline
EnableSSHKeysign
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host
HostKeyAlgorithms
HostKeyAlias
HostbasedAcceptedAlgorithms
HostbasedAuthentication
Hostname
IPQoS
IdentitiesOnly
IdentityAgent
IdentityFile
IgnoreUnknown
Include
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
LogVerbose
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
ObscureKeystrokeTiming
PKCS11Provider
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
RequiredRSASize
RevokedHostKeys
SecurityKeyProvider
SendEnv
ServerAliveCountMax
ServerAliveInterval
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
SyslogFacility
TCPKeepAlive
Tag
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
-P tag Especifica um nome de tag que pode ser usado para selecionar a configuração em ssh_config(5). Consulte
as palavras-chave Tag e Match em ssh_config(5) para obter mais informações.
-p port
Porta para conectar no host remoto. Isso pode ser especificado em uma base por host no arquivo de configuração.
-Q query_option
Consulta os algoritmos suportados por um dos seguintes recursos: cipher (algoritmos de cifra simétrica suportados), cipher-auth (algoritmos de cifra simétrica suportados que suportam criptografia autenticada), help (termos de consulta suportados para uso com a flag -Q), mac (códigos de integridade de mensagem suportados), kex (algoritmos de troca de chaves), kex-gss (algoritmos de troca de chaves GSSAPI), key (tipos de chaves), key-ca-sign (algoritmos de assinatura de CA válidos para certificados), key-cert (tipos de chaves de certificado), key-plain (tipos de chaves não-certificado), key-sig (todos os tipos de chaves e algoritmos de assinatura), protocol-version (versões de protocolo SSH suportadas) e sig (algoritmos de assinatura suportados). Alternativamente, qualquer palavra-chave de ssh_config(5) ou sshd_config(5) que recebe uma lista de algoritmos pode ser usada como um alias para o query_option correspondente.
-q Modo silencioso. Faz com que a maioria das mensagens de aviso e diagnóstico sejam suprimidas.
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
-R [bind_address:]port
Especifica que as conexões à porta TCP ou ao socket Unix fornecido no host remoto devem ser encaminhadas para o lado local.
Isso funciona alocando um socket para ouvir em uma porta TCP ou em um socket Unix no lado remoto. Sempre que uma conexão é feita a esta porta ou socket Unix, a conexão é encaminhada pelo canal seguro e uma conexão é feita da máquina local para um destino explícito especificado por host port hostport ou local_socket, ou, se nenhum destino explícito foi especificado, o ssh atuará como um proxy SOCKS 4/5 e encaminhará as conexões para os destinos solicitados pelo cliente SOCKS remoto.
Os encaminhamentos de porta também podem ser especificados no arquivo de configuração. Portas privilegiadas só podem ser encaminhadas quando o usuário faz login como root na máquina remota. Os endereços IPv6 podem ser especificados colocando o endereço entre colchetes.
Por padrão, os sockets de escuta TCP no servidor serão vinculados apenas à interface de loopback. Isso pode ser substituído especificando um bind_address. Um bind_address vazio ou o endereço ‘*’ indica que o socket remoto deve ouvir em todas as interfaces. Especificar um bind_address remoto só será bem-sucedido se a opção GatewayPorts do servidor estiver habilitada (veja sshd_config(5)).
Se o argumento de porta for ‘0’, a porta de escuta será alocada dinamicamente no servidor e relatada ao cliente em tempo de execução. Quando usado em conjunto com -O forward, a porta alocada será impressa na saída padrão.
-S ctl_path
Especifica o local de um socket de controle para compartilhamento de conexão ou a string "none" para desabilitar o compartilhamento de conexão. Consulte a descrição de ControlPath e ControlMaster em ssh_config(5) para obter detalhes.
-s Pode ser usado para solicitar a invocação de um subsistema no sistema remoto. Os subsistemas facilitam o uso do SSH como um transporte seguro para outros aplicativos (por exemplo, [sftp]({filename}../../sftp)(1)). O subsistema é especificado como o comando remoto. Consulte a descrição de SessionType em ssh_config(5) para obter detalhes.
-T Desabilita a alocação de pseudo-terminal.
-t Força a alocação de pseudo-terminal. Isso pode ser usado para executar programas arbitrários baseados em tela em uma máquina remota, o que pode ser muito útil, por exemplo, ao implementar serviços de menu. Várias opções -t forçam a alocação de tty, mesmo que o ssh não tenha um tty local.
-V Exibe o número da versão e sai.
-v Modo verboso. Faz com que o ssh imprima mensagens de depuração sobre seu progresso. Isso é útil para depurar problemas de conexão, autenticação e configuração. Várias opções -v aumentam a verbosidade. O máximo é 3.
-W host:port
Solicita que a entrada e saída padrão no cliente sejam encaminhadas para o host na porta especificada através do canal seguro. Implica -N, -T, ExitOnForwardFailure e ClearAllForwardings, embora estes possam ser substituídos no arquivo de configuração ou usando opções de linha de comando -o.
-w local_tun[:remote_tun]
Solicita o encaminhamento de dispositivo de túnel com os dispositivos tun(4) especificados entre o cliente (local_tun) e o servidor (remote_tun).
Os dispositivos podem ser especificados por ID numérico ou pela palavra-chave “any”, que usa o próximo dispositivo de túnel disponível. Se remote_tun não for especificado, ele assume o valor “any”. Consulte também as diretivas Tunnel e TunnelDevice em ssh_config(5).
Se a diretiva Tunnel não estiver definida, ela será definida como o modo de túnel padrão, que é “ponto a ponto”. Se um modo de encaminhamento Tunnel diferente for desejado, ele deve ser especificado antes de -w.
-X Habilita o encaminhamento X11. Isso também pode ser especificado por host no arquivo de configuração.
O encaminhamento X11 deve ser habilitado com cautela. Usuários com a capacidade de ignorar as permissões de arquivo no host remoto (para o banco de dados de autorização X do usuário) podem acessar a exibição X11 local através da conexão encaminhada. Um invasor pode então ser capaz de realizar atividades como monitoramento de pressionamento de teclas.
Por esse motivo, o encaminhamento X11 está sujeito a restrições da extensão X11 SECURITY por padrão. Consulte a opção ssh -Y e a diretiva ForwardX11Trusted em ssh_config(5) para obter mais informações.
(Específico do Debian: o encaminhamento X11 não está sujeito a restrições da extensão X11 SECURITY por padrão, porque muitos programas atualmente falham neste modo. Defina a opção ForwardX11Trusted como “no” para restaurar o comportamento upstream. Isso pode mudar no futuro, dependendo das melhorias do lado do cliente.)
-x Desabilita o encaminhamento X11.
-Y Habilita o encaminhamento X11 confiável. Os encaminhamentos X11 confiáveis não estão sujeitos aos controles de extensão X11 SECURITY.
(No Debian: na configuração padrão, esta opção é equivalente a -X, pois ForwardX11Trusted tem como padrão “yes”, conforme descrito acima. Defina a opção ForwardX11Trusted como “no” para restaurar o comportamento upstream. Isso pode mudar no futuro, dependendo das melhorias do lado do cliente.)
-y Envia informações de registro usando o módulo de sistema syslog(3). Por padrão, essas informações são enviadas para stderr.
O ssh pode obter dados de configuração adicionais de um arquivo de configuração por usuário e de um arquivo de configuração de sistema. O formato do arquivo e as opções de configuração são descritos em ssh_config(5).
AUTENTICAÇÃO
O cliente OpenSSH SSH suporta o protocolo SSH 2.
Os métodos disponíveis para autenticação são: autenticação baseada em GSSAPI, autenticação baseada em host, autenticação de chave pública, autenticação interativa por teclado e autenticação por senha. Os métodos de autenticação são tentados na ordem especificada acima, embora PreferredAuthentications possa ser usado para alterar a ordem padrão.
A autenticação baseada em host funciona da seguinte maneira: Se a máquina da qual o usuário faz login estiver listada em /etc/hosts.equiv ou /etc/ssh/shosts.equiv na máquina remota, o usuário não for root e os nomes de usuário forem os mesmos em ambos os lados, ou se os arquivos ~/.rhosts ou ~/.shosts existirem no diretório home do usuário na máquina remota e contiverem uma linha contendo o nome da máquina cliente e o nome do usuário nessa máquina, o usuário é considerado para login. Além disso, o servidor deve ser capaz de verificar a chave de host do cliente (veja a descrição de /etc/ssh/ssh_known_hosts e ~/.ssh/known_hosts, abaixo) para que o login seja permitido. Este método de autenticação fecha brechas de segurança devido a spoofing de IP, DNS e roteamento. [Observação para o administrador: /etc/hosts.equiv, ~/.rhosts e o protocolo rlogin/rsh em geral são inerentemente inseguros e devem ser desativados se a segurança for desejada.]
A autenticação por chave pública funciona da seguinte maneira: O esquema é baseado em criptografia de chave pública, usando criptossistemas onde a criptografia e a descriptografia são feitas usando chaves separadas, e é impraticável derivar a chave de descriptografia da chave de criptografia. A ideia é que cada usuário crie um par de chaves pública/privada para fins de autenticação. O servidor conhece a chave pública, e apenas o usuário conhece a chave privada. O ssh implementa automaticamente o protocolo de autenticação de chave pública, usando um dos algoritmos ECDSA, Ed25519 ou RSA.
O arquivo ~/.ssh/authorized_keys lista as chaves públicas que são permitidas para login. Quando o usuário faz login, o programa ssh informa ao servidor qual par de chaves ele gostaria de usar para autenticação. O cliente prova que tem acesso à chave privada e o servidor verifica se a chave pública correspondente está autorizada a aceitar a conta.
O servidor pode informar ao cliente sobre erros que impediram a autenticação por chave pública de ter sucesso após a autenticação ser concluída usando um método diferente. Estes podem ser visualizados aumentando o LogLevel para DEBUG ou superior (por exemplo, usando a flag -v).
O usuário cria seu par de chaves executando ssh-keygen(1). Isso armazena a chave privada em ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (ECDSA hospedado pelo autenticador), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (Ed25519 hospedado pelo autenticador) ou ~/.ssh/id_rsa (RSA) e armazena a chave pública em ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (ECDSA hospedado pelo autenticador), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (Ed25519 hospedado pelo autenticador) ou ~/.ssh/id_rsa.pub (RSA) no diretório home do usuário. O usuário deve então copiar a chave pública para ~/.ssh/authorized_keys em seu diretório home na máquina remota. O arquivo authorized_keys corresponde ao arquivo convencional ~/.rhosts e tem uma chave por linha, embora as linhas possam ser muito longas. Depois disso, o usuário pode fazer login sem fornecer a senha.
Uma variação da autenticação por chave pública está disponível na forma de autenticação por certificado: em vez de um conjunto de chaves pública/privada, certificados assinados são usados. Isso tem a vantagem de que uma única autoridade de certificação confiável pode ser usada em vez de muitas chaves pública/privada. Consulte a seção CERTIFICADOS de ssh-keygen(1) para obter mais informações.
A maneira mais conveniente de usar a autenticação por chave pública ou certificado pode ser com um agente de autenticação. Consulte ssh-agent(1) e (opcionalmente) o diretivo AddKeysToAgent em ssh_config(5) para obter mais informações.
A autenticação interativa por teclado funciona da seguinte maneira: o servidor envia um texto de "desafio" arbitrário e solicita uma resposta, possivelmente várias vezes. Exemplos de autenticação interativa por teclado incluem a autenticação BSD (consulte login.conf(5)) e PAM (alguns sistemas que não são OpenBSD).
Finalmente, se outros métodos de autenticação falharem, o ssh solicita ao usuário uma senha. A senha é enviada para o host remoto para verificação; no entanto, como todas as comunicações são criptografadas, a senha não pode ser vista por alguém que esteja ouvindo a rede.
O ssh mantém e verifica automaticamente um banco de dados contendo a identificação de todos os hosts com os quais já foi usado. As chaves de host são armazenadas em ~/.ssh/known_hosts no diretório inicial do usuário. Além disso, o arquivo /etc/ssh/ssh_known_hosts é verificado automaticamente para hosts conhecidos. Quaisquer novos hosts são adicionados automaticamente ao arquivo do usuário. Se a identificação de um host mudar, o ssh avisa sobre isso e desativa a autenticação por senha para evitar a falsificação do servidor ou ataques man-in-the-middle, que poderiam ser usados para contornar a criptografia. A opção StrictHostKeyChecking pode ser usada para controlar os logins em máquinas cuja chave de host não é conhecida ou mudou.
Quando a identidade do usuário é aceita pelo servidor, o servidor executa o comando fornecido em uma sessão não interativa ou, se nenhum comando tiver sido especificado, faz login na máquina e fornece ao usuário um shell normal como uma sessão interativa. Toda a comunicação com o comando ou shell remoto será criptografada automaticamente.
Se uma sessão interativa for solicitada, o ssh por padrão solicitará apenas um pseudo-terminal (pty) para sessões interativas quando o cliente tiver um. As flags -T e -t podem ser usadas para substituir esse comportamento.
Se um pseudo-terminal foi alocado, o usuário pode usar os caracteres de escape notados abaixo.
Se nenhum pseudo-terminal foi alocado, a sessão é transparente e pode ser usada para transferir dados binários de forma confiável. Na maioria dos sistemas, definir o caractere de escape como "nenhum" também tornará a sessão transparente, mesmo que um tty seja usado.
A sessão é encerrada quando o comando ou shell na máquina remota é finalizado e todas as conexões X11 e TCP são fechadas.
CARACTERES DE ESCAPE
Quando um pseudo-terminal foi solicitado, o ssh suporta várias funções através do uso de um caractere de escape.
Um único caractere de til pode ser enviado como ~~ ou seguindo o til com um caractere diferente daqueles descritos abaixo. O caractere de escape deve sempre seguir uma nova linha para ser interpretado como especial. O caractere de escape pode ser alterado nos arquivos de configuração usando a diretiva de configuração EscapeChar ou na linha de comando usando a opção -e.
Os escapes suportados (assumindo o padrão ‘\~’) são:
~. Desconectar.
~^Z Colocar o ssh em segundo plano.
~# Listar as conexões encaminhadas.
~& Colocar o ssh em segundo plano no logout quando estiver aguardando que as conexões encaminhadas / sessões X11 sejam encerradas.
~? Exibir uma lista de caracteres de escape.
~B Enviar um BREAK para o sistema remoto (útil apenas se o par suportar).
~C Abrir linha de comando. Atualmente, isso permite a adição de encaminhamentos de porta usando as opções -L, -R e -D (veja acima). Também permite o cancelamento de encaminhamentos de porta existentes com -KL[bind_address:]port para encaminhamento local, -KR[bind_address:]port para encaminhamento remoto e -KD[bind_address:]port para encaminhamento de porta dinâmico. !command permite que o usuário execute um comando local se a opção PermitLocalCommand estiver habilitada no ssh_config(5). Ajuda básica está disponível, usando a opção -h.
~R Solicitar a renegociação da conexão (útil apenas se o par suportar).
~V Diminuir a verbosidade (LogLevel) quando os erros estão sendo gravados no stderr.
~v Aumentar a verbosidade (LogLevel) quando os erros estão sendo gravados no stderr.
ENCAMINHAMENTO TCP
O encaminhamento de conexões TCP arbitrárias por meio de um canal seguro pode ser especificado na linha de comando ou em um arquivo de configuração. Uma possível aplicação do encaminhamento TCP é uma conexão segura com um servidor de e-mail; outra é contornar firewalls.
No exemplo abaixo, vemos como criptografar a comunicação para um cliente IRC, mesmo que o servidor IRC ao qual ele se conecta não suporte diretamente a comunicação criptografada. Isso funciona da seguinte forma: o usuário se conecta ao host remoto usando ssh, especificando as portas a serem usadas para encaminhar a conexão. Depois disso, é possível iniciar o programa localmente, e o ssh criptografará e encaminhará a conexão para o servidor remoto.
O exemplo a seguir cria um túnel para uma sessão IRC do cliente para um servidor IRC em “server.example.com”, unindo-se ao canal “#users”, apelido “pinky”, usando a porta IRC padrão, 6667
$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1
A opção -f coloca o ssh em segundo plano e o comando remoto “sleep 10” é especificado para permitir um período de tempo (10 segundos, no exemplo) para iniciar o programa que usará o túnel. Se nenhuma conexão for feita dentro do tempo especificado, o ssh será encerrado.
REDIRECIONAMENTO X11
Se a variável ForwardX11 estiver definida como “yes” (ou consulte a descrição das opções -X, -x e -Y acima) e o usuário estiver usando X11 (a variável de ambiente DISPLAY estiver definida), a conexão com o servidor X11 será automaticamente redirecionada para o lado remoto de forma que qualquer programa X11 iniciado no shell (ou comando) seja executado através do canal criptografado, e a conexão com o servidor X real será feita a partir da máquina local. O usuário não deve definir a variável DISPLAY manualmente.
O redirecionamento de conexões X11 pode ser configurado na linha de comando ou em arquivos de configuração.
O valor de DISPLAY definido pelo ssh apontará para a máquina do servidor, mas com um número de exibição maior que zero. Isso é normal e ocorre porque o ssh cria um servidor X “proxy” na máquina do servidor para encaminhar as conexões através do canal criptografado.
O ssh também configurará automaticamente os dados Xauthority na máquina do servidor. Para esse fim, ele gerará um cookie de autorização aleatório, armazenará no Xauthority no servidor e verificará se as conexões redirecionadas carregam este cookie e o substituirá pelo cookie real quando a conexão for aberta. O cookie de autenticação real nunca é enviado para a máquina do servidor (e nenhum cookie é enviado em texto não criptografado).
Se a variável ForwardAgent estiver definida como “yes” (ou consulte a descrição das opções -A e -a acima) e o usuário estiver usando um agente de autenticação, a conexão com o agente será automaticamente redirecionada para o lado remoto.
VERIFICAÇÃO DE CHAVES DE HOST
Ao se conectar a um servidor pela primeira vez, uma impressão digital da chave pública do servidor é apresentada ao usuário (a menos que a opção StrictHostKeyChecking tenha sido desabilitada). As impressões digitais podem ser determinadas usando ssh-keygen(1):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
Se a impressão digital já for conhecida, ela pode ser comparada e a chave pode ser aceita ou rejeitada. Se apenas impressões digitais (MD5) legadas para o servidor estiverem disponíveis, a opção ssh-keygen(1) -E pode ser usada para reduzir o algoritmo de impressão digital para corresponder.
Devido à dificuldade de comparar chaves de host apenas olhando para as strings de impressão digital, também há suporte para comparar chaves de host visualmente, usando arte aleatória. Ao definir a opção VisualHostKey como “yes”, um pequeno gráfico ASCII é exibido em cada login em um servidor, não importa se a sessão em si é interativa ou não. Ao aprender o padrão que um servidor conhecido produz, um usuário pode facilmente descobrir que a chave de host foi alterada quando um padrão completamente diferente é exibido. Como esses padrões não são inequívocos, um padrão que parece semelhante ao padrão memorizado dá apenas uma boa probabilidade de que a chave de host seja a mesma, não uma prova garantida.
Para obter uma lista das impressões digitais juntamente com suas artes aleatórias para todos os hosts conhecidos, o seguinte comando pode ser usado:
$ ssh-keygen -lv -f ~/.ssh/known_hosts
Se a impressão digital for desconhecida, um método alternativo de verificação está disponível: as impressões digitais SSH verificadas por DNS. Um registro de recurso (RR) adicional, SSHFP, é adicionado a um arquivo de zona e o cliente que se conecta pode corresponder a impressão digital com a chave apresentada.
Neste exemplo, estamos conectando um cliente a um servidor, “host.example.com”. Os registros de recurso SSHFP devem ser adicionados primeiro ao arquivo de zona para host.example.com:
$ ssh-keygen -r host.example.com.
As linhas de saída devem ser adicionadas ao arquivo de zona. Para verificar se a zona está respondendo a consultas de impressão digital:
$ dig -t SSHFP host.example.com
Finalmente, o cliente se conecta:
$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Impressão digital da chave do host correspondente encontrada no DNS. Você tem certeza de que deseja continuar a conexão (sim/não)?
Consulte a opção VerifyHostKeyDNS em ssh_config(5) para obter mais informações.
REDES PRIVADAS VIRTUAIS BASEADAS EM SSH
ssh contém suporte para tunelamento de Rede Privada Virtual (VPN) usando o dispositivo de rede tun(4), permitindo que duas redes sejam unidas com segurança. A opção de configuração sshd\_config(5) PermitTunnel controla se o servidor suporta isso e em que nível (tráfego da camada 2 ou 3).
O seguinte exemplo conectaria a rede do cliente 10.0.50.0/24 com a rede remota 10.0.99.0/24 usando uma conexão ponto a ponto de 10.1.1.1 para 10.1.1.2, desde que o servidor SSH em execução no gateway para a rede remota, em 192.168.1.15, permita isso.
No cliente:
# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2
No servidor:
# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1
O acesso do cliente pode ser ajustado com mais precisão por meio do arquivo /root/.ssh/authorized_keys (veja abaixo) e da opção do servidor PermitRootLogin. A seguinte entrada permitiria conexões no dispositivo tun(4) 1 do usuário “jane” e no dispositivo tun 2 do usuário “john”, se PermitRootLogin estiver definido como “forced-commands-only”:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
Como uma configuração baseada em SSH envolve uma quantidade razoável de sobrecarga, pode ser mais adequada para configurações temporárias, como para VPNs sem fio. VPNs mais permanentes são melhor fornecidas por ferramentas como ipsecctl(8) e isakmpd(8).
AMBIENTE
normalmente, o ssh define as seguintes variáveis de ambiente:
DISPLAY A variável DISPLAY indica a localização do servidor X11. Ele é definido automaticamente por ssh para apontar para um valor no formato “hostname:n”, onde
“hostname” indica o host onde o shell é executado e ‘n’ é um inteiro ≥
ssh usa este valor especial para encaminhar as conexões X11 através do canal seguro. O usuário normalmente não deve definir DISPLAY explicitamente, pois isso tornará a conexão X11 insegura (e exigirá que o usuário copie manualmente quaisquer cookies de autorização necessários).
HOME Define como o caminho do diretório pessoal do usuário.
LOGNAME Sinônimo de USER; definido para compatibilidade com sistemas que usam esta variável.
MAIL Define como o caminho da caixa de correio do usuário.
PATH Define como o PATH padrão, conforme especificado ao compilar o ssh.
SSH_ASKPASS Se o ssh precisar de uma senha, ele lerá a senha do terminal atual, caso tenha sido executado a partir de um terminal. Se o ssh não tiver um terminal associado a ele, mas DISPLAY e SSH_ASKPASS estiverem definidos, ele executará o programa especificado por SSH_ASKPASS e abrirá uma janela X11 para ler a senha. Isso é particularmente útil ao chamar o ssh a partir de um script .xsession ou relacionado. (Observe que, em algumas máquinas, pode ser necessário redirecionar a entrada de /dev/null para que isso funcione.)
SSH_ASKPASS_REQUIRE Permite um controle mais preciso sobre o uso de um programa askpass. Se esta variável estiver definida como “never”, o ssh nunca tentará usar um. Se estiver definida como “prefer”, o ssh preferirá usar o programa askpass em vez do TTY ao solicitar senhas. Finalmente, se a variável estiver definida como “force”, o programa askpass será usado para toda entrada de senha, independentemente de DISPLAY estar definido ou não.
SSH_AUTH_SOCK Identifica o caminho de um socket de domínio Unix usado para se comunicar com o agente.
SSH_CONNECTION Identifica as extremidades cliente e servidor da conexão. A variável contém quatro valores separados por espaços: endereço IP do cliente, número da porta do cliente, endereço IP do servidor e número da porta do servidor.
SSH_ORIGINAL_COMMAND Esta variável contém a linha de comando original se um comando forçado for executado. Pode ser usado para extrair os argumentos originais.
SSH_TTY Esta variável é definida com o nome do tty (caminho para o dispositivo) associado ao shell ou comando atual. Se a sessão atual não tiver um tty, esta variável não será definida.
SSH_TUNNEL Opcionalmente definido por [sshd]({filename}../../sshd)(8) para conter os nomes das interfaces atribuídas se o encaminhamento de túnel foi solicitado pelo cliente.
SSH_USER_AUTH Opcionalmente definido por [sshd]({filename}../../sshd)(8), esta variável pode conter um caminho para um arquivo que lista os métodos de autenticação usados com sucesso quando a sessão foi estabelecida, incluindo quaisquer chaves públicas que foram usadas.
TZ Esta variável é definida para indicar o fuso horário atual, se foi definido quando o daemon foi iniciado (ou seja, o daemon passa o valor para novas conexões).
USER Define como o nome do usuário que está fazendo login.
Além disso, o ssh lê ~/.ssh/environment e adiciona linhas no formato “VARNAME=value” ao ambiente se o arquivo existir e os usuários tiverem permissão para alterar seu ambiente. Para obter mais informações, consulte a opção PermitUserEnvironment em sshd_config(5).
ARQUIVOS
~/.rhosts
Este arquivo é usado para autenticação baseada em host (veja acima). Em algumas máquinas, este arquivo pode precisar ser legível por todos se o diretório pessoal do usuário estiver em uma partição NFS, porque o sshd(8) o lê como root. Além disso, este arquivo deve ser de propriedade do usuário e não deve ter permissões de gravação para mais ninguém. A permissão recomendada para a maioria das máquinas é leitura/gravação para o usuário e inacessível para outros.
~/.shosts
Este arquivo é usado da mesma forma que .rhosts, mas permite a autenticação baseada em host sem permitir o login com rlogin/rsh.
~/.ssh/
Este diretório é o local padrão para todas as configurações e informações de autenticação específicas do usuário. Não há nenhum requisito geral para manter todo o conteúdo deste diretório em segredo, mas as permissões recomendadas são leitura/gravação/execução para o usuário e inacessível para outros.
~/.ssh/authorized_keys
Lista as chaves públicas (ECDSA, Ed25519, RSA) que podem ser usadas para fazer login como este usuário. O formato deste arquivo é descrito na página do manual sshd(8). Este arquivo não é altamente sensível, mas as permissões recomendadas são leitura/gravação para o usuário e inacessível para outros.
~/.ssh/config
Este é o arquivo de configuração por usuário. O formato do arquivo e as opções de configuração são descritos em ssh_config(5). Devido ao potencial de abuso, este arquivo deve ter permissões estritas: leitura/gravação para o usuário e não gravável por outros. Pode ser gravável pelo grupo, desde que o grupo em questão contenha apenas o usuário.
~/.ssh/environment
Contém definições adicionais para variáveis de ambiente; veja “AMBIENTE”, acima.
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Contém a chave privada para autenticação. Esses arquivos contêm dados confidenciais e devem ser legíveis pelo usuário, mas inacessíveis a outros (leitura/gravação/execução). O ssh simplesmente ignorará um arquivo de chave privada se ele for acessível a outros. É possível especificar uma senha ao gerar a chave, que será usada para criptografar a parte confidencial deste arquivo usando AES-128.
~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
Contém a chave pública para autenticação. Esses arquivos não são confidenciais e podem (mas não precisam) ser legíveis por qualquer pessoa.
~/.ssh/known_hosts
Contém uma lista de chaves de host para todos os hosts nos quais o usuário fez login que não estão já na lista de chaves de host conhecida do sistema. Consulte sshd(8) para obter mais detalhes sobre o formato deste arquivo.
~/.ssh/rc
Os comandos neste arquivo são executados pelo ssh quando o usuário faz login, logo antes de o shell (ou comando) do usuário ser iniciado. Consulte a página do manual sshd(8) para obter mais informações.
/etc/hosts.equiv
Este arquivo é para autenticação baseada em host (veja acima). Ele deve ser gravável apenas pelo usuário root.
/etc/ssh/shosts.equiv
Este arquivo é usado exatamente da mesma forma que hosts.equiv, mas permite a autenticação baseada em host sem permitir o login com rlogin/rsh.
/etc/ssh/ssh_config
Arquivo de configuração do sistema. O formato do arquivo e as opções de configuração são descritas em ssh_config(5).
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
Esses arquivos contêm as partes privadas das chaves de host e são usados para autenticação baseada em host.
/etc/ssh/ssh_known_hosts
Lista do sistema de chaves de host conhecidas. Este arquivo deve ser preparado pelo administrador do sistema para conter as chaves públicas de host de todas as máquinas da organização. Ele deve ser legível por todos os usuários. Veja sshd(8) para mais detalhes sobre o formato deste arquivo.
/etc/ssh/sshrc
Os comandos neste arquivo são executados pelo ssh quando o usuário faz login, imediatamente antes do início do shell (ou comando) do usuário. Veja a página do manual sshd(8) para obter mais informações.
STATUS DE SAÍDA ssh sai com o status de saída do comando remoto ou com 255 se ocorrer um erro.
VEJA TAMBÉM scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)
PADRÕES S. Lehtinen e C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, Janeiro 200.
T. Ylonen e C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, Janeiro de 2006.
T. Ylonen e C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, Janeiro de 2006.
T. Ylonen e C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, Janeiro 200.
T. Ylonen e C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, Janeiro de 2006.
J. Schlyter e W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, Janeiro de 2006.
F. Cusack e M. Forssen, Generic Message Exchange Authentication for the Secure Shell (SSH) Protocol, RFC 4256, Janeiro de 2006.
J. Galbraith e P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, Janeiro de 2006.
M. Bellare, T. Kohno e C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, Janeiro de 2006.
B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, Janeiro de 2006.
M. Friedl, N. Provos e W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, Março de 2006.
J. Galbraith e R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, Novembro 200.
D. Stebila e J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, Dezembro de 2009.
A. Perrig e D. Song, Visualização de Hash: uma Nova Técnica para Melhorar a Segurança no Mundo Real, 1999,
Workshop Internacional sobre Técnicas Criptográficas e Comércio Eletrônico (CrypTEC '99).
AUTORES
O OpenSSH é um derivado da versão original e gratuita do ssh 1.2.12 de Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt e Dug Song removeram muitos bugs, reintroduziram recursos mais recentes e criaram o OpenSSH. Markus Friedl contribuiu com o suporte para as versões 1.5 e 2.0 do protocolo SSH.