Blindar o SSH em Produção: Chaves FIDO2 ed25519-sk, Bastion Hosts e o Fim das Passwords

O Perigo das Passwords e das Chaves Privadas Guardadas no Teu Disco

Se geres servidores Linux em produção, o SSH é a tua principal ferramenta de trabalho diário. No entanto, em dezenas de auditorias técnicas, continuamos a encontrar os mesmos erros graves: logins por password ainda ativos para conveniência, acessos diretos como utilizador root com IP público e chaves privadas RSA guardadas sem qualquer palavra-passe no portátil de trabalho.

Se o teu computador for infetado por um infostealer descarregado num pacote duvidoso, os teus ficheiros ~/.ssh/id_rsa ou ~/.ssh/id_ed25519 são roubados em frações de segundo. Os atacantes vasculham repositórios no GitHub para descobrirem os IPs dos teus servidores e entram nos teus sistemas com privilégios máximos. Em 2026, a única forma profissional de administrares os teus nós é adotares chaves de hardware FIDO2, arquiteturas de bastion host e desativares autenticação por password sem exceções.

CHAVES EM DISCO VS. CHAVES FÍSICAS FIDO2 (ED25519-SK)

• CENÁRIO VULNERÁVEL (CHAVE TRADICIONAL GRAVADA NO DISCO): O Teu Computador → Ficheiro ~/.ssh/id_ed25519 no Disco
• (Risco de Roubo por Malware Local)
• Acesso Imediato do Atacante ao Teu Servidor
• CENÁRIO BLINDADO (CHAVE DE HARDWARE FIDO2 / YUBIKEY): O Teu Computador → Apenas Ponteiro sem Segredo Criptográfico
• (Exige Toque Físico com o Teu Dedo)
• Token de Hardware YubiKey: Assinatura no Chip de Segurança Isolado
• Ligação Autorizada com Segurança Criptográfica Inquebrável

Na Webxtek, seguimos uma política estrita de confiança zero: nenhuma credencial de administração crítica deve existir como um ficheiro exportável. Com a nossa consultoria técnica, ajudamos a tua equipa a implementar estas defesas para evitar falhas humanas.

Chaves de Hardware FIDO2: Como Gerar e Usar ed25519-sk

O OpenSSH suporta chaves de segurança FIDO2 nativamente através do algoritmo ed25519-sk. Ao contrário das chaves normais, a chave privada nunca sai do chip seguro da tua pen de hardware. No disco do teu computador fica apenas um ponteiro (key handle).

Para criares uma chave de segurança residente no teu token que exija a introdução de um PIN de hardware e a confirmação através de toque físico:

# Gera a tua chave de hardware protegida por PIN e presença física
ssh-keygen -t ed25519-sk -O resident -O verify-required -f ~/.ssh/id_ed25519_sk_prod

# Inspeciona a chave pública gerada para copiares para o servidor
ssh-keygen -y -f ~/.ssh/id_ed25519_sk_prod

DESAFIO E RESPOSTA CRIPTOGRÁFICA COM FIDO2

• 1. O Teu Cliente Pede Acesso SSH ao Servidor de Produção
• 2. O Servidor Envia um Desafio Criptográfico Aleatório (Nonce)
• 3. O Cliente SSH Transmite o Desafio para o Teu Token USB
• 4. O Teu Token Pisca a Luz LED e Pede o Teu Toque Físico
• 5. O Chip Criptográfico Assina o Desafio Internamente
• 6. A Resposta Volta ao Servidor → Sessão SSH Estabelecida!

Mesmo que um invasor tome controlo total do teu sistema operativo local via software malicioso, não consegue entrar no teu servidor de produção sem carregar fisicamente com o dedo no botão do teu token.

Configuração do Servidor: Hardening do /etc/ssh/sshd_config

A configuração que vem por defeito no OpenSSH costuma dar prioridade à compatibilidade com clientes antigos. Em instalações Debian, deves reforçar a segurança criando um ficheiro dedicado em /etc/ssh/sshd_config.d/99-hardened.conf:

# Porta e protocolo de escuta
Port 2222
AddressFamily inet

# Políticas de Autenticação Rígidas
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

# Controlo de Tentativas e Sessões
MaxAuthTries 3
MaxSessions 2
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Desativação de Funcionalidades Arriscadas
X11Forwarding no
AllowTcpForwarding yes
AllowAgentForwarding no

# Cifras Modernas e Rejeição de Algoritmos Fracos (RSA antigo e SHA-1)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com

Antes de reiniciares o serviço SSH, testa sempre a sintaxe para não correres o risco de fechar a tua própria ligação:

# Verifica se a configuração tem erros de escrita
sshd -t

# Recarrega o serviço de forma segura
systemctl reload ssh

Ao aplicares estas boas práticas recomendadas pela OWASP, fechas a porta a varrimentos automáticos que tentem explorar fraquezas criptográficas.

Bastion Jump Hosts: Protege os Teus Servidores em Sub-redes Privadas

Colocar os teus servidores de base de dados e sistemas internos diretamente com IPs públicos na Internet é um erro que deves corrigir imediatamente. Na arquitetura correta, apenas uma máquina isolada (o bastion host) tem um IP público. Todos os outros servidores comunicam exclusivamente através de uma rede interna privada.

ARQUITETURA DE BASTION HOST COM PROXYJUMP O Teu Portátil de Trabalho (Com o Token FIDO2) (Ligação SSH Encriptada / Porta 2222) SERVIDOR BASTION (Ponto de Entrada) IP Público Único: 203.0.113.10 (Sem bases de dados nem ficheiros web) (VLAN Privada 10.10.0.0/24 / Zero IPs Públicos)

• Nó de Apps: 10.10.0.15
• Base de Dados: 10.10.0.22

Nunca uses o antigo reencaminhamento de agente (ssh -A), porque se o servidor intermédio for comprometido, um invasor pode aceder ao socket da tua chave. Usa antes o ProxyJump (-J), que cria um túnel direto sem expor as tuas credenciais.

Adiciona esta configuração no teu ficheiro local ~/.ssh/config:

# Servidor Bastion de Entrada
Host bastion.interno
    HostName 203.0.113.10
    Port 2222
    User utilizadorsalto
    IdentityFile ~/.ssh/id_ed25519_sk_prod

# Base de Dados em Produção (Rede Privada)
Host db01.prod
    HostName 10.10.0.22
    User postgresadmin
    ProxyJump bastion.interno
    IdentityFile ~/.ssh/id_ed25519_sk_prod

Agora basta executares ssh db01.prod no teu terminal. O OpenSSH estabelece o túnel pelo bastion e conecta-te à máquina interna em segurança.

Auditoria de Sessões e Procedimentos de Emergência

Para manteres controlo rigoroso sobre quem acede aos teus servidores, ativa o registo de chaves no teu sshd_config com LogLevel VERBOSE. Isto regista a impressão digital de cada chave utilizada no diário do sistema (journalctl).

Para situações de emergência (caso percas o teu token físico durante uma deslocação), deves manter um par de chaves de emergência guardado num cofre seguro offline.

Ao juntares estas defesas com o nosso serviço de alojamento gerido e contratos estruturados de manutenção preventiva, asseguras que os teus servidores Linux operam sempre com os mais elevados padrões de segurança e disponibilidade da indústria.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como cibersegurança e cibersegurança b2b e inteligência corporativa. Quando alinhas a tua estrutura através de consultoria técnica antes de construir e alojamento gerido para websites e aplicações, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.