> > 2) Configure the ssh client so that it can login to their account on the
> > server machine without requiring an interactive login (I've never done that
> > for ssh, so I can't tell you how to do it.

> ...and the ``obvious things'' don't seem to work.  (From the
> documentation, and examination of the (as-installed) configuration files,
> I _should_ be able to just use {r,s}hosts{.equiv,} and it should ``just
> work''.  Even if I use an account with the same name as with the remote
> system, this doesn't seem to work.

They should have a frickin' HOWTO section in the ssh man page on this,
because I can't see how anyone using ssh regularly wouldn't need to do it.

Have each user run ``ssh-keygen'' on their own machine. Hopefully these are
secure enough machines already; just hit return for the 'passphrase' and it
won't bother you with Yet Another Password Prompt whenever you use it. Then
have the users look in ~/.ssh/identity.pub -- this should be a one line (but
a _long_ line) file.

Create accounts for each user on the server machine. Have them login and get
the identity.pub file onto their server account somehow. Then:

	mkdir .ssh
	chmod 755 .ssh
	mv identity.pub .ssh/authorized_keys
	# must restrict access to authorized_keys, or sshd ignores the file!
	chmod 600 .ssh/authorized_keys

The last step is to test it. I usually use ``ssh server uname -a'' to do this.
Note that you may get a ``host not found in the list of known hosts'' prompt
once with each client/server combination. I always do this 'hello world' check
after setup now, because if I forget then the prompt will hang my scripts (and
I expect that it would cause trouble for CVS, too).

After this, you can expect things like ``scp file server:file'' to work, and
you can safely use ssh in place of rsh. Some other notes:

    1. rsh does not return remote exit codes, but ssh does. This may be good
	or bad (or indifferent) depending on your application.
    2. At least 1.2.25 is known to have a problem when stdout is redirected
	on the client; when the remote program exits, the ssh server process
	shuts everything down immediately and doesn't ensure that all of stdout
	is forwarded through. This can lead to random episodes of mysteriously
	truncated output files. A PR with fix has been filed, so a new enough
	ssh package may already have it fixed.

Todd Whitesel
toddpw @ best.com