SSH on Mac OS X for Worry-Free Wireless
Subject:   corrections, clarifications, comments
Date:   2001-11-26 20:06:16
From:   res

I'd like to make a few corrections, clarifications, and further comments
regarding this article, which may be of help to your readers.

rob@entropy$ ssh-keygen -d
* The -d option specifies DSA keys (instead of RSA keys).

The version of OpenSSH which comes with Mac OS X is 2.3.0, and it does use
the ssh-keygen -d command to generate a DSA key. It's useful to
note, however, that later versions of OpenSSH (3.0.1 is the current
release) use different switches; the equivalent would be ssh-keygen -t

The ssh v2 protocol uses DSA keys, and is widely regarded as more secure
than v1.

In fact, the SSH-2 protocol defines the use of either RSA or DSA keys, and
can accomodate any public-key authentication method.

The procedure described here makes a few unstated assumptions:

  • That the SSH server supports protocol 2. It may not, in which
    case the public-key authentication will not work, since DSA keys may only
    be used with protocol 2.

  • That the SSH server is in fact also OpenSSH. The details of
    how to authorize a key for login are not part of the SSH protocol, and
    vary from one implementation to another. Placing the public key in
    ~/.ssh/authorized_keys2 on the server will not work if the server
    is the software, for example.

  • That the server supports only protocol 2. The OpenSSH
    2.3 client prefers protocol 1 if available (this default was changed in
    OpenSSH 2.9). Thus, if you follow these directions and connect to a
    server which supports both protocol versions, the client will select
    protocol 1 and fail public-key authentication, even though it could have
    succeeded by using protocol 2. You can force the use of protocol 2 with
    the -2 switch to ssh.

After entering the command, hit enter three times (to take the default
filename, and to enter no passphrase.)
It should log you in without a password.

This describes the use of an unencrypted private key file. While there
can be situations in which this is acceptable, I don't think it's a good
idea to recommend this without further comment -- it is not the normal way
of using SSH, and it is a security risk. With this setup, anyone who can
read the private key file has immediate access to all remote accounts
accessible with that key. If someone breaks security on this machine, the
attacker has immediate transitive access to all these remote accounts with
no further effort. It is equivalent to putting your account password in a
file in your home directory named PASSWORD.PLEASE-STEAL-ME. If
your home directory is shared via unsecured NFS (as most NFS installations
are), your key can be read off the network by a passive snooper.

For interactive use, a better way to achieve automatic public-key
authentication, is to use ssh-agent. Now, the purpose of the
procedure described here is to set up SSH for use in a non-interactive
batch ("cron") job, which requires unattended authentication. A plaintext
key is one way of achieving this, but there are others, and it has risks
which should be carefully understood before doing it. At the very least,
this key should not be the user's default key for SSH authentication (as
is done here), and one must carefully limit what the key can do using the
command option in the authorized_keys file on the

| Richard Silverman | co-author: SSH, The Secure Shell (The Definitive Guide) |
| | O'Reilly, 2001 -- |