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

Secure Shell (SSH) é a base do gerenciamento remoto de servidores, oferecendo comunicação criptografada para acessar e controlar sistemas remotos. Embora confiável, a configuração do SSH, especialmente com autenticação baseada em chave, às vezes pode levar a falhas frustrantes de conexão. O culpado mais comum é o temido erro Permissão negada.

Este guia abrangente o guiará pelo diagnóstico e resolução dos erros de SSH mais frequentes. Focaremos especificamente em entender as causas raiz por trás de Permissão negada (publickey) e abordaremos armadilhas comuns relacionadas a permissões de arquivo, configuração incorreta e incompatibilidades na configuração do cliente/servidor. Dominar estas etapas de solução de problemas garante acesso seguro e confiável à sua infraestrutura remota.

Entendendo o Fluxo de Autenticação SSH

Antes de solucionar problemas, é crucial entender como o SSH autentica os usuários. Quando você tenta se conectar, o servidor geralmente verifica as credenciais na seguinte ordem (dependendo da configuração):

Autenticação de 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).
Autenticação por Senha: Se a autenticação por chave falhar ou estiver desabilitada, o servidor solicitará uma senha.

Quando você recebe Permissão negada, quase sempre significa que o servidor rejeitou suas credenciais durante a etapa 1 ou 2.

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

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

Usando Flags Verbose

Use a seguinte estrutura de comando:

ssh -vvv usuario@host_remoto

O que procurar na saída:

Troca de Chaves: Procure por linhas indicando quais métodos de autenticação o cliente tentou (por exemplo, Oferecendo chave RSA: /caminho/para/id_rsa).
Resposta do Servidor: Preste muita atenção às mensagens de rejeição do servidor. Se a saída mostrar que o servidor está verificando chaves, mas não consegue encontrar correspondência, o problema provavelmente é de configuração de chave ou permissões no lado do servidor.
Solicitação de Senha: Se a saída pular as verificações de chave e solicitar imediatamente uma senha, a autenticação por chave pode estar desabilitada no servidor.

Resolvendo `Permissão negada (publickey)`

Este erro afirma explicitamente que o servidor rejeitou a credencial de chave pública fornecida. A correção geralmente reside em permissões ou emparelhamento 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 em seu arquivo de chave privada (por exemplo, ~/.ssh/id_rsa). Se esses arquivos estiverem muito abertos, o cliente se recusará a usá-los.

Correção Acionável (Cliente): 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 que você está se conectando com o arquivo de identidade correto, especialmente se usar chaves não padrão ou vários pares de chaves.

Correção Acionável (Cliente): Especifique a chave privada correta usando a flag -i.

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

3. Permissões e Propriedade do Servidor

Esta é a fonte mais comum de falha. O SSH impõe permissões rigorosas de diretório e arquivo no servidor para o usuário que 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

Correção Acionável (Servidor): Faça login via console ou autenticação por senha (se habilitado) e execute estes comandos:

# 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

Aviso: Se as permissões no diretório home do usuário (~/) forem muito amplas (por exemplo, graváveis pelo grupo ou outros), o SSH também pode falhar por motivos de segurança. Procure por 755 ou mais restritivo em ~/ se os problemas persistirem.

4. Confirme se a Chave foi Realmente Adicionada

Certifique-se de que a string da chave pública no cliente corresponda exatamente ao que foi colado no arquivo ~/.ssh/authorized_keys do servidor. Um caractere ausente ou um espaço em branco no final causará falha na autenticação.

Dica: Ao adicionar uma chave, use ssh-copy-id, se disponível, pois ele lida automaticamente com permissões e formatação:

ssh-copy-id usuario@host_remoto

Solução de Problemas de Arquivos 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 estejam comentadas (#) e definidas corretamente:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. Status da Autenticação por Senha

Se você estiver dependendo de login por senha temporariamente, 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 seja 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 yes

Etapa Crucial: Após quaisquer alterações em /etc/ssh/sshd_config, você deve reiniciar o serviço SSH para que as alterações entrem em vigor:
bash sudo systemctl restart sshd # Ou service ssh restart

Outros Erros Comuns de Conexão

Embora problemas de chave sejam os principais, outros erros podem bloquear o acesso:

A. Tempo Limite da Conexão Excedido

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.

Possíveis Causas:
* O servidor está inativo 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 do host incorreto.

Solução de Problemas: Use ping para verificar a conectividade básica e telnet ou nc (netcat) para verificar se a porta está aberta:

# Verificar se a porta 22 está acessível
telnet host_remoto 22

B. Sem Rota para o Host

Semelhante ao tempo limite, este é 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, o 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 verbose 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.

Resumo das Melhores Práticas

Sempre use o Modo Verbose (-vvv) para diagnóstico.
Segurança da Chave do Cliente: Certifique-se de que as chaves privadas estejam definidas como 600 (chmod 600).
Integridade dos Arquivos do Servidor: Verifique se ~/.ssh é 700 e authorized_keys é 600.
Reinicie o Daemon: Sempre reinicie o sshd após modificar /etc/ssh/sshd_config.
Use ssh-copy-id sempre que possível para automatizar a implantação de chaves.