How to troubleshoot SSH Related Issues?
Guide to Troubleshoot SSH related Issues
SSH, also known as Secure Shell or Secure Socket Shell, is a service that gives users and system administrators, a secure way to access a server over an unsecured network.
At times, it can happen that the server becomes inaccessible through SSH or the SSH service becomes unresponsive. Specified below are several methods that can be used to troubleshoot SSH connectivity issues.
Before proceeding with SSH troubleshooting, you need to make sure that :
- Your Cloud Server is working correctly through the VNC console.
- There are no SSH access restriction rules set in the firewall in your client portal.
Troubleshooting SSH Connectivity Issues
1. Remote Hostname Identification Error
You may get errors like the below ones when trying to access through SSH:
Host Identification Has Changed
ssh: Could not resolve hostname: Name or service not known
Unable to open connection to layerstack.com Host does not exist
A hostname error may occur when a host fails to connect to SSH using a specific network address or hostname.
To resolve such errors, you may follow the steps below:
- Check if the hostname is correct.
- Check if the hostname has ping.
- If the hostname is not resolving properly, you can use the IP address of the cloud server for SSH as below, where user is the SSH username that you use and 220.127.116.11 is the server IP.
2. Connection Timeout error
This error shows up when a user tries to connect to a server, but the server refuses to establish the connection within a specified timeout period.
The common error messages in such cases are as below:
ssh: connect to host xxx.xxx.xxx.xxx port 22: connection timed out
PuTTY error output
Network error: Connection time out
To correct this error, follow the below steps.
- Make sure that the server IP address is correctly typed in.
- Confirm that your network allows SSH port connectivity.
- Verify that the firewall rules on your VPS are not at fault.
3. Connection failure
Connection failure and timeout are both different. A connection failure occurs when your SSH request reaches the SSH port but the server refuses to accept it.
In this case, you may see the below errors:
ssh: connect to host 18.104.22.168port 22: connection refused
PuTTY error output
Network error: Connection refused
The resolution steps for connection failure is like those of connection timeout. To correct this error, use the following steps.
- Make sure that the IP address of the server is correct.
- Confirm that your network allows SSH connection.
- Verify that the server firewall rules allow SSH access.
Basic solutions to troubleshoot SSH connectivity
1. Check Firewall Configuration
One of the common causes of SSH connectivity is firewall block.
Firewall applications differ between various OS being used in the server. With CentOS7, it is firewalld, whereas with Ubuntu, it is ufw. If these are not present in the server, probably it is using iptables.
The firewall rules in your server can be listed using the below command with sudo or as root user.
If there are any REJECT or DROP rules, you should ensure that the INPUT chain allows the default SSH port, 22.
Below command will show the list of services supported by firewalld.
The below output should that the firewall supports SSH traffic:
If you are using a custom port for SSH, you can check with the –list-ports option.
In Ubuntu servers, with ufw installed, the below command can be used to check the firewall rules.
An output like below shows available ports, make sure that SSH port is in the list.
To Action From
— —— —-
22 LIMIT Anywhere
80 ALLOW Anywhere
22 (v6) LIMIT Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
2. Check status of SSH service
If you face any issues when connecting to a server using SSH, the first thing is to make sure that the SSH server is up and running.
can use the below commands to check the status of the SSH service in
For older OS systems such as Ubuntu 14.04, Debian 8, or CentOS6, use the service command.
service ssh status
For new versions, use the systemctl command.
systemctl status sshd
In case if the SSH service isn’t executing or active, the below commands can be used to start the service depending on the OS system.
systemctl start sshd
service ssh start
3. Check the SSH Port
The default SSH port in all OS systems is 22. You can also use custom SSH port, which can be set in the configuration file of the SSH service located at the path /etc/ssh/sshd_config.
Use the below command to check on the SSH port being used in the server:
grep -i port /etc/ssh/sshd_config
You can also use the netstat command to check on the port that is being used by the SSH service. Execute the below command and the output should show up the SSH port.
netstat -ntlp | grep sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1234/sshd
tcp6 0 0 :::22 :::* LISTEN 1234/sshd
Basic solutions to troubleshoot rejected SSH login
For checking on issues related to SSH rejecting login attempts, the below guidelines can be followed.
1. Check if Root Login is permitted
SSH service can be configured to disable logins for the root user. To check if root login is permitted or not, run the below command:
grep PermitRootLogin /etc/ssh/sshd_config
Set the value of PermitRootLogin in /etc/ssh/sshd_configto yes, restart SSH, and try logging in as root again.
2. Check if Password Authentication is accepted
SSH can be configured to accept/not accept passwords and instead make use of public key authentication. To check if password authentication is enabled or not, run the below command:
grep PasswordAuthentication /etc/ssh/sshd_config
Set the value of PasswordAuthentication in /etc/ssh/sshd_config to yes, restart SSH, and try logging in with your password again.
3. Checking SSH public key stored on the Server
If login attempts to your server using public key authentication are not working, you need to make sure that the public key has been set inside your server. To view the public keys stored in your server, make use of the below command.
If your public key is not listed in this file, add it to the file on a new line.
On some servers, the location of the authorized keys may be different. Run the below command to see where the file is located:
grep AuthorizedKeysFile /etc/ssh/sshd_config