When connecting an SSH client to an SSH server, the first step is establishing basic network connectivity. This article covers how to identify some common situations that would cause issues at this point in the process, how to resolve those situations, and additional resources to prevent them in the future.
Most resolution errors occur when the reference to the SSH host can’t be mapped to a network address. While this is almost exclusively DNS related, the root cause isn’t always a DNS issue.
In an OpenSSH client, a command like ssh [email protected]
may return an error like this:
ssh: Could not resolve hostname example.com: Name or service not known
In PuTTY, you might see an error window with text like this:
Unable to open connection to example.com Host does not exist
Here are some steps you can take to troubleshoot this error.
ping
command. Using third-party sites like WhatsMyDns.net to check beyond your own DNS caching can also help confirm the results.If you’re having DNS resolution issues at any level, you can also use the Droplet IP address as an interim solution, as in ssh [email protected]
instead of ssh [email protected]
.
The following tutorials are a good resource to begin working out DNS configuration errors:
A connection timeout means that the client attempted to establish a network socket to the SSH server, but the server failed to respond within the timeout period.
In an OpenSSH client, a command like ssh [email protected]
may give an error like this:
ssh: connect to host 203.0.113.0 port 22: Connection timed out
In PuTTY, you might see an error window with text like this:
Network error: Connection timed out
Here are some steps you can take to troubleshoot this error.
22
or custom SSH ports. You can do this by, for example, testing other hosts using the same port with a known working SSH server. This can help you determine if the issue isn’t specific to your Droplet.A connection being refused has some subtle differences from a timeout. This means that the request is being routed to the SSH host, but the host does not successfully accept the request.
In an OpenSSH client, a command like ssh [email protected]
may return an error like this:
ssh: connect to host 203.0.113.0 port 22: Connection refused
In PuTTY, you might see an error window with text like this:
Network error: Connection refused
In this situation, you may have the same root issue as with connection timeout errors, but there are some additional things you can check:
22
or custom SSH ports. You can do this by, for example, testing other hosts using the same port with a known working SSH server. This can help you determine if the issue isn’t specific to your Droplet.Some connectivity problems can be caused by firewall configurations. If your firewall is set up to block certain ports or services, it can prevent you from connecting. You can learn more about firewalls in What is a Firewall and How Does It Work?.
If you add a firewall rule that allows your local machine to connect by IP address, verify that the IP address assigned by your ISP has not changed. If it has, then you need to modify that firewall rule to permit the new IP address or address range.
How you check your firewall rules depends on which firewall your Droplet uses. Ubuntu servers usually run UFW; CentOS servers often use FirewallD. If you’re not using either, it’s likely that you’re using iptables.
For whichever firewall your system has, make sure to familiarize yourself with how to modify its rules. You also need to know which port your SSH service is using. By default, it’s 22
, but you can follow the Checking the SSH Service Port section below to confirm.
For Linux systems not running UFW or FirewallD, list your firewall rules using the iptables
command with sudo
or as the root user.
iptables -nL
The following output would indicate that there are no rules in place that would block SSH traffic:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
If you see rules or a default policy of REJECT
or DROP
, you should ensure that the INPUT
chain allows the port your SSH service is running on, which is 22
by default.
For FirewallD users, use the firewall-cmd
command to list the services:
firewall-cmd --list-services
The output should reveal the list of services including SSH (default port 22
) to indicate that the firewall supports SSH traffic:
dhcpv6-client http ssh
If you are using a custom port for SSH, you can check with the --list-ports
option. If you created a custom service definition, you should still see SSH normally with --list-services
.
Users working with UFW should use ufw status
to inspect their firewall:
ufw status
The output similarly shows the ports available:
Status: active
To Action From
-- ------ ----
22 LIMIT Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
Anywhere ALLOW 192.168.0.0
22 (v6) LIMIT Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
Make sure that your SSH port is on the list.
If you can’t SSH to your Droplet, you should check that the SSH service is running. How to very the service is running varies from system to system.
On older OS versions (Ubuntu 14 and below, CentOS 6, Debian 6) this may use the service
command backed by Upstart. More modern distributions with systemd use the systemctl
command. Red Hat-based distributions (e.g. CentOS and Fedora) call the service sshd
while Debian and Ubuntu call it ssh
.
Similarly, on a server using systemd (like CentOS 7), use the systemctl
command to check the status:
systemctl status sshd
A running service shows output like this, with active (running) on the Active: line.
sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Mon 2017-03-20 11:00:22 EDT; 1 months 1 days ago
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (sshd)
CGroup: /system.slice/sshd.service
├ 906 /usr/sbin/sshd -D
├26941 sshd: [accepted]
└26942 sshd: [net]
If the service is not running, the Active line displays inactive followed by recent journal entries for the service:
sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: inactive (dead) since Fri 2017-04-21 08:36:13 EDT; 2s ago
Process: 906 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (code=exited, status=0/SUCCESS)
In this case, restart it with systemctl start sshd
.
For systems using the service
command, check the status of the SSH process with the following command (run as root or with sudo
):
service ssh status
Output like this, which includes the PID (process ID), indicates that the process is running as expected:
ssh start/running, process 1262
If it isn’t running, you’ll see output indicating the process is stopped:
ssh stop/waiting
In this case, restart it with service ssh start
.
There are two general ways to check which port the SSH service is running on. One is checking the SSH configuration file, and the other is examining the running process.
On most systems, the SSH configuration file is /etc/ssh/sshd_config
. The default port is 22
, but can be overridden by any configuration line in this file specifying a Port
directive with a number.
You can search lines like this using grep:
grep Port /etc/ssh/sshd_config
You’ll see output like this with the port number:
Port 22
If you know the service is running, you can confirm that the service is running on the expected port using ss
(run with sudo
or as the root user). Similar output is provided for the netstat -plnt
command as well, but ss
is the preferred command for querying socket information from the kernel.
ss -plnt
The output you are looking for should reference the program name listening on the configured port. For example, this output shows that the SSH service is listening on all interfaces, *
, on port 22
.
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:22 *:* users:(("sshd",pid=1493,fd=3))
LISTEN 0 128 :::22 :::* users:(("sshd",pid=1493,fd=4))
The interface references *
and 0.0.0.0
indicate all interfaces on the Droplet. 127.0.0.1
indicates that the service is not publicly accessible. The relevant sshd_config
directive is ListenAddress
and should be commented out to default to all interfaces, or set to the public IP address of the Droplet.
If you need further help, you can open a support ticket. Make sure to include the following information:
Including all the above diagnostic information and clarifying where you are encountering the issue when trying to connect can help us quickly get up to speed with where your need on the issue is.