Peter Cordes <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] 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 */
