Pares de chave SSH têm um problema de proliferação. Certificados são a solução.

Pares de chave SSH funcionam bem para três servidores. Aos trinta, tornam-se um problema de segurança. Aos trezentos, são um pesadelo de conformidade. Chaves obsoletas se acumulam sem prazo de validade, mecanismo central de revogação ou trilha de auditoria que conecte uma chave a um evento de login específico. Certificados SSH resolvem todos esses três problemas sem mudar nada na forma como engenheiros se conectam aos servidores.

O problema da proliferação de chaves SSH

O tempo médio de vida de uma chave SSH em uma organização com mais de 100 engenheiros é de 4,3 anos, de acordo com a pesquisa Machine Identity Management 2024 da Venafi. Engenheiros entram, geram um par de chaves, colam a chave pública em authorized_keys em cada servidor que precisam — e depois nada muda quando saem. Checklists de desligamento perdem servidores. As chaves continuam vivas.

Os problemas estruturais dos pares de chave SSH em escala:

Sem expiração. Uma chave criada em 2019 continua válida em 2026 a menos que alguém a remova manualmente de todos os arquivos authorized_keys de todos os servidores onde foi adicionada.
Sem revogação centralizada. Se uma chave privada for roubada ou um notebook perdido, revogar o acesso significa fazer SSH em cada servidor afetado e editar o authorized_keys. Em um ambiente de 200 servidores, isso leva horas — se você souber quais servidores têm a chave.
Sem trilha de auditoria. O sshd registra qual impressão digital da chave autenticou uma sessão, mas não há registro autoritativo que conecte essa impressão digital à identidade de um engenheiro específico no momento da emissão. Impressões digitais de chaves não são identidades.
Risco de movimento lateral. Uma chave roubada concede acesso a todos os servidores onde foi adicionada. Não há restrição de escopo, limite de tempo ou maneira de limitar uma chave a um IP de origem específico após a emissão.

Nada disso é hipotético. A violação do Twitter em 2020 envolveu um insider usando acesso SSH obtido por engenharia social. A proliferação de chaves tornou o escopo do incidente significativamente mais difícil.

Como funcionam os certificados SSH

Uma Autoridade Certificadora (CA) SSH é, ela mesma, apenas um par de chaves SSH — tipicamente ed25519. Em vez de distribuir chaves públicas de usuários para servidores, você configura os servidores para confiar na chave pública da CA. A CA então assina as chaves públicas individuais dos usuários para produzir certificados.

Um certificado SSH assinado inclui os seguintes campos:

Principals: a lista de nomes de usuário ou grupos para os quais este certificado é válido (ex.: alice, eng-team)
Valid after / Valid before: timestamps rígidos — o certificado é criptograficamente inválido fora dessa janela
Restrição de endereço de origem: faixa de IP opcional de onde este certificado pode ser usado
Extensões: capacidades como permit-pty, permit-port-forwarding, permit-agent-forwarding — cada uma pode ser concedida ou negada por certificado
Número de série do certificado: um identificador único que aparece nos logs de autenticação do sshd

O sshd_config do servidor contém uma única linha: TrustedUserCAKeys /etc/ssh/ca_user_key.pub. Essa é a única mudança de configuração necessária. Chega de gerenciar arquivos authorized_keys.

Configurando sua própria CA em 15 minutos

Você não precisa de Teleport ou HashiCorp Vault para começar. O OpenSSH já vem com tudo que é necessário.

Passo 1 — Gere a chave da CA em um host seguro:

ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "SSH User CA"

Mantenha ca_user_key (privada) offline ou em um gerenciador de segredos. Distribua ca_user_key.pub para cada servidor.

Passo 2 — Configure o sshd em cada servidor:

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

Recarregue o sshd. O servidor agora aceitará qualquer certificado assinado por esta CA, sujeito às restrições de principal e validade.

Passo 3 — Emita um certificado para um usuário:

ssh-keygen -s ca_user_key -I "[email protected]" -n alice -V +8h alice.pub

Isso produz alice-cert.pub. A flag -I define o ID da chave (registrado na autenticação), -n alice define o principal, -V +8h o torna válido por 8 horas a partir de agora.

Passo 4 — O usuário se conecta normalmente:

ssh alice@prod-server-01

O OpenSSH apresenta automaticamente o certificado junto com a chave privada. Nenhuma mudança no fluxo de trabalho do usuário.

Certificados de curta duração + plataformas de identidade

A emissão manual de certificados funciona para equipes pequenas. Para produção em escala, você quer emissão automatizada vinculada ao seu provedor de identidade.

Teleport atua tanto como CA SSH quanto como camada de proxy. Engenheiros autenticam via Okta ou Azure AD SSO, o Teleport emite um certificado de curta duração (padrão de 12 horas) e toda a atividade da sessão é registrada. Revogar acesso significa remover o usuário do grupo no IdP — nenhuma alteração no servidor é necessária.

HashiCorp Vault SSH Secrets Engine fornece a funcionalidade de CA sem a camada de proxy. Configure um role no Vault:

vault write ssh/roles/eng-ssh \
  key_type=ca \
  allowed_users="*" \
  default_user=ubuntu \
  ttl=8h \
  max_ttl=24h \
  allowed_extensions="permit-pty,permit-port-forwarding"

Engenheiros autenticam no Vault (via OIDC/Okta/Azure AD + MFA), solicitam um certificado com vault ssh -role eng-ssh -mode ca -mount-point ssh user@host e recebem um certificado com tempo limitado. O Vault registra cada emissão com a identidade do solicitante.

AWS EC2 Instance Connect usa o mesmo modelo nativamente para instâncias EC2 — envia uma chave pública temporária (válida por 60 segundos), conecta, pronto. Sem authorized_keys persistente.

A revogação de chaves em qualquer um desses sistemas é instantânea. Parar a CA de emitir novos certificados para um usuário significa que todos os seus certificados existentes expiram em no máximo algumas horas. Compare isso com a caça manual a entradas de chaves em centenas de servidores.

Certificados de host: a outra metade

Certificados SSH funcionam nos dois sentidos. Certificados de usuário autenticam usuários nos servidores; certificados de host autenticam servidores nos usuários.

Sem certificados de host, o SSH usa TOFU (Trust On First Use) — na primeira vez que você se conecta a um host, é solicitado a aceitar sua impressão digital. Isso é vulnerável a ataques MITM via chaves de host falsas, e o prompt treina engenheiros a ignorar avisos de segurança.

Com uma CA de host, você assina a chave de host de cada servidor:

ssh-keygen -s ca_host_key -I "prod-server-01" -h -n prod-server-01,10.0.1.5 -V +52w /etc/ssh/ssh_host_ed25519_key.pub

Adicione a CA ao known_hosts do cliente:

@cert-authority *.internal.example.com ssh-ed25519 AAAA... SSH Host CA

Agora cada servidor da sua frota é automaticamente confiável por todos os clientes. Sem prompts de impressão digital. Sem TOFU. Se um servidor for comprometido e sua chave de host mudar, os clientes rejeitarão a conexão imediatamente.

A trilha de auditoria que você realmente ganha

Com a autenticação baseada em certificados, cada evento de login carrega um número de série do certificado. Habilite o registro detalhado no sshd_config:

LogLevel VERBOSE

As entradas do log de autenticação agora ficam assim:

Accepted publickey for alice from 10.0.1.22 port 52341 ssh2: ED25519-CERT SHA256:... ID [email protected] (serial 42) CA ED25519 SHA256:...

O serial 42 mapeia de volta para uma entrada específica de emissão do Vault ou evento de auditoria do Teleport com o contexto completo de identidade: quem solicitou o certificado, quando, de qual IP, após autenticar via qual método MFA. Essa é a trilha de auditoria que ferramentas SIEM e auditores de conformidade realmente precisam — não uma impressão digital de chave divorciada de qualquer identidade.

Caminho de migração

Migrar uma frota existente é direto se feito na ordem certa:

Audite primeiro. Execute find / -name authorized_keys 2>/dev/null em toda a sua frota (ou use uma ferramenta de gerenciamento de configuração). Documente cada chave, quando foi adicionada e quem a possui.
Adicione confiança na CA sem remover chaves existentes. Adicione TrustedUserCAKeys ao sshd_config em todos os servidores. A autenticação baseada em chave existente continua funcionando.
Emita certificados para todos os engenheiros. Peça que cada engenheiro gere um novo par de chaves e o faça assinar, ou inscreva-se no Teleport/Vault para obter emissão automatizada de certificados.
Execute em paralelo por 30 dias. Ambos os métodos funcionam durante essa janela. Monitore os logs de autenticação para confirmar que todos os logins de produção estão vindo via certificados.
Remova as chaves brutas. Após 30 dias de logins limpos apenas com certificados, remova as entradas antigas de authorized_keys.
Chave de emergência. Mantenha um par de chaves de longa duração em um cofre de segredos lacrado (ex.: HashiCorp Vault com política de quebra de vidro) para acesso emergencial se a CA ficar indisponível. Audite o acesso a ela trimestralmente.

A migração não exige nenhum tempo de inatividade e os engenheiros quase não notam mudanças em seu fluxo de trabalho diário — exceto que não recebem mais prompts de impressão digital para novos servidores.

A conclusão

SSH baseado em certificados não é mais complexo de usar do que autenticação por chave. Para engenheiros, a experiência é idêntica ou mais simples — sem distribuição manual de chaves, sem prompts de impressão digital, sem "cole sua chave pública neste thread do Slack." Para equipes de segurança, oferece controle centralizado, revogação instantânea, expiração forçada e uma trilha de auditoria por sessão vinculada a identidades reais. As ferramentas — OpenSSH, Teleport, HashiCorp Vault, AWS EC2 Instance Connect — são maduras e bem documentadas. A única coisa que impede a maioria das equipes de migrar é a inércia.