Criptografia Assimétrica para Autenticação no SSH

1. Definição e Papel na Negociação SSH

No protocolo SSH, a Criptografia Assimétrica (também conhecida como criptografia de chave pública) desempenha o papel vital de garantia de identidade. Ela é utilizada no início da conexão para resolver dois problemas críticos de confiança: o servidor precisa provar que é quem diz ser, e o cliente precisa provar que tem autorização para acessar o sistema.

Diferente da criptografia simétrica (usada para cifrar o tráfego após o handshake), a criptografia assimétrica é computacionalmente cara, sendo reservada exclusivamente para as fases de autenticação e troca de chaves de sessão.

2. O Conceito de Par de Chaves

A base desta autenticação é a existência de dois componentes matematicamente relacionados, mas funcionalmente opostos:

• Chave Pública: Pode ser compartilhada livremente. No SSH, ela é colocada no servidor (normalmente no arquivo ~/.ssh/authorized_keys).
• Chave Privada: Deve ser mantida em segredo absoluto pelo proprietário. Ela nunca viaja pela rede.

A magia da autenticação assimétrica reside no fato de que algo cifrado ou assinado por uma chave só pode ser verificado/decifrado pela outra, tornando a falsificação virtualmente impossível sem fatoração matemática de números primos gigantescos (no caso do RSA).

Tabela: Tamanhos de Chave e Equivalência de Segurança

3. Autenticação do Servidor (Host Verification)

Antes mesmo de o usuário introduzir sua senha ou chave, o SSH utiliza a criptografia assimétrica para autenticar o servidor.

• Cada servidor SSH possui uma "Host Key" única, gerada na primeira instalação do pacote openssh-server.
• Quando o cliente se conecta, o servidor envia sua chave pública.
• O cliente verifica se essa chave mudou (consultando o arquivo local ~/.ssh/known_hosts). Se a chave for reconhecida, o cliente sabe que não está sofrendo um ataque de Man-in-the-Middle.
• Se a chave for desconhecida (primeira conexão), o cliente exibe fingerprint e solicita confirmação explícita do usuário (TOFU - Trust On First Use).

Exemplo: Verificação de Host Key

$ ssh admin@servidor.com
The authenticity of host 'servidor.com (203.0.113.50)' can't be established.
ED25519 key fingerprint is SHA256:abc123def456ghi789jkl012mno345pqr678stu901.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Visualização da Fingerprint do Servidor

# Listar fingerprints de todas as host keys
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
# 256 SHA256:abc123... root@servidor (ED25519)

# Visualizar em formato Base64 (para comparação visual)
ssh-keygen -l -E base64 -f /etc/ssh/ssh_host_ed25519_key.pub

4. Autenticação do Usuário (Public Key Auth)

Este é o método de login mais seguro e recomendado, substituindo o uso de passwords tradicionais. O processo segue esta sequência lógica:

1. Desafio (Challenge): O servidor envia uma mensagem aleatória (um "challenge") ao cliente.
2. Assinatura (Signature): O cliente utiliza sua Chave Privada local para assinar digitalmente essa mensagem.
3. Verificação (Verification): O cliente envia a assinatura de volta. O servidor utiliza a Chave Pública (que já estava guardada no perfil do usuário em ~/.ssh/authorized_keys) para validar a assinatura.
4. Acesso (Grant): Se a assinatura for matematicamente válida, o servidor tem a prova absoluta de que o cliente possui a chave privada correspondente e permite o acesso.

Fluxo Detalhado no Protocolo SSH

Cliente                                  Servidor
  |                                         |
  |  1. Inicia conexão TCP (porta 22)        |
  |  --------------------------------------> |
  |                                         |
  |  2. Troca de algoritmos e host key       |
  |  <-------------------------------------- |
  |                                         |
  |  3. Cliente envia ID da chave pública    |
  |  --------------------------------------> |
  |                                         |
  |  4. Servidor gera nonce aleatório        |
  |  <-------------------------------------- |
  |                                         |
  |  5. Cliente assina nonce com chave priv  |
  |  --------------------------------------> |
  |                                         |
  |  6. Servidor verifica com pubkey (auth)  |
  |  <-------------------------------------- |
  |                                         |
  |  7. Canal cifrado estabelecido (AES/CTR) |
  |  <=====================================> |

5. Algoritmos Utilizados

O SSH suporta diversos algoritmos para esta fase de autenticação, cada um com diferentes níveis de segurança e performance:

RSA (Rivest-Shamir-Adleman)

O mais antigo e compatível, mas requer chaves grandes (mínimo 3072 bits) para ser considerado seguro hoje. Baseado na dificuldade de fatoração de produtos de primos grandes.

ECDSA (Elliptic Curve Digital Signature Algorithm)

Baseado em Curvas Elípticas; oferece a mesma segurança que o RSA com chaves muito menores, sendo mais eficiente. Padrão FIPS 186-4.

Ed25519

Atualmente considerado o "padrão ouro" para o SSH. É extremamente rápido, seguro e as chaves são curtas e fáceis de gerir. Baseado na Curve25519 com assinatura EdDSA. Resistente a ataques de side-channel por não depender de geração de números aleatórios no momento da assinatura.

Comparativo Prático

6. Vantagens sobre as Passwords

• Imunidade a Brute Force: Enquanto uma password pode ser adivinhada, uma chave de 4096 bits é impossível de quebrar por tentativa e erro (2¹²⁸ operações para Ed25519).
• Proteção contra Intercepção: Como a chave privada nunca sai do computador do usuário, ela não pode ser capturada durante a transmissão, ao contrário de senhas enviadas em texto simples (em protocolos legados como Telnet).
• Automatização: Permite que scripts e sistemas automatizados (como backups, deploys CI/CD) se conectem de forma segura sem intervenção humana e sem expor credenciais em texto simples.
• Auditabilidade: Cada acesso fica registrado com a fingerprint da chave, permitindo rastreamento preciso em logs.

Exemplo de Log de Acesso por Chave

Jan 15 14:32:10 servidor sshd[12345]: Accepted publickey for admin from 203.0.113.10 port 54321 ssh2: ED25519 SHA256:abc123def...

7. Boas Práticas: Passphrase

Mesmo sendo uma autenticação assimétrica, a chave privada em disco deve ser protegida por uma Passphrase. Isso adiciona uma camada de "autenticação de dois fatores":

1. Algo que possui: O arquivo da chave privada (~/.ssh/id_ed25519).
2. Algo que sabe: A frase secreta para desbloquear essa chave.

Desta forma, se o computador for roubado, o atacante ainda não conseguirá utilizar a chave para acessar os servidores.

Recursos Avançados

• ssh-agent: Daemon que mantém chaves desbloqueadas na memória RAM durante a sessão, evitando redigitar a passphrase a cada conexão.
• ssh-add: Carrega chaves no agent, com tempo de vida configurável (-t 3600 para expirar em 1 hora).
• Forwarding de Agent: Permite usar chaves locais ao saltar entre servidores intermediários, sem expor a chave privada aos servidores hop (ssh -A). Cuidado: forwarding em servidores comprometidos permite sequestro de sessão.

Comandos Práticos

# Gerar chave Ed25519 com passphrase forte
ssh-keygen -t ed25519 -C "admin@empresa.com" -f ~/.ssh/id_ed25519

# Carregar chave no agent
eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519

# Copiar chave pública para servidor remoto
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@servidor.com

# Listar chaves carregadas no agent
ssh-add -l

# Desativar login por senha (hardening)
# Em /etc/ssh/sshd_config:
# PasswordAuthentication no
# PubkeyAuthentication yes
# PermitRootLogin prohibit-password

8. Conclusão

A criptografia assimétrica é o coração da segurança do SSH. Sem ela, qualquer um poderia se passar por qualquer servidor (MITM) ou atacar senhas por força bruta. Compreender o par de chaves pública/privada, os algoritmos disponíveis (preferindo Ed25519), e as boas práticas de passphrase e ssh-agent é o conhecimento fundamental para qualquer administrador de sistemas que precise gerenciar acesso remoto a infraestruturas críticas.