termalAs mensagens de erro do SSH são lacônicas de propósito — o protocolo não diz a um estranho por que o rejeitou. Isso é boa segurança e péssima ergonomia: a mensagem que você vê costuma estar a dois passos do problema real. Este é um guia prático dos treze erros que você de fato vai encontrar, o que cada um realmente significa e o caminho mais rápido para a correção.
Uma ferramenta antes de começar: ssh -v user@host (acrescente até -vvv — como ler essa saída (em inglês)). Quase todo mistério abaixo deixa de ser mistério assim que você vê em qual etapa do handshake ele morre.
Os erros num relance
| Erro | O que significa | Primeiro passo |
|---|---|---|
Connection refused | O host respondeu; nada escutando naquela porta | Verifique se o sshd está no ar e na porta que você discou |
Connection timed out | Pacotes sumiram no caminho | Verifique o firewall/security group da nuvem |
Permission denied (publickey) | Nenhuma chave que você ofereceu foi aceita | Verifique o usuário, depois a chave, depois o authorized_keys |
Permission denied (sem prompt) | A autenticação por senha está desativada; uma chave precisa funcionar | Use uma chave, ou entre pelo console do provedor |
Host key verification failed | A chave do servidor mudou desde que você confiou nela | Verifique por outro canal, depois ssh-keygen -R |
Too many authentication failures | O agente ofereceu chaves demais | -o IdentitiesOnly=yes com -i |
UNPROTECTED PRIVATE KEY FILE | O arquivo da chave pode ser lido por outros | chmod 600 na chave privada |
Broken pipe | Uma conexão ociosa foi derrubada | Adicione ServerAliveInterval |
no matching key exchange method | Servidor legado, cliente moderno | Reative um algoritmo só para aquele host |
Connection reset by peer | O TCP fechou de supetão antes do olá do SSH | Verifique o fail2ban / MaxStartups |
Bad configuration option | Seu cliente é velho demais para uma linha de config | Atualize o ssh, ou proteja a linha |
did not receive identification string | Algo conectou, mas não enviou banner | Geralmente um scanner; ignore no lado do servidor |
Unspecified GSS failure | Uma tentativa de Kerberos falhou e recuou | Ignore se o login ainda funcionar |
1. Connection refused
A máquina está acessível, mas nada está escutando na porta em que você bateu. Este quase nunca é sobre você:
- o sshd não está rodando —
systemctl status sshda partir de um console (provedores de VPS têm um console web para exatamente este momento); - ele escuta em uma porta fora do padrão — tente
ssh -p 2222, ou verifiquePortem/etc/ssh/sshd_config; - um firewall está ativamente rejeitando (em vez de descartar) a porta.
Se você acabou de reconstruir o servidor, é o firewall. Se funcionava ontem, o sshd caiu ou a porta mudou.
Correção completa: connection refused vs timed out, decifrados.
2. Connection timed out
Diferente de recusado: seus pacotes estão sumindo. O host está fora do ar, o IP está errado ou — na maioria das vezes em máquinas na nuvem — um security group / ACL de rede descarta silenciosamente a porta 22. Verifique primeiro as regras de firewall do provedor, depois se você está em uma rede que bloqueia a saída pela 22 (o Wi-Fi de visitantes de hotéis e escritórios adora isso; tente um acesso baseado na porta 443 ou uma rede diferente para confirmar).
Correção completa: o mesmo passo a passo de refused vs timed out tem o ramo do timed-out detalhado.
3. Permission denied (publickey)
O campeão de todos os tempos. O servidor só aceita autenticação por chave, e não aceitou nenhuma chave que você ofereceu. Em ordem de probabilidade:
- Usuário errado.
ubuntuem imagens Ubuntu,ec2-userno Amazon Linux,rootna maioria dos VPSes crus. A mesma chave com o nome de usuário errado produz exatamente este erro — cada imagem de nuvem escolhe seu próprio usuário de login, o que é metade do primeiro login em EC2/VPS (em inglês). - Sua chave não foi oferecida.
ssh -vmostra cada chave tentada. Se a sua chave não está na lista, aponte para ela explicitamente:ssh -i ~/.ssh/id_ed25519 user@host. - A chave não está no servidor. A metade pública dela precisa ser uma linha em
~user/.ssh/authorized_keys— daquele usuário, não do root. - Permissões no lado do servidor. O sshd se recusa a honrar o
authorized_keysse o diretório home, o~/.ssh(700) ou o próprio arquivo (600) tiver permissão de escrita para o grupo. Este é o clássico “copiei a chave e ainda não funciona”.
Correção completa: Permission denied (publickey), uma correção sistemática e rápida (em inglês) percorre cada culpado em ordem.
4. Permission denied quando você esperava um pedido de senha
Se você queria autenticação por senha e nunca foi perguntado, o servidor tem PasswordAuthentication no — a maioria das imagens de nuvem vem assim, e é o padrão certo. Use o console do provedor ou a sua chave existente para entrar, depois adicione a nova chave do jeito certo, em vez de reativar as senhas.
5. Host key verification failed / REMOTE HOST IDENTIFICATION HAS CHANGED
O banner assustador com energia de caveira em ASCII. O servidor apresentou uma chave diferente da que você confiou antes. Duas explicações: a máquina foi legitimamente reconstruída/reinstalada (de longe o caso comum), ou algo entre você e o servidor está se passando por ele (o caso para o qual o aviso existe).
Se — e somente se — você sabe que o servidor foi reconstruído: ssh-keygen -R hostname remove a entrada obsoleta, e a próxima conexão volta a confiar. Não roteirize cegamente essa remoção no seu fluxo de trabalho; a única vez em que o aviso é real, é o único aviso que você recebe.
Correção completa: Host key verification failed, e o jeito certo de corrigir (em inglês).
6. Too many authentication failures
Seu agente ofereceu com entusiasmo seis chaves, e o MaxAuthTries do servidor disse basta. Diga ao cliente para oferecer só a chave que você quer:
ssh -o IdentitiesOnly=yes -i ~/.ssh/the_right_key user@host…ou torne isso permanente em ~/.ssh/config por host. Se você carrega muitas chaves, IdentitiesOnly yes sob Host * vai lhe poupar deste erro para sempre.
7. WARNING: UNPROTECTED PRIVATE KEY FILE
Sua chave privada pode ser lida por outros, e o cliente se recusa a usá-la. chmod 600 ~/.ssh/id_ed25519. No Windows, isso aparece depois de copiar chaves entre máquinas ou de um drive na nuvem — corrija pelas propriedades de Segurança do arquivo, ou mantenha as chaves totalmente fora de pastas sincronizadas.
8. client_loop: send disconnect: Broken pipe (a sessão que morre quando você desvia o olhar)
Conexões ociosas derrubadas por um roteador NAT ou um firewall agressivo entre você e o servidor. Keepalives resolvem no lado do cliente:
Host *
ServerAliveInterval 30
ServerAliveCountMax 4Dois minutos de silêncio tolerados, pacotes a cada 30 segundos para que a tabela NAT nunca esqueça você. Se as sessões morrem sob carga em vez de ociosas, é outro bicho — olhe o MTU (VPNs especialmente), não os keepalives.
9. no matching key exchange method found / no matching cipher
Você está falando com algo antigo — um roteador, um switch, um appliance preso em criptografia legada. O OpenSSH moderno removeu esses algoritmos por um bom motivo. Reative-os só para aquele host, nunca globalmente:
Host ancient-switch
KexAlgorithms +diffie-hellman-group14-sha1
Ciphers +aes256-cbcA mensagem de erro nomeia os algoritmos que o servidor ofereceu; adicione o menos ruim que ela listar.
10. ssh_exchange_identification: read: Connection reset by peer
A conexão TCP abriu e foi fechada de supetão na mesma hora, antes mesmo de o SSH dizer olá. Suspeitos de sempre: o fail2ban ou o DenyHosts baniram o seu IP (verifique /etc/hosts.deny e a jail do fail2ban a partir de um console), o sshd está sobrecarregado (MaxStartups esgotado por um scanner martelando a porta), ou um health check de load balancer está comendo as conexões. Se for o fail2ban e for o seu próprio servidor, a correção é um login pelo console e fail2ban-client unban <your-ip> — depois tire o SSH do radar dos scanners ou aperte a jail para você não ser o dano colateral da semana que vem.
11. Bad configuration option: pubkeyacceptedalgorithms
Não é problema de servidor — o seu ssh local é velho demais para o seu arquivo de configuração. PubkeyAcceptedAlgorithms chegou no OpenSSH 8.5 (substituiu o PubkeyAcceptedKeyTypes); entregue essa linha a um cliente mais antigo — o ssh de fábrica de um macOS de certa idade, uma distro antiga, uma imagem mínima de contêiner — e ele se recusa a interpretar o arquivo por completo. Três saídas: atualize o cliente (ssh -V diz onde você está); use a grafia antiga PubkeyAcceptedKeyTypes, que as versões mais novas ainda aceitam como alias; ou proteja a linha para que só clientes capazes a leiam:
Match all
# only OpenSSH >= 8.5 gets here via Include ordering— na prática, a proteção mais simples é manter as opções sensíveis à versão em um arquivo separado puxado com Include, de modo que um cliente antigo sobre os mesmos dotfiles simplesmente o pule. O mesmo formato de erro (Bad configuration option: <something>) sempre significa a mesma coisa: aquela palavra é desconhecida para este binário — verifique primeiro a grafia da opção, depois a versão do binário.
12. did not receive identification string / invalid ssh identification string
Ambos vivem na primeira etapa do SSH — a troca de banner, antes de qualquer criptografia. did not receive identification string from <ip> é registrado no lado do servidor pelo sshd quando algo abriu uma conexão TCP na porta 22, mas nunca enviou a linha SSH-2.0-...: um port scanner, um health check de load balancer, uma sonda de monitoramento ou um cliente que desistiu. Nos logs do seu servidor, quase sempre é ruído de fundo, não um defeito — a menos que seja o seu cliente falhando ao conectar, caso em que algo no caminho (um proxy, um TCP wrapper, um IDS) está comendo o banner.
kex_exchange_identification: ... invalid ssh identification string é a imagem espelhada: algo respondeu, mas com dados que não são SSH. Causas de sempre, em ordem: você apontou o ssh para a porta errada — um servidor HTTP, um banco de dados, um portal cativo devolvendo HTML; um middlebox no caminho está interceptando a conexão e respondendo no lugar do servidor; ou uma má configuração de ProxyCommand/ProxyJump está canalizando para o cliente algo que não é um fluxo SSH — a página de erro de um proxy chegando onde deveria vir um banner. Confirme que você está mesmo falando com um sshd: nc <host> 22 deve imprimir um banner SSH-2.0-OpenSSH... imediatamente. Se imprimir HTML ou nada, a porta (ou o host, ou o salto do proxy) está errada, não a sua chave.
13. Unspecified GSS failure / debug1: unspecified GSS failure. Minor code may provide more information
Ruído de Kerberos. Por padrão, o OpenSSH tenta a autenticação GSSAPI (Kerberos) antes da sua chave e, se você não está em um realm Kerberos — o caso da maioria —, ela falha e registra isto em nível de debug, depois recua para a autenticação por chave e conecta normalmente. Se a conexão acaba dando certo, esta linha é inofensiva; ignore-a. Ela só importa se você realmente depende do SSO via Kerberos e a autenticação está falhando, caso em que é um problema real de ticket/realm (verifique klist, o desvio de relógio e o SPN do host no DNS). Para parar o ruído em uma configuração sem Kerberos, adicione GSSAPIAuthentication no à sua config.
Faça as correções durarem
Metade delas são correções pontuais; a outra metade merece uma linha em ~/.ssh/config para que nunca voltem — keepalives, IdentitiesOnly, portas e identidades por host. Config vence memória.
A outra coisa que vence a memória é um cliente que guarda o estado por você. O Termalin guarda as configurações por host — porta, usuário, chave, keepalives — junto do próprio host, verifica os servidores na primeira conexão e avisa alto quando uma impressão digital muda, e sua barra de status mostra os sinais vitais da máquina ao vivo, então “a máquina está sequer no ar?” deixa de ser um passo do diagnóstico. O plano Free não tem limite de hosts — pegue o Termalin e aposente alguns desses erros de vez.