Chaves FIDO2 SSH: Como Blindar o Acesso ao Servidor Sem Virar Refém de Senhas

chaves FIDO2 SSH parece nome de tecnologia que só entra na pauta quando alguém compra um token USB caro e quer justificar a nota fiscal. Só que, na prática, ela resolve um problema bem menos glamouroso: servidor exposto, chave SSH copiada para três notebooks, senha de emergência esquecida num cofre digital e aquela sensação de que o acesso de produção está protegido mais por esperança do que por engenharia.

Eu gosto de automação, mas tem uma parte da automação que vive tentando nos sabotar: quanto mais fácil fica entrar em máquinas, rodar deploys e disparar scripts, mais provável é que uma credencial antiga fique dando sopa. Chaves FIDO2 SSH colocam uma barreira física nesse caos. O atacante pode roubar seu arquivo de chave; ele ainda vai precisar do token, do toque humano e, dependendo da configuração, do PIN. É menos “senha forte” e mais “sem o pedaço de plástico certo, boa sorte”.

O problema real: SSH ainda é a porta dos fundos mais subestimada

Todo mundo fala de firewall, WAF, antivírus, varredura de container, dashboard bonito e outras pulseiras fitness de infraestrutura. Mas o SSH continua lá, quieto, esperando alguém errar. Em muitos ambientes pequenos e médios, o acesso administrativo é um arquivo em ~/.ssh/id_ed25519, copiado para máquinas pessoais, agentes de deploy, notebooks antigos e talvez um backup sem criptografia. Aí o time chama isso de “simples”. Simples também é deixar a chave do carro em cima do pneu.

O ponto não é demonizar chaves SSH tradicionais. Elas são ótimas quando bem gerenciadas. O problema é que “bem gerenciadas” costuma significar rotação, inventário, passphrase forte, revogação rápida, separação por ambiente e disciplina. Ou seja: exatamente o tipo de coisa que times cansados prometem fazer depois do próximo deploy. Spoiler: depois do próximo deploy vem outro deploy.

O que são chaves FIDO2 SSH, sem fumaça de vendedor

FIDO2 é um padrão de autenticação que usa criptografia de chave pública com proteção contra phishing e, em muitos casos, presença física do usuário. Quando usado com OpenSSH, ele permite criar chaves do tipo ecdsa-sk ou ed25519-sk. O “sk” vem de security key. A chave privada não vira um arquivo comum exportável; ela é materializada pelo dispositivo FIDO2 quando você autoriza a operação.

Na prática: você tenta conectar no servidor, o SSH pede a assinatura, o token exige toque — e talvez PIN — e só então a autenticação acontece. Isso muda o modelo de risco. Um malware que copie sua pasta .ssh não consegue usar a chave sozinho. Um vazamento acidental no repositório não carrega a identidade completa. Um backup mal protegido deixa de ser o buffet livre do invasor.

Quando vale usar — e quando é exagero cafona

Use chaves FIDO2 SSH quando o acesso abre portas importantes: servidores de produção, bastion hosts, máquinas com banco de dados, contas com permissão de deploy, repositórios sensíveis e qualquer host que permita pivô para dentro da rede. É especialmente bom para times pequenos porque reduz a dependência de processos perfeitos. Você ainda precisa de processo, claro. Mas o hardware reduz a quantidade de tragédia possível por descuido humano, e isso já paga metade da terapia.

Talvez seja exagero para laboratório descartável, VM local sem segredos, ambiente efêmero ou host que já vive atrás de uma camada de acesso centralizada com certificados curtos e MFA forte. Segurança boa não é comprar todos os brinquedos; é colocar fricção onde ela realmente impede dano.

Pré-requisitos: não pule essa parte, campeão

Você precisa de um token compatível com FIDO2, como YubiKey, SoloKey, Nitrokey ou similar. Também precisa de OpenSSH relativamente moderno: suporte a security keys entrou no OpenSSH 8.2. Em distribuições atuais, isso costuma estar pronto. Em servidores jurássicos, você vai descobrir que “LTS” às vezes significa “Legado Tecnicamente Sofrível”.

• Cliente com OpenSSH 8.2 ou superior.
• Token FIDO2 configurado e testado no sistema operacional.
• Acesso alternativo temporário ao servidor para não se trancar do lado de fora.
• Backup administrativo: outro usuário, console do provedor ou janela SSH aberta.
• Política clara de revogação em authorized_keys.

Gerando a chave FIDO2 SSH

Para criar uma chave FIDO2 baseada em Ed25519, rode no cliente:

ssh-keygen -t ed25519-sk -C "alisson@automente-fido2" -f ~/.ssh/id_ed25519_sk_automente

O comando deve pedir interação com o token. Em muitos dispositivos, você toca no sensor. Em alguns sistemas, pode aparecer prompt de PIN. O arquivo privado criado no disco não é uma chave privada tradicional completa; ele funciona como um “handle” que precisa do token para assinar. Isso é o pulo do gato. Um atacante que rouba só o arquivo fica com um ingresso sem o estádio.

Se você quiser exigir verificação de usuário, quando suportado pelo token, use:

ssh-keygen -t ed25519-sk -O verify-required -C "alisson@automente-fido2" -f ~/.ssh/id_ed25519_sk_automente

Esse modo aumenta a segurança porque a autenticação passa a depender também do PIN ou biometria do token. É mais chato? Sim. Mas produção deveria ser um pouco chata. Se produção é confortável demais, provavelmente alguém está devendo auditoria.

Instalando a chave no servidor

Copie a chave pública para o servidor como faria com uma chave normal:

ssh-copy-id -i ~/.ssh/id_ed25519_sk_automente.pub usuario@servidor

Se preferir manualmente, adicione o conteúdo do arquivo .pub em ~/.ssh/authorized_keys no usuário remoto. Depois teste em uma nova sessão sem fechar a sessão antiga:

ssh -i ~/.ssh/id_ed25519_sk_automente usuario@servidor

Se funcionar, ótimo. Se não funcionar, respire antes de editar três arquivos ao mesmo tempo como se estivesse desarmando bomba em filme ruim. Verifique a versão do OpenSSH no servidor, permissões de ~/.ssh, logs de autenticação e suporte do cliente ao token.

Endurecendo o sshd sem cometer auto-sabotagem

Depois de validar o acesso com FIDO2, você pode endurecer o servidor. Eu recomendo fazer em etapas. Primeiro reduza senha. Depois restrinja usuários. Depois pense em portas, bastion e certificados. O erro clássico é mudar cinco controles de uma vez e descobrir que não sabe qual deles te expulsou.

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers deploy alisson
MaxAuthTries 3

Antes de reiniciar, valide a configuração:

sudo sshd -t
sudo systemctl reload ssh

Use reload quando possível, não restart no impulso. E mantenha uma sessão aberta. Parece conselho de iniciante porque é. Também é o conselho que salva gente experiente quando o café acaba.

Box perrengue técnico: eu já vi hardening virar sequestro do próprio servidor por causa de três linhas: PasswordAuthentication no, chave nova não testada e console do provedor com MFA quebrado. O post-mortem foi curto: “fomos corajosos onde deveríamos ter sido metódicos”. A regra é simples: nunca remova o caminho velho antes de provar que o caminho novo aguenta peso.

Configuração do cliente: pare de digitar caminhos como um monge penitente

Adicione um bloco no ~/.ssh/config para deixar o uso previsível:

Host automente-prod
    HostName exemplo.automente.com.br
    User deploy
    IdentityFile ~/.ssh/id_ed25519_sk_automente
    IdentitiesOnly yes
    PubkeyAuthentication yes

Agora o acesso vira:

ssh automente-prod

Essa pequena organização evita que o SSH tente oito chaves aleatórias antes da correta, reduz ruído em logs e deixa automações mais legíveis. Segurança não é só criptografia; é legibilidade operacional. O que ninguém entende, ninguém mantém.

E automações? CI/CD não vai tocar no token por você

Esse é o ponto que separa arquitetura de fantasia. Chaves FIDO2 SSH são excelentes para acesso humano privilegiado. Para CI/CD, jobs agendados e robôs, elas podem ser inviáveis porque exigem presença física. Não tente enfiar token humano em pipeline e chamar isso de DevSecOps. É só gambiarra com crachá.

Para automação, prefira identidades separadas: deploy keys limitadas, certificados SSH de curta duração, runners com escopo mínimo, OIDC quando disponível e ambientes que não carregam segredo além do necessário. O humano entra com FIDO2 para administrar. A máquina entra com credencial curta, auditável e revogável. Misturar os dois é pedir para o incidente chegar vestido de eficiência.

Revogação e perda do token: planeje antes do drama

Perder token é menos divertido do que perder guarda-chuva, mas não precisa virar novela. Tenha pelo menos duas chaves administrativas cadastradas: uma principal e uma reserva guardada com cuidado. Documente quem possui cada token, em quais servidores a chave pública está instalada e como remover acesso rapidamente.

• Crie uma chave FIDO2 principal para uso diário.
• Crie uma chave reserva em outro token físico.
• Guarde a reserva em local seguro e testado periodicamente.
• Mantenha inventário de authorized_keys por servidor.
• Revogue removendo a linha da chave pública comprometida.

Se o token sumiu, remova a chave pública associada e investigue. O arquivo no notebook sem o token provavelmente não basta para autenticar, mas “provavelmente” não é política de segurança. Faça a higiene completa.

Como auditar se você está melhorando ou só decorando o caos

Alguns sinais práticos mostram que a adoção funcionou. Primeiro: menos chaves privadas exportáveis circulando. Segundo: logs de SSH com usuários claros e identidades separadas. Terceiro: acesso de produção exigindo toque físico ou verificação de usuário. Quarto: processo de perda e revogação documentado. Quinto: ninguém precisou mandar “qual é a senha mesmo?” no chat. Esse último deveria ser métrica oficial de maturidade.

# Ver últimas tentativas de login em sistemas com journalctl
sudo journalctl -u ssh --since "24 hours ago"

# Conferir chaves autorizadas de um usuário
sudo awk '{print NR, $1, $3}' /home/deploy/.ssh/authorized_keys

Também vale combinar com boas práticas já discutidas no AutoMente, como SSH Certificate Authentication para ambientes com mais escala, idempotência em automações para evitar repetição destrutiva, e filas resilientes com SQLite quando você quer que tarefas falhem direito em vez de falhar artisticamente. A categoria Fortaleza Digital existe exatamente para esse tipo de blindagem pragmática.

Checklist de implantação em produção

1. Confirme versões do OpenSSH no cliente e servidor.
2. Gere chave ed25519-sk com comentário identificável.
3. Teste o token localmente.
4. Adicione a chave pública ao servidor sem remover acessos antigos.
5. Abra nova sessão SSH usando a chave FIDO2.
6. Valide logs e permissões.
7. Crie token reserva e documente.
8. Só então reduza senha, root login e usuários permitidos.
9. Revise inventário de chaves a cada ciclo de manutenção.

Erros comuns que fazem a adoção parecer pior do que é

O primeiro erro é comprar o token e tentar resolver cultura com embalagem lacrada. Se todo mundo continua usando a mesma conta compartilhada, a chave FIDO2 vira amuleto caro. Cada pessoa precisa de identidade própria, comentário claro na chave e permissão compatível com função. Conta genérica é confortável até o dia em que você precisa descobrir quem executou o comando que derrubou o serviço.

O segundo erro é não separar ambientes. A mesma chave que entra em staging não deveria necessariamente entrar em produção. Pode até ser a mesma pessoa, mas o nível de fricção precisa acompanhar o risco. Para produção, exigir verificação de usuário faz sentido. Para laboratório interno, talvez presença física baste. Segurança pragmática é calibrada, não histérica.

O terceiro erro é ignorar onboarding e offboarding. Quando alguém entra no time, a chave pública vai para os servidores certos. Quando sai, a chave sai também. Parece óbvio, mas metade dos incidentes operacionais nasce de obviedades abandonadas. Um arquivo authorized_keys sem dono vira cemitério de permissões, e cemitério de permissões sempre assombra em algum momento.

Conclusão: segurança boa é a que sobrevive ao cansaço

Chaves FIDO2 SSH não transformam uma infraestrutura bagunçada em fortaleza mágica. Elas não substituem patch, firewall, logs, backup, menor privilégio ou bom senso. Mas fazem uma coisa muito valiosa: tornam o roubo de credencial bem menos útil. E, no mundo real, reduzir utilidade do roubo já é uma vitória enorme.

Minha recomendação é começar pelos acessos humanos mais privilegiados. Um servidor crítico. Um bastion. Uma conta de deploy manual. Implante, teste perda de token, documente revogação e só depois expanda. Segurança que começa pequena e funciona vence segurança grandiosa que só existe no diagrama.

Agora me diz: qual automação ou rotina de infraestrutura você quer ver blindada no próximo laboratório do AutoMente? A melhor pauta quase sempre nasce daquele perrengue que você está empurrando com a barriga desde terça-feira.