Fix SSH Connection Refused on a Linux VPS

If you’re seeing “Connection refused” when trying to SSH into your Linux VPS, it means your client reached the server but nothing was listening on port 22 (or your custom SSH port). This guide walks through the most common causes and fixes, from checking the SSH service to adjusting firewall rules and verifying network settings. You’ll need root or sudo access to the VPS, either through a web-based console provided by your hosting provider or another login method.

What You’ll Need

• Access to your VPS control panel (to use the web console or reboot if needed)
• Root or sudo privileges on the server
• Basic familiarity with the Linux command line
• The IP address and SSH port of your VPS

Step-by-Step

1. Log in via the web console. Most VPS providers offer a browser-based console (e.g., VNC, noVNC, or a serial console). Use that to get a shell on the server. If you can’t log in that way, you may need to reboot the server from the control panel and try again.
2. Check if the SSH service is running. Run systemctl status ssh (or sshd on some distributions). If it’s not active, start it with sudo systemctl start ssh. If it’s active but you still get refused, check the port it’s listening on.
3. Verify the SSH port. Run sudo netstat -tlnp | grep ssh or sudo ss -tlnp | grep ssh. Look for the 0.0.0.0:22 or :::22 entry. If it shows a different port (e.g., 2222), use that port when connecting: ssh -p 2222 user@your-vps-ip.
4. Check the SSH configuration. Open /etc/ssh/sshd_config and look for the Port directive. If it’s commented out, the default is 22. Also check ListenAddress – if it’s set to a specific IP, make sure that IP is assigned to the server. After any change, restart SSH: sudo systemctl restart ssh.
5. Inspect firewall rules. If the SSH service is running but you still get refused, a firewall may be blocking the port. Check with sudo ufw status (if using UFW) or sudo iptables -L -n (for raw iptables). If SSH is not allowed, add a rule: sudo ufw allow 22/tcp or sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT. Then reload the firewall: sudo ufw reload or sudo iptables-save.
6. Check for fail2ban or similar. If you have fail2ban installed, it might have banned your IP after too many failed attempts. Check with sudo fail2ban-client status sshd. If banned, unban with sudo fail2ban-client set sshd unbanip YOUR_IP.
7. Verify the SSH service is enabled at boot. Run sudo systemctl enable ssh to ensure it starts automatically after a reboot.
8. Test locally. From the web console, run ssh localhost on the server. If that works, the issue is likely network-related, not SSH itself.
9. Check network connectivity. From your local machine, run ping your-vps-ip. If you get no response, the server may be down or the IP changed. Also check if your ISP or hosting provider blocks port 22 – try connecting from a different network or using a different port.
10. Review logs. Look at sudo journalctl -u ssh or sudo tail -f /var/log/auth.log for any error messages. This can reveal configuration mistakes or service crashes.

Common Mistakes

• Forgetting to restart SSH after config changes. Always run sudo systemctl restart ssh after editing sshd_config.
• Firewall rules that don’t match the SSH port. If you changed the SSH port, you must update the firewall rule to allow the new port.
• Using the wrong IP address. If your VPS has a private IP and a public IP, make sure you’re connecting to the public one.
• SSH key permissions too open. If you use key-based auth, the private key on your client must have permissions 600 (chmod 600 ~/.ssh/id_rsa).

Tips

• Use a non-standard port. Changing SSH to a port like 2222 reduces automated attacks, but remember to update your firewall and client.
• Set up key-based authentication. It’s more secure than passwords and avoids lockouts due to forgotten credentials.
• Keep a backup connection. If you’re making changes to SSH config, keep the web console open until you’ve verified the new settings work.
• Use a terminal multiplexer like tmux or screen. If your SSH session drops, your processes continue running.

Troubleshooting

If you’ve followed the steps and still get “Connection refused,” try these additional checks:

• Is the server actually running? Check your control panel for CPU/memory usage. If the server is overloaded, SSH might not respond.
• Is the SSH service crashing? Look at sudo systemctl status ssh for any errors. If it’s in a failed state, try sudo systemctl reset-failed ssh and start it again.
• Check SELinux or AppArmor. On CentOS/RHEL, SELinux might block SSH. Run sudo getenforce. If it’s enforcing, try sudo setenforce 0 temporarily to test. On Ubuntu, check AppArmor status with sudo aa-status.
• Verify network routes. From the web console, run ip addr to see if the server has an IP assigned. If not, you may need to renew DHCP with sudo dhclient (or the appropriate command for your distro).
• Check /etc/hosts.deny and /etc/hosts.allow. If you have TCP wrappers configured, they might block your IP. Look for entries like sshd: ALL in hosts.deny.
• Try connecting from a different device. This helps isolate whether the problem is on your local network or the VPS.

Frequently Asked Questions

Why does SSH say “Connection refused” instead of “Connection timed out”?

“Connection refused” means the server is reachable but no service is listening on the port. “Timed out” means the server is unreachable (firewall drop, network issue).

Can I change the SSH port to something else?

Yes, edit /etc/ssh/sshd_config, change the Port line, restart SSH, and update your firewall to allow the new port. Then connect with ssh -p <port> user@host.

What if I accidentally locked myself out by changing SSH config?

Use the web console to revert the changes. If you changed the port, set it back to 22. If you disabled password auth, re-enable it temporarily.

How do I check if my firewall is blocking SSH?

Run sudo ufw status or sudo iptables -L -n. Look for rules that drop or reject port 22. If you see them, allow the port and reload the firewall.

Is it safe to disable password authentication and use only SSH keys?

Yes, it’s more secure. But make sure your key is backed up and you have a fallback like the web console. Set PasswordAuthentication no in sshd_config after you’ve added your public key to ~/.ssh/authorized_keys.

Why does SSH work locally but not from the internet?

This usually indicates a firewall on the VPS blocking external connections, or your hosting provider’s network firewall. Check both your server’s firewall and any security group settings in your VPS control panel.

Related

• Android 11 Media Controls on Any Phone
• SQL vs T-SQL: Key Differences Explained
• How to Flip or Invert a Picture on iPhone