SSH agent forwarding: riscos de segurança e guia ProxyJump

O SSH agent forwarding através da flag -A ou da diretiva ForwardAgent yes permite utilizar chaves privadas locais através de servidores de salto (bastion hosts) intermédios sem as copiar remotamente. Contudo, este mecanismo cria um socket UNIX que qualquer utilizador com permissões de root no jump server pode sequestrar para se autenticar noutros sistemas da sua rede.

A mecânica do sequestro de sockets no SSH agent forwarding

O OpenSSH armazena o socket de comunicação do agente num caminho temporário definido pela variável de ambiente SSH_AUTH_SOCK no host remoto, tipicamente em /tmp/ssh-XXXXXXXXXX/agent.<ppid>. Embora este descritor de ficheiro esteja restrito ao utilizador do sistema conectado por predefinição, o utilizador root ou qualquer processo com permissões ao nível do sistema nesse servidor intermédio tem acesso de leitura e escrita ao socket.

Quando um atacante compromete um jump server, não precisa de extrair as suas chaves privadas, uma vez que estas permanecem estritamente na memória do seu cliente local. Em vez disso, o atacante apenas aponta para a variável de ambiente sequestrada e solicita assinaturas criptográficas diretamente ao seu agente local ativo enquanto a sua sessão permanecer ligada:

# Locate active agent sockets from other connected users on the bastion
ls -la /tmp/ssh-*/agent.*

# Hijack the socket to authenticate toward internal infrastructure
export SSH_AUTH_SOCK=/tmp/ssh-AbCdEf1234/agent.5678
ssh [email protected]

O seu cliente local a executar o ssh-agent assinará o desafio recebido enviado pelo host de destino, incapaz de distinguir entre comandos iniciados por si e pedidos feitos pelo atacante. Esta exposição transforma qualquer bastion partilhado ou de perímetro numa ponte imediata de escalada horizontal de privilégios em toda a sua infraestrutura.

Comparação de segurança entre Agent Forwarding e ProxyJump

A diretiva ProxyJump, introduzida em versões modernas do OpenSSH e disponível através da flag de linha de comandos -J, elimina completamente a necessidade de expor um agente de autenticação em hosts intermediários. Com o ProxyJump, o seu cliente SSH local estabelece um fluxo TCP cifrado ponto a ponto diretamente para o sistema de destino através do stdio padrão, utilizando o jump host puramente como um router de transporte cego.

Ao recorrer ao ProxyJump, mesmo que um atacante controle o root no bastion intermédio enquanto estiver ligado, apenas observará tráfego cifrado em bruto a passar para a porta 22 de destino. Não terá qualquer acesso a assinaturas de autenticação arbitrárias.

Configurar bastion hosts de forma limpa em ~/.ssh/config

O OpenSSH impõe permissões estritas de 700 no diretório ~/.ssh e de 600 no ficheiro config e nas chaves privadas. Em vez de ativar o ForwardAgent yes globalmente—o que cria riscos de segurança significativos—a prática recomendada consiste em definir blocos de encaminhamento declarativos dentro do seu ficheiro de configuração local:

# Hardened ~/.ssh/config configuration
Host bastion
    HostName bastion.example.com
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

Host internal-node
    HostName 10.0.1.50
    User deploy
    IdentityFile ~/.ssh/id_production
    ProxyJump bastion

A ligação através de ssh internal-node conecta-se automaticamente através de bastion utilizando autenticação ponto a ponto. As infraestruturas modernas devem tirar partido de chaves Ed25519, suportadas desde o OpenSSH 6.5 (janeiro de 2014), ou chaves FIDO2 protegidas por hardware (ed25519-sk), suportadas desde o OpenSSH 8.2 (fevereiro de 2020). Note que as assinaturas legadas ssh-rsa com SHA-1 foram desativadas por predefinição desde o OpenSSH 8.8 (setembro de 2021).

Gerir sessões de salto seguras e fluxos de trabalho móveis

Em plataformas móveis, as chaves geradas dentro do terminal SSH e Mosh para iOS e Android termi1 permanecem protegidas no keystore de hardware ou no Secure Enclave, garantindo que as chaves privadas nunca saem do dispositivo. Ao gerir servidores remotos através de ligações móveis variáveis, o Mosh mantém o estado continuamente através de transições entre Wi-Fi e dados móveis usando as portas UDP 60000-61000.

No entanto, o Mosh não suporta reencaminhamento de portas nem tunelamento de agente. Ao aceder a hosts privados sem endereços IP públicos ou portas expostas, uma alternativa aos bastions de salto tradicionais é executar redes mesh como as redes mesh privadas sem portas abertas (Prialo) ou o Tailscale. Uma rede overlay mesh atribui endereços IP privados diretos a cada nó e cliente móvel, eliminando por completo a necessidade de bastions SSH multi-hop ou de agent forwarding.

Quando os bastion hosts clássicos são obrigatórios, funcionalidades de terminal móvel como teclas dedicadas fn, Ctrl e Esc evitam erros de sintaxe em ambientes de produção, enquanto funcionalidades como o Production Guard protegem a infraestrutura ao suspender comandos destrutivos antes de serem executados em hosts críticos.

Perguntas frequentes

Quando é aceitável utilizar ssh -A com agent forwarding?

O SSH agent forwarding só é aceitável ao ligar-se temporariamente a servidores fiáveis de utilizador único sob o seu controlo direto. Em servidores partilhados, bastions de terceiros ou jump hosts na cloud pública, reencaminhar o agente expõe o seu socket de autenticação e deve ser sempre substituído pelo ProxyJump.

Um atacante pode extrair a minha chave privada através de um socket sequestrado?

As chaves privadas não podem ser extraídas de um socket ssh-agent sequestrado, pois nunca saem da memória do dispositivo cliente. Um atacante apenas consegue abusar do socket para gerar assinaturas criptográficas de autenticação válidas contra servidores secundários enquanto a sua ligação SSH permanecer ativa.

Como é que a flag ProxyJump substitui o ForwardAgent na linha de comandos?

A flag ProxyJump substitui o agent forwarding na linha de comandos através da sintaxe -J sem exigir alterações de configuração. Executar ssh -J user@bastion user@destination estabelece um canal cifrado ponto a ponto diretamente até ao destino, contornando totalmente a criação de um socket de agente no servidor intermédio.

O Mosh suporta SSH agent forwarding ou reencaminhamento de portas?

O Mosh não suporta SSH agent forwarding, reencaminhamento de portas TCP ou de X11, visto que opera via UDP após estabelecer a sessão SSH inicial. Os utilizadores que gerem infraestruturas privadas com o Mosh devem ligar-se através de redes mesh como o Prialo ou utilizar SSH padrão para bastions.