How to Solve "Connection Refused" Error on Linux Port 22

Server administration on the Linux system is not always a flawless process, from time to time there might be some issues and errors. Here we will share our practical experience about the “connection refused” error. When such an issue occurs, that means connection via SSH protocol cannot be conducted and you should better follow some of the professional recommendations in order to solve this problem with a methodical approach.

Client Connectivity Assessment

To start solving this issue, there should be some testing done on the client side. For this purpose, we will share in detail the utilization of telnet and ping.

Server Reachability Test via Ping

The first thing that can be done for testing purposes is the usage of ping and IP or hostname to define whether the server can be reached. Here is how you can do it:

$ ping 11.321.44.2

If the server is reachable, you will get some additional information and also ping statistics. However, in case of no response to this command that doesn’t 100 percent guarantee that the server is unreachable.  

Port Availability Check with Telnet

One more great option is to check port availability with telnet command, which utilizes a text-based connection. So, let’s use the next command for testing the default SSH port:

$ telnet 11.321.44.2 22

If the connection is successfully made, then you will see information about the operating system and SSH server software. If the attempt is not established and you haven’t got such data, then it doesn’t mean that this server is unreachable.  

SSH Server Configuration Examination

Now, let’s check that the SSH port functions in the right way by reviewing the server configuration with the usage of:

$ grep Port /etc/ssh/sshd_config
Port 2222

Here we are not using a default 22 port. Then use the following line:

$ ssh -p 2222 user_name@ourserverip

This port can be easily changed to the default one with the usage of:

$ grep Port /etc/ssh/sshd_config
Port 22

After that, you should only do the restart with systemctl. After doing so, the connection via a default port could be done:

$ sudo systemctl restart sshd

SSH Service Status Inspection

The next step in our procedure will be an inspection of the SSH service and a review of the installation status.

Status Check for SSH Service

The status check is straightforward and should include the following line:

$ systemctl status ssh

The output to this line should contain all the details about process data, current status, log events, and also configuration. If you don’t have such a detailed output and the server is not running, then you can use the next command:

$ sudo systemctl start sshd

In addition to this, it may be also needed to enable SSH service:

$ sudo systemctl enable sshd

At the end you should perform a reboot, and you can try to check the status once again.

Firewall Configuration and Examination

One more explanation of this error can be connected with the firewall block. That’s why we will need to specify the tool which controls our access to the system.

ufw Firewall Usage

To inspect whether there is no blockage of the SSH traffic, use the following command:

$ sudo ufw status

When reviewing the output, you will see whether the traffic is allowed and from where. If you cannot see this information, then try first to open the default port by:

$ sudo ufw allow 22

Then do a reload and try again:

$ sudo ufw reload

iptables Firewall Configuration

The next step in this process will be reviewing the iptables rules:

$ sudo iptables -n -L | grep 22

With the usage of this command, you can check rules that allow certain traffic on port 22. If you don’t have incoming traffic in the output, you can change this with the help of:

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

Now, let’s explain the above-mentioned line for you to have a better understanding of the process:

• 22 – this part determines the port.
• -p tcp – here we mention the needed protocol; in this case, it is TCP.
• -j ACCEPT – means that traffic that matches such rule must be accepted.

The following step will be the installation of iptables-persistent, this should be done to make them persistent after the rebooting:

$ sudo apt-get install iptables-persistent

During the process, you will be asked to save the current rules.

firewalld Firewall Configuration

We utilize the following command to check whether the SSH port is open, this should be done in case firewalld functions on Linux:

$ sudo firewall-cmd --list-ports

There might be a scenario when this port is not in the list so you can allow it with the line:

$ sudo firewall-cmd --permanent --add-port=22/tcp

By the usage of this command, you are adding port 22 to the permanent configuration. After doing this step, make a reload:

$ sudo firewall-cmd --reload

SSH Host Management

Now, let’s try to deal with the issues that might be connected with the host keys. We can cope with this by clearing the file:

$ cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak && echo > ~/.ssh/known_hosts

Examination of SSH Logs

Another method that we can use to fix the error is to test SSH logs for any possible issues. To check the latest logs use tail and -f to review the new entries:

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

You can also try /var/log/secure, in case the location in the sample command has not worked. These are 2 typical options, but you have also got another pass.

SSH Issue Analysis

If none of the above-mentioned variants worked for your case, then we can offer one more thing:

$ ssh -v asr@177.155.233.156

The output will help you to determine the issues of SSH connection.

Conclusion

Here we shared with you some practical recommendations about the SSH error in the Linux system. We’ve tried to include all the most common strategies regarding the most basic connectivity troubles. Start with checking the SSH configuration, then start testing the firewall setup, and of course, you can also use SSH Issue Analysis. Just by following the simplest procedure, you will get a secure SSH connection on your operating system (in our case Linux).