Guides - Troubleshooting SSH on Compute Instances
Linux virtual machines equipped with a tailored set of resources designed to run any cloud-based workload.
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.
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 Linode Community Site for posts that match your system’s symptoms. Or, post a new question in the Community Site and include your commands’ output.
Linode is not responsible for the configuration or installation of software on your Compute Instance. Refer to Linode’s Scope of Support for a description of which issues Linode 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 Using the Lish Console guide. In particular, using your web browser 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
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?
To check on the status of your SSH daemon, run:
Distribution Command systemd systems (Arch, Ubuntu 16.04+, Debian 8+, CentOS 7+, etc)
sudo systemctl status sshd -l
sudo service sshd status
Ubuntu 14.04, Debian 7
sudo service ssh status
If the command reports the service is running, review the Is SSH Running on a Non-Standard Port? section.
If the command reports the service is not running, then try restarting it:
Distribution Command systemd systems
sudo systemctl restart sshd
sudo service sshd restart
Ubuntu 14.04, Debian 7
sudo service ssh restart
Check the status of the service again. If it’s still not running, view the logs for the service:
Distribution Command systemd systems
sudo journalctl -u sshd -u ssh
Ubuntu 14.04, Debian 7
NoteReview the journalctl and less guides for help with navigating your logs when using those commands.
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 Linode 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.
Is SSH Running on a Non-Standard Port?
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 firstname.lastname@example.org -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: 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
netstatcommand 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
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
Assign a different port to the other service
netstatcommand to find out what service is bound to the same port.
Then, change the configuration for that service to use a different port.
Bind SSH to a Port Number
/etc/ssh/sshd_configin your editor. Search for a line in this file that declares the port for SSH:
- File: /etc/ssh/sshd_config
Uncomment this line and provide a different number.
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 frontends 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
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.
Create a temporary backup of your current iptables rules:
sudo iptables-save > ~/iptables.txt
OUTPUTpacket policies as
sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT
nattable that is consulted when a packet that creates a new connection is encountered:
sudo iptables -t nat -F
mangletable that is used for specialized packet alteration:
sudo iptables -t mangle -F
Flush all the chains in the table:
sudo iptables -F
Delete every non-built-in chain in the table:
sudo iptables -X
Repeat these steps with the
ip6tablescommand to flush your IPv6 rules. Be sure to assign a different name to the IPv6 rules file (e.g.
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
no, then try logging in with another user. Or, set the value in
yes, restart SSH, and try logging in as root again.
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
no, create a key-pair. Or, set the value in
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:
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
-voption. Passing more than one
vincreases the verbosity. You can use up to three
ssh -v email@example.com ssh -vv firstname.lastname@example.org ssh -vvv email@example.com
Try pasting your logs into a search engine or searching for your logs in the Linode 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.
This page was originally published on