TL;DR — Resumo Rápido

Guia de gestão de chaves SSH para sysadmins: gere chaves Ed25519, use ssh-agent, configure ~/.ssh/config, rode e revogue chaves e use certificados SSH.

As chaves SSH são a base do acesso remoto seguro para todo sysadmin e profissional de DevOps. Este guia de gerenciamento de chaves SSH cobre o ciclo de vida completo: gerar chaves, armazená-las em cache com ssh-agent, organizar múltiplos hosts com ~/.ssh/config, implantar chaves públicas, rotacionar e revogar credenciais comprometidas, escalar com certificados SSH e fortalecer com chaves de hardware.

Pré-requisitos

  • Linux, macOS ou WSL com cliente OpenSSH (ssh, ssh-keygen, ssh-agent, ssh-copy-id).
  • Acesso SSH a pelo menos um servidor remoto para praticar.
  • Opcional: ssh-audit (pip install ssh-audit) para auditoria de algoritmos.
  • Opcional: YubiKey ou outra chave de hardware FIDO2 para máxima proteção.

Geração de Chaves SSH: Ed25519 vs RSA

Ed25519 (recomendado)

ssh-keygen -t ed25519 -C "voce@exemplo.com"

Ed25519 usa criptografia de curva elíptica sobre Curve25519. As chaves têm 256 bits, as assinaturas são rápidas e o algoritmo é resistente a ataques de canal lateral. Esta é a escolha padrão para todas as novas chaves.

RSA (compatibilidade legada)

ssh-keygen -t rsa -b 4096 -C "voce@exemplo.com"

Use RSA-4096 apenas quando o sistema remoto não suportar Ed25519 — por exemplo, versões muito antigas do OpenSSH (< 6.5) ou certos dispositivos de rede. RSA-2048 não é mais recomendado.

Melhores práticas para senhas

  • Sempre defina uma senha. Ela criptografa sua chave privada em disco. Uma chave roubada sem a senha é inútil.
  • Use pelo menos 20 caracteres — uma senha aleatória do seu gerenciador de senhas é ideal.
  • Armazene-a no seu gerenciador de senhas (1Password, Bitwarden, pass).

SSH Agent: Cache de Chaves na Sessão

# Iniciar o agente
eval "$(ssh-agent -s)"

# Adicionar sua chave (solicita senha uma vez)
ssh-add ~/.ssh/id_ed25519

# Listar chaves carregadas
ssh-add -l

# Remover todas as chaves
ssh-add -D

Dica de segurança: Passe -t 3600 ao ssh-add para expirar automaticamente a chave após uma hora:

ssh-add -t 3600 ~/.ssh/id_ed25519

Arquivo de Configuração SSH: Gerenciando Múltiplos Hosts

# ~/.ssh/config

# Configurações padrão para todos os hosts
Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Servidor web de produção
Host prod-web
    HostName 203.0.113.10
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519_prod

# Servidor de banco de dados interno via jump host
Host db-internal
    HostName 10.0.1.50
    User dbadmin
    ProxyJump prod-web

# GitHub
Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Com esta configuração, ssh prod-web conecta com o usuário e a chave corretos, e ssh db-internal tunela automaticamente pelo bastion.

Implantação de Chaves Públicas

ssh-copy-id (mais fácil)

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@host

Implantação manual

cat ~/.ssh/id_ed25519.pub | ssh usuario@host \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && \
   chmod 600 ~/.ssh/authorized_keys"

Permissões de arquivo — crítico

CaminhoPermissãoPor que
~/.ssh/700Apenas o proprietário pode listar/entrar
~/.ssh/id_ed25519600Chave privada — apenas leitura/escrita do proprietário
~/.ssh/id_ed25519.pub644Chave pública — legível por todos
~/.ssh/authorized_keys600Apenas o proprietário pode modificar
~/.ssh/config600Impede que outros leiam sua configuração

O SSH recusará usar chaves com permissões de leitura global e falhará silenciosamente.

Estratégias de Rotação de Chaves

Rotacione chaves SSH quando:

  • Uma chave é mais antiga que a política da sua organização (comumente 1–2 anos).
  • Um funcionário com acesso a chaves sai da empresa.
  • Uma máquina ou mídia que continha a chave privada é descontinuada ou perdida.
  • Você suspeita de comprometimento.

Procedimento seguro de rotação:

  1. Gere um novo par de chaves: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_nova.
  2. Implante a nova chave pública em todos os hosts sem remover a antiga.
  3. Verifique se você pode fazer login com a nova chave: ssh -i ~/.ssh/id_ed25519_nova usuario@host.
  4. Atualize ~/.ssh/config para usar a nova chave.
  5. Remova a chave pública antiga de todos os arquivos authorized_keys.
  6. Delete com segurança a chave privada antiga: shred -u ~/.ssh/id_ed25519_antiga.

Revogação de Chaves Comprometidas

O SSH não tem uma lista de revogação integrada para chaves públicas, então a revogação é um processo manual:

  1. Remova a chave imediatamente de todos os arquivos authorized_keys em todos os hosts.
  2. Para infraestruturas de certificados SSH, adicione a chave a um arquivo RevokedKeys no servidor (RevokedKeys /etc/ssh/revoked_keys no sshd_config).
  3. Audite os logs de login (/var/log/auth.log, journalctl -u ssh) para sessões usando a chave comprometida.
  4. Rotacione quaisquer segredos ou credenciais que possam ter sido acessados.

Certificados SSH: Gerenciamento de Frotas em Escala

Quando você tem dezenas ou centenas de servidores, gerenciar authorized_keys em cada máquina é propenso a erros. Os certificados SSH resolvem isso introduzindo uma Autoridade Certificadora (CA).

Criar um par de chaves CA

ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "org-ssh-ca"

Mantenha ca_key privada e offline. Distribua ca_key.pub para cada servidor.

Configurar servidores para confiar na CA

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Assinar uma chave de usuário

ssh-keygen -s /etc/ssh/ca_key \
  -I "alice@corp" \
  -n alice,admin \
  -V +30d \
  ~/.ssh/id_ed25519.pub

Vantagens sobre authorized_keys

  • Expiração automática — os certificados expiram sem limpeza manual.
  • Controle centralizado — revogue removendo a confiança da CA ou usando RevokedKeys.
  • Aplicação de principals — um certificado só pode fazer login como nomes de usuário específicos.

Chaves de Hardware: YubiKey e FIDO2

# Gerar chave armazenada no YubiKey/FIDO2 (OpenSSH 8.2+)
ssh-keygen -t ed25519-sk -O resident -C "yubikey@corp"

A chave privada nunca sai do dispositivo. Durante a autenticação, o dispositivo requer um toque físico, tornando impossível o roubo remoto de chaves.

Tabela Comparativa: Ed25519 vs RSA vs ECDSA

CaracterísticaEd25519RSA-4096ECDSA P-256
Tamanho da chave256 bits4096 bits256 bits
Velocidade de assinaturaMuito rápidaLentaRápida
Velocidade de verificaçãoRápidaRápidaRápida
Tamanho do arquivo de chave~400 bytes~3.3 KB~600 bytes
Compatibilidade legadaOpenSSH 6.5+ (2014)UniversalOpenSSH 5.7+ (2011)
Resistência a ataques de canal lateralExcelenteModeradaRuim
Chave FIDO2/hardwareSim (ed25519-sk)NãoSim (ecdsa-sk)
RecomendaçãoPrimeira escolhaApenas legadoEvitar

Cenário Real

Você tem uma frota de produção de 40 servidores Linux. Três desenvolvedores saíram da empresa no mês passado. Você precisa revogar o acesso SSH deles imediatamente sem tempo de inatividade.

Com authorized_keys: Você deve acessar (ou usar Ansible) todos os 40 servidores, localizar a impressão digital da chave pública de cada usuário saindo, remover essas linhas e repetir. Um servidor esquecido é uma brecha.

Com certificados SSH: A CA simplesmente para de assinar certificados para esses usuários. Certificados existentes expiram naturalmente. Para revogação imediata, adicione suas impressões digitais ao arquivo RevokedKeys implantado via Ansible em segundos:

ssh-keygen -lf usuario-saindo-cert.pub >> /tmp/revogados
ansible all -m copy -a "src=/tmp/revogados dest=/etc/ssh/revoked_keys mode=0644"
ansible all -m service -a "name=sshd state=reloaded"

Concluído em menos de dois minutos em toda a frota.

Configuração SSH no GitHub e GitLab

GitHub

gh ssh-key add ~/.ssh/id_ed25519.pub --title "estacao-trabalho-2026"

Teste: ssh -T git@github.com

GitLab

Adicione a chave em GitLab → Configurações do Usuário → Chaves SSH.

Teste: ssh -T git@gitlab.com

Armadilhas e Casos Especiais

  • StrictHostKeyChecking=no em scripts — Desabilitar a verificação de chave de host remove a proteção contra ataques man-in-the-middle. Em vez disso, pré-popule ~/.ssh/known_hosts com ssh-keyscan durante o provisionamento.
  • Chaves compartilhadas — Nunca compartilhe uma chave privada entre múltiplas pessoas ou máquinas. Cada pessoa e máquina deve ter seu próprio par de chaves.
  • Login root — Desabilite PermitRootLogin yes no sshd_config. Use um usuário regular com sudo.
  • Nomes de chave não padrão — Se você criar uma chave com nome não padrão, o SSH não a usará automaticamente. Especifique-a no ~/.ssh/config ou passe -i explicitamente.

Solução de Problemas

ProblemaSolução
”Permission denied (publickey)“Verifique permissões com ls -la ~/.ssh/. Execute ssh -vvv host para ver quais chaves são tentadas
Agente não funcionaVerifique com ssh-add -l. Se disser “Could not open connection to agent”, execute eval $(ssh-agent -s)
Chave errada usada para o hostAdicione IdentityFile explícito e IdentitiesOnly yes no ~/.ssh/config
”Host key verification failed”A chave do servidor mudou. Remova a entrada antiga: ssh-keygen -R hostname
Certificado rejeitadoVerifique a expiração com ssh-keygen -L -f cert.pub. Verifique se o principal corresponde ao nome de usuário
YubiKey não detectadoCertifique-se de que pcscd está ativo (systemctl start pcscd). Tente ssh-add -K para carregar chaves residentes

Resumo

  • Gere chaves Ed25519 para todos os novos pares; use RSA-4096 apenas para compatibilidade legada.
  • Sempre defina uma senha e use ssh-agent para armazená-la em cache na sessão.
  • Use ~/.ssh/config com ProxyJump para gerenciar múltiplos hosts e bastions de forma limpa.
  • Implante chaves com ssh-copy-id; nunca compartilhe chaves privadas entre pessoas ou máquinas.
  • Para frotas de mais de ~10 servidores, adote certificados SSH para expiração, principals e revogação centralizada.
  • Armazene chaves em hardware FIDO2 (YubiKey) para máxima segurança.
  • Aplique permissões de arquivo corretas (700 em ~/.ssh/, 600 em chaves e authorized_keys).
  • Audite regularmente a configuração do seu servidor SSH com ssh-audit.

Artigos Relacionados