Como Eliminar Ficheiros authorized_keys Espalhados Usando Certificados SSH com step-ca

Gerir frotas de servidores Linux através de ficheiros ~/.ssh/authorized_keys estáticos é uma dívida técnica e de segurança que quase todas as equipas acumulam. À medida que colaboradores entram, saem ou mudam de projeto, chaves públicas perpétuas (ssh-rsa ou ssh-ed25519) ficam esquecidas em dezenas de máquinas virtuais e nós de computação sem qualquer registo central de auditoria.

Se o portátil de um programador for comprometido por malware ou se uma chave privada for copiada indevidamente, o atacante obtém acesso permanente e silencioso ao coração dos servidores de produção. Em setores regulados como Fintech Startups (Neobanks) ou nós de cálculo em Astronomia e Observatórios Espaciais, este modelo de chaves estáticas viola diretamente as exigências de controlo de acessos das normas ISO 27001, SOC 2 e NIS2.

A solução Zero-Trust recomendada pelo setor não passa por gerir chaves manuais com Ansible, mas por erradicar completamente os ficheiros authorized_keys. Ao implementares uma Autoridade de Certificação (SSH CA) interna com o step-ca ligada ao teu fornecedor de identidade (OIDC com MFA/Passkeys), os engenheiros deixam de ter chaves permanentes: autenticam-se no início do dia e recebem certificados criptográficos OpenSSH temporários válidos apenas por 12 horas.

No Webxtek Studio, onde desenhamos arquiteturas blindadas para ambientes críticos, esta abordagem estende a estratégia de fecho de portas e redução de superfície de ataque apresentada no nosso Alerta CISA, NSA e FBI: Blindagem PHP, Node e Portas Expostas.

Abaixo explico como funciona a criptografia dos certificados OpenSSH e apresento o guia de implementação passo a passo com step-ca no Linux.

1. Das Chaves de Latão aos Cartões Temporários: A Arquitetura de Certificados Nativos do OpenSSH

Para eliminares os ficheiros authorized_keys estáticos na tua frota Linux, tens de criar uma Autoridade de Certificação SSH com o step-ca, configurar a diretiva TrustedUserCAKeys e AuthorizedPrincipalsFile no sshd_config dos servidores e autenticar os engenheiros via OIDC para emitir certificados ssh-ed25519-cert-v01@openssh.com com validade de 12 horas.

Muitos administradores de sistemas usam o OpenSSH há mais de uma década sem saberem que, desde a versão 5.4, o protocolo suporta nativamente uma infraestrutura completa e ultraleve de Autoridade de Certificação (SSH CA), documentada ao detalhe no manual oficial do OpenBSD para o sshd_config.

Ao contrário dos complexos certificados X.509 usados no HTTPS (que exigem bibliotecas pesadas de parsing ASN.1), os certificados do OpenSSH (ssh-ed25519-cert-v01@openssh.com) são estruturas binárias minimalistas e determinísticas desenhadas especificamente para acesso a terminais. Um certificado OpenSSH contém a chave pública efémera do utilizador junta com metadados invioláveis assinados criptograficamente pela chave privada da tua Autoridade de Certificação (CA):

Fluxo de Autenticacao SSH Zero-Trust com step-ca e OIDC:
1. Inicio do Turno (09:00):
   O engenheiro executa 'step ssh login' no terminal do seu portatil.
2. Validacao de Identidade:
   O step-ca redireciona para o Identity Provider corporativo (OIDC + FIDO2 Passkey).
3. Emissao em RAM:
   O step-ca gera um par de chaves efemero e assina um Certificado de Utilizador:
   - Identidade (Key ID): "josue@webxtek.com"
   - Principals (Roles autorizadas): ["sre-prod", "web-deploy"]
   - Validade Temporal: Das 09:00 as 21:00 de hoje (TTL de 12 horas)
   - Chave injetada diretamente no ssh-agent na memoria RAM (zero chaves privadas no disco).
4. Ligacao ao Servidor:
   O engenheiro corre 'ssh root@srv-db-01.x078.internal'.
5. Verificacao Matematica Offline:
   - O servidor Linux le /etc/ssh/ssh_user_ca.pub (TrustedUserCAKeys).
   - Confirma a assinatura matematica da CA, valida o relogio e confirma que o principal
     "sre-prod" consta em /etc/ssh/auth_principals/root.
   - Acesso concedido instantaneamente sem qualquer ficheiro ~/.ssh/authorized_keys!

Repara nas duas vantagens arquiteturais gigantescas deste modelo, suportado pela ferramenta open-source Smallstep step-ca:

• Fim do Pesadelo do Trust On First Use (TOFU): No SSH tradicional, da primeira vez que te ligas a um servidor novo, aparece o famoso aviso “The authenticity of host … can’t be established”. Na prática, toda a gente escreve yes sem confirmar o hash, abrindo a porta a ataques Man-in-the-Middle (MITM). Com uma Host CA, o step-ca também assina o certificado de identidade de cada servidor Linux (HostCertificate). Os portáteis da tua equipa têm apenas uma linha @cert-authority *.x078.internal no seu ficheiro known_hosts e reconhecem automaticamente qualquer servidor novo legítimo da empresa no primeiro milissegundo, bloqueando qualquer máquina impostora.
• Controlo de Acesso Baseado em Funções (RBAC via Principals): O servidor Linux não precisa de saber quem é o João, a Maria ou o Pedro. O servidor de base de dados apenas sabe que qualquer certificado válido que traga o Principal (etiqueta de função) role-db-admin pode entrar como postgres ou root, enquanto um certificado com o Principal role-frontend-dev só pode entrar nos servidores de staging como www-data. Para isolar ainda mais os utilizadores que precisam de SFTP, combinamos esta técnica com as diretivas de chroot documentadas no nosso guia de HestiaCP: Isolamento SSH com Jailkit e SFTP Seguro.

2. Implementação Passo a Passo no Terreno: CA Dupla, OIDC e Blindagem do sshd_config

Vou guiar-te pela configuração exata que aplicamos em servidores Debian 12 e Ubuntu 24.04 LTS em produção. Vamos configurar a Autoridade de Certificação, trancar os servidores de destino e automatizar o fluxo diário do programador.

Passo 1: Inicializar o step-ca com Suporte para Certificados SSH e Provisioner OIDC

Num servidor interno isolado e dedicado à gestão de identidades (ou dentro de uma enclave protegida por HSM / YubiKey HSM2), inicializamos o step-ca com a flag --ssh ativa. Isto gera duas chaves raiz independentes: uma User CA (para assinar certificados de pessoas) e uma Host CA (para assinar certificados de servidores):

# 1. Inicializar a PKI e Autoridade de Certificacao SSH (cria User CA e Host CA Ed25519)
step ca init \
  --ssh \
  --name="Webxtek Internal Zero-Trust PKI" \
  --dns="ca.internal.webxtek.com" \
  --address="127.0.0.1:9000" \
  --provisioner="admin@webxtek.com"

# 2. Adicionar o fornecedor Single Sign-On (Google Workspace, Okta, Keycloak ou Entra ID) via OIDC
step ca provisioner add "corporate-sso" \
  --type=OIDC \
  --ssh \
  --client-id="webxtek-ssh-ca-client-id" \
  --client-secret="SEGREDO_OIDC_AQUI" \
  --configuration-endpoint="https://accounts.google.com/.well-known/openid-configuration" \
  --domain="webxtek.com"

Depois de o step-ca estar ativo, extrai as duas chaves públicas raiz (ssh_user_ca_key.pub e ssh_host_ca_key.pub) que vais distribuir pela tua frota:

# Extrair a chave publica da User CA (vai para /etc/ssh/ssh_user_ca.pub em todos os servidores Linux)
step ssh config --roots > /tmp/ssh_user_ca.pub

# Extrair a chave publica da Host CA (vai para o known_hosts dos portateis da equipa)
step ssh config --host --roots > /tmp/ssh_host_ca.pub

Passo 2: Configurar e Assinar a Identidade do Servidor Linux (Host Certificate)

Em cada servidor Linux da tua frota (por exemplo, srv-prod-01.internal.webxtek.com), vamos assinar a chave pública do servidor (/etc/ssh/ssh_host_ed25519_key.pub) para que ele possa provar matematicamente a sua identidade aos clientes:

# No servidor de destino (srv-prod-01):
# 1. Copiar a chave publica da User CA para /etc/ssh/ssh_user_ca.pub
sudo install -m 0644 -o root -g root /tmp/ssh_user_ca.pub /etc/ssh/ssh_user_ca.pub

# 2. Emitir o certificado de Host para a chave Ed25519 do servidor (valido por 30 dias, renovado semanalmente)
sudo step ssh certificate \
  "srv-prod-01.internal.webxtek.com" \
  /etc/ssh/ssh_host_ed25519_key.pub \
  --host \
  --sign \
  --provisioner="admin@webxtek.com" \
  --principal="srv-prod-01.internal.webxtek.com" \
  --principal="10.20.30.15" \
  --not-after=720h

Isto gera o ficheiro /etc/ssh/ssh_host_ed25519_key-cert.pub diretamente ao lado da chave do servidor.

Passo 3: Blindar o /etc/ssh/sshd_config e Definir o Mapa de Principals (RBAC)

Agora vamos configurar o daemon do OpenSSH no servidor de produção para confiar na nossa User CA, mapear que funções (Principals) podem entrar em que utilizadores locais do Linux e desativar a leitura de ficheiros ~/.ssh/authorized_keys espalhados pelas pastas /home, impedindo que alguém tente deixar uma chave estática de backdoor num utilizador comprometido:

# 1. Criar a diretoria imutavel de Principals autorizados por utilizador do sistema
sudo mkdir -p /etc/ssh/auth_principals

# 2. Definir quem pode autenticar-se como 'root' ou 'sysadmin'
cat << 'EOF' | sudo tee /etc/ssh/auth_principals/root
sre-core
josue@webxtek.com
EOF

# 3. Definir quem pode autenticar-se como utilizador de deploy aplicacional 'deployer'
cat << 'EOF' | sudo tee /etc/ssh/auth_principals/deployer
sre-core
fullstack-devs
ci-deploy-bot
EOF

sudo chmod 0644 /etc/ssh/auth_principals/*

De seguida, cria o ficheiro de configuração /etc/ssh/sshd_config.d/10-webxtek-zero-trust-ca.conf:

# ============================================================================
# /etc/ssh/sshd_config.d/10-webxtek-zero-trust-ca.conf
# Arquitetura OpenSSH Zero-Trust por Certificados Efemeros (Webxtek Studio)
# ============================================================================

# 1. Apresentar o Certificado do Servidor assinado pela nossa Host CA
HostKey /etc/ssh/ssh_host_ed25519_key
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# 2. Confiar nos Certificados de Utilizador assinados pela nossa User CA
TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub

# 3. Mapear os Principals do certificado para o ficheiro correspondente ao utilizador Linux (%u)
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# 4. ERRADICAR CHAVES ESTATICAS: Ignorar qualquer ficheiro ~/.ssh/authorized_keys no disco!
AuthorizedKeysFile none

# 5. Criptografia Moderna Estrita e Desativacao de Passwords
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitRootLogin prohibit-password

# Restringir algoritmos apenas a curvas modernas Ed25519 e cifras AEAD (ChaCha20-Poly1305 / AES-GCM)
PubkeyAcceptedAlgorithms ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha25519,curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

# 6. Registo Forense Detalhado (Grava o ID do Certificado e numero de serie no journald)
LogLevel VERBOSE

Valida a sintaxe antes de recarregares o serviço SSH para garantires que não existem erros de configuração:

# Testar sintaxe do sshd e recarregar o daemon sem cortar sessoes ativas
sudo sshd -t && sudo systemctl reload ssh

Repara na linha AuthorizedKeysFile none combinada com PubkeyAcceptedAlgorithms ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com: a partir deste segundo, mesmo que um atacante consiga escrever uma chave pública num ficheiro /root/.ssh/authorized_keys, o daemon do OpenSSH nem sequer lê esse ficheiro e rejeita qualquer chave que não seja um certificado assinado pela tua CA. Para verificar continuamente que nenhum ficheiro do sistema foi adulterado, emparelhamos esta configuração com os playbooks de integridade de ficheiros do nosso guia de Wazuh SIEM no Linux: FIM e Resposta Ativa Automática. Se geres servidores partilhados onde terceiros necessitam de acesso a ficheiros, deves também confinar essas contas com o nosso playbook de HestiaCP: Isolamento SSH com Jailkit e SFTP Seguro.

3. A Experiência do Engenheiro e Auditoria Forense de Sessões

Muitas vezes, quando implementamos medidas rigorosas de cibersegurança, a equipa queixa-se de que o processo fica lento ou burocrático. Com certificados SSH via step-ca, acontece exatamente o oposto: a experiência de utilização (um princípio que valorizamos tanto na engenharia de sistemas como no nosso trabalho de Design UX/UI) torna-se mais rápida e fluida do que gerir dezenas de chaves no portátil.

O Fluxo Diário na Máquina do Engenheiro

Na estação de trabalho do programador, configuramos a confiança na Host CA uma única vez:

# 1. Configurar o portatil do engenheiro para confiar em todos os servidores assinados pela Host CA
echo "@cert-authority *.internal.webxtek.com,10.20.*.* $(cat /tmp/ssh_host_ca.pub)" >> ~/.ssh/known_hosts

# 2. Todas as manhas, autenticar via OIDC + MFA para injetar o certificado de 12h no ssh-agent (em RAM)
step ssh login josue@webxtek.com --provisioner="corporate-sso"

# 3. Inspecionar o certificado ativo na memoria RAM do ssh-agent
ssh-add -L | step ssh inspect

O comando step ssh inspect devolve a radiografia exata da credencial efémera que acabou de ser gerada em memória:

/dev/stdin:
  Type: ssh-ed25519-cert-v01@openssh.com user certificate
  Public key: ED25519-CERT SHA256:9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1f0a
  Signing CA: ED25519 SHA256:4d3c2b1a0f9e8d7c6b5a4f3e2d1c0b9a8f7e6d5c
  Key ID: "josue@webxtek.com"
  Serial: 14892039481029384
  Valid: from 2026-10-20T09:00:12 to 2026-10-20T21:00:12
  Principals:
    josue@webxtek.com
    sre-core
    fullstack-devs
  Critical Options: (none)
  Extensions:
    permit-X11-forwarding
    permit-agent-forwarding
    permit-port-forwarding
    permit-pty

Rastreabilidade Forense Total nos Logs do Servidor (journalctl)

Num servidor tradicional onde cinco administradores entram como root usando chaves copiadas para /root/.ssh/authorized_keys, quando olhas para os logs de sistema só vês Accepted publickey for root, tornando difícil provar a um auditor externo quem executou determinada operação.

Com certificados OpenSSH e LogLevel VERBOSE, cada login grava no /var/log/auth.log (e no journald) o e-mail exato do engenheiro (Key ID), o número de série único do certificado e a impressão digital da CA:

# Auditar no servidor quem entrou como 'root' ou 'deployer' e com que certificado exato
sudo journalctl -u ssh --since "today" | grep "Accepted publickey"
# Output real no log:
# Accepted publickey for root from 10.66.66.12 port 54312 ssh2: ED25519-CERT SHA256:9f8a... ID josue@webxtek.com (serial 14892039481029384) CA ED25519 SHA256:4d3c...

4. Comparativo Técnico: Chaves Estáticas (authorized_keys) vs. Arquitetura step-ca Zero-Trust

Na tabela seguinte contrasto a gestão tradicional de chaves SSH com o modelo de certificados efémeros que implementamos para clientes empresariais:

Quando apoias a evolução da tua arquitetura em Consultoria Técnica e entregas a operação diária das máquinas à nossa equipa de Alojamento Gerido, eliminas de uma só vez a dívida operacional de gerir acessos manuais e blindas o teu perímetro contra o roubo de credenciais.

5. Revogação de Emergência (RevokedKeys / KRL) e Checklist de Produção

E se o portátil de um engenheiro for roubado às 11:00 da manhã, quando o seu certificado temporário ainda tem mais 10 horas de validade até às 21:00? Para cobrir essa janela de horas, o OpenSSH suporta ficheiros binários ultracompactos chamados Key Revocation Lists (KRL) através da diretiva RevokedKeys /etc/ssh/revoked_keys:

# Revogar imediatamente um certificado especifico pelo seu numero de serie (Serial) numa emergencia
sudo ssh-keygen -k -f /etc/ssh/revoked_keys -s /etc/ssh/ssh_user_ca.pub <(echo "serial: 14892039481029384")

Antes de dares a migração para certificados SSH por concluída na tua empresa, valida estes cinco passos essenciais:

1. Mantém Uma Consola de Emergência Fora de Banda (Out-of-Band IPMI / KVM): Antes de aplicares AuthorizedKeysFile none e recarregares o sshd, mantém uma sessão SSH aberta com privilégios root num segundo terminal e confirma que tens acesso à consola série/KVM do teu datacenter (Hetzner vKVM, AWS Session Manager ou Proxmox Console).
2. Sincroniza o Relógio dos Servidores com Chrony (NTP): Como os certificados têm janelas temporais estritas, um servidor cujo relógio de sistema esteja atrasado ou adiantado 10 minutos vai rejeitar certificados recém-emitidos. Confirma com timedatectl status que System clock synchronized: yes está ativo em toda a frota.
3. Bloqueia Encaminhamento de Agente Desnecessário (AllowAgentForwarding no): Nos servidores de destino, desativa o AllowAgentForwarding no sshd_config. Se um engenheiro precisar de saltar de uma máquina de bastião para um servidor interno, deve usar obrigatoriamente ProxyJump (-J), que nunca expõe o socket do ssh-agent na máquina intermédia.
4. Automatiza a Renovação do HostCertificate: Configura um systemd.timer semanal em cada servidor Linux (step ssh renew /etc/ssh/ssh_host_ed25519_key-cert.pub /etc/ssh/ssh_host_ed25519_key) para que a identidade dos teus servidores nunca expire.
5. Apaga os Ficheiros ~/.ssh/authorized_keys Antigos do Disco: Depois de confirmares que toda a equipa entra via certificado step-ca, limpa os ficheiros authorized_keys legados para manteres a higiene forense do sistema.

A segurança real não consiste em dificultar a vida aos teus engenheiros com dez camadas de palavras-passe; consiste em substituir processos manuais falíveis por garantias matemáticas invisíveis. No Webxtek Studio, aplicamos este rigor criptográfico em todas as camadas das plataformas que construímos. Através de Consultoria Técnica, infraestruturas blindadas de Alojamento Gerido e excelência em Design UX/UI, ajudamos a tua empresa a operar com segurança de nível institucional e velocidade de execução máxima.