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...)
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
