You SSH into your VPS, and instead of the familiar prompt you get: ssh: connect to host 1.2.3.4 port 22: Connection refused. Or maybe Connection timed out. Or Permission denied. Each of these means something different and points to a different fix. This guide walks through seven common causes, in rough order from "most likely" to "less common," with copy-paste diagnostic commands and fixes for each. We'll also cover what to do when you genuinely can't get in via SSH and need to use the provider's emergency console.
Important first step: Distinguish between "Connection refused" (server reached but actively refused — port closed, sshd not running) and "Connection timed out" (server unreachable — network problem, firewall dropping silently). The error message tells you which family of problem you have.
Causes covered
1. SSH daemon (sshd) not running
Symptom: Connection refused.
The most common cause when sshd was working before. The SSH service crashed, was stopped, or failed to start after a reboot. The server is reachable on the network but nothing is listening on port 22.
To diagnose (you'll need console access — see emergency section if you can't SSH):
# Check if sshd is running
sudo systemctl status sshd
# or on some systems: sudo systemctl status ssh
# If it's not running, check why
sudo journalctl -u sshd -n 50
# Check if anything is listening on port 22
sudo ss -tlnp | grep :22If sshd is stopped, start it:
sudo systemctl start sshd
sudo systemctl enable sshd # to start on boot
# Verify it's listening
sudo ss -tlnp | grep :22
# Should show something like: LISTEN ... :22 ... users:(("sshd",pid=...))If sshd refuses to start, it's usually a config error. Check syntax:
# Test sshd config without restarting
sudo sshd -t
# If errors, check the config
sudo nano /etc/ssh/sshd_config
# Common breakage: bad PermitRootLogin syntax,
# typo in port number, missing AuthorizedKeysFile path
# Restart after fixing
sudo systemctl restart sshd2. Firewall blocking port 22
Symptom: Connection timed out (firewall is dropping silently). Sometimes refused.
UFW, firewalld, iptables, or your provider's network firewall is blocking port 22. Common after enabling UFW for the first time without explicitly allowing SSH.
# Check UFW status
sudo ufw status verbose
# If active and 22 isn't allowed:
sudo ufw allow 22/tcp
sudo ufw reload
# Check firewalld (CentOS/RHEL)
sudo firewall-cmd --list-all
# Allow SSH on firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
# Check raw iptables
sudo iptables -L INPUT -n -v --line-numbers
# Look for DROP/REJECT rules affecting port 22If your VPS provider has a separate cloud firewall (security groups, network ACLs), check that too — common gotcha on cloud providers.
3. Wrong IP address
Symptom: Connection timed out, or Connection refused (different host responding).
Sounds dumb but happens often, especially after VPS rebuilds, IP changes, or copy-paste errors. The IP you're using doesn't actually point to your VPS.
# From your local machine, check what you're SSHing to
ssh -v user@your.vps.ip 2>&1 | head -20
# verbose output shows the IP being connected to
# Verify the IP from your provider's control panel
# Compare to what you're using
# Test reachability with ping (assuming ICMP allowed)
ping -c 3 your.vps.ip
# Or use traceroute to see path
traceroute your.vps.ip
# Expected: hops increasing, eventually reaching your VPS
# Suspicious: traceroute completing at a different hostIf you're connecting to example.com rather than IP directly, the DNS might be pointing to the wrong place — see cause 7.
4. SSH port changed from 22
Symptom: Connection refused.
Common with security hardening — admins move sshd from port 22 to a high random port like 2222 or 53472. If you forgot or you're trying to connect with default port 22, you'll get refused.
# Connect with explicit port
ssh -p 2222 user@your.vps.ip
# Or set in your local ~/.ssh/config
Host my-vps
HostName your.vps.ip
Port 2222
User youruser
# Then connect with: ssh my-vpsTo verify what port sshd is actually on (from console access):
# Check sshd config
grep -i "^port" /etc/ssh/sshd_config
# Or check what's actually listening
sudo ss -tlnp | grep ssh5. Fail2ban or other IP banning
Symptom: Connection times out (often) or refused. Worked yesterday, fails today.
You typed the password wrong a few times, or your IP got banned by fail2ban / sshguard / your provider's auto-ban system. The ban usually expires in 10-30 minutes but can be permanent if configured aggressively.
# From console (since you can't SSH), check fail2ban
sudo fail2ban-client status sshd
# See banned IPs
sudo fail2ban-client status sshd | grep "Banned IP"
# Unban your IP
sudo fail2ban-client set sshd unbanip YOUR.HOME.IP.HERE
# Or temporarily stop fail2ban to recover
sudo systemctl stop fail2ban
# (re-enable after you're back in)If you don't have console access and you've been banned: try connecting from a different IP (mobile hotspot, VPN, different location) — typically gets you a fresh IP that isn't banned. Or contact provider support; they can usually help with a console session.
6. SSH key issues (Permission denied)
Symptom: Permission denied (publickey).
Different from connection refused — you're reaching sshd but authentication is failing. Common causes:
- SSH key not added to
~/.ssh/authorized_keyson the server - Wrong permissions on
~/.ssh(must be 700) orauthorized_keys(must be 600) - Wrong username (you're trying
rootwhen the VPS usesubuntu, or vice versa) - Local SSH agent doesn't have the right key loaded
- SELinux context wrong on .ssh directory (CentOS/RHEL)
# Verbose SSH to see exactly which key it's trying
ssh -vvv user@your.vps.ip
# Look for lines like "Offering public key: ..."
# and "Authentications that can continue: publickey"
# On the server (from console), check authorized_keys
ls -la ~/.ssh/
cat ~/.ssh/authorized_keys
# Fix permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# Add a new key from console (if locked out)
echo "ssh-ed25519 AAAA... user@laptop" >> ~/.ssh/authorized_keys
# Check sshd logs for auth failures
sudo journalctl -u sshd -f
# (then try to SSH from another terminal — watch the log)For CentOS/RHEL with SELinux:
# Restore SELinux context on .ssh
restorecon -R -v ~/.ssh7. DNS or hostname issue
Symptom: Connection refused (to wrong host) or timed out, plus "wrong" SSH host key warning.
If you're connecting via hostname (ssh user@server.example.com), DNS could be pointing to the wrong IP. Maybe an A record was changed, maybe DNS hasn't propagated yet, maybe a typo when setting up the record.
# Check what hostname resolves to
dig +short server.example.com
nslookup server.example.com
# Compare against actual VPS IP from provider panel
# Try connecting by IP directly to skip DNS
ssh user@your.vps.ip
# If this works but hostname doesn't, it's a DNS issue
# Force fresh DNS lookup (some clients cache)
sudo systemd-resolve --flush-cachesAlso a SSH-specific gotcha: if the server's IP recently changed but you have the old host key in ~/.ssh/known_hosts, SSH refuses to connect with a "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" message. Fix:
# Remove the old host key
ssh-keygen -R server.example.com
ssh-keygen -R your.vps.ip
# Reconnect — accept the new host keyVNC console included on every plan
OliveVPS gives you VNC console access via the control panel — so when SSH dies, you can still get in to fix things. Critical for any VPS where you've enabled a strict firewall or done aggressive hardening.
See VPS Plans →Emergency: getting in without SSH
When SSH is genuinely broken — sshd won't start, firewall locked you out, no way in — you need a way around it. Options:
Provider VNC / Web console
Most reputable VPS providers (us included) give you VNC console access via the control panel. This connects to the VPS as if you had a physical keyboard and monitor — works regardless of network state, firewall, sshd. Log in with username/password (you may need to set a console password ahead of time).
Rescue mode
Many providers offer "rescue mode" — boot the VPS from a recovery image, mount your disk, and fix things from outside the regular OS. Useful when the regular OS won't even start, or when you've badly broken something fundamental.
# Typical rescue workflow:
# 1. From provider panel, boot to rescue mode
# 2. SSH into the rescue environment
# 3. Mount your disk
mount /dev/sda1 /mnt
# 4. chroot into your normal system (optional)
chroot /mnt
# 5. Fix things — edit files, reinstall packages, etc.
# 6. Exit chroot, unmount, reboot to normal OSSnapshot rollback
If you have a recent snapshot, rolling back is the fastest fix when you've badly broken something and don't want to investigate. Take a snapshot before risky changes.
Provider support
If all else fails, support can usually help. Most providers can give you console access, mount your disk for rescue, or restore from backup. We respond to "I locked myself out" tickets within minutes.
FAQ
What's the difference between "Connection refused" and "Connection timed out"?
Connection refused = the server is reachable on the network but is actively rejecting connections on that port (nothing listening, or actively closed). Connection timed out = the server isn't responding to connection attempts at all (network blocking, host down, firewall dropping silently). Different families of problems.
How do I prevent locking myself out in the future?
Always have console access available. When changing firewall or sshd config, test in a second terminal before disconnecting the working one. Take snapshots before major changes. Set up SSH key auth before disabling password auth (don't lock yourself out with no key). For sshd config changes, use sshd -t to verify syntax before restarting.
Should I really change SSH from port 22?
Mild benefit — reduces login attempts in your logs from automated scanners. Doesn't meaningfully improve security on its own (a determined attacker scans all ports). Combine with key-only auth, fail2ban, and proper firewall for real security. If you do change ports, document it and never forget — many SSH lockouts come from people forgetting their custom port.
What does "REMOTE HOST IDENTIFICATION HAS CHANGED" mean?
SSH detected the remote server's host key changed since you last connected. Could be benign (server rebuilt, IP reused for new VPS) or malicious (man-in-the-middle attack). If you know the host legitimately changed, remove the old key with ssh-keygen -R hostname. If you don't know why it changed, investigate before connecting.
Why does sshd sometimes refuse to start?
Almost always a config error in /etc/ssh/sshd_config. Test with sudo sshd -t before restarting. Common errors: typo in directive name, port number too high (>65535), missing AuthorizedKeysFile path, conflicting Match blocks. Keep a working config backed up before you make changes.