We hope you find this tutorial helpful. In addition to guides like this one, we provide simple cloud infrastructure for developers. Learn more →

How To Troubleshoot SSH Connectivity Issues On Your Droplet

PostedApril 28, 2017 1.8k views Linux Basics Arch Arch Linux CentOS CoreOS Debian FreeBSD RHEL Ubuntu Ubuntu 12.04 Ubuntu 16.04

Introduction

This is a continuation of our SSH troubleshooting article series.

The first article will help you determine when to troubleshoot an issue instead of migrating or redeploying, and provides resources for the information you'll need to have to troubleshoot effectively. The other parts of this series cover how to identify and resolve specific SSH errors, and are broken down by which phase of a successful SSH connection you need to debug:

When connecting an SSH client to an SSH server, basic network connectivity must be properly established. This tutorial will cover 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

Prerequisites

To troubleshoot SSH connectivity issues, you will need to make sure your Droplet is responding normally from the web console with a working network configuration. You can do this by following the How and When To Troubleshoot SSH Issues tutorial.

Before troubleshooting SSH, you should always check your cloud panel for ongoing issues in the region impacting your Droplet, the hypervisor status, and the state of the Droplet through the web console.

Errors

Below are some common SSH connectivity errors you might encounter.

Hostname Resolution

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 user@example.com may result in an error similar to:

Error output
ssh: Could not resolve hostname example.com: Name or service not known

In PuTTY, you might see an error dialogue with text similar to:

PuTTY error output
Unable to open connection to example.com Host does not exist

Here are some steps you can take to troubleshoot this error.

  • Verify the hostname is properly spelled. Typographical errors can strike at any time.
  • Verify that you can resolve the hostname on your client machine using the system 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 user@111.111.111.111 instead of ssh user@example.com.

The following tutorials are a good resource to begin working out DNS configuration errors:

Connection Timeout

A connection timeout indicates 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 user@111.111.111.111 may result in an error similar to:

Error output
ssh: connect to host 111.111.111.111 port 22: Connection timed out

In PuTTY, you might see an error dialogue with text similar to:

PuTTY error output
Network error: Connection timed out

Here are some steps you can take to troubleshoot this error.

  • Verify that the host IP address is correct for the Droplet.
  • Verify that your network supports connectivity over the SSH port being used. Some public networks may block port 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.
  • Verify the Droplet firewall rules. Check that they're not set to a default policy of DROP and the port is not added to allow connections.

Connection Refused

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 user@111.111.111.111 may result in an error similar to:

Error output
ssh: connect to host 111.111.111.111 port 22: Connection refused

In PuTTY, you might see an error dialogue with text similar to:

PuTTY error output
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 may want to check.

  • Verify that the host IP address is correct for the Droplet.
  • Verify that your network supports connectivity over the SSH port being used. Some public networks may block port 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.
  • Verify the Droplet firewall rules. Check that they're not set to a default policy of DROP and the port is not added to allow connections.
  • Verify that the service is currently running and bound to the expected port.

Solutions

Below are some troubleshooting methods and solutions to common SSH connectivity errors.

Checking Your Firewall

Some connectivity problems can be caused by firewall configurations. If your firewall is set up to block certain ports or services, it can prohibit you from connecting. You can learn about firewalls in this What is a Firewall and How Does It Work? tutorial.

For whichever firewall your system has, you'll need to familiarize yourself with how to modify its rules. Ubuntu servers usually run UFW; CentOS servers often use FirewallD. If you're not using either, it's like that you're using iptables. You'll 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 find out.

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:

Output
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:

Output
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.

Finally, users working with UFW should use ufw status to inspect their firewall:

  • ufw status

The output similarly shows the ports available:

Output
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.

Checking the SSH Service Status

If you can't SSH to your Droplet, you should check that the SSH service is running. How to do this depends on which operating system your Dropet is running. On older OS versions (like Ubuntu 14.04, CentOS 6, or Debian 8), this will use the service command. On more modern distributions using Systemd will use the systemctl command.

Verifying that the service is actually running can vary 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, while on more modern distributions using systemd, you will manage the service using the systemctl command.

Note: Red Hat-based distributions (e.g. CentOS and Fedora) call the service sshd while Debian and Ubuntu call it ssh.

For systems using the service command on Ubuntu 14.04, you can check the status of the SSH process with this command (run as root or with sudo):

  • service ssh status

If the process is running as expected, you'll see output like this that includes the PID (process ID):

Output (running)
ssh start/running, process 1262

If it isn't running, you'll see output indicating the process is stopped:

Output (not running)
ssh stop/waiting

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. Notice the Active line in particular.

Output (running)
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, you'll instead see Inactive on that line followed by recent journal entries for the service:

Output (not running)
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)

If the service is not running in either case, you can restart it using service ssh start or systemctl start sshd as appropriate.

Checking the SSH Service Port

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:

Output
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`.

Output
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.

Conclusion

If you need further help establishing a connection to your SSH service running on your Droplet, you can open a ticket with our Support Team. Make sure to include:

  • The username, host, and port you are using to connect
  • The authentication mechanism you expect to use
  • The full output of the errors linked to the stage of error, including verbose output of the SSH client
  • All of the information you've gathered from troubleshooting so far
  • Anything you were unclear about while referencing this article

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.

0 Comments

Creative Commons License