Chaves SSH: como funcionam e como usar com segurança

#O que o SSH protege

SSH (Secure Shell) é o protocolo que a maioria das pessoas usa para entrar em servidores Linux, máquinas virtuais de laboratório e hospedagens de Git. Ele abre um shell sobre um canal criptografado, e o mesmo canal pode copiar arquivos ou fazer encaminhamento de portas. Ele tem três funções. Criptografa o tráfego para que ninguém no caminho da rede consiga ler. Prova ao servidor quem você é. Prova a você quem é o servidor.

As chaves fazem a segunda função sem mandar uma senha pela rede. Uma senha pode ser adivinhada ou roubada por phishing. Um par de chaves funciona de outro jeito. O servidor guarda só a metade pública. Para entrar, o seu cliente assina um desafio com a metade privada, e o servidor confere a assinatura. A chave privada nunca sai da sua máquina.

O SSH não protege você em alguns casos, e eles importam tanto quanto o protocolo. Se o seu próprio computador estiver comprometido, um malware rodando com o seu usuário pode ler o arquivo da chave privada ou pedir ao agente que assine coisas por você. Se a chave privada for roubada e a senha dela for fraca, o atacante pode tentar adivinhá-la offline. Se você aceitar a identidade de um servidor sem conferir, pode estar falando com alguém que não é o servidor.

#Dois tipos de chave

O SSH usa dois tipos diferentes de chave, e as pessoas costumam confundi-los.

Chaves de host identificam o servidor. Cada servidor SSH tem uma ou mais, normalmente guardadas em /etc/ssh/ssh_host_*_key. A parte privada fica no servidor. A parte pública é apresentada a todo cliente que se conecta. Na primeira vez que o seu cliente a vê, ele salva a chave em known_hosts. Nas conexões seguintes, uma chave de host diferente dispara um aviso.

Chaves de usuário identificam você. Você gera o par na sua própria máquina. A chave privada fica com você. A chave pública vai para o servidor, em ~/.ssh/authorized_keys da conta que você quer usar.

A diferença tem consequências práticas. Copiar a sua chave privada para um servidor entrega a esse servidor, e a quem puder lê-la, o material necessário para agir como você em todo lugar onde a chave é confiável. Ignorar um aviso de chave de host significa que você pode enviar sua senha ou seus comandos a um impostor.

#Por que Ed25519 com senha de proteção

O OpenSSH suporta vários tipos de chave. RSA ainda funciona, mas chaves RSA novas devem ter pelo menos 3072 bits, e as linhas de chave pública ficam longas. Chaves Ed25519 são curtas, rápidas de verificar e padronizadas para SSH na RFC 8709. O OpenSSH 9.5 e as versões seguintes já usam Ed25519 como padrão no ssh-keygen. Para uma chave de laboratório, Ed25519 é a escolha certa, a menos que um sistema que você precisa acessar aceite só um tipo mais antigo.

A senha de proteção (passphrase) criptografa o arquivo da chave privada no disco. Sem ela, quem copiar o arquivo pode usar a chave. Com ela, o atacante precisa do arquivo e da senha. Isso protege contra os acidentes mais comuns: um backup enviado para o lugar errado, uma chave deixada em pasta compartilhada, um arquivo sincronizado por engano com a nuvem. A senha não ajuda depois que a chave é carregada em um agente e um malware roda como você. Use uma senha longa, guarde-a em um gerenciador de senhas e mantenha uma cópia do arquivo da chave em um lugar seguro.

#Como uma conexão funciona

A RFC 4253 descreve a camada de transporte. Em linhas gerais, uma conexão passa por estas etapas:

1. Seu cliente abre uma conexão TCP com o servidor, normalmente na porta 22.
2. Os dois lados enviam os algoritmos que suportam e combinam uma troca de chaves. A troca gera segredos compartilhados, e a partir daí todo o tráfego é criptografado.
3. O servidor envia a chave de host e uma assinatura sobre a troca. Seu cliente compara essa chave com o known_hosts. Se o host for novo, o cliente mostra a impressão digital e pede que você a confirme.
4. Você se autentica. O cliente oferece uma chave pública. Se o servidor a encontrar em authorized_keys, envia um desafio. Seu cliente assina o desafio com a chave privada, e o servidor confere a assinatura.

Repare de onde vem a confiança. A etapa 3 trata do servidor. A etapa 4 trata de você. Se você pular a conferência da impressão digital na etapa 3, o restante do processo continua funcionando para quem atendeu a chamada.

#Impressões digitais

Uma impressão digital é um hash curto de uma chave pública. O OpenSSH mostra impressões SHA256 por padrão. Duas pessoas podem comparar a impressão digital para confirmar que têm a mesma chave pública, sem ler a chave inteira em voz alta.

Os comandos abaixo foram executados em um Windows 11 com OpenSSH 9.9p2 (ssh -V), no Git Bash. A chave era uma cópia de teste criada só para esta observação, com senha vazia, para que a saída pudesse ser mostrada aqui. A sua chave real terá outra impressão digital.

ssh-keygen -t ed25519 -C 'lab-key' -f ./lab_ed25519 -N ''
ssh-keygen -lf ./lab_ed25519.pub

Saída observada:

256 SHA256:2BAyZTrHADdiG1FNwfCwb/fC5vSVZPwfGnZjRaaExc4 lab-key (ED25519)

ssh-keygen -lvf mostra a mesma impressão digital com uma figura aleatória. A figura ajuda a notar uma mudança, mas o texto da impressão digital é o que você compara.

#Parte prática: laboratório

Você precisa de uma máquina virtual ou instância na nuvem que seja sua e que você controle, com um servidor OpenSSH rodando e uma conta que possa usar sudo. Uma VM local no VirtualBox ou no Hyper-V serve. Uma instância pequena na nuvem que você paga e pode apagar também serve. Não execute estes passos em uma máquina que pertença a outra pessoa.

#Passo 1: gerar a chave

ssh-keygen -t ed25519 -C 'lab-key' -f ~/.ssh/lab_ed25519

Quando pedido, digite uma senha de proteção longa. O comando cria dois arquivos: lab_ed25519 (privada) e lab_ed25519.pub (pública). Só o arquivo .pub deve sair da sua máquina.

#Passo 2: conferir a impressão digital

ssh-keygen -lf ~/.ssh/lab_ed25519.pub

Anote esta impressão digital, ou pelo menos os primeiros caracteres. Você vai compará-la depois.

#Passo 3: proteger o arquivo da chave privada

chmod 600 ~/.ssh/lab_ed25519

No Linux e no macOS, o ssh recusa uma chave privada que outros usuários conseguem ler. No Windows, o OpenSSH confere as ACLs do arquivo, e não os bits de modo do Unix. Nesta máquina Windows, o chmod 600 rodou sem erro, mas o ls -l continuou mostrando -rw-r--r-- depois. Não presuma que os bits de modo mudaram ali. Se o ssh reclamar de permissões no Windows, inspecione o arquivo com icacls e remova o acesso de outras contas.

#Passo 4: instalar a chave pública na VM

ssh-copy-id -i ~/.ssh/lab_ed25519.pub seuusuario@sua-vm-de-laboratorio

Esta é a única vez em que você digita a senha da conta de propósito. O comando acrescenta a chave pública em ~/.ssh/authorized_keys na VM.

A primeira conexão com a VM também mostra uma impressão digital da chave de host. Compare-a com a real. Na VM, rode:

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

Se as duas impressões digitais baterem, digite yes. Se não baterem, pare. Descubra o motivo antes de continuar. A diferença pode significar que você reinstalou a VM, ou que alguém está no meio do caminho entre você e ela.

Este passo não foi executado aqui, porque nenhuma VM estava disponível nesta máquina. Por isso os comandos dos passos 4 a 6 aparecem sem saída. Você pode conferir cada um na sua VM.

#Passo 5: entrar com a chave

ssh -i ~/.ssh/lab_ed25519 seuusuario@sua-vm-de-laboratorio

O cliente pede a senha de proteção da chave, e não a senha da conta. Se aparecer um shell, a chave funciona. Mantenha esta sessão aberta para o próximo passo.

#Passo 6: desligar o login por senha

Na VM:

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart ssh

A linha do sed substitui a linha PasswordAuthentication, esteja ela comentada ou não. O sshd -t confere a sintaxe da configuração e interrompe a sequência se houver erro. O systemctl restart ssh aplica a mudança. No Fedora e em outras distribuições da família RHEL, o serviço se chama sshd, então use esse nome.

Três problemas são comuns aqui:

• A linha é sobrescrita. Em muitos sistemas Debian e Ubuntu, o /etc/ssh/sshd_config inclui arquivos de /etc/ssh/sshd_config.d/, e vale o primeiro valor lido para cada palavra-chave. Confira o valor que o sshd realmente usa:

sudo sshd -T | grep -i '^passwordauthentication'

Depois da mudança, a saída deve ser passwordauthentication no. Se ainda disser yes, encontre o arquivo que define o valor e corrija ali.

• A linha não existe. O sed só edita uma linha que já existe. Se não houver linha PasswordAuthentication, vale o padrão, e a página de manual do sshd_config(5) diz que o padrão é yes. Acrescente a linha você mesmo:

echo 'PasswordAuthentication no' | sudo tee -a /etc/ssh/sshd_config

• Você se tranca para fora. Antes de fechar a sessão que usou no passo 5, abra um segundo terminal e entre com a chave. Feche o primeiro só depois que o segundo funcionar. Se perder o acesso, use o console da VM no painel do seu hipervisor ou da nuvem para corrigir a configuração.

Depois, teste da sua máquina se o login por senha é recusado:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password seuusuario@sua-vm-de-laboratorio

A conexão deve falhar com uma mensagem de permissão negada. Faça essa conferência você mesmo, na VM que você controla. Ela não foi executada nesta máquina.

#O agente e o known_hosts

#ssh-agent

Digitar a senha de proteção em cada conexão cansa. O ssh-agent mantém a chave já descriptografada na memória durante a sua sessão, então você digita a senha uma vez.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/lab_ed25519
ssh-add -l

O ssh-add -l lista as impressões digitais que o agente tem carregadas. Nesta máquina Windows, o ssh-add -l rodou sem um agente ativo e mostrou Could not open a connection to your authentication agent., com código de saída 2. No Windows, isso é feito pelo serviço OpenSSH Authentication Agent. Inicie esse serviço pelo console de Serviços ou por um PowerShell como administrador. É uma mudança no seu sistema, então faça você mesmo e só se quiser o agente rodando.

O agente é cômodo e também é alvo. Quem conseguir falar com o socket do agente enquanto você está logado pode pedir a ele que assine coisas. Por isso, evite o encaminhamento de agente (ssh -A) para hosts em que você não confia por completo. Um usuário root no host remoto pode usar o agente encaminhado. Se precisar chegar a uma máquina privada por um bastion, use um jump host:

ssh -J seuusuario@bastion seuusuario@vm-privada

#known_hosts

O cliente guarda as chaves de host em ~/.ssh/known_hosts, uma linha por host e tipo de chave. As linhas podem ser embaralhadas (hash) se você definir HashKnownHosts yes, o que esconde os nomes dos hosts de quem ler o arquivo.

Para procurar um host:

ssh-keygen -F sua-vm-de-laboratorio

Para remover uma entrada depois de reconstruir a VM e obter uma nova chave de host:

ssh-keygen -R sua-vm-de-laboratorio

Faça isso só quando souber o motivo da mudança da chave. Uma chave de host alterada é um alerta, não um incômodo. Apagar a entrada antiga sem conferir a nova impressão digital ensina você a ignorar o próximo alerta, e o próximo pode ser real.

#Pontos principais

• Nunca compartilhe a chave privada. Só o arquivo .pub vai para servidores, hospedagens de Git ou outras pessoas.
• Proteja a chave privada com senha de proteção e mantenha uma cópia do arquivo.
• Confira a impressão digital do host na primeira conexão e investigue qualquer mudança depois.

#Erros comuns

• Colar a chave privada em um chat, issue, ticket ou captura de tela. Trate-a como uma senha que não pode ser redefinida. Se vazar, gere uma chave nova, instale-a e remova a chave pública antiga de authorized_keys.
• Instalar a chave privada no servidor em vez da pública. O servidor precisa só da linha do .pub em authorized_keys.
• Permissões no servidor. No Linux, ~/.ssh deve ser 700 e authorized_keys deve ser 600. Modos mais abertos podem fazer o sshd ignorar a chave. Olhe os logs do sshd quando um login por chave falhar.
• Desligar a senha antes de o login por chave funcionar. É o trancamento mais comum. Siga a ordem do passo 6.
• Uma chave para tudo. Usar a mesma chave em VMs de laboratório, hospedagens de Git e sistemas de produção significa que um vazamento abre tudo. Use chaves separadas por finalidade, como lab_ed25519 para o laboratório e outra chave para o GitHub.
• Aceitar uma chave de host desconhecida sem conferir. A primeira conexão é o momento em que um impostor tem mais chance de entrar. Compare a impressão digital antes de digitar yes.
• Perder a senha de proteção. Não há recuperação. Guarde-a em um gerenciador de senhas.
• Linhas duplicadas em authorized_keys. Rodar o ssh-copy-id duas vezes não causa dano, mas acrescentar a mesma chave à mão várias vezes torna o arquivo difícil de auditar. Remova as chaves que você não usa mais.

#Como seguir em frente

Depois que o laboratório funcionar, alguns passos deixam o uso diário mais seguro e organizado.

• Configurações por host em ~/.ssh/config. Dê um apelido a cada host, defina o IdentityFile e acrescente IdentitiesOnly yes, para que o cliente ofereça só a chave que você escolheu. Assim ele não testa todas as chaves do agente em cada servidor.
• Chaves de segurança. O OpenSSH pode criar chaves guardadas em um dispositivo de segurança de hardware, com ssh-keygen -t ed25519-sk. A parte privada não pode ser copiada para fora do dispositivo. Confira a sua versão do OpenSSH e o suporte antes de depender disso.
• Certificados SSH. Organizações com muitos servidores costumam usar uma autoridade certificadora em vez de distribuir chaves para cada host. O conceito vale a pena mesmo se você ainda não precisar dele.
• Leia os documentos de referência. As páginas de manual do ssh-keygen e do sshd_config descrevem todas as opções que você vai encontrar. A RFC 4253 explica a camada de transporte, e a RFC 8709 trata do Ed25519 no SSH.

Se permissões e donos de arquivos ainda forem novidade para você, leia antes o artigo anterior sobre permissões de arquivos no Linux. O próximo artigo trata de redes Docker isoladas para laboratórios, que ajudam a manter o tráfego do laboratório longe da sua rede do dia a dia.

#Fontes

• Manual do OpenBSD, ssh-keygen(1): https://man.openbsd.org/ssh-keygen
• Manual do OpenBSD, sshd_config(5): https://man.openbsd.org/sshd_config
• OpenSSH 9.5 release notes: https://www.openssh.com/txt/release-9.5
• RFC 4253, The Secure Shell (SSH) Transport Layer Protocol: https://www.rfc-editor.org/rfc/rfc4253
• RFC 8709, Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol: https://www.rfc-editor.org/rfc/rfc8709