[Beowulf] problem of mpich-1.2.7p1

[Mark Hahn]

>> but if you do want passwordless ssh, IMO the only sane solution is to
>> configure hostbased trust.  having an unencrypted private key in your
>> home directory is hideous (moral equivalent of putting your password
>> in a file, in the clear...)
>
> Completely agree that host-based passwordless SSH is the best approach,
> especially when jobs are submitted via a resource manager..
>
> Also agree that an empty passphrase is a particularly bad approach.
>
> But, when done via ssh-agent, I don't see partiularly onerous security issues
> for a usage where you're manually launching jobs from an interactive session
> unless you have no faith in the system's integrity at all...

absolutely.  I spoke sloppily - I use agent-based PK logins myself,
and only wanted to badmouth password and unencrypted PK logins.
I think it's really important even for end-users to understand 
the basics of ssh:
 	- first stage is mutual authentication of _machines_.  this is
 	what all that "hostkey of xxx has changed; maybe a hack!".
 	once this is done, hosts have an encrypted channel between
 	authentic hosts.
 	- second stage is user PK authentication: the client is challenged to
 	prove knowlege of the private key, which can happen by an
 	un-encrypted private key in ~/.ssh, or by prompting the user for the
 	passphrase to an encrypted privkey, or by interacting with ssh-agent.
 	- finally, as a last resort, username/password can be used -
 	basically the worst case security-wise: maximal exposure to
 	clocal keyboard logging and remote daemon compromise.

A QUESTION: how many clusters used/managed by people on this list
mandate the use of PK login (ie, rule out passwords)?  I know some do,
but we haven't, figuring there would be an outcry (not to mention making
our systems harder to use for the technically weaker users.)

we've thought of providing users with a customized package of windows
ssh client with a unique encrypted PK preinstalled.  might work...

if you think of threat models, it's interesting to note that if an sshable
account is attacked through windows-based clients, keylogging is probably
the more likley issue.  if compromise is of clients on a *nix system,
I'm guessing the main risk is unencrypted PKs in /home/*/.ssh.  server-side
compromise seems to usually be of the daemon, which simply logs
password-based logins (not outgoing connections in the versions I've seen,
and no compromise of ssh-agent to collect passphrase+key combos...)