Introduction to Verbose Mode

Now that we've covered the generalities of command-line options and configuration files, we're about to launch into an extended discussion of configuration. Before we begin, let's practice some defense. As you try these options, occasionally you might see behavior that's not what you expected. Whenever this occurs, your first instinct should be: turn on verbose mode with the -v command-line option to track down the problem:

    $ ssh -v server.example.com

In verbose mode, the client prints messages as it proceeds, providing clues to the problem. New SSH users (and quite a few experienced ones) frequently forget or neglect to use verbose mode when problems arise. Don't hesitate! Many questions we've seen in the Usenet SSH newsgroup, comp.security.ssh [12.3], could have been answered immediately by running ssh -v and examining the output.

Suppose you just installed your public key on server.example.com and are trying to authenticate with it. Strangely, you are prompted for your login password instead of your public-key passphrase:

    $ ssh server.example.com
    barrett@server.example.com's password:

Don't just sit there scratching your head in wonder. Let verbose mode come to the rescue:

    $ ssh -v server.example.com
    OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug1: Connecting to server.example.com [192.168.0.10] port 22.
    debug1: Connection established.
    debug1:  Remote: Bad file modes for /users/barrett/.ssh         Uh oh!
    debug1: Server refused our key.
    debug1: Doing password authentication.
    barrett@server.example.com's password:

These messages (which are abbreviated for this example) confirm that the SSH connection is succeeding, but public-key authentication is failing. The reason is "bad file modes": the remote SSH directory, /home/barrett/.ssh, has incorrect permissions. A quick trip to the server and a well-placed chmod command later, the problem is solved:

    # On the server
    $ chmod 700 ~/.ssh

Repeating the -v option causes OpenSSH clients to produce even more detailed information:

    # OpenSSH
    $ ssh -v -v -v server.example.com

whereas for Tectia, use its -d option, as we saw in detail for sshd: [5.9]

    # Tectia
    $ ssh -d3 server.example.com

And of course, verbose mode also works for scp :

    $ scp -v myfile server.example.com:
    Executing: program /usr/bin/ssh host server.example.com, user (unspecified), command 
scp -v -t .
    OpenSSH_3.9p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7e 24 Oct 2004
    ...

except that Tectia's scp uses -D instead of -d:^[106]

    # Tectia
    $ scp -D3 myfile server.example.com:

scp also supports the -q option for no output at all:

    # Tectia
    $ scp -q myfile server.example.com: Be completely quiet

Verbose mode is your friend. Use it liberally. Now we're ready to learn those dozens of options.

---

^[106] Tectia's -v option is equivalent to -D2, and can also be written as --verbose.