This article addresses the initial phase of connecting an SSH client to an SSH server, focusing on troubleshooting common network connectivity issues that may arise. It provides insights into identifying these issues, offers solutions for resolution, and recommends additional resources to prevent similar occurrences in the future.
Errors
Hostname Resolution: The majority of resolution errors stem from an inability to map the SSH host reference to a network address. Although this issue is typically DNS-related, the underlying cause may not always be directly related to DNS.
In an OpenSSH client, executing a command such as "ssh [email protected]" might yield an error similar to this:
| ssh: Could not resolve hostname ample.com: Name or service not known |
In PuTTY, an error window may display text resembling this:
| Unable to open connection to ample.com Host does not exist |
Below are troubleshooting steps you can follow to address this error: Check the hostname for correct spelling, as typographical errors can occur unexpectedly.
Confirm that you can resolve the hostname on your client machine using the system ping command. Additionally, utilize third-party sites like WhatsMyDns.net to verify beyond your own DNS caching and confirm the results.
If encountering DNS resolution problems at any stage, consider utilizing the cloud VM IP address as a temporary solution, demonstrated by
| ssh [email protected] instead of ssh [email protected]. |
Connection Timeout: A connection timeout occurs when the client tries to establish a network socket to the SSH server, but the server fails to respond within the specified timeout period.
In an OpenSSH client, executing a command such as "ssh [email protected]" might result in an error similar to this:
| ssh: connect to host 202.0.114.0 port 22: Connection timed out |
Below are steps you can follow to troubleshoot this error.
- Ensure that the instance host IP address is accurate.
- Confirm if your network allows connectivity over the SSH port being utilized. Public networks might block port 22 or customized SSH ports. You can verify this by testing other hosts using the same port with a known working SSH server, which can help determine if the problem isn't unique to your cloud VM.
- Check the firewall rules to ensure they don't have a default policy blocking cloud VMs, and verify that the port is not restricted to allow connections.
Connection Refused: A "connection refused" error differs subtly from a timeout. In this case, the request is directed to the SSH host, but the host does not successfully accept the request.
In an OpenSSH client, executing a command such as "ssh [email protected]" may yield an error similar to this:
| ssh: connect to host 202.0.114.0 port 22: Connection refused |
In PuTTY, an error window may display text resembling the following:
| Network error: Connection refused |
In this scenario, you might encounter the same underlying problem as with connection timeout errors. However, there are additional checks you can perform:
- Ensure the correctness of the instances IP address.
- Confirm if your network allows SSH port connectivity. Certain public networks might block port 22 or customized SSH ports. You can verify this by testing other hosts using the same port with a known functioning SSH server, aiding in identifying if the issue pertains specifically to your cloud VM.
- Check the cloud VM’s firewall rules to ensure they don't employ a default policy blocking cloud VMs and that the port is not restricted to allow connections.
Verify that the service is operational and bound to the intended port.
Solutions
Checking Your Firewall: Firewall configurations can contribute to connectivity issues. If your firewall is configured to block specific ports or services, it may impede your ability to connect.
When adding a firewall rule allowing your local machine's IP address to connect, ensure that your ISP-assigned IP address hasn't changed. If it has, you'll need to update the firewall rule to accommodate the new IP address or address range.The method for checking firewall rules varies depending on the firewall used by your VM instances. Ubuntu servers typically utilize UFW, while CentOS servers often employ FirewallD. If neither is in use, it's likely that iptables is being used.
Familiarize yourself with modifying rules for the firewall your system utilizes. Additionally, determine the port your SSH service is assigned. While the default port is 22, you can verify this in the "Checking the SSH Service Port" section below.
Iptables
For Linux systems not utilizing UFW or FirewallD, use the iptables command with sudo or as the root user to list your firewall rules.
| iptables -nL |
The following output suggests that there are no rules obstructing 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 observe rules, verify that the INPUT chain permits the port your SSH service operates on, typically 22 by default.
UFW
Users utilizing UFW should employ "ufw status" to examine their firewall settings.
| ufw status |
The output also displays the available ports.
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) |
Ensure that your SSH port is included in the list.
FirewalID
For FirewallD users, utilize the "firewall-cmd" command to list the services.
| firewall-cmd --list-services |
The output should display the list of services, including SSH (default port 22), indicating that the firewall supports SSH traffic.
| dhcpv6-client http ssh |
If you're using a custom port for SSH, you can verify it with the --list-ports option. Even if you've created a custom service definition, SSH should still be visible with --list-services.
Checking the SSH Service Status
To ensure SSH connectivity to your Cloud VM, verify that the SSH service is operational. The method for confirming the service's status varies depending on the system.
For older OS versions (Ubuntu 14 and below, CentOS 6, Debian 6), utilize the service command supported by Upstart. On more modern distributions with systemd, use the systemctl command. Red Hat-based distributions (e.g., CentOS and Fedora) refer to the service as sshd, while Debian and Ubuntu refer to it as ssh.
Using systemctl
Likewise, for servers employing systemd (such as CentOS 7), employ the systemctl command to verify the status:
| systemctl status sshd |
A running service displays output similar to this, with "active (running)" indicated 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 will show "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 scenario, restart it using systemctl start sshd.
Checking the SSH Service Port
There are two primary methods to determine the port on which the SSH service is operating. One involves inspecting the SSH configuration file, while the other entails examining the running process.
For most systems, the SSH configuration file is located at /etc/ssh/sshd_config. The default port is 22, but any configuration line in this file specifying a Port directive with a numerical value can override it.
You can search for lines like this using grep:
| grep Port /etc/ssh/sshd_config |
You will observe output similar to this, indicating the port number:
| Port 22 |
If you are certain that the service is operational, you can verify that it is running on the anticipated port using "ss" (executed with sudo or as the root user). Although "netstat -plnt" provides similar output, "ss" is the preferred command for querying socket information from the kernel.
| ss -plnt |
The desired output should indicate the program name listening on the configured port. For instance, this output indicates that the SSH service is listening on all interfaces, denoted by "*", 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" signify all interfaces on the Cloud VM instance. The presence of "127.0.0.1" indicates that the service is not publicly accessible. To default to all interfaces, the relevant sshd_config directive, ListenAddress, should be commented out. Alternatively, it can be set to the public IP address of the Cloud VM instance.
For additional assistance, please consider opening a support ticket. Ensure to include the following details:
The username, host, and port you are attempting to connect to.
The expected authentication mechanism.
The complete error output associated with each stage of the error, including verbose output from the SSH client.
Providing all the diagnostic information mentioned above and specifying where you encounter the issue during the connection attempt can help us quickly understand your needs regarding the issue.
