Como diagnosticar um erro SSH no seu VPS Ubuntu

Registre uma tentativa sem perder o acesso atual

Comandos do cliente rodam no seu computador com Linux, macOS ou WSL. Comandos do servidor precisam de uma sessão válida ou console autenticado. Não cole verificações do servidor no terminal local.

Troque 203.0.113.10, ubuntu, porta 22 e o caminho da chave pelos seus valores. O endereço mostrado é documental. Primeiro veja a configuração efetiva do cliente e faça uma conexão nova:

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Confira hostname, user, port, identityfile e proxies. A segunda tentativa desativa o compartilhamento de conexão para não aproveitar uma sessão existente. Registre horário e erro final. Antes de compartilhar a depuração, remova usuários, endereços e caminhos; nunca envie a chave privada.

Escolha a investigação pelo erro

Deslize a tabela para ver todas as colunas →

Esses sinais reduzem as hipóteses, mas não provam uma causa única. Se a saída mostrou Connection established antes do timeout, investigue a negociação SSH e os logs em vez de concluir que todo o tráfego foi bloqueado.

Timeout: confira o caminho de rede

Compare o destino de ssh -v com o IP atual do painel. Um nome pode resolver para DNS antigo ou para uma IPv6 diferente. Confirme se o acesso deve ser público, por VPN ou por um host intermediário.

Verifique a VM em execução, rota, porta real e seu IP público de origem. O IP residencial pode mudar sem que a regra /32 seja atualizada. Confira o firewall do sistema convidado pelo console.

Na Oracle, listas, NSGs, rotas e regras da imagem importam. Instalar UFW ou limpar iptables não é diagnóstico. Preserve o firewall fornecido e consulte o percurso de rede OCI. Um ping sem resposta, sozinho, não prova que SSH está indisponível.

Conexão recusada: confira quem está escutando

A rejeição não autentica que aquele destino é seu VPS. Confirme identidade e porta. No servidor, por uma sessão válida ou console, faça consultas:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Procure a porta e o endereço esperados e relacione os logs ao horário da tentativa. Ubuntu pode ativar SSH por socket: ssh.service inativo não prova indisponibilidade quando ssh.socket está escutando.

sshd -t verifica configuração e chaves sem iniciar o daemon. Sucesso silencioso não comprova acesso pela rede. Se houver erro, identifique arquivo e opção antes de recarregar; não reinicie o serviço por tentativa.

Chave recusada: confira conta, arquivo e política

Use a conta inicial documentada ou um administrador que você criou. Na depuração do cliente, identifique a impressão da chave oferecida. Para reduzir chaves extras vindas do agente, tente no computador:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Entradas IdentityFile da configuração ainda podem valer; confira ssh -G. Se a chave privada não puder ser lida ou tiver permissões excessivas, corrija o arquivo local antes de alterar o servidor.

No servidor, confira a conta e as chaves públicas autorizadas. Troque /home/ubuntu pelo diretório que getent mostrar:

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Compare impressões e consulte erros de proprietário, permissões e política. Confira AuthorizedKeysFile, arquivos incluídos e regras Match se o caminho padrão não se aplicar. Serviços de chaves gerenciados pelo provedor também podem mudar o mecanismo. Preserve as chaves existentes; não desative StrictModes nem habilite senhas só para esconder a falha.

Identidade alterada: verifique antes de conectar

Uma reconstrução ou IP redistribuído pode mudar a chave. Uma mudança inesperada também pode indicar destino errado ou interceptação. Confira identificador da instância e alteração planejada no painel autenticado.

No console confiável do sistema convidado, consulte a chave do mesmo algoritmo mostrado pelo cliente. Para Ed25519:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Compare SHA256 com o aviso. Essa é a chave do servidor, não sua chave de login nem a do gateway de console. Somente após confirmar, faça cópia de known_hosts e atualize a entrada daquele host/porta. Não apague o arquivo inteiro nem desative a verificação. Sem explicação para a mudança, interrompa a conexão e investigue.

Valide a correção em uma conexão nova

Corrija apenas a causa identificada: endereço, conta, chave, regra de rede restrita ou configuração inválida. Mantenha um acesso independente e valide a sintaxe antes de aplicar alterações. Mudar porta pode exigir ajuste de socket, não só reiniciar um serviço.

Repita a tentativa sem compartilhar conexões. Confira a conta alcançada e sudo quando necessário. Uma sessão antiga continuar funcionando não substitui isso. Registre a causa e a alteração, depois volte à configuração do site se ela foi interrompida.

Perguntas e respostas