Re: ssh-vs-rsh benchmark result
Peter Cordes <peter@llama.nslug.ns.ca> writes:
<snip!, lots of very good points deleted>
> Also, nobody has pointed out some of the things you can do with ssh that
> you can't do with rsh. With ssh, you can create a keypair, and put the
> public key in the authorized_keys file on any host you want to be able to
> log in to using the private key. The cool part is that you can limit that
> key to running only a certain command. The advantage is that you can
> automate tasks that need root on remote machines without allowing
> passwordless root shell logins in general. Read more in
> sshd(8): AUTHORIZED_KEYS FILE FORMAT.
Note that the ssh keypair != a certificate. In particular, ssh
keypairs are not revocable. If a key is compromised, the only way to
repair the damage is to locate and remove every copy of the pubkey.
For this reason some sites configure ssh to reject keypair
authentication from outside machines.
Also, in some situations keypairs actually lower security. Eg, on
``control networks'' that are internal to a cluster, where more than
one sysadmin needs to do rootly things, it's arguably a little safer
to use rsh .hosts type authentication. Using keypairs means either
sharing the private key password with every sysad, or using no
password. In either case you'll run into the non revocable problem
when a sysadmin leaves. [Or you could do passwd auth, but I'm
guessing most sysadmins don't want to type the password 1/node for
something like a 128 node cluster. :-) ]
Obviously, the above are both extreme examples. In general ssh is
muchmuch more secure than rsh. If you're a small operation with a
couple of sysadmins, everything Peter mentions about ssh is correct.
--
/* Dale Southard Jr. dsouth@llnl.gov 925-422-1463, fax 422-9429 */
/* Computer Scientist, Accelerated Strategic Computing Initiative */
/* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */
/* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
Reply to: