Chaves SSH: como configurar o acesso ao servidor sem senha

Uma chave SSH é um par de arquivos: a chave privada fica com você e a chave pública vai para o servidor. Na conexão, o servidor confere se você possui a chave privada correspondente a uma das chaves públicas autorizadas e, nesse caso, deixa entrar sem senha. Isso é mais prático e muito mais seguro do que uma senha, porque adivinhar a chave por força bruta é praticamente impossível. A seguir você vê a configuração completa, da geração das chaves até a proibição do login por senha, com a explicação dos erros em que as pessoas costumam tropeçar.

Como funciona a autenticação por chave

As chaves são assimétricas. A chave pública (id_ed25519.pub) pode ser mostrada a qualquer pessoa: a partir dela não é possível recuperar a chave privada. A chave privada (id_ed25519) nunca sai do seu computador nem é transmitida pela rede.

Ao entrar, o cliente informa ao servidor qual chave quer usar. O servidor procura essa chave pública no arquivo ~/.ssh/authorized_keys do usuário e, se a encontrar, pede que o cliente assine os dados da sessão com a chave privada. A assinatura é conferida com a chave pública, e o acesso é liberado. Em nenhum momento a senha é enviada.

Passo 1: gerar a chave com ssh-keygen

No seu computador (Linux, macOS, ou Windows 10/11 com o OpenSSH embutido), execute:

ssh-keygen -t ed25519 -C "alena@laptop"

A opção -t define o algoritmo, e -C define um comentário que vai para o final da chave pública e ajuda a identificar depois de quem ela é. O Ed25519 é o algoritmo moderno recomendado: as chaves são curtas, rápidas e seguras. Se o servidor for muito antigo e não aceitar Ed25519, use RSA com pelo menos 3072 bits: ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

A senha da chave (passphrase) é necessária?

A passphrase cifra a chave privada no disco. Se o notebook for roubado ou o arquivo vazar, sem a passphrase a chave não serve para nada. Para chaves pessoais, vale definir uma passphrase; para não digitá-la a cada conexão, use o ssh-agent, que mantém a chave decifrada na memória até o fim da sessão.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # lista as chaves carregadas

Chaves sem passphrase são justificadas em automações, como um CI ou um script de backup. Essas chaves convém restringir no servidor (veja mais adiante).

Passo 2: copiar a chave pública para o servidor com ssh-copy-id

O caminho mais simples é o ssh-copy-id. Ele se conecta pela senha uma última vez, acrescenta sua chave pública ao ~/.ssh/authorized_keys do servidor e ajusta as permissões corretas.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Se o servidor usa uma porta diferente, acrescente -p 2222.

Se o ssh-copy-id não estiver disponível

No Windows não existe o ssh-copy-id. A chave pode ser enviada manualmente com um único comando:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Provedores de nuvem costumam pedir a chave pública já na criação do servidor; ela vai para o authorized_keys pelo cloud-init.

Passo 3: testar o acesso

ssh deploy@203.0.113.10

Se a senha não for mais pedida (ou se for pedida apenas a passphrase da chave), tudo funcionou. Na primeira conexão com um servidor novo, o SSH mostra a impressão digital da chave do host e pergunta se você confia nele. Ao responder yes, a impressão digital fica salva em ~/.ssh/known_hosts, e o SSH avisa depois se a chave do servidor mudar.

Para ver quais chaves o cliente tenta e por que o servidor recusa, faça a conexão em modo detalhado:

ssh -v deploy@203.0.113.10

O arquivo ~/.ssh/config: nomes curtos para os servidores

Quando há vários servidores, digitar usuário, IP, porta e caminho da chave toda vez é cansativo. Tudo isso pode ser descrito em ~/.ssh/config:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-internal
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Agora basta ssh prod, e o scp, o rsync e o Git também entendem esses nomes: rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes: usa somente a chave indicada. Sem essa linha, o cliente testa todas as chaves do agente, e o servidor pode desconectar por excesso de tentativas antes de chegar à chave certa.
• ProxyJump: conecta-se a um servidor interno passando por um servidor intermediário (bastião) com um único comando.
• ServerAliveInterval: envia um sinal a cada 60 segundos para que a conexão não caia por ociosidade.

O arquivo precisa ter permissão 600, senão o SSH pode se recusar a lê-lo: chmod 600 ~/.ssh/config.

Encaminhamento do agente: quando usar e qual o risco

Às vezes é preciso, a partir do servidor, conectar-se a outra máquina, por exemplo para fazer git pull de um repositório privado. Não se deve copiar a chave privada para o servidor. Em vez disso, pode-se usar ssh -A ou ForwardAgent yes: o servidor passa a usar o seu agente local durante a sessão. Porém, quem tiver root nesse servidor também poderá usar o agente enquanto você estiver conectado. Por isso, ative o encaminhamento apenas para hosts confiáveis, e para passar por um intermediário prefira o ProxyJump, que não expõe o agente.

Passo 4: desativar o login por senha

Enquanto a senha for aceita, o servidor continua sendo alvo de tentativas de adivinhação. Depois de confirmar que entra com a chave, desative as senhas. Importante: não feche a sessão atual antes de testar o acesso em uma janela nova, senão você pode perder o acesso ao servidor.

Abra /etc/ssh/sshd_config (ou crie um arquivo em /etc/ssh/sshd_config.d/, se o arquivo principal carregar outros pela diretiva Include) e defina:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no proíbe entrar diretamente como root: os administradores entram com os próprios usuários e elevam privilégios com sudo. Se for indispensável entrar como root, use PermitRootLogin prohibit-password, que permite somente acesso por chave.

Verifique a sintaxe e recarregue o serviço:

sudo sshd -t
sudo systemctl reload ssh      # Debian/Ubuntu; nas distribuições RHEL, use sshd

O comando sshd -t não mostra nada se a configuração estiver correta. Agora, em um novo terminal, confirme que o acesso por chave funciona e que o servidor recusa a senha:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Proteção adicional

Desativar as senhas é a medida principal. Em seguida, costuma-se restringir a porta 22 no firewall (ufw allow from 198.51.100.0/24 to any port 22) e instalar o fail2ban, que bloqueia um IP depois de uma série de tentativas falhas. O estado da proteção do SSH aparece com sudo fail2ban-client status sshd.

Uma chave usada em automação pode ser limitada no próprio authorized_keys, com opções antes da chave: por exemplo, from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup permite a entrada somente a partir desse endereço e sem shell interativo.

Erros comuns e como corrigi-los

Permission denied (publickey)

É o erro mais frequente. As causas, das mais comuns às mais raras:

1. Permissões incorretas no servidor.O sshd ignora o authorized_keys se o diretório ou o arquivo puderem ser gravados por outros usuários. Correção: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, e o diretório pessoal não pode ser gravável pelo grupo ou pelos demais.
2. Dono incorreto.Se você criou os arquivos com sudo, eles pertencem ao root. Correção: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. A chave foi colocada no usuário errado.Você copiou a chave para o root, mas entra como deploy, ou o contrário.
4. O cliente oferece a chave errada.Veja a saída de ssh -v: as linhas Offering public key mostram quais chaves são testadas. Indique a certa com -i ou com IdentityFile.
5. A chave ficou corrompida na cópia.A chave pública deve ocupar uma única linha. Uma quebra de linha ao colar a partir da área de transferência a estraga.

O log do servidor mostra o motivo da recusa: sudo journalctl -u ssh -n 30 (no RHEL, use -u sshd). Podem aparecer linhas como Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

O cliente se recusa a usar uma chave privada que outros usuários conseguem ler. Correção: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

A chave do host não confere com a que está salva em known_hosts. Isso acontece depois de reinstalar o servidor ou mudar seu IP, mas o mesmo aviso aparece em um ataque do tipo «homem no meio». Confirme que o servidor foi realmente recriado e apague o registro antigo: ssh-keygen -R 203.0.113.10.

Too many authentication failures

O agente ofereceu ao servidor chaves demais, e ele fechou a conexão pelo limite MaxAuthTries. A solução é IdentitiesOnly yes com um IdentityFile explícito no ~/.ssh/config.

Conclusão

Configurar chaves SSH leva cinco minutos: ssh-keygen -t ed25519, depois ssh-copy-id, depois o teste de acesso e, por fim, PasswordAuthentication no com o recarregamento do sshd, mantendo a segunda sessão aberta. O ~/.ssh/config dispensa comandos longos, e as permissões 700 e 600 resolvem a maioria dos erros de «Permission denied». SSH, rsync e a proteção do servidor com firewall e fail2ban são explicados com prática no curso de Linux.