Guide
Training

Troubleshooting SSH on Compute Instances

Suggest Edits

This guide presents troubleshooting strategies for when you can't connect to your Compute Instance via SSH. If you currently cannot ping your Compute Instance, then your server also likely has more basic connection issues. If this is the case, you should instead follow the Troubleshooting basic connection issues guide. If you restore basic networking to your Compute Instance but still can't access SSH, return to this guide.

If you can access SSH but not other services, refer to the Troubleshooting web servers, databases, and other services guide.

📘

Additional resources for help

This guide explains how to use different troubleshooting commands on your Compute Instance. These commands can produce diagnostic information and logs that may expose the root of your connection issues. For some specific examples of diagnostic information, this guide also explains the corresponding cause of the issue and presents solutions for it.

If the information and logs you gather do not match a solution outlined here, consider searching the Community Site for posts that match your system's symptoms. Or, post a new question in the Community Site and include your commands' output.

We are not responsible for the configuration or installation of software on your Compute Instance. Refer to Scope of Support for a description of which issues Support can help with.

Before you begin

Before troubleshooting your SSH service, familiarize yourself with the Linode Shell.

The Linode shell (Lish)

Lish is a shell that provides access to your Compute Instance's serial console. Lish does not establish a network connection to your Compute Instance, so you can use it when your networking is down or SSH is inaccessible. While troubleshooting SSH, all commands you enter on your system will be performed from the Lish console.

To learn about Lish in more detail, and for instructions on how to connect to your Compute Instance via Lish, review the Access your system console using Lish > Through SSH guide. In particular, Cloud Manager is a fast and simple way to access Lish.

Forgotten your password?

If you have forgotten your Linux user's password, you will not be able to log in with Lish. You can reset the root password for your Compute Instance with these instructions. If you are logged in as root, you can change the password of another user with the passwd command:

passwd <username>

If you reset your password and can log in with Lish, try logging in with SSH, as that may have been the cause of your connection problems.

Troubleshoot unresponsive SSH connections

If your SSH connection attempts are timing out or are being immediately rejected, then your SSH daemon may not be running, or your firewall may be blocking SSH connections. This section will help troubleshoot these issues.

If your connections are not timing out or being rejected, or if you are able to resolve these issues but you still can't access SSH because of rejected login attempts, then continue to the Troubleshoot rejected SSH logins section.

Is SSH running?

  1. To check on the status of your SSH daemon, run:

    DistributionCommand
    systemd systems (Arch, Ubuntu 16.04+, Debian 8+, CentOS 7+, etc)sudo systemctl status sshd -l
    CentOS 6sudo service sshd status
    Ubuntu 14.04, Debian 7sudo service ssh status

  2. If the command reports the service is running, review the Is SSH running on a non-standard port? section.

  3. If the command reports the service is not running, then try restarting it:

    DistributionCommand
    systemd systemssudo systemctl restart sshd
    CentOS 6sudo service sshd restart
    Ubuntu 14.04, Debian 7sudo service ssh restart

  4. Check the status of the service again. If it's still not running, view the logs for the service:

    DistributionCommand
    systemd systemssudo journalctl -u sshd -u ssh
    CentOS 6less /var/log/secure
    Ubuntu 14.04, Debian 7less /var/log/auth.log

    📘

    Review the journalctl and less guides for help with navigating your logs when using those commands.

  5. Review the Is another service bound on the same port? section. Then:

    • If you can start the SSH service successfully, but your connections still time out or are rejected, then review your firewall rules.

    • If you can't get the service to start, try pasting your logs into a search engine or searching for your logs in the Community Site to see if anyone else has run into similar issues. If you don't find any results, you can try asking about your issues in a new post on the Community Site.

Is SSH running on a non-standard port?

Run netstat on your Compute Instance to check which port is used by SSH:

sudo netstat -plntu | grep ssh

tcp        0      0 0.0.0.0:41              0.0.0.0:*               LISTEN      4433/sshd
tcp6       0      0 :::41                   :::*                    LISTEN      4433/sshd

This example output shows that SSH is running on port 41. You can connect to SSH by manually specifying this port:

ssh username@192.0.2.4 -p 41

Alternatively, you can bind SSH on the standard port (22).

Is another service bound on the same port?

Check your SSH logs for a message that looks like:

Jan 23 10:29:52 localhost sshd[4370]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.

This error indicates that another service on your system is already using the same port that SSH binds to, and so SSH can't start. To resolve this issue, choose one of the following solutions.

  • Bind SSH to a different port

    Follow instructions for setting SSH's port number, and specify a different number than the one that is already in-use.

  • Stop the other service

    1. Use the netstat command to discover which other process is using the same port:

      sudo netstat -plntu | grep :22

      tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      4433/some-other-service
tcp6       0      0 :::22                   :::*                    LISTEN      4433/some-other-service

    2. Stop and disable that other service:

      sudo systemctl stop some-other-service
sudo systemctl disable some-other-service

      Or, kill the process using the process ID listed next to the process name in the output from netstat.

  • Assign a different port to the other service

    1. Use the netstat command to find out what service is bound to the same port.

    2. Then, change the configuration for that service to use a different port.

    3. Restart SSH.

Bind SSH to a port number

  1. Open /etc/ssh/sshd_config in your editor. Search for a line in this file that declares the port for SSH:

    #Port 22

  2. Uncomment this line and provide a different number.

  3. Save the file and restart the SSH service.

Review firewall rules

If your service is running but your connections still fail, your firewall (which is likely implemented by the iptables software) may be blocking the connections. To review your current firewall ruleset, run:

sudo iptables-save # displays IPv4 rules
sudo ip6tables-save # displays IPv6 rules

📘

Your deployment may be running FirewallD or UFW, which are front ends used to more easily manage your iptables rules. Run these commands to find out if you are running either package:

sudo ufw status
sudo firewall-cmd --state

Review How to configure a firewall with UFW and Introduction to FirewallD on CentOS to learn how to manage and inspect your firewall rules with those packages.

Firewall rulesets can vary widely. Review the Control network traffic with iptables guide to analyze your rules and determine if they are blocking connections. A rule which allows incoming SSH traffic could look like this:

-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

In some cases, fail2ban, a tool used for automating the creation of firewall rules to block IP addresses, may be responsible for creating rules that result in a lost connection. If you see firewall chains in place prefixed with f2b or fail2ban, see our fail2ban guide for troubleshooting this service.

Disable firewall rules

In addition to analyzing your firewall ruleset, you can also temporarily disable your firewall to test if it is interfering with your connections. Leaving your firewall disabled increases your security risk, so we recommend re-enabling it afterward with a modified ruleset that will accept your connections. Review Control network traffic with iptables for help with this subject.

  1. Create a temporary backup of your current iptables rules:

    sudo iptables-save > ~/iptables.txt

  2. Set the INPUT, FORWARD and OUTPUT packet policies as ACCEPT:

    sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

  3. Flush the nat table that is consulted when a packet that creates a new connection is encountered:

    sudo iptables -t nat -F

  4. Flush the mangle table that is used for specialized packet alteration:

    sudo iptables -t mangle -F

  5. Flush all the chains in the table:

    sudo iptables -F

  6. Delete every non-built-in chain in the table:

    sudo iptables -X

  7. Repeat these steps with the ip6tables command to flush your IPv6 rules. Be sure to assign a different name to the IPv6 rules file (e.g. ~/ip6tables.txt).

Troubleshoot rejected SSH logins

If SSH is listening and accepting connections but is rejecting login attempts, review these instructions:

Is root login permitted?

SSH can be configured to disable logins for the root user. To check your SSH configuration, run:

grep PermitRootLogin /etc/ssh/sshd_config

If the value of the PermitRootLogin is no, then try logging in with another user. Or, set the value in /etc/ssh/sshd_config to yes, restart SSH, and try logging in as root again.

📘

This option can also be set with the value without-password. If this value is used, root logins are accepted with public key authentication.

Are password logins accepted?

SSH can be configured to not accept passwords and instead accept public key authentication. To check your SSH configuration, run:

grep PasswordAuthentication /etc/ssh/sshd_config

If the value of the PasswordAuthentication is no, create a key-pair. Or, set the value in /etc/ssh/sshd_config to yes, restart SSH, and try logging in with your password again.

Is your public key stored on the server?

If you prefer to use public key authentication, but your login attempts with your key are not working, double-check that the server has your public key. To check which keys are recognized for your user, run:

cat ~/.ssh/authorized_keys

If your public key is not listed in this file, add it to the file on a new line.

On some systems, your authorized keys file may be listed in a different location. Run this command to show where your file is located:

grep AuthorizedKeysFile /etc/ssh/sshd_config

Collect login attempt logs

If the previous troubleshooting steps do not resolve your issues, collect more information about how your logins are failing:

  • View your login attempts in the log files described in step 4 of Is SSH running?. In particular, you can search these logs for your local IP address, and the results will show what error messages were recorded for your logins. To find out what your local IP is, visit a website like https://www.whatismyip.com/.

  • Use your SSH client in verbose mode, which will show details for each part of the connection process. Verbose mode is invoked by passing the -v option. Passing more than one v increases the verbosity. You can use up to three vs:

    ssh -v username@192.0.2.4
ssh -vv username@192.0.2.4
ssh -vvv username@192.0.2.4

Try pasting your logs into a search engine or searching for your logs in the Community Site to see if anyone else has run into similar issues. If you don't find any results, you can try asking about your issues in a new post on the Linode Community Site.

Updated 4 months ago