How to Fix SSH Connection Refused on VPS (Step-by-Step Guide)

An “SSH connection refused” error means that your client could not establish the requested TCP connection. A stopped SSH service, the wrong port or an active firewall rejection can cause it. The message alone does not prove that the VPS is otherwise healthy.

Work through the service, listening port, network rules and logs in that order. The examples use Linux with systemd; Ubuntu/Debian commonly use ssh, while RHEL-based systems commonly use sshd.

Another option for your VPS requirements would be the UltaHost VPS Hosting if your VPS will be used for development and management.

Key Takeaways

• “SSH connection refused” means that the connection was refused by the server.
• Better to check the SSH daemon before you configure the firewall.
• Port 22 must be open for SSH access if nothing else has been configured yet.
• SSH could be blocked by UFW, iptables, firewalld, and even cloud firewalls.
• Incorrect configurations of the sshd_config file could lead to the service not starting.
• SSH configuration must always be tested before a service restart.

Before changing access: keep the current SSH session open and confirm recovery-console access. Back up configuration and run sudo sshd -t before a restart after edits. Test a second connection before closing the original session.

What Does “SSH Connection Refused” Mean?

Connecting to a VPS via SSH causes your PC to open a TCP connection to the SSH port on the server. By default, on most Linux distributions, this port is port number 22.

“SSH connection refused” means the destination actively rejected the connection attempt. Often nothing is listening on that address and port; a firewall can also reject it. A timeout means no response arrived in time, while authentication errors occur after the SSH service has been reached.

The OpenSSH server uses the sshd daemon to accept new SSH connections. Ubuntu documentation says that sshd listens to incoming connections. It manages the remote session once the connection is made.

Error	What it usually means	Common causes
Connection refused	Server rejected the connection	SSH service stopped, wrong port, firewall rejection
Connection timed out	No response arrived	Firewall, network issue, unreachable server
Permission denied	Server was reached but authentication failed	Wrong password, SSH key, username, permissions
No route to host	Network cannot reach the destination	Routing, firewall, network failure
Connection reset by peer	Existing connection was forcibly closed	SSH service, firewall, network, server process
Could not resolve hostname	Hostname could not be converted to an IP address	DNS or incorrect hostname

The distinction matters. Restarting SSH may not solve anything because the service is already reachable if you have SSH permission denied. Investigate network and firewall paths before assuming sshd is broken if you have an SSH connection timed out.

Check That SSH Service Is Running

Let us check the straightforward thing: Is sshd running?

The service is usually named ssh on Ubuntu and Debian. sshd on RHEL systems is usually what people use for the name of the service.

Under Ubuntu or Debian:

sudo systemctl status ssh

Start the service if it is not running:

sudo systemctl start ssh

To restart it:

sudo systemctl restart ssh

You can also check whether the service is enabled for auto-start:

sudo systemctl is-enabled ssh

Under RHEL-based systems:

sudo systemctl status sshd
sudo systemctl start sshd
sudo systemctl restart sshd

You can also check that the SSH process is running:

ps aux | grep '[s]shd'

Do not repeatedly try to start the service without checking the logs. A misconfiguration might prevent sshd from starting.

You will find the installation instructions in the official documentation if there is no OpenSSH installed on Ubuntu:

sudo apt install openssh-server

Check That Port 22 is Listening

A running SSH service is not enough. The SSH service should also be listening on the port on which it is expected to listen.

Type:

sudo ss -tlnp | grep ':22'

The following output will show if something is listening on TCP port 22:

LISTEN 0 128 0.0.0.0:22 0.0.0.0:*

You can check using lsof:

sudo lsof -iTCP:22 -sTCP:LISTEN

Some old systems might still have netstat:

sudo netstat -tlnp | grep ':22'

An empty result means that this check found no listener on port 22. The service might be stopped, bound to another address or listening on a different port. Check service status and configuration before choosing the next step.

Check the configured SSH port. On Ubuntu installations using socket activation, also inspect systemctl status ssh.socket and its listener; the socket can own the port even when the service appears idle. See the Ubuntu socket-activation notes before changing that setup.

sudo grep -E '^[[:space:]]*Port[[:space:]]+' /etc/ssh/sshd_config

For Port 2222 connect via:

ssh -p 2222 username@server_ip

Port 22 is not always right. The default port for OpenSSH is 22. It is still possible to configure another one. It should also be noted that Port is a directive used by sshd to specify the port number to listen on.

Check Firewall Rules: Connections Could Be Refused Because of These Rules

If SSH is up and listening but connections are refused, check your firewall.

• UFW: Many Ubuntu servers use UFW.

Check UFW state:

sudo ufw status

If SSH is not allowed yet, it is possible to allow the SSH service explicitly:

sudo ufw allow ssh

Or allow TCP port 22:

sudo ufw allow 22/tcp

Now check your rules again:

sudo ufw status numbered

It is crucially important to make sure your connection will be allowed in case of any changes in firewall rules to avoid being locked out.

iptables

Check current rules:

sudo iptables -L -n -v

Look for rules associated with TCP port 22.

If your firewall policy requires an explicit allow rule, replace YOUR_IP with your trusted source IP and 22 with the actual SSH port. This IPv4 example may not survive a reboot unless your firewall setup saves it; review IPv6 separately.

sudo iptables -I INPUT -p tcp -s YOUR_IP --dport 22 -j ACCEPT

• firewalld: In RHEL, Rocky Linux, AlmaLinux, Fedora, and other distributions which use firewalld, examine the current configuration:

sudo firewall-cmd --list-all

See if SSH is allowed:

sudo firewall-cmd --list-services

To allow the default SSH service in firewalld, select the active zone that contains your network interface. The examples below use the default zone; add --zone=YOUR_ZONE if your interface uses a different one. Allow the actual port instead when using a custom SSH port.

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

It is recommended to examine the full configuration of zones because a service might be enabled although not listed in a list of open ports.

• Cloud Firewall: Your Linux firewall might not be the only firewall along the path.

Almost all VPS providers have a separate firewall, security group, network ACL, or firewall rules. Check out the control panel of your provider and make sure that TCP connections to your SSH port are permitted from your IP address.

Pay more attention to the cloud firewall if your local SSH port 22 is available from the VPS itself but not remotely.

Firewall	Check
UFW	sudo ufw status
iptables	sudo iptables -L -n -v
firewalld	sudo firewall-cmd --list-all
Cloud firewall	VPS provider control panel
Custom SSH port	Allow the configured port instead of 22

Check SSH Configuration (sshd_config)

A misconfiguration could stop SSH from launching or make it listen to ports in an unexpected way.

The configuration file is normally:

/etc/ssh/sshd_config

Ubuntu can also load configuration from other sources via:

/etc/ssh/sshd_config.d/

Ubuntu reads configuration snippets through the Include directive. The effective setting can depend on include order and conditional sections. Inspect the loaded configuration rather than assuming that the last line you edited applies.

Check the port:

sudo grep -Rni '^[[:space:]]*Port' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Check authentication settings:

sudo grep -RniE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|AllowUsers)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

• PermitRootLogin: Allows root to log in directly. Disabling this feature may improve security. This change can affect the way you access the server. This directive is described by OpenSSH as root login control.
• PasswordAuthentication: Enables or disables password-based authentication. Do not forget to enable SSH key authentication before disabling PasswordAuthentication.
• AllowUsers: Allows SSH access only to certain users. Legitimate users will not be able to access the server if you enter the wrong username. AllowUsers directive is described by OpenSSH as a username restriction.
• Test the Configuration Before Restarting: This is the main safety precaution. Use the command:

sudo sshd -t

When there is no output, this means that the configuration is syntactically correct. Fix this error before restarting SSH if there is an error message. As Ubuntu developers note, you should run sshd -t before restarting the service after configuration modification because a configuration error may prevent sshd from starting at all.

Restart the SSH Service Safely

After the configuration has passed the syntax test, restart the SSH service.

Ubuntu/Debian:

sudo systemctl restart ssh

RHEL derivatives:

sudo systemctl restart sshd

If only one parameter that can be reloaded has been changed in the configuration file, try using:

sudo systemctl reload ssh

Do not terminate the current SSH session before testing the new configuration. Open another terminal window and attempt to create a new connection.

For the default SSH port:

ssh username@server_ip

For a non-default port:

ssh -p 2222 username@server_ip

Check SSH Logs

If sshd does not work, the logs will give you the reason.

If your system uses systemd:

sudo journalctl -u ssh

If it is based on RHEL:

sudo journalctl -u sshd

To get the recent entries:

sudo journalctl -u ssh --since "30 minutes ago"

For live SSH logs:

sudo journalctl -fu ssh

According to Ubuntu, the command journalctl -fu ssh is also used to troubleshoot SSH.

The old logs may be helpful too.

Ubuntu and Debian use:

/var/log/auth.log

RHEL systems use:

/var/log/secure

For instance:

sudo tail -f /var/log/auth.log

or

sudo tail -f /var/log/secure

In case the SSH service won’t start, look for messages such as syntax error, invalid directive, unavailable port, permissions issue or failed dependencies.

Common SSH errors You Must Know About

Not all SSH failures are the SSH connection refused problem. It is important to know the exact error message.

Error	Meaning	First thing to check
Connection refused	Destination rejected the TCP connection	SSH service and listening port
Connection timed out	No response was received	Firewall, routing, network
Permission denied	SSH reached the server but authentication failed	Username, password, SSH key
No route to host	Your system cannot reach the destination	Network route and firewall
Connection reset by peer	Connection was forcibly closed	SSH service, firewall, server logs
Could not resolve hostname	Hostname does not resolve to an IP	Hostname and DNS

“so be particularly careful when editing the configuration on a remote server.”

Best Practices to Avoid SSH Connection Issues

It is easier to avoid SSH issues than to fix them once you are locked out.

• Second Access Method: Before applying any important SSH or firewall rules, know how you will gain access to your VPS using its web console, KVM, recovery console, or other out-of-band method.

• Test Configuration before Restarting – always run:

sudo sshd -t

The syntax error test will help you recognize the error without any loss of connectivity.

• Do Not Close The Existing SSH Session: Do not close the current SSH session while modifying the configuration. Test the modification from another terminal window.

• Use SSH Keys: SSH keys allow you to get good security without using passwords at all. Ubuntu encourages users to use Ed25519 keys. Generate a key with:

ssh-keygen -t ed25519

Then install the public key on the server in the following way:

ssh-copy-id username@server_ip

• Be Cautious: Determine what port number SSH is listening on before any changes. Limiting access to port 22 will not be of much help if SSH is using port 2222.

• Create Backup Copies – Before making any changes:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

The documentation for Ubuntu further suggests creating a copy of the original SSH configuration file during the process of making modifications to it.

• SSH Logs Monitoring: Regular monitoring of SSH logs is essential to identify any failures or misconfigurations.
• Fail2Ban Caution: Fail2Ban may be utilized to protect the SSH service from repeated authentication attempts. One should be cautious while implementing the rules for Fail2Ban because they may lock out even legitimate users.
• Check SELinux: There could be a need to change the SELinux policy as well while using a RHEL OS and changing the SSH port. Red Hat explains the ssh_port_t SELinux policy type for such use cases. For instance:

sudo semanage port -a -t ssh_port_t -p tcp 2222

The command will vary depending on the version of SELinux and the policies that you have installed.

How to Verify That SSH is Back to Normal

Try logging in from your machine once you have made all changes.

For port 22:

ssh username@server_ip

For other ports:

ssh -p 2222 username@server_ip

SSH connection is successful if a login prompt appears and the process of authentication succeeds.

And check if the server listens on that port from the local machine:

sudo ss -tlnp | grep ssh

And finally, check the service:

sudo systemctl status ssh

or

sudo systemctl status sshd

If everything goes well, there will be confirmation of three things. The SSH service is up and running. The correct port is listening. The firewall and network path are clear for the connection.

Conclusion 

Diagnose SSH connection refusal by checking the actual service, listening port, firewall path and logs. Keep a recovery route available, validate configuration and test a second login before closing the original session. A Linux VPS gives you control over these settings, along with responsibility for maintaining them.

FAQs