Português
English
The server answers ping, but SSH gives Connection timed out or Permission denied. In the overwhelming majority of cases the server is fine — what happened is that you locked yourself out.
These are the four causes we see, in order of frequency, and what to do about each.
1. You enabled the firewall and forgot port 22
By far the most common. A ufw enable with no rule for SSH closes the very door you were coming in through. The symptom is clear: ping answers, port 22 times out.
| Before enabling any firewall. Allow the SSH port first, enable second: ufw allow 22/tcp and only then ufw enable. And confirm in a second connection while the first is still open — if something goes wrong, you still have a way back. |
2. You disabled passwords and lost the key
Setting PasswordAuthentication no leaves you depending on the private key. Lose the key and SSH answers Permission denied (publickey), and no password will help.
There is no way to recover a lost private key — that is the whole point of it. The route is to get in outside SSH, through the console, and either restore password login or install a new key.
3. fail2ban or the firewall banned your address
If you got the password wrong several times, or someone else in the same office did, your public address may be banned. The tell-tale sign is that it works on another network — mobile data, say — and not on yours. See how to unblock your IP address and why your IP gets blocked by the firewall.
4. You changed the port and did not write it down
An SSH moved to another port times out on 22 exactly as if it were closed. If you moved it, try the new port. If you inherited the server from someone else, you will have to find out through the console.
How you get in when SSH will not let you
All the cases above are solved the same way: a console that does not go through the network. It is the equivalent of walking up to the server with a keyboard and a screen.
|
|
|
| Do not ask for a reinstall as a first resort. Reinstalling wipes everything on it. Losing access almost never justifies losing the data — and there is almost always a way through the console. Only after that fails does reinstalling the operating system come into it. |
What is ours and what is yours
On an unmanaged server, what runs inside it is your responsibility: we do not hold your passwords or your keys, and we do not go in unless you ask. What we do is give you the console, check the network, and confirm the server is running on our side.
On a managed server, we handle it. The difference is in managed or unmanaged VPS: which to choose and who does what and the general line in how far our support goes.
So it does not happen again
| Habit | Why |
| Keep the private key in two places | One copy on the computer and one off it. A lost key cannot be recovered |
| Leave passwords on until the key is tested | Only disable password authentication after you have successfully signed in with the key |
| Test in a second window | Before closing the session where you touched SSH or the firewall, open another and confirm you can get in |
| Write the port down, if you change it | Put it where you keep the credentials, not in your head |
And if what you have is a different error — memory, disk, reboots — see common VPS and Cloud errors.
|
Locked out of your own server? Ask us for the console |
RECOMMENDED PRODUCT VPS server with root access Resources of your own, the OS you choose, reinstall whenever you like. from $5.14/mo See plans |
- 0 Users Found This Useful
