Chapter 12. Troubleshooting and FAQ
SSH1, SSH2, and OpenSSH are complex products. When a problem occurs, your plan of action should be, in order:
Contents:Debug Messages: Your First Line of Defense
Problems and Solutions
Other SSH Resources
12.1. Debug Messages: Your First Line of DefenseSSH1/SSH2 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.
12.1.1. Client DebuggingMost clients print debug messages when invoked with the -v (verbose mode) option: [Section 7.4.15, "Logging and Debugging"]
So many problems can be identified in verbose mode. This should be your first instinct whenever you encounter a problem.$ ssh -v server.example.com $ scp -v myfile server.example.com:otherfile
TIP: Please take a deep breath and repeat after us: "ssh -v is my friend..." "ssh -v is my friend..." "ssh -v is my friend..."
12.1.2. Server DebuggingThe SSH1, SSH2, and OpenSSH servers also print debug messages when asked:
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). SSH2 has a more complicated system for debugging: numeric debugging levels, specified with the -d option, where a higher number means more information. [Section 5.8.2, "Logging and SSH2"] 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:# SSH1, OpenSSH $ sshd -d # SSH2 only $ sshd2 -v
Use the -p option in the client when testing this debugging instance of the server:$ sshd1 -d -p 54321
This way, you don't interrupt or affect another sshd in use.$ ssh -p 54321 localhost
Copyright © 2002 O'Reilly & Associates. All rights reserved.