Português
English
O servidor responde ao ping, mas o SSH dá Connection timed out ou Permission denied. Na esmagadora maioria dos casos o servidor está bem — o que aconteceu foi que se trancou a si próprio do lado de fora.
Estas são as quatro causas que vemos, por ordem de frequência, e o que fazer em cada uma.
1. Ligou o firewall e esqueceu a porta 22
É a mais comum de longe. Um ufw enable sem regra para o SSH fecha a porta por onde estava a entrar. O sintoma é claro: o ping responde, a porta 22 dá time out.
| Antes de activar qualquer firewall. Autorize primeiro a porta do SSH, só depois ligue: ufw allow 22/tcp e só a seguir ufw enable. E confirme numa segunda ligação, com a primeira ainda aberta — se algo correr mal, ainda tem por onde desfazer. |
2. Desligou a senha e perdeu a chave
Quem põe PasswordAuthentication no fica a depender da chave privada. Perdida a chave, o SSH responde Permission denied (publickey) e não há senha que valha.
Não há forma de recuperar uma chave privada perdida — é esse o objectivo dela. O caminho é entrar por fora do SSH, pela consola, e voltar a pôr a senha ou instalar uma chave nova.
3. O fail2ban ou o firewall bloqueou o seu endereço
Se errou a senha várias vezes, ou se alguém no mesmo escritório errou, o seu endereço público pode estar banido. O sinal típico é funcionar noutra rede — nos dados móveis, por exemplo — e não funcionar na sua. Ver como desbloquear o seu endereço IP e porque é que o seu IP fica bloqueado.
4. Mudou a porta e não a anotou
Um SSH mudado para outra porta responde a time out na 22 como se estivesse fechado. Se foi você que a mudou, tente a porta nova. Se herdou o servidor de outra pessoa, tem de descobrir pela consola.
Como se entra quando o SSH não deixa
Todos os casos acima se resolvem pelo mesmo caminho: uma consola que não passa pela rede. É o equivalente a ir ao servidor com um teclado e um ecrã.
|
|
|
| Não peça a reinstalação como primeiro recurso. Reinstalar apaga tudo o que lá está. Perder o acesso quase nunca justifica perder os dados — e quase sempre há caminho pela consola. Só depois de esse falhar é que se fala em reinstalar o sistema operativo. |
O que é nosso e o que é seu
Num servidor não gerido, o que corre dentro dele é da sua responsabilidade: não temos as suas senhas nem as suas chaves, e não entramos sem que peça. O que fazemos é dar-lhe a consola, verificar a rede e confirmar que o servidor está a funcionar do nosso lado.
Num servidor gerido, tratamos nós. A diferença está em VPS gerido ou não gerido: qual escolher e quem faz o quê e a fronteira geral em até onde vai o nosso suporte.
Para não voltar a acontecer
| Hábito | Porquê |
| Guarde a chave privada em dois sítios | Uma cópia no computador e outra fora dele. A chave perdida não se recupera |
| Deixe a senha activa até ter a chave testada | Só desligue a autenticação por senha depois de entrar com a chave com sucesso |
| Teste numa segunda janela | Antes de fechar a ligação onde mexeu no SSH ou no firewall, abra outra e confirme que entra |
| Anote a porta, se a mudar | Escreva-a onde guarda as credenciais, não na memória |
E se o que tem é um erro diferente — memória, disco, reinicializações — ver erros comuns de VPS e Cloud.
|
Trancado do lado de fora do seu próprio servidor? Peça-nos a consola |
PRODUTO RECOMENDADO Servidor VPS com acesso root Recursos só seus, o sistema que escolher, reinstalação quando quiser. desde 4.630,96 Kz/mês Ver planos |
- 0 Utilizadores acharam útil
