VPS Linux não responde ao SSH: como recuperar o acesso sem reinstalar
VPS Linux travada e SSH não conecta? Diagnostique a causa real (rede, firewall, sshd, disco cheio) e recupere o acesso sem reinstalar do zero.
VPS Linux que parou de responder ao SSH é o tipo de problema que parece grave mas raramente é. Em 90% dos casos a máquina está rodando normalmente — o que falhou foi um componente específico entre você e o shell: rota de rede, firewall, daemon sshd, ou o disco encheu e o sistema deixou de aceitar novas conexões.
Este guia é pra quem tem uma VPS Linux inacessível agora e precisa recuperar o acesso sem apertar o botão de reinstalar. A reinstalação apaga tudo e é quase sempre desnecessária. O caminho correto é diagnosticar pelo console out-of-band do painel da hospedagem, identificar a causa real e corrigir em poucos minutos.
Tempo estimado: 10 a 20 minutos, dependendo da causa. Assumindo Ubuntu 22.04 ou 24.04 LTS — os comandos valem com pequenas variações pra Debian 12, AlmaLinux 9 e Rocky Linux 9.
Pré-requisitos
Você precisa do painel da Hostini aberto com acesso ao console out-of-band (VNC ou serial) da VPS afetada, a senha root atual ou de um usuário com sudo, e um segundo terminal/aba pra testar reconexão sem perder a sessão de console.
Ubuntu 22.04 / 24.04 LTS 22/tcp Painel Hostini 10–20 min Triagem rápida: descubra o que falhou
Antes de abrir o console, vale dois testes de fora pra eliminar hipóteses. Eles levam 30 segundos e te poupam de investigar a coisa errada.
Do seu computador local, teste se a VPS responde a ping:
ping -c 4 SEU.IP.DA.VPSSe ping volta, a máquina está viva e a rede funciona. Se não volta, pode ser problema de rede do datacenter (raro), VPS desligada, ou ICMP bloqueado por firewall — passe pro próximo teste.
Teste especificamente a porta 22 com nc ou telnet:
nc -vz SEU.IP.DA.VPS 22Resultado succeeded significa que o sshd está escutando e o firewall permite — o problema é autenticação ou banimento por fail2ban. Resultado Connection refused significa que o sshd não está rodando. Connection timed out significa firewall bloqueando ou VPS sem rede.
Essas duas saídas já dividem o problema em três categorias claras: rede/VPS down, daemon caído, ou autenticação. Você abre o console com hipótese, não às cegas.
Acessando o console out-of-band
O console é um canal de emergência que conecta direto no terminal serial da máquina virtual — independente de SSH, firewall ou rede. Ele é a sua chave reserva.
No painel da Hostini, vá em Serviços → sua VPS → Console. O console abre numa janela no próprio navegador. Em alguns navegadores o foco do teclado precisa ser ativado clicando uma vez na área preta.
Logue com root e a senha definida no provisionamento, ou com seu usuário sudo. Se você esqueceu a senha root, use o procedimento de reset do painel — ele reinicia a VPS em modo single-user e permite redefinir.
A latência do console é maior e não há histórico de comandos por padrão. Evite digitar comandos longos manualmente — copie e cole quando possível. Comandos destrutivos com syntax errada vão executar do mesmo jeito.
Diagnóstico no console: 4 verificações em ordem
Já dentro do console, rode essas quatro verificações na sequência. A primeira que falhar é provavelmente sua causa raiz.
1. O daemon sshd está rodando?
sudo systemctl status sshSe aparecer active (running), ok — passe pra próxima. Se aparecer inactive, failed ou dead, o serviço caiu. Suba com:
sudo systemctl start ssh
sudo systemctl enable sshOlhe o log das últimas mensagens pra entender por que caiu:
sudo journalctl -u ssh -n 50 --no-pagerCausas comuns de failed: sintaxe inválida em /etc/ssh/sshd_config após edição manual, certificado de host corrompido, ou OOM killer matando o processo.
2. O sshd escuta na porta esperada?
sudo ss -tlnp | grep sshSaída esperada com porta 22:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))Se a porta for diferente de 22, você ou alguém editou Port em /etc/ssh/sshd_config. Ajuste pra 22 (ou abra a porta nova no firewall — próximo item) e reinicie o serviço.
3. O firewall está deixando passar?
Em Ubuntu/Debian o firewall padrão é ufw:
sudo ufw status verboseProcure uma linha 22/tcp ALLOW IN Anywhere. Se não tiver, adicione:
sudo ufw allow 22/tcp
sudo ufw reloadEm AlmaLinux/Rocky use firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadSe você habilita o ufw sem antes liberar a porta 22, a conexão SSH cai instantaneamente. O console out-of-band resolve, mas a dor de cabeça é evitável: sempre sudo ufw allow 22/tcp antes de sudo ufw enable.
4. O disco está cheio?
df -hSe / ou /var aparecer com 100% (ou 99% com Avail em zero), o sshd não consegue criar arquivos de sessão e novas conexões falham silenciosamente após o handshake. Libere espaço:
sudo journalctl --vacuum-time=2d
sudo apt clean
sudo find /var/log -name "*.gz" -mtime +7 -deleteEm seguida rode df -h de novo pra confirmar que liberou pelo menos uns 500 MB e tente SSH outra vez.
Causas menos óbvias
Quando as quatro verificações acima passam mas o SSH ainda não conecta, vale checar três culpados secundários.
fail2ban baniu seu IP
Se você errou senha várias vezes ou tem outro serviço rodando no IP que disparou o ban, seu IP pode estar na blacklist:
sudo fail2ban-client status sshdA saída lista IPs banidos. Pra liberar o seu:
sudo fail2ban-client set sshd unbanip SEU.IP.PUBLICOPra descobrir seu IP público de fora da VPS, rode curl ifconfig.me num shell local — operadoras com CGNAT entregam IPs diferentes do esperado.
sshd_config quebrado
Edições manuais em /etc/ssh/sshd_config quebram o daemon silenciosamente quando contêm sintaxe inválida. Valide:
sudo sshd -tSem saída = config ok. Qualquer mensagem aponta a linha problemática. Corrija e reinicie:
sudo systemctl restart sshMudança de chave SSH do host
Se você reinstalou pacotes do SSH ou restaurou snapshot, a chave do host pode ter mudado. Do seu computador local, o cliente reclama com REMOTE HOST IDENTIFICATION HAS CHANGED. Remova a entrada antiga:
ssh-keygen -R SEU.IP.DA.VPSE reconecte normalmente.
Verificação: confirme que voltou
Antes de fechar o console, valide a recuperação por duas vias independentes.
Numa aba local, abra uma nova sessão SSH normalmente:
ssh [email protected]Se conectar, ótimo. Mantenha a sessão aberta enquanto faz o próximo passo.
Ainda com o console out-of-band aberto, confirme que a sessão SSH está registrada:
sudo ss -tnp | grep :22Você deve ver pelo menos uma conexão ESTAB (estabelecida) vinda do seu IP. Isso prova que rede, firewall e sshd estão funcionando ponta-a-ponta.
Sempre que for editar sshd_config, ufw ou iptables, deixe o console aberto numa janela e abra uma segunda sessão SSH pra testar a mudança. Se a segunda sessão funcionar, você pode fechar a primeira com segurança. Esse hábito de duas-sessões evita 90% dos lockouts.
Próximos passos
Recuperar acesso é só o começo — depois vale endurecer a configuração pra evitar repetição.
- Configure autenticação por chave SSH e desabilite senha em
PasswordAuthentication nonosshd_config. Antes de fechar a sessão, teste a chave numa segunda aba. - Instale e ajuste
fail2banpra banir IPs com bantime razoável (1h) e maxretry de 5 — banir demais cria lockouts próprios. - Crie snapshots regulares da VPS pelo painel antes de mudanças grandes no SSH ou no firewall. Rollback de snapshot é mais rápido que reinstalação.
- Se você gerencia múltiplas VPSes, considere centralizar o acesso com um bastion host — uma única porta exposta na internet e o resto atrás dela.
- Documente sua porta SSH, usuário admin e procedimento de console no seu próprio runbook. Em emergência ninguém quer lembrar disso de cabeça.
Se você precisa de uma VPS com console out-of-band confiável e snapshots integrados — o que torna esse tipo de recuperação trivial — a VPS Hostini entrega ambos no painel padrão, sem custo adicional.
Perguntas frequentes
Por que minha VPS Linux responde a ping mas não ao SSH?
Ping responde em camada 3 (ICMP) e SSH é camada 7 (TCP/22). Se ICMP volta mas TCP/22 não, o kernel da VPS está vivo mas o sshd parou, está escutando em outra porta, ou o firewall (ufw/iptables/nftables) bloqueia a porta 22. Use o console out-of-band do painel pra inspecionar `ss -tlnp` e `ufw status`.
Reiniciar a VPS pelo painel resolve um SSH travado?
Resolve quando a causa é processo zumbi, kernel oops ou OOM killer recente — basicamente qualquer estado de memória inconsistente. Não resolve se a causa for configuração persistente: sshd_config quebrado, firewall com regra ruim ou disco raiz cheio. Por isso vale diagnosticar via console antes de reiniciar às cegas.
Como acessar a VPS sem SSH funcionando?
Pelo console serial/VNC out-of-band oferecido no painel da hospedagem. Esse canal é independente do sshd e do firewall — ele conecta direto no tty da máquina virtual. Você loga com a senha root ou usuário sudo que já existia e pode editar arquivos, reiniciar serviços e ajustar regras de rede.
Disco cheio pode derrubar o SSH?
Sim. Quando `/` ou `/var` chega a 100%, o sshd não consegue gravar em `/var/log/auth.log`, escrever em `/run`, nem criar arquivos temporários da sessão — e a conexão falha logo após o handshake. Limpar logs antigos em `/var/log` e pacotes em `/var/cache/apt` costuma reabrir o acesso em segundos.
Mudei a porta SSH e me tranquei fora. Como reverter?
Entre pelo console out-of-band como root, abra `/etc/ssh/sshd_config`, troque `Port` de volta pra 22 (ou pra porta que o firewall permite), rode `sudo systemctl restart sshd` e ajuste `sudo ufw allow 22/tcp`. Sempre teste a nova porta numa segunda sessão antes de fechar a atual — esse é o erro número um de quem hardeniza SSH.
fail2ban pode estar bloqueando meu IP?
Sim, se você errou a senha várias vezes. Via console, rode `sudo fail2ban-client status sshd` pra ver IPs banidos. Pra liberar o seu, use `sudo fail2ban-client set sshd unbanip SEU.IP.AQUI`. Confirme seu IP público em `curl ifconfig.me` antes — operadoras com CGNAT podem te dar um IP diferente do que você esperava.