Quick answer
The message "connection refused" means the server is reachable but no service is accepting a connection on the requested port. The most common cause is that the SSH service (sshd) is not running, is listening on a different port, or is blocked by a firewall. Check in order: whether sshd is running, on which port, whether the port is open, and whether you are on the right host.
How to recognize the problem
- The client reports "ssh: connect to host ... port 22: Connection refused"
- Ping to the server succeeds but the SSH connection is immediately refused
- The connection works from one network but not from another
- Access stops after changing the port or sshd configuration
- The server came up after a restart and SSH no longer accepts connections
Most common causes
SSH service is not running
The sshd process is not running or has crashed, so the operating system refuses the connection on port 22. Check the service status and logs.
SSH is listening on a different port
The port was changed in the configuration (for example to 2222) but you are connecting to the default 22. The client then gets connection refused.
Firewall is blocking the port
A local firewall (ufw, firewalld, nftables) or a cloud security group is rejecting traffic on the SSH port.
Wrong host or IP
You are connecting to an IP address where SSH is not running, to the wrong server, or to a device that does not allow SSH.
Service listens only on localhost
sshd is bound to 127.0.0.1 or the wrong interface, so it does not accept external connections.
Step-by-step fix
- 1
Check that you are on the right host and port
First confirm the server's IP address or name and the port. If you do not know the port, ask the administrator or check the configuration. The default is 22, but many servers use a different port. On the client, try explicitly:
ssh -p 22 user@server. If you still get "connection refused", continue. - 2
Check that the server is reachable
From the client, run
ping serverandnc -vz server 22(ortelnet server 22). If ping succeeds but nc reports "Connection refused", the network is fine but the service is not accepting the connection. If nc reports "timed out", the firewall is probably dropping packets. - 3
Log in locally or via the console
If you have physical access or the provider's console (KVM, VNC, serial), log in as root or a user with sudo rights. Without that you cannot check the service state. If you do not have console access, contact the provider.
- 4
Check the SSH service status
Run
systemctl status ssh(Debian/Ubuntu) orsystemctl status sshd(RHEL/CentOS). If the service is inactive, start it:sudo systemctl start ssh(Debian/Ubuntu) orsudo systemctl start sshd(RHEL/CentOS). Then check that it is enabled at boot:sudo systemctl enable ssh(Debian/Ubuntu) orsudo systemctl enable sshd(RHEL/CentOS). - 5
Check the logs for errors
Use
journalctl -u ssh -n 50orjournalctl -u sshd -n 50. Look for startup error messages, such as "bind: Address already in use" or "error: Bind to port 22 failed". On older systems, check/var/log/auth.logor/var/log/secure. - 6
Check which port and interface sshd is listening on
Run
ss -tlnp | grep sshornetstat -tlnp | grep ssh. Pay attention to the Local Address column. If it shows127.0.0.1:22, sshd is listening only locally. If it shows0.0.0.0:2222, the port is 2222. In the configuration file/etc/ssh/sshd_config, checkPortandListenAddress. - 7
Check the firewall
On Ubuntu/Debian:
sudo ufw status verbose. On RHEL/CentOS:sudo firewall-cmd --list-all. Make sure the SSH port is allowed. If you use a cloud, check the security group or network firewall in the provider's console. If you use ufw, you can allow the SSH port (for examplesudo ufw allow 22/tcp). - 8
Fix the configuration and restart sshd
If you changed
/etc/ssh/sshd_config, check the syntax:sudo sshd -t. Then restart the service:sudo systemctl restart ssh(Debian/Ubuntu) orsudo systemctl restart sshd(RHEL/CentOS). Note that a restart can drop existing connections, so make sure you have an alternative access method first. If everything is fine, try again from the client.
If nothing helps: advanced checks
If sshd is active and listening on 0.0.0.0:22 but the connection is still refused, check whether there is another firewall layer (for example nftables rules, or fail2ban that has added a ban). Check sudo nft list ruleset and sudo fail2ban-client status sshd. In a cloud environment, check that the public IP address is correctly mapped to the instance. You can temporarily run sshd on another port for testing: sudo sshd -p 2222 -d (debug mode, do not interrupt the session). If the problem occurs only from one client, check the local firewall or VPN. For production servers, always have an alternative access method (console, another SSH port) to avoid lockout.
How to prevent it
- Regularly check the sshd service status and logs
- Keep a record of port changes and firewall rules
- Provide an alternative access method (console, another port)
- Use monitoring that detects SSH unavailability
When to call a professional
If you do not have console or alternative access to the server and SSH is not working, you risk a permanent lockout. In that case, it is better to contact IT support with experience in remote recovery.
IT infrastructure maintenance · Servers, networks, backup, security and helpdeskFAQ
Why do I get "connection refused" when ping succeeds?
Ping tests network reachability, not the service. Connection refused means the host is reachable but no process is accepting a connection on that port. Most often sshd is not running or is listening on a different port.
How can I find out which port SSH is running on?
On the server, run `ss -tlnp | grep ssh` or check `/etc/ssh/sshd_config` (the `Port` directive). If you do not have access to the server, ask the administrator or provider.
Is it safe to restart sshd?
A restart can drop existing SSH sessions but will not delete data. Before restarting, check the syntax with `sudo sshd -t` and make sure you have an alternative access method (for example a console). If you are not sure about the configuration, do not restart sshd over the same session.