Re: ssh-vs-rsh benchmark result
Peter Cordes <peter@llama.nslug.ns.ca> 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. 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: