Hardening de SSH 2026: Algoritmos, Certificados e Bastion Hosts

Toda vez que abrimos o shodan.io e filtramos por port:22, ainda descobrimos centenas de milhares de servidores aceitando ssh-rsa com SHA-1, password authentication exposta direto na internet e MACs como hmac-sha1. Em 2026 isso nao e configuracao legada esquecida: e divida tecnica que paga juros em forma de incidente. Hardening de SSH deixou de ser uma checklist de seis linhas no sshd_config e virou um pequeno subsistema com CA interna, bastion auditavel, material de chave de vida curta e telemetria centralizada. Este guia percorre o stack inteiro do jeito que a equipe Basilisk monta em laboratorio antes de levar para producao, com configuracao concreta, comandos reais e os modos de falha que a gente encontra o tempo todo.

Por que SSH ainda e a porta predileta do atacante

SSH e o protocolo de administracao remota de praticamente todo o Linux e da maioria dos equipamentos de rede, o que o torna a credencial de maior valor do parque. Atacantes o adoram porque uma unica chave ou senha valida entrega um shell interativo com os privilegios da conta alvo, sem cadeia de exploit. As tres causas raiz recorrentes sao: chaves reutilizadas ou nunca rotacionadas que sobrevivem ao funcionario que as criou; autenticacao por senha atacada por forca bruta a partir de botnets; e o downgrade para algoritmos fracos que permite a um atacante de rede manipular o handshake. Trate SSH como um sistema de identidade, nao como um utilitario. Cada decisao de projeto abaixo reduz uma dessas tres classes, e a ordem importa: conserte a autenticacao antes da telemetria, porque registrar uma invasao que voce nao consegue prevenir so diz quando voce perdeu.

Base de sshd_config que nao se negocia

Comece pelo daemon do servidor. Num /etc/ssh/sshd_config moderno, force PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no, UsePAM yes e PermitEmptyPasswords no. Adicione MaxAuthTries 3, LoginGraceTime 20 e ClientAliveInterval 300 para que sessoes semiabertas morram. Limite o alcance com AllowGroups ssh-users em vez de permitir cada conta local. Valide o arquivo antes de recarregar com sshd -t, e nunca edite a porta em producao sem uma segunda sessao aberta, porque um erro de digitacao num bloco Match pode te trancar do lado de fora. Essas diretivas sao o piso: nenhuma custa nada e todas removem uma primitiva de ataque.

Algoritmos modernos e troca de chaves pos-quantica

Restrinja KexAlgorithms para sntrup761x25519-sha512@openssh.com,curve25519-sha256, Ciphers para chacha20-poly1305@openssh.com,aes256-gcm@openssh.com e MACs para hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com. O hibrido sntrup761 entrega resistencia pos-quantica desde o OpenSSH 9.0, e em 2026 nao ha razao para nao habilitar: ele protege o trafego capturado hoje contra a decifragem quantica de amanha, o problema harvest-now-decrypt-later. Rode ssh-audit contra o host antes e depois. A diferenca entre nota C+ e A e basicamente desligar diffie-hellman-group14-sha1, cifras CBC e MACs truncados. Prefira as variantes etm (encrypt-then-MAC) porque autenticam o texto cifrado, nao o texto claro. Trate passar no ssh-audit como pre-requisito, nao como entrega.

Trocar chaves espalhadas por uma CA SSH interna

O salto real de maturidade vem ao aposentar os arquivos authorized_keys e emitir certificados. Gere um par de chaves de CA (ssh-keygen -t ed25519 -f ssh_user_ca) cuja metade privada viva apenas num HSM ou signatario offline, e assine certificados de usuario com TTL curto de 4 a 12 horas: ssh-keygen -s ssh_user_ca -I alice@corp -n alice -V +8h user_key.pub. Em cada servidor voce distribui apenas a chave publica da CA via TrustedUserCAKeys /etc/ssh/ca.pub. O usuario se autentica com um certificado emitido por step-ca, HashiCorp Vault SSH ou Teleport, amarrado ao SSO corporativo. Revogar acesso de um ex-funcionario deixa de ser caca a chaves em 400 hosts e vira simplesmente nao reemitir o certificado. Em pentests internos, essa unica mudanca quebra metade dos caminhos de movimentacao lateral baseados em chaves orfas, porque a chave roubada nao vale nada assim que seu certificado expira.

O bastion como proxy de identidade, nao como jump box

Um bastion endurecido nao e um Linux qualquer com SSH aberto. Pense nele como um proxy de identidade: ele recebe a conexao do usuario, valida o certificado contra a CA, registra a sessao inteira (input e output) e abre um segundo SSH para o alvo via ProxyJump. Teleport, HashiCorp Boundary e a combinacao step-ca + auditd + tlog cobrem esse caso. Numa configuracao tipica para um cliente de fintech, o bastion ficava em uma VPC isolada com Security Group permitindo apenas porta 22 da VPN corporativa, e os servidores internos recusavam qualquer SSH que nao viesse do CIDR do bastion. Isso colapsa a superficie de ataque de centenas de IPs alcancaveis pela internet para um unico ponto monitorado onde cada tecla e registrada e cada sessao e atribuivel a uma identidade humana.

Hardening do lado cliente e chaves ancoradas em hardware

Nao esqueca do cliente. Force ~/.ssh/config com HashKnownHosts yes, VerifyHostKeyDNS yes quando aplicavel, e gere uma chave ancorada em hardware com ssh-keygen -t ed25519-sk para que a metade privada nunca saia de uma YubiKey e cada autenticacao exija um toque fisico. Rode ssh-agent com confirmacao (ssh-add -c) para que uma workstation comprometida nao reutilize o socket do agente em silencio. Desabilite opcoes que voce nao precisa: AllowAgentForwarding no e AllowTcpForwarding no no servidor, a menos que um fluxo documentado exija, porque agent forwarding para um host nao confiavel permite que esse host sequestre seu agente enquanto o socket estiver vivo.

CI/CD e chaves de servico sem segredos de vida longa

Identidades de maquina costumam ser o lugar onde o acesso humano endurecido vaza de volta. Proiba chaves estaticas em CI. Em vez disso, emita certificados curtos via OIDC do GitHub Actions ou GitLab contra o seu Vault, para que um pipeline receba um certificado valido por minutos, limitado ao host exato que precisa alcancar. Isso elimina a classe inteira de incidentes onde uma chave vazada num log fica valida por anos. Para alvos de deploy, use blocos Match que amarram um certificado de servico a um unico comando com ForceCommand e PermitOpen, transformando um shell geral numa acao estreita e auditavel que nao pode ser reaproveitada em acesso interativo.

Logging centralizado e deteccoes que realmente disparam

Logging fecha o ciclo. Habilite LogLevel VERBOSE no sshd para registrar fingerprints de chave, envie /var/log/auth.log via journald-remote ou Fluent Bit para um Elastic ou Loki, e escreva regras Sigma para os padroes que importam: falhas repetidas seguidas de sucesso da mesma origem, login com certificado expirando em menos de uma hora, um principal de certificado que nao bate com o usuario do SSO, ou comandos suspeitos capturados por session recording. Em uma simulacao de red team, demoramos 11 minutos para sermos pegos reaproveitando uma chave roubada justamente porque o principal do certificado nao batia com a identidade do SSO e a regra de correlacao alertou. Sem essa correlacao, levariamos dias. SSH e uma das fontes de telemetria mais ricas e mais subutilizadas que voce possui.

Pegadinhas comuns que anulam seu hardening em silencio

Os erros recorrentes: deixar PermitRootLogin prohibit-password e dar por encerrado enquanto uma chave root compartilhada ainda existe; endurecer o daemon mas deixar ~/.ssh/authorized_keys gravavel pelo usuario, de modo que qualquer execucao de codigo readicione uma chave; esquecer que blocos Match sao avaliados de cima para baixo e um match amplo mais cedo esconde um estrito mais adiante; e rotacionar host keys sem atualizar a distribuicao de known_hosts, o que ensina os usuarios a ignorar avisos de host key. Outro assassino silencioso e um MaxStartups sem limite que deixa uma enxurrada de conexoes esgotar o daemon. Audite isso de forma explicita; nenhum aparece como erro, so deixam a porta encostada.

Checklist de hardening

Antes de declarar um host endurecido, verifique: nota A no ssh-audit; auth por senha e teclado-interativo desabilitada; login root desligado; apenas KEX, cifra e MAC modernos; certificados emitidos pela CA com TTL abaixo de 12 horas; TrustedUserCAKeys configurado e sem authorized_keys perdidos; ingresso apenas pelo bastion forcado na camada de rede; session recording ativo; logs VERBOSE enviados e pelo menos tres regras Sigma vivas; chaves de cliente ancoradas em hardware; sem chaves estaticas em CI; e um runbook de emergencia capaz de revogar e reemitir toda a frota em menos de uma hora. Se qualquer linha ficar sem marcar, o host nao esta pronto.

FAQ: SSH com certificado e exagero para um time pequeno?

Nao. Mesmo com cinco engenheiros, uma CA interna elimina o pior risco operacional, as chaves orfas, e se monta numa tarde com step-ca. O ponto de equilibrio nao e o tamanho da frota, e o momento em que uma segunda pessoa precisa de acesso a um segundo host, porque e ai que a gestao manual de authorized_keys comeca a derivar. Comece com um TTL de 8 horas amarrado ao seu provedor de identidade e cresca a partir disso.

FAQ: Habilitar sntrup761 quebra clientes antigos?

Clientes com OpenSSH anterior ao 9.0 nao negociam o KEX hibrido e simplesmente caem para curve25519-sha256, por isso voce o mantem na lista. A resposta pratica e atualizar clientes: qualquer workstation ainda num OpenSSH anterior ao 9.0 esta atrasada em patches por outros motivos. Mantenha o KEX pos-quantico primeiro na ordem de preferencia para que clientes modernos o obtenham automaticamente.

Takeaway pratico: monte um laboratorio com tres VMs (CA, bastion, alvo) usando step-ca, configure TTL de 8 horas, force os algoritmos modernos, rode ssh-audit ate tirar A e depois tente se autenticar com uma chave antiga. Se conseguir entrar, sua configuracao ainda nao esta hardenizada. Repita o exercicio a cada trimestre, rotacione a chave da CA anualmente e mantenha o runbook de emergencia testado. SSH continua sendo a porta de entrada predileta de atacantes em 2026 justamente porque tratamos como infraestrutura invisivel. Pare de tratar assim.