Solucionando Erros Comuns de 'Permissão Negada' e Problemas de Conexão SSH

Um erro SSH Permissão negada geralmente significa que o servidor foi acessível, mas se recusou a autenticar você. Isso é diferente de Conexão expirou, Conexão recusada ou Sem rota para o host. Tratar todos esses como "SSH está quebrado" perde tempo, então comece separando falhas de autenticação de falhas de rede.

Execute o comando com falha com registro verboso:

ssh -vvv usuario@host_remoto

Você está procurando pistas claras: qual nome de usuário o cliente usou, quais arquivos de chave ele ofereceu, se o servidor aceitou alguma chave e quais métodos de autenticação permanecem. A maioria das correções abaixo vem de corresponder essas pistas ao estado do lado do servidor.

Entendendo o Fluxo de Autenticação SSH

Quando você tenta se conectar, o servidor permite apenas os métodos de autenticação habilitados em sua configuração. Um servidor típico tenta a autenticação por chave pública primeiro e pode permitir a autenticação por senha depois, dependendo da política:

1. Autenticação por Chave Pública: O cliente apresenta uma chave pública, e o servidor verifica se a chave privada correspondente é válida e corresponde a uma chave autorizada (arquivo authorized_keys).
2. Autenticação por Senha: Se a autenticação por chave falhar ou estiver desabilitada, o servidor solicita uma senha.

Quando você recebe Permissão negada, a conexão TCP funcionou. O servidor simplesmente não aceitou a credencial que você apresentou para aquele usuário.

Diagnosticando Problemas de Conexão: O Poder do Modo Verboso

A ferramenta mais eficaz para diagnosticar problemas de SSH é executar o cliente em modo verboso. Ao adicionar os sinalizadores -v, -vv ou -vvv, o cliente gera informações detalhadas de depuração sobre o processo de negociação.

Usando Sinalizadores Verbosos

Use a seguinte estrutura de comando:

ssh -vvv usuario@host_remoto

O que procurar na saída:

• Nome de usuário: Procure por Autenticando para ... como 'usuario'. Um nome de usuário Linux errado é um dos erros mais fáceis de passar despercebido.
• Chaves oferecidas: Procure por Oferecendo chave pública. Se a chave esperada nunca aparecer, corrija a configuração do cliente.
• Resposta do servidor: Se cada chave oferecida for seguida por Autenticações que podem continuar, o servidor rejeitou essas chaves.
• Métodos de autenticação: Se publickey não estiver listado, o servidor pode não permitir autenticação por chave para aquela conta ou bloco de host.

---

Resolvendo Permissão negada (publickey)

Este erro afirma explicitamente que o servidor rejeitou a credencial de chave pública fornecida. A correção geralmente está nas permissões ou no pareamento de chaves.

1. Verifique as Permissões do Arquivo de Chave (Lado do Cliente)

Por segurança, os clientes SSH são muito rigorosos quanto às permissões do seu arquivo de chave privada (por exemplo, ~/.ssh/id_rsa). Se esses arquivos estiverem muito abertos, o cliente se recusará a usá-los.

Certifique-se de que sua chave privada seja legível apenas por você:

chmod 600 ~/.ssh/id_rsa

2. Verifique a Existência da Chave e o Uso Correto da Chave

Certifique-se de estar se conectando com o arquivo de identidade correto, especialmente se você usar chaves não padrão ou vários pares de chaves.

Especifique a chave privada correta usando o sinalizador -i:

ssh -i /caminho/para/sua/chave_privada_especifica usuario@host_remoto

Se seu agente tiver muitas chaves carregadas, adicione IdentitiesOnly=yes para este teste:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod usuario@host_remoto

3. Permissões e Propriedade do Lado do Servidor

Esta é a fonte mais comum de falha de autenticação por chave. O SSH impõe permissões estritas de diretório e arquivo no servidor para o usuário com o qual você está tentando fazer login.

Caminho no Servidor	Permissões Necessárias	Proprietário
Diretório ~/.ssh	700 (rwx------)	Usuário
Arquivo ~/.ssh/authorized_keys	600 (rw-------)	Usuário

Faça login via console, console serial em nuvem, autenticação por senha ou outra conta de administrador e execute estes comandos como o usuário alvo ou com o caminho correto:

# Definir permissões do diretório
chmod 700 ~/.ssh

# Definir permissões do authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verificar propriedade (substitua 'meuusuario' pelo nome de usuário real)
chown -R meuusuario:meuusuario ~/.ssh

Se o diretório home do usuário for gravável por grupo ou outros, o OpenSSH também pode rejeitar a chave quando StrictModes estiver habilitado. Verifique com:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Para a maioria dos homes de usuário normais, 755 ou mais restritivo é suficiente.

4. Confirme que a Chave Foi Realmente Adicionada

Certifique-se de que a chave pública no cliente corresponda ao que foi colado no arquivo ~/.ssh/authorized_keys do servidor. Um caractere faltando, linha quebrada ou chave privada copiada causará falha de autenticação.

Ao adicionar uma chave, use ssh-copy-id se o acesso por senha ainda estiver disponível:

ssh-copy-id usuario@host_remoto

---

Solucionando Problemas de Arquivo de Configuração (sshd_config)

Se as chaves e permissões estiverem corretas, o problema geralmente está no arquivo de configuração do daemon SSH, normalmente localizado em /etc/ssh/sshd_config no servidor.

1. Verifique os Métodos de Autenticação

Certifique-se de que a autenticação por chave pública esteja explicitamente permitida.

Verificação de Configuração: Procure pelas seguintes linhas e certifique-se de que não estão comentadas (#) e configuradas corretamente:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Verifique também blocos Match perto do final do arquivo. Uma configuração global pode permitir chaves públicas, enquanto um bloco Match User, Match Group ou Match Address posterior pode desabilitá-las para o login exato que você está testando.

2. Status da Autenticação por Senha

Se você estiver dependendo temporariamente do login por senha, verifique se ele está habilitado. Se estiver definido como no, você deve usar chaves.

PasswordAuthentication yes

3. PermitRootLogin

Se você estiver tentando fazer login como root, certifique-se de que isso é permitido. A melhor prática geralmente é fazer login como um usuário padrão e usar sudo, mas para solução de problemas, você pode verificar esta configuração:

PermitRootLogin prohibit-password

Para login root, muitos sistemas padronizam para acesso root apenas por chave ou desabilitam completamente o login root. Prefira um usuário normal com sudo. Se você precisar alterar as configurações do daemon SSH, valide a sintaxe antes de recarregar:

sudo sshd -t
sudo systemctl reload sshd  # Alguns sistemas usam: sudo systemctl reload ssh

---

Outros Erros Comuns de Conexão

Embora os problemas de chave sejam primários, outros erros podem bloquear o acesso:

A. Conexão Expirou

Isso geralmente significa que o cliente não conseguiu alcançar o servidor, indicando um problema de rede, não um problema de autenticação.

Causas Possíveis:

• O servidor está desligado ou inacessível.
• Um firewall (local ou de rede) está bloqueando a conexão na porta 22 (ou porta SSH personalizada).
• Endereço IP ou nome de host incorreto.

Use ping para uma dica básica de acessibilidade e nc para verificar a porta SSH:

nc -vz host_remoto 22

B. Sem Rota para o Host

Semelhante ao timeout, isso é um problema de infraestrutura de rede. O cliente não consegue encontrar um caminho para o endereço IP do servidor. Verifique as tabelas de roteamento, status da VPN ou certifique-se de que o servidor remoto tenha uma interface de rede válida ativa.

C. Servidor Recusou Nossa Chave

Se a saída verbosa mostrar que o servidor está rejeitando ativamente as chaves, mas você verificou o arquivo authorized_keys, verifique os contextos de segurança SELinux ou AppArmor no servidor. Esses módulos de segurança podem substituir as permissões de arquivo e bloquear o acesso SSH se os contextos estiverem incorretos.

Uma Ordem Prática que Geralmente Funciona

Verifique o nome de usuário primeiro. Em seguida, force a chave que você espera com ssh -o IdentitiesOnly=yes -i .... Se o cliente oferecer a chave correta e o servidor a rejeitar, inspecione authorized_keys, propriedade e permissões no servidor. Se a chave nunca for oferecida, corrija seu ~/.ssh/config local, agente ou caminho da chave. Se a conexão nunca atingir a autenticação, mude para a solução de problemas de rede em vez de alterar os arquivos de chave.