SSH clients and servers have debugging built in. When invoked with appropriate options, these programs emit messages about their progress and failures. You can use these messages to isolate problems.
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:otherfileSo 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_specIn 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 54321Then 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.
Q: | How do I install my public-key file on the remote host for the first time? |
A: | Connect by password authentication and use your terminal program’s copy and paste feature. [12.2.2.4] |
Q: | I put my SSH public-key file, mykey.pub, into my remote SSH directory, but public-key authentication doesn’t work. |
A: | The public key must be referenced in your remote authorization file. [12.2.2.4] |
Q: | Public-key authentication isn’t working. |
A: | Use ssh -v, and check your keys, files, and permissions. [12.2.2.4] |
Q: | Password authentication isn’t working. |
A: | Use ssh -v. There are a variety of possible causes. [12.2.2.2] |
Q: | Hostbased authentication isn’t working. |
A: | Use ssh -v. Check your four control files, hostnames, and setuid status of the SSH client program or ssh-signer2. [12.2.2.3] |
Q: | How do I authenticate without typing a password or passphrase? |
A: | ssh-agent, unencrypted keys, trusted-host authentication, or Kerberos. |
Q: | How do I secure FTP with port forwarding? |
A: | Forward a local port to port 21 on the FTP server for the control connection; the data connection is much harder. [12.2.5.6] Alternatively, use an SSH client with special support for FTP forwarding, such as Tectia. [9.2.11] Also consider using the SFTP protocol instead of FTP. |
Q: | X forwarding isn’t working. |
A: | Don’t set your remote |
Q: | Why don’t wildcards or shell variables work on the scp command line? |
A: | Your local shell expands them before scp runs. Escape the special characters. [12.2.5.4] |
Q: | A feature of ssh or scp isn’t working, but I’m sure I’m using it correctly. |
A: | Use ssh -v. Also, the system configuration may be overriding your settings. |