NoctisNode
← GuiasSegurança2026-10-238 min

SSH StrictModes, agent forwarding (ssh -A) e ssh -a explicados

O StrictModes do SSH recusa chaves se o home, o ~/.ssh ou o authorized_keys puderem ser escritos por outros; corrija com chmod. Evite ssh -A em hosts não confiáveis; ssh -a desativa o encaminhamento.

Resposta curta: `StrictModes yes` (o padrão do OpenSSH) faz o sshd verificar o dono e as permissões do seu diretório home, de `~/.ssh` e de `~/.ssh/authorized_keys` antes de aceitar uma chave, e recusa o login com "Authentication refused: bad ownership or modes" se qualquer um deles puder ser escrito pelo grupo ou por outros, ou pertencer a outro usuário. Corrija as permissões em vez de desativar a verificação. O agent forwarding com `ssh -A` permite que o host remoto use suas chaves locais enquanto você está conectado, então evite-o em hosts nos quais você não confia totalmente e use `ssh -J` (ProxyJump) no lugar; o `ssh -a` minúsculo desativa explicitamente o agent forwarding.

Este guia complementa o guia de hardening de SSH e se aplica ao Debian 12/13, ao Ubuntu 24.04 e a sistemas da família RHEL, como AlmaLinux 9 e Rocky 9.

O que o StrictModes do SSH verifica

StrictModes é uma configuração do lado do servidor em `/etc/ssh/sshd_config`. O objetivo é simples: se outro usuário pudesse escrever no seu `authorized_keys`, ele poderia adicionar a própria chave e entrar como você. Por isso o sshd se recusa a confiar no arquivo, a menos que todo o caminho esteja protegido. Ele verifica o arquivo e os diretórios acima dele, incluindo o diretório home.

Confirme o valor efetivo com `sshd -T | grep -i strictmodes`. No Ubuntu 24.04 e no Debian 13, confira também os arquivos drop-in em `/etc/ssh/sshd_config.d/`.

CaminhoExigência do StrictModesModo recomendado
/home/alicePertencer a alice ou ao root, sem escrita para grupo/outros755, 750 ou 700
/home/alice/.sshPertencer a alice ou ao root, sem escrita para grupo/outros700
/home/alice/.ssh/authorized_keysPertencer a alice ou ao root, sem escrita para grupo/outros600
/root e /root/.ssh (login como root)Pertencer ao root, sem escrita para grupo/outros700

Corrija "Authentication refused: bad ownership or modes"

O cliente mostra apenas um `Permission denied (publickey)` genérico. O motivo real está no log do servidor, que indica o caminho exato, por exemplo `Authentication refused: bad ownership or modes for directory /home/alice` ou `... for file /home/alice/.ssh/authorized_keys`. Use o console do seu VPS ou outra sessão para corrigir.

  1. 01.Leia o log: `journalctl -u ssh -n 50` no Debian e no Ubuntu, ou `journalctl -u sshd -n 50` no AlmaLinux e no Rocky.
  2. 02.Corrija o dono do diretório SSH do usuário: `chown -R alice:alice /home/alice/.ssh`.
  3. 03.Corrija os modos: `chmod 700 /home/alice/.ssh` e `chmod 600 /home/alice/.ssh/authorized_keys`.
  4. 04.Remova a escrita de grupo e de outros do diretório home: `chmod go-w /home/alice`.
  5. 05.Em sistemas com SELinux (AlmaLinux, Rocky, Fedora), restaure os rótulos: `restorecon -Rv /home/alice/.ssh`.
  6. 06.Teste a partir de um novo terminal com `ssh -v alice@server`, mantendo aberta a sessão que está funcionando.
# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys   # shows owner and mode of every path component

Note · Não defina `StrictModes no` para fazer o erro sumir. Isso remove uma proteção real e esconde a configuração errada em vez de corrigi-la.

StrictModes vs StrictHostKeyChecking

Buscas por "ssh strictmode" muitas vezes confundem duas opções sem relação. `StrictModes` fica no `sshd_config` do servidor e verifica permissões de arquivos. `StrictHostKeyChecking` fica no `ssh_config` ou no `~/.ssh/config` do cliente e controla o que acontece quando a chave de host de um servidor é desconhecida ou mudou. O cliente também tem a própria verificação de permissões: ele se recusa a usar uma chave privada que outros usuários conseguem ler, com um aviso sobre arquivo de chave privada desprotegido; `chmod 600 ~/.ssh/id_ed25519` resolve isso.

Agent forwarding com ssh -A: o risco

`ssh -A` (ou `ForwardAgent yes`) cria um socket no host remoto, referenciado por `$SSH_AUTH_SOCK`, que repassa pedidos de assinatura de volta ao ssh-agent da sua máquina. Sua chave privada nunca sai da sua máquina, mas qualquer um que acesse esse socket pode usar sua chave enquanto você estiver conectado. No host remoto, isso inclui o root e qualquer processo rodando como o seu usuário.

Se o servidor for comprometido, ou administrado por outra pessoa, um atacante pode entrar silenciosamente em todos os outros hosts que a sua chave abre, incluindo hospedagem Git e servidores de produção. É por isso que o cliente OpenSSH usa `ForwardAgent no` por padrão.

  • ▹Nunca encaminhe seu agent para hosts compartilhados, de terceiros ou recém-reinstalados que você ainda não reforçou.
  • ▹Se precisar encaminhar, use `ssh-add -c` para que cada uso da chave exija confirmação local.
  • ▹O OpenSSH 8.9 e versões mais novas suportam restrições de destino com `ssh-add -h`, limitando para quais hosts uma chave encaminhada pode ser usada.
  • ▹No lado do servidor, `AllowAgentForwarding no` no `sshd_config` o desativa, embora usuários com acesso ao shell ainda possam montar os próprios encaminhadores.

Prefira ProxyJump (ssh -J) para bastions

A maior parte do agent forwarding é usada para saltar por um bastion até uma máquina interna. O `ssh -J` faz isso sem expor seu agent: o bastion apenas repassa um fluxo TCP criptografado, e a autenticação no host interno acontece de ponta a ponta a partir do seu notebook. Para servidores acessíveis só por uma rede privada, um túnel WireGuard é outra opção; veja o guia de VPN WireGuard ou o guia de malha WireGuard e, para as configurações de keepalive e PSK, este guia de ajuste do WireGuard.

Num VPS NoctisNode você tem root completo via SSH numa máquina KVM, então um plano Wisp pequeno pode servir como jump host dedicado, sem mais nada rodando nele; veja os planos VPS.

# one-off
ssh -J [email protected] [email protected]

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
    ForwardAgent no

Host db1
    HostName 10.88.0.3
    User alice
    ProxyJump bastion

O que o ssh -a (minúsculo) faz

O `ssh -a` minúsculo desativa o agent forwarding naquela conexão, o oposto de `-A`. Ele é útil quando seu `~/.ssh/config` ativa `ForwardAgent` para um host curinga e você quer garantir que uma conexão específica não encaminhe, por exemplo `ssh -a admin@untrusted-host`. Não confunda com `ssh-agent -a`, que define o caminho do socket do agent, nem com `ssh-add`, que carrega chaves no agent.

Perguntas frequentes

QO que o StrictModes faz no sshd_config?

AEle faz o sshd verificar se o diretório home do usuário, o ~/.ssh e o authorized_keys pertencem ao usuário ou ao root e não podem ser escritos pelo grupo ou por outros. Se a verificação falhar, a autenticação por chave é recusada.

QComo corrijo Authentication refused: bad ownership or modes?

ARode `chmod go-w ~`, `chmod 700 ~/.ssh` e `chmod 600 ~/.ssh/authorized_keys` e garanta que os arquivos pertençam ao usuário. O log do servidor indica o caminho exato que está errado.

QO agent forwarding com ssh -A é seguro?

ASó em hosts nos quais você confia totalmente. Enquanto você está conectado, o root ou uma conta comprometida no host remoto pode usar seu agent encaminhado para se autenticar como você em outros lugares; use `ssh -J` no lugar.

QQual é a diferença entre ssh -A e ssh -a?

AO `-A` maiúsculo ativa o encaminhamento do seu ssh-agent para o host remoto. O `-a` minúsculo desativa o agent forwarding naquela conexão, sobrepondo qualquer `ForwardAgent yes` da sua configuração.

QDevo definir StrictModes no?

ANão. Desativá-lo permite logins mesmo quando outros usuários poderiam modificar seu authorized_keys, o que é uma falha de segurança real; corrija o dono e as permissões em vez disso.

SSH StrictModes, agent forwarding (ssh -A) e ssh -a explicados · NoctisNode