Recupere o acesso quando o SSH parar de funcionar

O Server Manager fala com seu servidor apenas por SSH. Se o SSH parar de funcionar, o Server Manager não consegue ajudar — ele não tem outro canal para entrar na máquina. Mas seu servidor está bem, e você tem outras formas de recuperar o acesso. Este artigo faz a triagem dos sintomas mais comuns e mostra os caminhos de recuperação.

Leia isto antes de entrar em pânico. Nenhum dos cenários comuns de SSH quebrado significa que seus dados sumiram. O servidor em si continua rodando; você só não consegue entrar nele pelo caminho de sempre. No pior caso, você reinstala o acesso SSH pelo console web do seu provedor de nuvem — mesma máquina, mesmos discos, mesmos arquivos.

Etapa 1 — Leia o erro em linguagem simples

Se você tentou se conectar pelo Server Manager e a conexão falhou, a janela Connect já mostra um diagnóstico em linguagem simples do que provavelmente deu errado:

Essa mensagem indica a causa mais provável. A tabela abaixo relaciona a mensagem que o Server Manager mostra com o próximo lugar onde você deve procurar.

Etapa 2 — Recupere pelo console web do seu provedor

Se o diagnóstico acima aponta para "algo quebrou no próprio servidor" (a maioria das linhas da tabela), o caminho de volta é o console web do seu provedor de nuvem — um terminal no navegador que contorna o SSH totalmente. Todo provedor grande tem um, só com nomes diferentes:

Depois de entrar pelo console web, você tem acesso completo ao shell sem passar pelo SSH — então pode corrigir o que está bloqueando o SSH e depois voltar para o Server Manager.

O console web pede a senha local do servidor. Essa é a senha no nível do sistema operacional para seu usuário no próprio servidor — geralmente a que o provedor enviou por e-mail, ou a senha que você definiu durante a configuração inicial. Não é sua frase secreta do Server Manager nem a senha da sua conta no provedor de nuvem. Se você nunca definiu uma e usava apenas chave, execute passwd <user> pelo serviço de metadados do seu provedor (a DigitalOcean tem "Reset root password" → envia uma nova por e-mail; a AWS tem redefinição de senha via Systems Manager).

Etapa 3 — Corrija as causas mais comuns

Depois de entrar pelo console web, passe por estes pontos:

"Editei o sshd_config e me tranquei do lado de fora"

O clássico. Você mudou algo em /etc/ssh/sshd_config, reiniciou o sshd e agora não consegue entrar de novo. Recuperação:

bashsudo sshd -t                                  # verificar sintaxe da configuração atual
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.broken
sudo nano /etc/ssh/sshd_config                # desfazer a alteração problemática
sudo sshd -t                                  # verificar sintaxe novamente
sudo systemctl restart sshd                   # reiniciar de forma limpa

Coisas comuns que fazem as pessoas perderem o acesso:

• PermitRootLogin no enquanto estão conectando como root → reative o root ou crie antes um usuário sudo que não seja root
• PasswordAuthentication no antes de adicionar a chave a ~/.ssh/authorized_keys
• Port 2222 (ou outra porta fora do padrão) — o servidor ainda está no ar, só está escutando em outro lugar; reconecte na nova porta
• AllowUsers alice que exclui o usuário com o qual você está tentando entrar de verdade

"O fail2ban baniu meu IP"

Se você digitou a senha errada 3–5 vezes seguidas, o fail2ban (ou sshguard) costuma bloquear seu IP por 10 minutos a uma hora. Para verificar e remover o banimento:

bashsudo fail2ban-client status sshd               # ver IPs banidos
sudo fail2ban-client unban <YOUR-IP>           # remover o banimento do seu

Seu IP atual é o que curl ifconfig.me mostra a partir da sua conexão de casa (não do servidor). Para evitar na próxima vez, adicione seu IP a /etc/fail2ban/jail.local em ignoreip = depois que você conseguir entrar de novo.

"ufw / iptables me trancou do lado de fora"

Você ativou o firewall sem permitir explicitamente a porta 22:

bashsudo ufw status                                # ver regras atuais
sudo ufw allow 22/tcp                          # permitir SSH explicitamente
sudo ufw reload

Para iptables diretamente:

bashsudo iptables -L INPUT -n -v                   # ver o que está bloqueando
sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
sudo netfilter-persistent save                 # salvar (Debian/Ubuntu)

"Removi minha própria chave pública de authorized_keys"

Se você esvaziou ~/.ssh/authorized_keys sem querer (ou aplicou chmod errado nele), adicione a chave de novo pelo console web:

bashmkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys                    # cole sua chave pública, salve
chmod 600 ~/.ssh/authorized_keys

A chave pública é o arquivo de uma linha curto, geralmente em ~/.ssh/id_ed25519.pub (ou id_rsa.pub) no seu notebook. Cole a linha inteira, incluindo o prefixo ssh-ed25519 … e o sufixo user@host.

Se você não tem mais a chave pública original, gere um novo par de chaves no seu notebook:

bashssh-keygen -t ed25519 -C "you@laptop"          # cria ~/.ssh/id_ed25519 + .pub
cat ~/.ssh/id_ed25519.pub                       # cole isto em authorized_keys

"O firewall do meu provedor mudou sozinho"

Ele não mudou sozinho, mas provedores às vezes ajustam políticas padrão. Abra a página Security List / Network Security Group / Firewall Rules do seu provedor e verifique se a porta 22 (ou a porta onde seu SSH escuta) ainda está permitida a partir da internet pública (0.0.0.0/0) ou a partir da sua faixa de IP específica.

Se seu IP mudou (provedor de internet residencial, mudança de cidade, troca para rede móvel) e você tinha restringido o firewall ao IP antigo, o novo IP está bloqueado. Amplie a regra temporariamente de volta para 0.0.0.0/0, entre, e depois restrinja de novo se quiser.

Etapa 4 — Reconecte pelo Server Manager

Quando o SSH funcionar pelo seu terminal (teste com ssh -v <user>@<host>), volte ao Server Manager e clique em Connect server. Digite as credenciais novamente e você estará de volta ao ponto em que estava. O histórico de chat da sessão anterior se perdeu (sessões SSH ficam só na RAM por projeto), mas seus sites e serviços no servidor não foram alterados.

Se você tem o servidor salvo (com uma frase secreta de criptografia do Server Manager), selecione-o no menu suspenso em vez de digitar tudo de novo.

Opções de último recurso

Se você não conseguir entrar nem pelo console web do provedor, ainda há opções:

• Reverter para um snapshot — se você tirou um snapshot antes de algo dar errado (e a maioria dos provedores oferece isso, às vezes de forma automática), restaure esse snapshot. Você perde as mudanças feitas desde então, mas recupera um sistema conhecido e funcional.
• Reconstruir a partir de um backup — se você tem um pacote .tar.gz do Server Manager (veja Backups), crie um servidor novo, instale o Server Manager nele e use o assistente Restaurar a partir de um backup. Mesmo site, servidor novo.
• Desanexar o disco e montar em outra VM — avançado, mas funciona na maioria dos provedores. Pare a VM com problema, desanexe o disco de boot dela, anexe a uma VM funcional como disco secundário, monte, edite os arquivos que estavam quebrados (sshd_config, authorized_keys), desmonte, anexe de volta à VM original e reinicie. A documentação do seu provedor tem o passo a passo.

Prevenção — antes de mudar qualquer coisa relacionada a SSH

Uma checklist rápida para antes de editar o sshd_config que já poupou muita gente de um pânico às 2 da manhã:

1. Abra uma segunda sessão SSH antes de editar — assim, se você se trancar para fora da nova sessão, a antiga continua ativa e você consegue desfazer.
2. **sudo sshd -t** antes de reiniciar — detecta a maioria dos erros de sintaxe.
3. Teste a nova configuração sem torná-la permanente. sudo /usr/sbin/sshd -D -p 2222 -f /etc/ssh/sshd_config.new executa um sshd de teste na porta 2222 usando uma configuração de teste. Entre por SSH com -p 2222 para verificar; se funcionar, aí sim troque a configuração e reinicie de verdade.
4. Deixe o acesso ao console web do seu provedor pronto antes de começar. Abra a aba, faça login, confirme que o console funciona e só então comece a editar.
5. **Não rode ufw enable por SSH** sem rodar sudo ufw allow 22/tcp antes.

Para mudanças que o Server Manager faz pelo chat: o Faro pausa para pedir sua aprovação em cada comando e não propõe nada que quebraria o SSH (nada de edições em sshd_config, nada de ufw enable sem uma regra explícita de permissão). O que pega as pessoas são as sessões manuais com nano /etc/ssh/sshd_config.

Perguntas comuns

Perdi alguma coisa? Não — seus arquivos, seus sites e seus bancos de dados estão exatamente como você deixou. SSH é só o canal; o servidor em si não foi alterado.

O histórico do chat sumiu? Sim. Sessões SSH ficam só na RAM — quando a sessão termina (do seu lado ou do lado do servidor), o chat é reiniciado. Mas o trabalho que o chat fez no servidor continua lá: sites publicados, configurações editadas e serviços instalados persistem normalmente.

Dá para evitar isso completamente? Na maior parte, sim. O caminho conduzido pelo Server Manager é mais seguro (aprovação a cada etapa; sem edições em sshd_config). O risco vem de sessões SSH manuais em que você edita a configuração por conta própria. Se você fizer tudo pelo Server Manager, o cenário de ficar sem acesso quase nunca acontece.

Meu servidor está em um provedor que não aparece na tabela acima. O princípio é universal: a maioria dos provedores tem alguma forma de console fora de banda (VNC, serial, shell web). Procure na documentação do seu provedor por "console" ou "rescue mode". Se você tem acesso físico (homelab), um monitor + teclado faz o mesmo papel.

O Server Manager diz "Connection refused", mas eu usei SSH pelo meu terminal há 5 minutos. Ou o sshd caiu (verifique pelo console do provedor: systemctl status sshd), ou o fail2ban baniu o IP da VPS do Server Manager (diferente do seu IP residencial — o Server Manager roda no próprio datacenter dele, e seu servidor enxerga esse IP como origem). Coloque o IP de saída do Server Manager na lista de permissões em ignoreip = do fail2ban, ou afrouxe as configurações de findtime/maxretry.

O que NÃO está no escopo aqui

• Recuperação no nível da conta (esqueceu o login do Server Manager, esqueceu a senha da conta do provedor de nuvem) — isso é fora de banda: fluxo de recuperação de conta do provedor + redefinição de senha do Server Manager na página de login.
• Resgate de disco criptografado (raiz criptografada com LUKS que não desbloqueia) — depende do provedor; consulte a documentação do seu provedor por "rescue mode" ou "single-user boot".
• Chave SSH perdida permanentemente sem nenhum outro método de acesso — nesse ponto, o caminho prático é reconstruir a partir de um backup. Veja Restaurar a partir de um backup e Backups para entender o cenário completo.