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 sshThis 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 sshdIf 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 sshIf 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 sshOR
sudo journalctl -u sshdThis 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 sshOR
sudo systemctl restart sshdDealing 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 statusThis command will display the status of the UFW firewall and the list of rules that are configured.
How to allow SSH connections via UFW?
To allow SSH connections via UFW on a system running Ubuntu or another distribution that uses UFW, follow these steps:
Allow SSH connections in UFW:
sudo ufw allow sshAlternatively, you can specify the port number directly (default SSH port is 22):
sudo ufw allow 22/tcpNow check the status of UFW to ensure the rule is added:
sudo ufw statusIPtables:
sudo iptables -LHow to allow SSH connections via IPtables?
To allow SSH connections via iptables, you can follow these steps:
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Now save the rules specified now. To save the rules, the command varies with the OS you using.
For Debian-based OS like Ubuntu:
sudo sh -c "iptables-save > /etc/iptables/rules.v4"
sudo systemctl restart netfilter-persistentFor RedHat-based OS like Centos:
sudo service iptables save
sudo systemctl restart iptablesFirewallD (Red Hat Enterprise Linux (RHEL), CentOS, Fedora, and other related distributions):
sudo firewall-cmd --get-active-zonesHow to allow SSH connections via FirewallD?
To allow SSH connections via firewalld, you can follow these steps:
Start by enabling the SSH service:
sudo firewall-cmd --permanent --add-service=sshNow, reload the firewall to apply the changes:
sudo firewall-cmd --reloadIn 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.logOn some systems, logs are present in a different file, to view it, use the command:
sudo less /var/log/secureLook 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-serverOn Linux (CentOS/RHEL):
sudo yum reinstall openssh-serverBy 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.
