SSH: protegendo o acesso remoto

O SSH-1, o protocolo original Secure Shell, continha uma falha fundamental de projeto que permitia a um invasor ativo inserir dados arbitrários em uma sessão criptografada sem ser detectado. O SSH-2, uma reformulação completa do protocolo publicada em 2006 como RFC 4251-4254, corrigiu essas fragilidades com protocolos separados para as camadas de transporte, autenticação e conexão, além de uma verificação de integridade mais robusta usando HMAC. O SSH-1 está obsoleto, e nenhum servidor moderno deve habilitá-lo.

O protocolo da camada de transporte do SSH gerencia a troca inicial de chaves e estabelece um canal criptografado e protegido contra alterações. Ele negocia algoritmos para troca de chaves (normalmente ECDH), autenticação do servidor (normalmente Ed25519 ou RSA), criptografia simétrica (normalmente AES-256-CTR ou ChaCha20-Poly1305) e MAC (normalmente HMAC-SHA2-256). Todos os pacotes subsequentes são criptografados e têm sua integridade verificada usando os algoritmos negociados.

Depois que a camada de transporte é protegida, a camada de autenticação de usuários negocia como o usuário comprovará sua identidade ao servidor. Três métodos comuns são senha (o usuário digita uma senha, que é enviada criptografada pela camada de transporte), chave pública (o usuário comprova que possui uma chave privada correspondente a uma chave pública autorizada no servidor) e GSSAPI (integração de logon único do Kerberos para ambientes empresariais).

A camada de conexão do SSH multiplexa vários canais lógicos sobre uma única conexão de transporte criptografada. Uma sessão SSH típica tem um canal para o interpretador de comandos interativo. Canais adicionais permitem o encaminhamento de portas, o encaminhamento X11 e a transferência de arquivos SFTP, todos compartilhando a mesma conexão autenticada e criptografada. As solicitações de canal permitem que o cliente solicite um pseudo-terminal, defina variáveis de ambiente ou execute um comando específico.

Ao conectar-se pela primeira vez a um servidor SSH, o cliente recebe a chave do servidor e precisa decidir se deve confiar nela. A política padrão é Confiança no primeiro uso (TOFU): o usuário é solicitado a verificar a impressão digital da chave (normalmente exibida como um hash, como SHA256:...) e, se a aceitar, ela é armazenada no arquivo known_hosts. Nas conexões subsequentes, a chave armazenada é comparada com a apresentada pelo servidor, e uma divergência dispara um alerta severo sobre possíveis ataques de intermediário.

O arquivo known_hosts, armazenado em ~/.ssh/known_hosts, mantém um banco de dados de chaves de servidores indexadas pelo nome do servidor e pelo endereço IP. Cada entrada associa o endereço de um servidor à sua chave pública. Se a chave de um servidor mudar, talvez porque ele tenha sido reinstalado ou porque um invasor esteja se passando por ele, o SSH se recusará a conectar e exibirá um aviso. Os administradores usam autenticação de servidores baseada em certificados para evitar decisões de confiança TOFU em larga escala.

A autenticação por chave pública armazena a chave pública do usuário em ~/.ssh/authorized_keys no servidor. Quando o usuário se conecta, o servidor envia um desafio criptografado com a chave pública; somente quem possui a chave privada correspondente pode responder corretamente, comprovando sua identidade sem transmitir a chave privada ou uma senha. Isso é mais seguro do que usar senhas, pois as chaves privadas nunca são enviadas pela rede e não podem ser obtidas por meio de fraude.

Três famílias de algoritmos de chaves SSH são amplamente usadas. Chaves RSA de 3072 ou 4096 bits são compatíveis com todos os servidores. A ECDSA usando a curva P-256 da NIST é mais rápida que a RSA com segurança equivalente, mas os parâmetros de segurança da P-256 têm sido objeto de escrutínio. A Ed25519, baseada no Algoritmo de Assinatura Digital de Curvas de Edwards, é a recomendação moderna: chaves de 256 bits rápidas e pequenas, propriedades de segurança robustas e nenhuma preocupação com parâmetros específicos.

Tatu Ylönen, um pesquisador finlandês da Universidade de Tecnologia de Helsinque, desenvolveu o SSH em 1995 depois que um ataque de captura de senhas à rede de sua universidade expôs centenas de credenciais. Ele escolheu a porta 22 porque ela ficava entre telnet (23) e ftp (21). O SSH substituiu ambos os protocolos inseguros. Ylönen fundou a SSH Communications Security e posteriormente lançou o SSH-2 como um padrão aberto por meio da IETF. O OpenSSH, a principal implementação de software livre, foi criado pelo projeto OpenBSD em 1999.

O agente SSH é um processo em segundo plano que mantém chaves privadas descriptografadas na memória, permitindo o logon único em vários servidores sem redigitar a frase secreta. O encaminhamento do agente (opção -A) amplia esse recurso encaminhando a conexão do agente para servidores remotos, permitindo acesso em um salto a servidores internos. No entanto, o encaminhamento do agente representa um risco de segurança: um servidor remoto comprometido pode usar o agente encaminhado para autenticar-se como você em outros servidores. Use ProxyJump em vez do encaminhamento do agente.

Uma configuração segura do SSH inclui desabilitar o login do root (PermitRootLogin no), desabilitar a autenticação por senha (PasswordAuthentication no) em favor do uso exclusivo de chaves públicas, usar chaves de servidor Ed25519, habilitar apenas o protocolo SSH-2, configurar tempos limite para sessões ociosas, restringir os usuários permitidos com AllowUsers ou AllowGroups e alterar a porta padrão como medida de obscuridade para reduzir o ruído de varreduras automatizadas. O Fail2ban ou ferramentas semelhantes bloqueiam endereços IP após várias tentativas malsucedidas.

O SSH-2 substituiu o SSH-1 defeituoso com camadas separadas de transporte, autenticação e conexão. A camada de transporte negocia criptografia e integridade. A autenticação de usuários oferece suporte a senhas, chaves públicas e GSSAPI. A verificação de chaves do servidor usa TOFU e known_hosts. Ed25519 é o algoritmo de chaves recomendado. O encaminhamento do agente representa um risco de segurança; use ProxyJump. O reforço da segurança inclui desabilitar o login do root e a autenticação por senha.