Troubleshooting “SSH Connection Refused” Error and Regaining Access

Are you facing the dreaded “SSH Connection Refused” error while trying to access your server? Don’t panic! In this comprehensive step-by-step guide, we will help you troubleshoot the issue and regain access to your SSH connection. In this article, we will walk you through the troubleshooting process, providing easy-to-follow instructions that will help you pinpoint the root cause of the error. From checking your network settings to verifying SSH server configuration, we will cover every possible reason behind the connection refused error.

This common issue can arise due to various reasons, such as SSH authentic failures, network problems, server misconfigurations, or firewall restrictions. Identifying the root cause is crucial to restoring your SSH access. By understanding the typical triggers behind this error, you can streamline the troubleshooting process and expedite the resolution.

Checking SSH Credentials

The foremost solution is to check the user credentials you tried to connect via SSH into the server were correct. This includes IP address, username, password, and the SSH port. A typo in any of these fields can lead to the server refusing your connection. By double-checking your credentials, you can rule out a simple mistake as the cause of the connection failure. If the credentials are correct, then go ahead with the next steps for resolving the issue.

Checking Network Connectivity

One of the primary culprits for the SSH connection refused error is incorrect network settings. Ensure that your server is connected to the internet and that no network disruptions are causing the communication breakdown. To check that you can use the Ping tool to ping the server first:

ping <server ip>

Replace the <server ip> with the server IP of your SSH connection issue machine.

If you are getting ping like the above picture, it means there are no issues with network connectivity. You can go ahead with the next steps. If the ping to the server IP does not function as expected as in below screenshot, it indicates that the issue lies not with SSH, but with network connectivity, which is beyond the scope of this blog.

The next step is to check the connectivity via a specific SSH port to the server. This can be checked with the Telnet tool. For Windows users, you can visit the website https://portchecker.co/ to check if the port is open for connections.

telnet <hostname_or_IP_address> <port> 

Replace <hostname_or_IP_address> with the hostname or IP address of the server and <port> with the SSH port you are using for SSH.

If the port is open and the SSH service is running, you will see a response similar to this:

If the port is closed or blocked by any firewall rules or misconfiguration inside the server, you will see a response indicating that the connection refused:

To proceed further, you must have access to the server through alternative methods such as physical access, VNC console, IPMI access, or any other means. Without such access, it will not be possible to check or resolve the issue with SSH.

Verifying SSH Server Status

After reviewing the network connectivity via ping the next step is to check if the SSH service is running on the server. Verifying this fundamental aspect is crucial for an issue related to SSH service.

To check if the SSH service is running, access the server via any other methods such as console and execute the following command:

sudo systemctl status ssh

This command will show the status of the SSH service. If it is running, you will see “active (running)” like the below screenshot.

On some systems, the service might be named sshd instead of ssh. If the above command doesn’t work for you use: sudo systemctl status sshd instead.

sudo systemctl status sshd

If it is not working, you will see either an inactive status or a disabled status. You can need to enable and activate it by the following commands:

sudo systemctl enable ssh
sudo systemctl restart ssh

If you encounter any errors while executing commands related to SSH or if you still find the SSH service inactive after executing the above commands, you should check the system logs using journalctl for more information about the issue.
You can view the logs related to SSH via the following command:

sudo journalctl -u ssh

OR

sudo journalctl -u sshd

This command will display log messages related to the SSH service, including any errors or warnings that may help diagnose the issue.

Verifying SSH Server Configuration

A critical aspect of troubleshooting the SSH connection refused error is examining the server-side configuration settings. Start by reviewing the SSH server’s configuration file, typically at /etc/ssh/sshd_config. Check parameters related to authentication, access controls, and port settings.

Inspect the SSH server’s access control rules. Ensure the AllowUsers and AllowGroups directives include the appropriate user accounts and groups for SSH access. Validate the SSH server’s port configuration. SSH typically operates on port 22, but confirm this in the configuration file. If running on a non-standard port, ensure your SSH client connects to the correct port. These adjustments can often resolve connectivity issues and mitigate the SSH connection refused error.

Open the SSH server configuration file with a text editor (e.g., nano, vi, or vim) and verify the values you have configured, such as the port number, PermitRootLogin, and PasswordAuthentication. Adjust these settings as needed to ensure they meet your requirements:

sudo nano /etc/ssh/sshd_config

After verifying and editing the configuration, restart the SSH service with command:

sudo systemctl restart ssh

OR

sudo systemctl restart sshd

Dealing with Firewall and Port-Blocking Issues

Firewall restrictions and port blocking issues are common culprits behind the SSH connection refused error, particularly in environments with stringent security policies. Firewalls, both at the server and network levels, can filter incoming connections and block traffic on specific ports, including the default SSH port 22. Resolving firewall and port-blocking issues involves adjusting the firewall rules to permit SSH traffic and unblocking the necessary ports.

For this, at first place, you need to check if the SSH daemon is running and listening on the designated port (usually port 22) via system monitoring tools like netstat or ss . Inorder to check it use one of the tool from it:

Using Netstat tool:

netstat -tuln | grep :22

Using SS tool:

ss -tuln | grep :22

If there is any output for these commands showing :22 or the SSH port of yours in it, then they are listening and open. If not, then try opening the ports via your firewall.

Use the appropriate command for your operating system’s firewalls:

UFW (Ubuntu and Debian-based Linux distributions):

sudo ufw status

This command will display the status of the UFW firewall and the list of rules that are configured.

sudo ufw allow ssh

sudo ufw allow 22/tcp

sudo ufw status

IPtables:

sudo iptables -L

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

sudo sh -c "iptables-save > /etc/iptables/rules.v4"
sudo systemctl restart netfilter-persistent

sudo service iptables save
sudo systemctl restart iptables

FirewallD (Red Hat Enterprise Linux (RHEL), CentOS, Fedora, and other related distributions):

sudo firewall-cmd --get-active-zones

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

sudo firewall-cmd --reload

In addition to server-side firewall configurations, consider inspecting network-level firewalls, such as hardware firewalls or cloud security groups, that might be filtering SSH traffic before it reaches the server. Ensure that these network devices are configured to allow SSH connections and that the necessary ports are open for inbound traffic. Collaborate with your network administrators or cloud service providers to adjust the firewall settings and eliminate any port blocking issues hindering the SSH connection.

Checking SSH Logs

SSH logs can provide insights into why the connection is being refused. You can use the journalctl command to view these logs on systems using systemd, or check specific log files directly. Viewing logs via journalctl command is already discussed earlier in this blog.

To check logs directly, open the terminal and run the following command:

sudo less /var/log/auth.log

On some systems, logs are present in a different file, to view it, use the command:

sudo less /var/log/secure

Look for recent entries related to SSH to find any errors or warnings that might explain why the connection is being refused. With these logs you will get an idea of the error and can solve with any of the methods discussed in the blog.

Tip: When attempting to access a server via SSH from your client machine, you can enhance the verbosity of the SSH command by using the -vvv flag. This flag provides detailed debugging information directly from the client side, helping you to understand the specific errors encountered during the connection process. 
i.e; ssh -vvv user@hostname_or_ip

Troubleshooting SSH client configuration

To resolve the connection refused error, thoroughly examine both server-side and SSH client configurations. The SSH client’s settings, typically found in ~/.ssh/config or /etc/ssh/ssh_config, should be carefully checked for misconfigurations. Pay close attention to any host-specific overrides and ensure correct server IP addresses or hostnames are used, along with appropriate SSH keys. Confirm compatibility of encryption algorithms and key exchange methods with server settings. If issues persist with a particular SSH client, test with an alternative to pinpoint whether the problem is client-specific or broader. By troubleshooting client settings and testing different clients, you can identify and address the underlying cause of the error.

In your local Linux computer, inspect SSH client configuration file with a text editor which will be located at ~/.ssh/config or /etc/ssh/ssh_config. This file path is same for macOS but Windows use a different path: C:\Users\username.ssh\config

Ensure there are no misconfigurations for the specific host you are trying to connect to. An example for the host-specific settings is shown below:

If you are using key-based authentication to the server, please ensure to provide correct path of the key file in it. Also inspect the preferred encryption algorithms and key exchange methods are correctly set here.

You can also attempt to check the issue by using an alternative SSH client software, such as PuTTY. Testing the connection through PuTTY can help determine if the problem persists across different client applications.

Reinstalling SSH Service and Restarting the Server

If SSH connection refused errors persist despite troubleshooting with the above methods, reinstalling SSH and restarting the server will be the final solution for you. Before doing it make sure to save work.

On Linux (Ubuntu/Debian):

sudo apt update
sudo apt install --reinstall openssh-server

On Linux (CentOS/RHEL):

sudo yum reinstall openssh-server

By systematically applying the approaches discussed in this blog, you can effectively troubleshoot and resolve the ‘SSH connection refused’ error, thereby restoring access to your server.