Peter Cordes <[EMAIL PROTECTED]> writes: > On Thu, Aug 29, 2002 at 09:41:10AM -0700, Dale Southard wrote: > > 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. > > You can have more than one public key in an authorized_keys file, so each > sysadmin can have their own private key. You just have to remove it from > all the authorized_keys files when they leave. That should be as simple as > grep -v key .ssh/authorized_keys > .ssh/new_ak > mv -f .ssh/new_ak .ssh/authorized_keys > (which you can run on all your machines with a for loop using ssh or rsh :)
Which doesn't actually revoke the key, it just removes it from the list of keys ssh accepts. This is no different than changing the list of users in .rhosts or .shosts -- security will depend on maintenance of a file (.ssh/authorized_keys) in the root account of all cluster nodes. If one tosses out keypairs and just uses the cluster hostnames in root's .rhosts or .shosts, removing an admins' permission to su/sudo/super to root is adequate without further file tweaking. On small clusters with few admins, keypairs are probably preferred. On large clusters with large admin teams, things may be different. -- /* 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 */
