O que é SSH e como ele funciona?

O que é SSH?

SSH (shell seguro) é um protocolo para iniciar sessão num computador remoto e executar comandos através de uma ligação encriptada. O que escreve é enviado para a máquina remota, o resultado volta para o seu computador e ninguém que monitorize a rede entre os dois consegue ler nenhum dos lados. Um servidor Linux alugado não tem ecrã nem teclado ligados, por isso o SSH é a forma de utilizar a máquina.

O nome refere-se a duas coisas. SSH é o protocolo, descrito nas RFC 4251 a RFC 4254. OpenSSH é o programa que o implementa e é utilizado por praticamente todos os servidores Linux e quase todos os computadores portáteis. Quando alguém diz "entrar no servidor por SSH", quer dizer que o programa cliente ssh na sua máquina comunica com o programa servidor sshd na outra extremidade.

O problema que o SSH foi criado para resolver

O login remoto é muito anterior ao SSH. O Telnet abria uma ligação TCP simples à porta 23 e enviava cada byte exatamente como era introduzido. Nada era encriptado, incluindo a sua palavra-passe. Qualquer pessoa que conseguisse ver o tráfego podia lê-lo: alguém na mesma rede do escritório ou o operador de qualquer router ao longo do percurso. A família rlogin tinha a mesma vulnerabilidade e confiava no nome da máquina cliente. Isso significa confiar no que quer que a rede afirmasse que esse nome era.

Tatu Ylönen escreveu o primeiro SSH em 1995, na Helsinki University of Technology, depois de um ataque de captura de palavras-passe na rede da universidade. O design mantém a parte útil do Telnet, um fluxo de bytes entre o seu terminal e uma shell remota, e acrescenta as duas coisas para as quais o Telnet não tem resposta: a encriptação do fluxo e a prova de que o servidor do outro lado é realmente aquele ao qual pretendia ligar-se.

É fácil não dar atenção à segunda parte, mas ela representa metade do que é o SSH. A encriptação, por si só, não o protegeria. Uma máquina intermediária poderia aceitar a sua ligação, encriptá-la corretamente, ler tudo o que enviasse e encaminhá-lo para o servidor real. O SSH impede isso ao atribuir a cada servidor uma identidade permanente, chamada host key, e ao verificá-la em todas as ligações.

Como funciona o modelo cliente-servidor

Existem dois programas. No servidor, sshd é executado continuamente e aguarda ligações. No seu computador, ssh estabelece essas ligações. São programas separados, com ficheiros de configuração separados, e confundir os dois é o motivo mais comum para uma alteração não produzir efeito.

• O servidor lê /etc/ssh/sshd_config. É neste ficheiro que o início de sessão por palavra-passe é desativado e a porta de escuta é definida.
• O cliente lê /etc/ssh/ssh_config para obter as predefinições do sistema e, em seguida, ~/.ssh/config para obter as suas próprias definições por host.

No Debian e no Ubuntu, a unidade do serviço chama-se ssh. No RHEL, Rocky e Fedora, chama-se sshd. As versões recentes do Ubuntu instalam-no com ativação por socket. Por isso, systemctl status ssh pode indicar inactive (dead) quando a máquina está perfeitamente acessível, porque ssh.socket é a unidade que faz a escuta e inicia o serviço conforme necessário.

O cliente não tem de ser OpenSSH. O PuTTY no Windows, o Termius num telefone e o suporte remoto integrado nos editores usam o mesmo protocolo para o mesmo sshd. O Windows 10 e 11 também incluem o cliente OpenSSH, por isso ssh you@server funciona no PowerShell sem instalar nada.

Por que o SSH usa a porta 22?

Uma porta é um número que informa ao kernel a que programa em escuta pertence uma ligação recebida. As portas no Linux funcionam da mesma forma para todos os serviços. O SSH usa a porta 22 porque a IANA lhe atribuiu esse número em 1995. Ylönen pediu um número livre junto dos protocolos que o SSH foi criado para substituir: a porta 21 era usada pelo FTP, a 23 pelo telnet e a 22 estava livre.

Como a porta 22 é a predefinida, tudo assume que ela será usada. O seu remote do Git, o script de cópias de segurança e o painel de controlo do seu fornecedor tentam primeiro a porta 22. Todos os scanners automatizados na Internet fazem o mesmo. Um servidor novo com o início de sessão por palavra-passe ativado começa a acumular linhas como esta em /var/log/auth.log poucos minutos depois do arranque:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Esse tráfego é constante e não é dirigido especificamente a si. Mudar sshd para a porta 2222 elimina a maioria dessas linhas, porque os scanners percorrem toda a Internet na porta 22 em vez de analisarem o seu servidor. Isso não torna a máquina mais difícil de comprometer para alguém que a esteja realmente a analisar. Considere a mudança de porta apenas uma redução de ruído.

Pode observar a resposta do servidor antes de iniciar sessão:

nc 203.0.113.10 22

No Ubuntu 24.04, isso apresenta algo semelhante a SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. O banner é enviado em texto simples, antes de existir qualquer encriptação, porque ambos os lados precisam dele para acordar a versão do protocolo. Prima Ctrl+C para fechar a ligação.

O que acontece na rede quando estabelece a ligação

A sequência abaixo mostra o que um ssh you@server faz antes de apresentar um prompt.

1. O cliente resolve o hostname para um endereço IP e abre uma ligação TCP à porta 22.
2. Ambos os lados enviam o respetivo banner de versão em texto simples.
3. Ambos os lados enviam as listas de algoritmos compatíveis: troca de chaves, cifra, autenticação de mensagens e compressão. Ainda em texto simples. É escolhida a opção mais forte que ambos conhecem.
4. É executada a troca de chaves. O OpenSSH atual prefere curve25519-sha256. No fim, ambas as extremidades têm o mesmo segredo partilhado, sem que esse segredo atravesse a rede. Assim, alguém que tenha gravado toda a conversa não consegue calculá-lo posteriormente.
5. O servidor assina o resultado dessa troca com a sua chave privada de host. O cliente verifica a assinatura comparando-a com a chave pública de host que tem guardada. Esta é a etapa que impede uma máquina colocada no meio de se fazer passar pelo seu servidor.
6. A cifra é ativada. chacha20-poly1305@openssh.com é a cifra predefinida no OpenSSH atual.
7. Só agora o cliente autentica o utilizador, com uma palavra-passe ou uma chave. O nome de utilizador e a palavra-passe circulam dentro do canal cifrado.
8. O cliente abre um canal e pede uma shell.

A ordem desta lista é toda a diferença em relação ao telnet. A autenticação ocorre depois de o canal ser cifrado e de o servidor provar a sua identidade. Por isso, não existe um momento em que a sua palavra-passe circule pela rede em texto simples.

Quem monitoriza a rede continua a obter alguma informação. Vê o seu endereço IP, o endereço IP do servidor, a porta 22, ambos os banners de versão em texto simples e o momento e o tamanho aproximado de cada pacote. Não vê o seu nome de utilizador, a sua palavra-passe, os seus comandos nem a respetiva saída. A consulta do hostname no passo 1 não faz parte do SSH e normalmente não é privada. Por isso, a consulta DNS que resolve o nome do seu servidor pode revelar a máquina à qual está prestes a ligar-se, embora a sessão permaneça protegida.

A chave de host e o aviso da impressão digital na primeira ligação

Quando openssh-server é instalado, gera pares de chaves de host para a máquina e grava-os em /etc/ssh/, por exemplo ssh_host_ed25519_key e ssh_host_ed25519_key.pub. A parte privada nunca sai do servidor. A parte pública é a identidade do servidor. É contra ela que a assinatura do passo 5 é verificada.

Na primeira ligação a um servidor novo, o cliente não tem nenhuma chave para comparar. Por isso, pergunta:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

A impressão digital é um hash SHA256 da chave pública de host, apresentado em base64 para ser suficientemente curto e permitir uma comparação visual. Escrever yes grava essa chave em ~/.ssh/known_hosts na sua própria máquina. Em todas as ligações seguintes ao mesmo endereço, o cliente compara a chave apresentada pelo servidor com a chave armazenada. Quando coincidem, nada é apresentado e a ligação prossegue diretamente para a linha de comandos.

Este modelo chama-se confiança na primeira utilização. É importante compreender o risco envolvido. A primeira ligação é o único momento em que fica desprotegido, porque está a aceitar uma chave que nunca viu. Para eliminar essa lacuna, obtenha a impressão digital por outro meio e compare-a. A maioria dos fornecedores apresenta-a no resultado do arranque mostrado na consola Web. Também pode apresentá-la diretamente no servidor:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Esse comando apresenta a mesma cadeia SHA256: que aparece no aviso. A opção [fingerprint] existe precisamente para este fim: cole a impressão digital esperada, e o cliente só prossegue se ela coincidir com a apresentada pelo servidor.

No Debian e no Ubuntu, known_hosts aplica hashing por predefinição. Por isso, o ficheiro contém linhas que começam por |1|, em vez de nomes de host legíveis. Execute ssh-keygen -F 203.0.113.10 para localizar a entrada de um host.

Por que o SSH informa que a chave do host mudou?

Mais cedo ou mais tarde, você verá este bloco de texto:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

A mensagem termina com Host key verification failed., e o cliente recusa a conexão. Ela também exibe Password authentication is disabled to avoid man-in-the-middle attacks., porque digitar sua senha em uma máquina desconhecida é exatamente o risco que esta verificação existe para evitar.

A mensagem parece indicar uma emergência, mas na maioria das vezes não indica. As causas comuns são:

• Você recriou ou reinstalou o servidor, então sshd gerou novas chaves de host na primeira inicialização. Esta é, de longe, a causa mais comum.
• Você destruiu uma VPS e criou outra, e o provedor atribuiu o endereço IP antigo à nova máquina.
• Você está se conectando por meio de um encaminhamento ou balanceador de carga que agora encaminha a conexão para outra máquina de backend.
• Alguém realmente está interceptando a conexão.

Identifique a causa antes de remover qualquer coisa. Se você reinstalou a máquina dez minutos atrás, a causa é óbvia. Se nada mudou do seu lado, pare e investigue, porque este aviso indica que a verificação está funcionando corretamente. Quando tiver certeza, remova a entrada obsoleta e conecte-se novamente:

ssh-keygen -R 203.0.113.10

Na próxima conexão, o prompt da impressão digital será exibido novamente. Assim, você terá uma nova oportunidade de compará-la com a impressão digital no console do provedor.

Login por palavra-passe versus login por chave

A autenticação por palavra-passe envia a sua palavra-passe através do canal já cifrado, e sshd compara-a com a base de dados de contas, normalmente através do PAM (módulos de autenticação conectáveis). Não requer preparação. Por isso, um fornecedor pode entregar-lhe um servidor novo apenas com uma palavra-passe de root.

A fragilidade não está na cifragem. Está no facto de uma palavra-passe ser um segredo curto, ser enviada para o servidor em cada login e a porta 22 ser alvo de tentativas de adivinhação continuamente por máquinas que nunca param.

A autenticação por chave pública funciona de forma diferente. Cria um par de chaves na sua própria máquina. A parte pública é colocada em ~/.ssh/authorized_keys na sua conta do servidor. A parte privada permanece no seu portátil e nunca é transmitida. Para iniciar sessão, o cliente assina um conjunto de dados que inclui o identificador da sessão obtido durante a troca de chaves, e o servidor verifica essa assinatura com a chave pública que já possui. Como os dados assinados estão associados a esta sessão específica, uma assinatura capturada não tem qualquer utilidade contra outra sessão.

Tenha atenção à direção, porque é comum invertê-la e isso é perigoso: a chave pública fica no servidor e a chave privada permanece consigo. Uma chave privada copiada para um servidor deixa de ser uma chave em que pode confiar.

O login por chave também tem os seus próprios modos de falha. sshd ignora as chaves quando as permissões do ficheiro são demasiado permissivas e regista essa informação no log do servidor:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

O cliente apenas lhe mostra Permission denied (publickey), que é a mesma mensagem para uma dúzia de causas diferentes. Por isso, vale a pena aprender a interpretar corretamente os erros de chave pública antes de ficar sem acesso. O trabalho prático de criar chaves, protegê-las com uma passphrase e carregá-las num agent está descrito em gestão de chaves SSH. Desativar o login por palavra-passe sem ficar sem acesso está descrito em proteger o SSH num VPS.

SFTP, scp e encaminhamento de portas usam a mesma ligação

Esta é a ideia que permite compreender o resto do SSH. A autenticação abre uma ligação encriptada, e essa ligação pode transportar vários canais independentes ao mesmo tempo. Uma shell é apenas um dos vários tipos de canal.

• Uma shell remota. ssh you@server abre um canal de sessão e pede uma shell interativa.
• Um comando único. ssh you@server uptime abre um canal, executa um comando, apresenta o resultado e termina.
• SFTP. O cliente pede a sshd para iniciar o seu subsistema sftp, e a transferência de ficheiros decorre dentro da mesma ligação. SFTP é um protocolo de transferência de ficheiros que usa SSH e não partilha o desenho do FTP. O protocolo que corresponde ao FTP com encriptação adicionada chama-se FTPS e não tem relação com SFTP.
• scp. Copia ficheiros usando o mesmo início de sessão. Desde o OpenSSH 9.0, lançado em 2022, scp usa o protocolo SFTP internamente por predefinição.
• Encaminhamento de portas. ssh -L 8080:localhost:80 you@server transforma a porta 8080 no seu portátil numa porta de entrada para a porta 80 no servidor, transportada dentro da ligação encriptada. -R encaminha no sentido inverso, e -D 1080 transforma a sessão num proxy SOCKS.
• Git. Um remoto como git@github.com:user/repo.git corresponde a um início de sessão SSH cujo lado remoto executa um processador de comandos em vez de uma shell.
• rsync e Ansible também são clientes SSH. Abrem um canal, executam uma operação e leem o resultado.

Todos os itens dessa lista usam a mesma porta, a mesma verificação da chave do host e as mesmas credenciais. Por isso, configurar a autenticação por chave uma vez compensa imediatamente o esforço: cada uma dessas ferramentas herda essa configuração. É também por isso que o mesmo ficheiro ~/.ssh/config que simplifica os seus inícios de sessão é o ficheiro que permite escalar quando está a gerir vários servidores Linux a partir de um portátil.

O que o SSH não faz

• Não torna o servidor seguro. O SSH protege o caminho até à porta. A porta continua exposta e haverá sempre tentativas de autenticação. Bloquear tentativas de início de sessão repetidas com fail2ban controla o volume, e a autenticação apenas com chaves elimina o segredo que estão a tentar adivinhar.
• Não protege contra a sua própria máquina. Qualquer pessoa com acesso ao seu portátil tem a sua chave privada e o seu agente carregado.
• Não oculta que está a utilizar SSH. O número da porta e o banner de versão em texto simples revelam isso.
• Não abrange o que acontece antes de a ligação existir. A resolução do nome e a sua decisão sobre qual endereço é de confiança ocorrem primeiro.

Para onde seguir

Se tem um servidor novo aberto na consola de um provedor, a ordem útil é fixa. Aceda ao servidor, crie um utilizador normal, instale a sua chave e depois feche as vias de acesso mais fáceis. Os primeiros dez minutos num VPS apresenta essa sequência do início ao fim, e o que é realmente um VPS explica a máquina subjacente se estes termos ainda forem novos. Depois disso, leia os textos sobre chaves e hardening, por esta ordem.

FAQ

O que significa SSH?

SSH significa shell seguro. É um protocolo para iniciar sessão num computador remoto e executar comandos nele através de uma ligação cifrada, definido nas RFC 4251 a RFC 4254. OpenSSH é a implementação usada por quase toda a gente: o cliente ssh na sua máquina e o servidor sshd na máquina remota. Substituiu o telnet, que enviava tudo, incluindo palavras-passe, pela rede em texto simples.

Por que razão o SSH usa a porta 22?

A IANA atribuiu a porta 22 ao SSH em 1995, ao lado do FTP na 21 e do telnet na 23, os protocolos que o SSH foi criado para substituir. Nada obriga a usar esse número: Port em /etc/ssh/sshd_config altera-o no servidor e ssh -p escolhe outro no cliente. Como 22 é a porta predefinida, os scanners automatizados tentam aceder-lhe constantemente. Por isso, o /var/log/auth.log de um servidor novo fica cheio de linhas Failed password for invalid user. Alterar a porta reduz esse ruído, mas não acrescenta proteção real.

O que devo fazer quando o SSH avisa que a chave do host mudou?

Descubra a causa antes de limpar qualquer coisa. O motivo habitual é inofensivo: o servidor foi reconstruído, pelo que sshd gerou novas chaves de host, ou foi atribuído o endereço IP antigo a uma máquina nova. Se sabe que a máquina foi reconstruída, execute ssh-keygen -R <host> para eliminar a chave armazenada, volte a ligar-se e compare a impressão digital apresentada com a que a consola do fornecedor indica. Se nada mudou do seu lado, não se ligue e não introduza a palavra-passe. O OpenSSH já recusa a autenticação por palavra-passe neste estado, precisamente por esse motivo.

O SFTP e o scp são diferentes do SSH?

Funcionam sobre o SSH. Depois de se autenticar, a ligação SSH pode transportar vários canais, e uma shell é apenas um deles. O SFTP é um protocolo de transferência de ficheiros que utiliza o subsistema sftp do sshd através da mesma ligação, e scp utiliza o protocolo SFTP internamente desde o OpenSSH 9.0. O encaminhamento de portas e o Git sobre SSH também são canais da mesma ligação. Todos usam a mesma porta, a mesma verificação da chave do host e o mesmo início de sessão. Tenha em atenção que SFTP não é FTP com cifragem adicionada; esse protocolo chama-se FTPS e é separado.

A autenticação por chave é realmente melhor do que uma palavra-passe?

Sim, para qualquer servidor acessível a partir da Internet. Uma palavra-passe é um segredo curto que entrega ao servidor em cada início de sessão, e a porta 22 é alvo de tentativas contínuas por parte de clientes automatizados. Com um par de chaves, a parte privada nunca sai da sua máquina: o cliente assina dados associados à sessão atual e o servidor verifica essa assinatura com a chave pública em ~/.ssh/authorized_keys. Uma assinatura gravada não pode ser reutilizada contra outro servidor. Proteja a chave privada com uma frase-passe, porque um ficheiro de chave sem frase-passe permite iniciar sessão a qualquer pessoa que o copie.