Debugging SSH connections

SSH is a very useful tool for accessing a remote system using a console (terminal).  There are also very many options and sometimes debugging a problematic SSH connection over can be challenging. 

First, click on this link to find all articles which mention ssh in our Knowledge Base.

Here's a list of things we'll probably want to know when you hyave trouble using SSH with

This info lets us look up a specific connection attempt:

  • Your account user name
  • Device name
  • Time of connection
  • connection details (e.g., port 34016)

This info may show you some useful error message:

  • ssh -v username@url -p port (use the -v option on the SSH command line)

This info will help us understand what type of system connectd is installed on and what programs (TCP listeners)  are detected:

  • uname -a - (what type of device/OS is this)
  • sudo netstat -lpn | grep tcp - (show active TCP listeners)

This info is general background around the ssh client and server

  • Information of initiator (OS, SSH client software)
  • Information of target (OS, SSH server software/version)

Running these commands on the target tells us about the connectd installation:

  • sudo connectd -n - (run a network test on the device)
  • ls -lR /etc/connectd/ - (show all installed provisioning files to understand whether interactive and/or auto/bulk registration has been used)
  • cat /etc/connectd/services/Connectdssh22.conf - (show ssh 22 configuration in provisioning file. only works when interactive installer was used. Other provisioning files may need to be looked at if 22 was not the port used, or if registration was bulk/auto)
  • ps ax |grep connectd |grep -v grep - (which connectd daemons are running)

Other tests to run on the target:

  • ssh -v username@localhost (see if SSH server accepts a connection from localhost - required to use connectd, but this test can be run without connectd)

Other information:

  • Behavior details of issue
  • Whether this issue happens all the time or intermittently

What to try if all else fails:

  • Contact  We may ask you to try one of the following:
  • Try rebooting the router.
  • Review syslog data on target device (e.g. Raspberry Pi: /var/log/messages, Ubuntu: /var/log/syslog)
  • Collect packet trace data (initiator side, target side) if possible.
Was this article helpful?
0 out of 0 found this helpful