Diagnóstico de Conectividade SSH: Guia Prático para Sysadmins

✎ Duarte Spínola  |  2026-07-12

O SSH é o protocolo fundamental para administração de servidores Linux, dispositivos de rede e, cada vez mais, Windows Server com OpenSSH. Quando falha, o sysadmin perde acesso remoto e tem de recorrer à consola iLO/iDRAC ou deslocar-se fisicamente ao datacenter. As anomalias mais comuns são: impossibilidade de conectar (firewall, serviço parado, porta alterada), autenticação que falha (chaves corrompidas, known_hosts em conflito, permissões incorrectas), lentidão (DNS reverso, GSSAPI, MTU), e desligamentos inesperados (timeout, fail2ban, ClientAliveInterval). O diagnóstico começa sempre pelo modo verbose do próprio cliente SSH, que mostra exactamente em que fase a conexão falha. Referência: OpenSSH — documentação oficial.

O SSH usa a porta TCP 22 por defeito. Em ambientes hardened, é comum alterar para uma porta não-standard (ex: 2222, 10022). Isto não substitui a necessidade de firewall e fail2ban, mas reduz o ruído de bots que fazem port scan ao 22.

1. Camadas de Diagnóstico SSH

Camada Sintoma Ferramenta de diagnóstico
Rede Connection timeout, host unreachable ping, tcping, nc -zv
Firewall Connection refused (porta fechada) iptables -L, ufw status, nft list ruleset
Serviço sshd Connection refused (serviço parado) systemctl status sshd, ss -tlnp
Autenticação (chave) Permission denied (publickey) ssh -v, ssh-keygen -l, permissões
Autenticação (password) Permission denied (password) ssh -v, PAM, /var/log/auth.log
known_hosts WARNING: HOST IDENTIFICATION HAS CHANGED ssh-keygen -R, verificar MITM
DNS reverso Conexão demora 10-30 segundos a estabelecer sshd_config: UseDNS, GSSAPI
MTU SSH conecta mas comandos hang a meio ping -M do -s 1472, ssh -o IPQoS
fail2ban Connection refused após várias tentativas fail2ban-client status sshd
Cliente Versão incompatível, cipher mismatch ssh -V, ssh -Q cipher

2. Passo 1 — O Modo Verbose é a Primeira Ferramenta

O cliente SSH tem três níveis de debug que mostram exactamente o que está a acontecer em cada fase da conexão. Antes de qualquer outra coisa, correr:

<span style=”color:#6c7086;”># Nível 1 — resumo da negociação</span>
ssh -v utilizador@servidor

<span style=”color:#6c7086;”># Nível 2 — detalhe de autenticação e chaves</span>
ssh -vv utilizador@servidor

<span style=”color:#6c7086;”># Nível 3 — detalhe máximo (debug de pacotes)</span>
ssh -vvv utilizador@servidor

O output do verbose mostra a sequência de fases. Identificar onde para:

<span style=”color:#6c7086;”># Output típico do ssh -v:</span>
debug1: Connecting to servidor [192.168.1.100] port 22. <span style=”color:#6c7086;”># 1. Rede</span>
debug1: Connection established. <span style=”color:#6c7086;”># 2. TCP conectou</span>
debug1: Local version string: OpenSSH_9.9p1 <span style=”color:#6c7086;”># 3. Versão do cliente</span>
debug1: Remote protocol version 2.0, remote software <span style=”color:#6c7086;”># 4. Versão do servidor</span>
debug1: SSH2_MSG_KEXINIT sent <span style=”color:#6c7086;”># 5. Início de negociação</span>
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent <span style=”color:#6c7086;”># 6. Key exchange</span>
debug1: Host ‘servidor’ is known and matches ED25519 key <span style=”color:#6c7086;”># 7. known_hosts OK</span>
debug1: Authenticating that user can log in. <span style=”color:#6c7086;”># 8. Autenticação</span>
debug1: Next authentication method: publickey <span style=”color:#6c7086;”># 9. Tentar chave</span>
debug1: Offering public key: /home/user/.ssh/id_ed25519 <span style=”color:#6c7086;”># 10. Chave oferecida</span>
debug1: Server accepts key <span style=”color:#6c7086;”># 11. Chave aceite</span>
debug1: Authentication succeeded (publickey). <span style=”color:#6c7086;”># 12. Autenticado</span>
Onde para Camada afectada Próximo passo
Linha 1 (Connecting) Rede — não chegou ao servidor Verificar IP, rota, firewall (secção 3)
Linha 2 (Connection established) TCP OK — problema é SSH Continuar verbose
Linha 5-6 (KEXINIT/KEX) Key exchange — cipher mismatch Verificar ciphers suportados (secção 7)
Linha 7 (known_hosts) Host key changed Verificar se é legítimo (secção 5)
Linha 8-10 (Authenticating/publickey) Autenticação falha Verificar chaves e permissões (secção 4)
Linha 12 (Authentication succeeded) Autenticado mas sessão hang MTU, DNS, ou servidor (secções 6, 8)

3. Passo 2 — Conectividade de Rede

3.1 Testar TCP à porta 22

<span style=”color:#6c7086;”># Linux — testar conexão TCP à porta 22</span>
nc -zv servidor 22

<span style=”color:#6c7086;”># Output OK:</span>
<span style=”color:#6c7086;”># Connection to servidor 22 port [tcp/ssh] succeeded!</span>

<span style=”color:#6c7086;”># Output erro:</span>
<span style=”color:#6c7086;”># nc: connect to servidor port 22 (tcp) failed: Connection refused</span>
<span style=”color:#6c7086;”># → Serviço sshd parado ou firewall a rejeitar</span>

<span style=”color:#6c7086;”># Ou:</span>
<span style=”color:#6c7086;”># nc: connect to servidor port 22 (tcp) failed: Connection timed out</span>
<span style=”color:#6c7086;”># → Firewall a descartar pacotes (DROP) ou IP errado</span>

<span style=”color:#6c7086;”># Alternativa com tcping (mede latência)</span>
tcping servidor 22

3.2 Verificar se o serviço sshd está a correr

<span style=”color:#6c7086;”># No servidor — verificar estado do serviço</span>
systemctl status sshd

<span style=”color:#6c7086;”># Verificar se está a escutar na porta 22</span>
ss -tlnp | grep :22

<span style=”color:#6c7086;”># Output esperado:</span>
<span style=”color:#6c7086;”># LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:((“sshd”,pid=1234,fd=3))</span>
<span style=”color:#6c7086;”># LISTEN 0 128 [::]:22 [::]:* users:((“sshd”,pid=1234,fd=4))</span>

<span style=”color:#6c7086;”># Se não está a escutar, iniciar serviço:</span>
sudo systemctl start sshd
sudo systemctl enable sshd

<span style=”color:#6c7086;”># Verificar configuração do sshd (testar sintaxe)</span>
sudo sshd -t
<span style=”color:#6c7086;”># Output vazio = configuração OK</span>
<span style=”color:#6c7086;”># Output com erro = indicar linha do problema</span>

3.3 Verificar firewall

<span style=”color:#6c7086;”># iptables</span>
sudo iptables -L -n | grep 22
<span style=”color:#6c7086;”># Procure por: ACCEPT tcp dpt:22</span>

<span style=”color:#6c7086;”># UFW (Ubuntu/Debian)</span>
sudo ufw status
<span style=”color:#6c7086;”># Procure por: 22/tcp ALLOW Anywhere</span>

<span style=”color:#6c7086;”># Se a regra não existe, adicionar:</span>
sudo ufw allow 22/tcp
<span style=”color:#6c7086;”># Ou porta custom:</span>
sudo ufw allow 2222/tcp

<span style=”color:#6c7086;”># nftables (Debian 12+, RHEL 9+)</span>
sudo nft list ruleset | grep 22

<span style=”color:#6c7086;”># firewalld (RHEL/Fedora/Rocky)</span>
sudo firewall-cmd –list-services
sudo firewall-cmd –add-service=ssh –permanent
sudo firewall-cmd –reload

3.4 Verificar se a porta foi alterada

<span style=”color:#6c7086;”># No servidor — verificar porta configurada</span>
grep -i “^Port” /etc/ssh/sshd_config

<span style=”color:#6c7086;”># Output padrão:</span>
<span style=”color:#6c7086;”># Port 22</span>

<span style=”color:#6c7086;”># Se for diferente (ex: Port 2222), o cliente deve usar:</span>
ssh -p 2222 utilizador@servidor

4. Passo 3 — Autenticação com Chaves

4.1 Verificar chaves no cliente

<span style=”color:#6c7086;”># Listar chaves disponíveis</span>
ls -la ~/.ssh/

<span style=”color:#6c7086;”># Ficheiros esperados:</span>
<span style=”color:#6c7086;”># id_ed25519 — chave privada (permissões 600)</span>
<span style=”color:#6c7086;”># id_ed25519.pub — chave pública (permissões 644)</span>
<span style=”color:#6c7086;”># id_rsa — chave RSA (legacy, preferir ed25519)</span>
<span style=”color:#6c7086;”># known_hosts — chaves de servidores conhecidos</span>

<span style=”color:#6c7086;”># Verificar fingerprint da chave</span>
ssh-keygen -l -f ~/.ssh/id_ed25519.pub

<span style=”color:#6c7086;”># Output:</span>
<span style=”color:#6c7086;”># 256 SHA256:abc123… user@cliente (ED25519)</span>

4.2 Verificar permissões (causa #1 de falha de chave)

<span style=”color:#6c7086;”># Permissões críticas — se incorrectas, o SSH ignora a chave silenciosamente</span>
chmod 700 ~/.ssh/
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config
chmod 644 ~/.ssh/known_hosts

<span style=”color:#6c7086;”># No servidor — verificar permissões do authorized_keys</span>
chmod 700 ~/.ssh/
chmod 600 ~/.ssh/authorized_keys

<span style=”color:#6c7086;”># Verificar dono (deve ser o próprio utilizador, não root)</span>
chown -R $USER:$USER ~/.ssh/

O SSH é extremamente rigoroso com permissões. Se ~/.ssh/ tem permissões 777, ou se authorized_keys tem permissões 666, o sshd recusa a chave silenciosamente — não dá erro, simplesmente ignora a chave e passa para o próximo método de autenticação. O ssh -v mostra “Offering public key” mas não “Server accepts key”.

4.3 Verificar authorized_keys no servidor

<span style=”color:#6c7086;”># No servidor — verificar se a chave pública está no authorized_keys</span>
cat ~/.ssh/authorized_keys

<span style=”color:#6c7086;”># Deve conter a chave pública do cliente:</span>
<span style=”color:#6c7086;”># ssh-ed25519 AAAAC3Nz… user@cliente</span>

<span style=”color:#6c7086;”># Se não está, copiar do cliente:</span>
ssh-copy-id -i ~/.ssh/id_ed25519.pub utilizador@servidor

<span style=”color:#6c7086;”># Ou manualmente — no cliente:</span>
cat ~/.ssh/id_ed25519.pub
<span style=”color:#6c7086;”># Copiar output, colar no servidor em ~/.ssh/authorized_keys</span>

4.4 Debug de rejeição de chave

<span style=”color:#6c7086;”># Cliente — verbose mostra porque a chave é rejeitada</span>
ssh -vvv utilizador@servidor

<span style=”color:#6c7086;”># Procurar estas linhas:</span>
<span style=”color:#6c7086;”># debug1: Offering public key: /home/user/.ssh/id_ed25519</span>
<span style=”color:#6c7086;”># debug2: we sent a publickey packet, wait for reply</span>
<span style=”color:#6c7086;”># debug1: Authentications that can continue: publickey,password</span>
<span style=”color:#6c7086;”># → Se “Server accepts key” não aparece, a chave não está no authorized_keys</span>
<span style=”color:#6c7086;”># ou as permissões estão incorrectas</span>

<span style=”color:#6c7086;”># No servidor — verificar logs de autenticação</span>
sudo tail -f /var/log/auth.log <span style=”color:#6c7086;”># Debian/Ubuntu</span>
sudo journalctl -u sshd -f <span style=”color:#6c7086;”># systemd</span>
sudo tail -f /var/log/secure <span style=”color:#6c7086;”># RHEL/CentOS</span>

Referência: ssh-keygen — documentação.

5. Passo 4 — Conflito known_hosts

Quando um servidor é reinstalado ou a sua chave SSH muda, o cliente recusa conectar com o erro:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

5.1 Verificar se a mudança de chave é legítima

Antes de remover a entrada, confirmar que a mudança de chave é esperada:

  • O servidor foi reinstalado? Sim → legítimo
  • O IP foi reatribuído a outro servidor? Sim → legítimo
  • Nenhuma das anteriores → investigar (possível MITM)

5.2 Remover entrada antiga

<span style=”color:#6c7086;”># Remover entrada específica do known_hosts</span>
ssh-keygen -R servidor

<span style=”color:#6c7086;”># Output:</span>
<span style=”color:#6c7086;”># /home/user/.ssh/known_hosts updated.</span>
<span style=”color:#6c7086;”># Original contents retained as /home/user/.ssh/known_hosts.old</span>

<span style=”color:#6c7086;”># Reconectar — vai pedir para aceitar a nova chave</span>
ssh utilizador@servidor
<span style=”color:#6c7086;”># The authenticity of host ‘servidor’ can’t be established.</span>
<span style=”color:#6c7086;”># ED25519 key fingerprint is SHA256:xyz789…</span>
<span style=”color:#6c7086;”># Are you sure you want to continue connecting (yes/no)? yes</span>

Se a mudança de chave não é esperada, não aceitar a nova chave sem verificar com o administrador do servidor. Pode ser um ataque man-in-the-middle. Verificar a fingerprint do servidor através de canal seguro (consola iLO, telefone, etc.).

6. Passo 5 — Lentidão ao Estabelecer Conexão

6.1 DNS reverso (causa mais comum)

Por defeito, o sshd tenta resolver o IP do cliente para um nome (DNS reverso). Se o DNS reverso falha ou é lento, a conexão demora 10-30 segundos antes de pedir a password.

<span style=”color:#6c7086;”># Verificar se é DNS reverso — desactivar temporariamente no servidor</span>
sudo sshd -t <span style=”color:#6c7086;”># testar config</span>
sudo nano /etc/ssh/sshd_config

<span style=”color:#6c7086;”># Adicionar ou alterar:</span>
UseDNS no

<span style=”color:#6c7086;”># Reiniciar sshd</span>
sudo systemctl restart sshd

<span style=”color:#6c7086;”># Testar do cliente — deve conectar instantaneamente</span>
time ssh utilizador@servidor exit

6.2 GSSAPI (segunda causa mais comum)

O GSSAPI (Kerberos) tenta autenticar via Kerberos antes de tentar chaves/password. Se não há Kerberos, timeout.

<span style=”color:#6c7086;”># No cliente — desactivar GSSAPI</span>
ssh -o GSSAPIAuthentication=no utilizador@servidor

<span style=”color:#6c7086;”># Ou permanentemente em ~/.ssh/config:</span>
<span style=”color:#6c7086;”># Host *</span>
<span style=”color:#6c7086;”># GSSAPIAuthentication no</span>

6.3 Verificar tempo de conexão

<span style=”color:#6c7086;”># Medir tempo total de conexão</span>
time ssh -o ConnectTimeout=10 utilizador@servidor exit

<span style=”color:#6c7086;”># Decompor as fases:</span>
ssh -v -o GSSAPIAuthentication=no -o UseDNS=no utilizador@servidor exit 2>&1 | \
awk ‘/debug1:/{print strftime(“%H:%M:%S”), $0}’

6.4 Desactivar features desnecessárias

<span style=”color:#6c7086;”># No cliente — ~/.ssh/config para conexões rápidas:</span>
Host *
GSSAPIAuthentication no
GSSAPIDelegateCredentials no
UseDNS no <span style=”color:#6c7086;”># apenas afecta o cliente se fizer reverse lookup</span>
PreferredAuthentications publickey
Compression yes <span style=”color:#6c7086;”># útil em WAN lenta</span>
ServerAliveInterval 60
ServerAliveCountMax 3

Referência: ssh_config — documentação.

7. Passo 6 — MTU e Sessões que Hang

O SSH conecta mas comandos hang a meio da execução — especialmente em VPNs, túneis, ou ligações WAN com MTU reduzido. O TCP handshake passa (pacotes pequenos) mas comandos com output grande (ex: ls -la, cat ficheiro) hang porque os pacotes grandes são dropped.

7.1 Diagnosticar MTU

<span style=”color:#6c7086;”># Ping com tamanho máximo para detectar MTU problemático</span>
ping -M do -s 1472 servidor
<span style=”color:#6c7086;”># 1472 = MTU 1500 – 28 bytes (IP+ICMP headers)</span>

<span style=”color:#6c7086;”># Se falhar, reduzir:</span>
ping -M do -s 1400 servidor
ping -M do -s 1300 servidor

<span style=”color:#6c7086;”># Quando encontra o maior que passa, usar no SSH:</span>
ssh -o IPQoS=throughput -o [email protected] utilizador@servidor

<span style=”color:#6c7086;”># Ou definir MSS no cliente:</span>
ssh -o ProxyCommand=”nc -M 1300 %h %p” utilizador@servidor

7.2 Desactivar compressão (piora em MTU baixo)

<span style=”color:#6c7086;”># Se compressão está activa, desactivar para diagnóstico</span>
ssh -o Compression=no utilizador@servidor

8. Passo 7 — Desligamentos Inesperados

8.1 Timeout do servidor (ClientAliveInterval)

<span style=”color:#6c7086;”># No servidor — verificar timeout configurado</span>
grep -i “ClientAlive” /etc/ssh/sshd_config

<span style=”color:#6c7086;”># Output comum:</span>
<span style=”color:#6c7086;”># ClientAliveInterval 300 # 5 minutos</span>
<span style=”color:#6c7086;”># ClientAliveCountMax 3 # 3 tentativas = 15 minutos total</span>

<span style=”color:#6c7086;”># Se ClientAliveInterval é muito baixo, a sessão desliga por inactividade</span>
<span style=”color:#6c7086;”># Aumentar:</span>
sudo sed -i ‘s/^ClientAliveInterval.*/ClientAliveInterval 600/’ /etc/ssh/sshd_config
sudo systemctl restart sshd

8.2 Keepalive do cliente

<span style=”color:#6c7086;”># No cliente — enviar keepalive para evitar desligamento</span>
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 utilizador@servidor

<span style=”color:#6c7086;”># Ou em ~/.ssh/config:</span>
Host *
ServerAliveInterval 60
ServerAliveCountMax 3

8.3 fail2ban a bloquear

O fail2ban bloqueia IPs após várias tentativas falhadas. Se o utilizador tenta conectar com chave errada várias vezes, o IP é banido.

<span style=”color:#6c7086;”># Verificar se fail2ban bloqueou o IP</span>
sudo fail2ban-client status sshd

<span style=”color:#6c7086;”># Output:</span>
<span style=”color:#6c7086;”># Banned IP list: 192.168.1.50</span>

<span style=”color:#6c7086;”># Desbloquear IP manualmente</span>
sudo fail2ban-client set sshd unbanip 192.168.1.50

<span style=”color:#6c7086;”># Verificar regras de iptables criadas pelo fail2ban</span>
sudo iptables -L f2b-sshd -n

8.4 TCP wrappers (hosts.deny)

<span style=”color:#6c7086;”># Verificar se o IP está bloqueado em TCP wrappers</span>
cat /etc/hosts.deny | grep -i ssh
cat /etc/hosts.allow | grep -i ssh

<span style=”color:#6c7086;”># Se hosts.deny tem:</span>
<span style=”color:#6c7086;”># sshd: ALL</span>
<span style=”color:#6c7086;”># E hosts.allow não tem excepção para o IP, todas as conexões são recusadas</span>

9. Passo 8 — Logs do Servidor

9.1 Ver logs de autenticação

<span style=”color:#6c7086;”># Debian/Ubuntu</span>
sudo tail -f /var/log/auth.log | grep ssh

<span style=”color:#6c7086;”># RHEL/CentOS/Rocky</span>
sudo tail -f /var/log/secure | grep ssh

<span style=”color:#6c7086;”># systemd (qualquer distro)</span>
sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

<span style=”color:#6c7086;”># Procurar tentativas falhadas</span>
sudo journalctl -u sshd –since “1 hour ago” | grep -i “failed\|invalid\|refused”

9.2 Mensagens comuns nos logs

Mensagem Significado Solução
Connection from X port Y Conexão recebida Normal
Failed publickey for user from X Chave rejeitada Verificar authorized_keys e permissões
Invalid user user from X Utilizador não existe Verificar nome de utilizador
Connection closed by X Cliente desligou Normal se intencional
Connection reset by X Rede cortou Verificar firewall/VPN
error: kex_exchange_identification Banner exchange falhou Versão SSH incompatível ou rede
refused connect from X TCP wrappers bloqueou Verificar hosts.deny
max startups Demasiadas conexões simultâneas Aumentar MaxStartups em sshd_config

9.3 Aumentar logging do sshd para diagnóstico

<span style=”color:#6c7086;”># Temporariamente — aumentar log level para debug</span>
sudo sed -i ‘s/^<span style=”color:#6c7086;”>#LogLevel.*/LogLevel DEBUG3/’ /etc/ssh/sshd_config</span>
sudo systemctl restart sshd

<span style=”color:#6c7086;”># Reproduzir o problema</span>
<span style=”color:#6c7086;”># Analisar logs</span>
sudo journalctl -u sshd –since “5 min ago” –no-pager

<span style=”color:#6c7086;”># Restaurar para INFO quando terminar</span>
sudo sed -i ‘s/^LogLevel DEBUG3/LogLevel INFO/’ /etc/ssh/sshd_config
sudo systemctl restart sshd

Referência: sshd_config — documentação.

10. Passo 9 — SSH em Windows

10.1 OpenSSH no Windows Server

<span style=”color:#6c7086;”># Verificar se OpenSSH Server está instalado</span>
Get-WindowsCapability -Online | Where-Object Name -like “OpenSSH.Server*”

<span style=”color:#6c7086;”># Instalar</span>
Add-WindowsCapability -Online -Name “OpenSSH.Server~~~~0.0.1.0″

<span style=”color:#6c7086;”># Iniciar e activar serviço</span>
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

<span style=”color:#6c7086;”># Verificar firewall</span>
Get-NetFirewallRule -Name *ssh*

<span style=”color:#6c7086;”># Se não existe regra, criar:</span>
New-NetFirewallRule -Name sshd -DisplayName “OpenSSH Server” -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Referência: OpenSSH no Windows — Microsoft Learn.

10.2 Chaves em Windows

<span style=”color:#6c7086;”># Gerar chave em Windows</span>
ssh-keygen -t ed25519

<span style=”color:#6c7086;”># As chaves ficam em:</span>
<span style=”color:#6c7086;”># C:\Users\utilizador\.ssh\id_ed25519</span>
<span style=”color:#6c7086;”># C:\Users\utilizador\.ssh\id_ed25519.pub</span>

<span style=”color:#6c7086;”># authorized_keys em Windows Server (admin):</span>
<span style=”color:#6c7086;”># C:\ProgramData\ssh\administrators_authorized_keys</span>
<span style=”color:#6c7086;”># Permissões: apenas SYSTEM e Administrators</span>

<span style=”color:#6c7086;”># authorized_keys em Windows Server (user normal):</span>
<span style=”color:#6c7086;”># C:\Users\utilizador\.ssh\authorized_keys</span>

Em Windows, as permissões de authorized_keys são diferente. Para administradores, o ficheiro fica em C:\ProgramData\ssh\administrators_authorized_keys e deve ter permissões apenas para SYSTEM e Administrators. Se um utilizador normal tiver permissão de escrita, o sshd ignora a chave.

11. Erros Comuns e Resolução

  • “Connection refused” — serviço sshd parado ou porta incorrecta. Verificar systemctl status sshd e ss -tlnp | grep :22.
  • “Connection timed out” — firewall a descartar pacotes (DROP) ou IP errado. Verificar iptables -L -n, ufw status.
  • “Permission denied (publickey)” — chave não está no authorized_keys, permissões incorrectas em ~/.ssh/ ou authorized_keys, ou chave privada errada. Usar ssh -vvv para ver qual chave é oferecida e se é aceite.
  • “REMOTE HOST IDENTIFICATION HAS CHANGED” — chave do servidor mudou. Confirmar se é legítimo e usar ssh-keygen -R servidor.
  • “No route to host” — IP errado, gateway em falta, ou VPN desconectada. Verificar ip route e ping gateway.
  • SSH demora 20-30 segundos a conectar — DNS reverso ou GSSAPI. Desactivar UseDNS no no servidor e GSSAPIAuthentication no no cliente.
  • SSH conecta mas comandos hang — problema de MTU. Testar com ping -M do -s 1472 e reduzir MTU se necessário.
  • “Bad permissions” (Windows) — authorized_keys com permissões incorrectas. Usar icacls para restringir a SYSTEM e Administrators.
  • Sessão desliga por inactividade — ClientAliveInterval no servidor ou ServerAliveInterval no cliente. Configurar keepalive.
  • “Too many authentication failures” — cliente tem demasiadas chaves e todas são tentadas antes da correcta. Usar ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 para forçar apenas uma chave.
  • “no matching cipher found” — cliente e servidor não têm ciphers em comum. Verificar ssh -Q cipher no cliente e Ciphers em sshd_config no servidor.
  • fail2ban bloqueia repetidamente — chave SSH incorrecta ou password errada a falhar. Verificar fail2ban-client status sshd e desbloquear com fail2ban-client set sshd unbanip <IP>.

12. Checklist de Diagnóstico

  1. Modo verbose — ssh -vvv utilizador@servidor para identificar a fase que falha
  2. Rede — nc -zv servidor 22 para testar TCP à porta SSH
  3. Serviço — systemctl status sshd e ss -tlnp | grep :22 no servidor
  4. Firewall — iptables -L, ufw status, ou firewall-cmd --list-services
  5. Porta — verificar Port em sshd_config se não é a padrão 22
  6. Permissões — chmod 700 ~/.ssh/, chmod 600 authorized_keys no servidor
  7. Chave — ssh-keygen -l -f ~/.ssh/id_ed25519.pub para verificar fingerprint
  8. authorized_keys — confirmar que a chave pública está no servidor
  9. known_hosts — ssh-keygen -R servidor se a chave do servidor mudou
  10. DNS reverso — UseDNS no no servidor se conexão é lenta
  11. GSSAPI — ssh -o GSSAPIAuthentication=no se conexão é lenta
  12. MTU — ping -M do -s 1472 servidor se sessões hang
  13. Logs — journalctl -u sshd -f ou /var/log/auth.log para erros
  14. Keepalive — ServerAliveInterval 60 no cliente para evitar desligamentos
  15. fail2ban — fail2ban-client status sshd se IP foi bloqueado

13. Artigos Relacionados

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário