Most clients print debug messages when invoked with the -v (verbose mode) option: [7.4.17]

    $ ssh -v server.example.com
    $ scp -v myfile server.example.com:otherfile

So many problems can be identified in verbose mode. This should be your first instinct whenever you encounter a problem.

The OpenSSH and Tectia servers also print debug messages when asked: [5.9]

    # OpenSSH
    $ sshd -d -e

    # Tectia
    $ sshd -v
    $ sshd -d debug_spec

In either case, the server enters a special debugging mode. It accepts a single connection, operates normally until the connection terminates, and then exits. It doesn’t go into the background or create a child process to handle the connection, and it prints information on its progress to the screen (that is, to the standard error stream).

Tectia has a more complicated system for debugging: numeric debugging levels, specified with the -d option, where a higher number means more information. [5.9] In fact, -v for verbose mode is actually just a shorthand for -d2. At higher debug levels, the output is so huge that only SSH developers will likely find it of use in tracking down obscure problems. But you may need to crank up the level beyond 2 to see the information you need. For example, to have it report which algorithms are negotiated for a connection, use -d3. If you get the error message “TCP/IP Failure,” turning up to -d5 shows the more specific OS-level error message returned from the connection attempt.

When debugging a server, remember to avoid port conflicts with any other running SSH server. Either terminate the other server, or use an alternative port number for debugging via the Port keyword or -p option. For example, using OpenSSH syntax, run the server:

    # OpenSSH
    $ sshd -d -e -p 54321

Then use the -p option in the client when testing this debugging instance of the server:

    $ ssh -p 54321 localhost

This way, you don’t interrupt or affect another sshd in use.