[Beowulf] Intra-cluster security
bill at cse.ucdavis.edu
Sun Sep 13 11:34:13 PDT 2009
Stuart Barkley wrote:
> - Each user
Very dangerous way to say it. Ideally you do everything possible to
minimize the work of the user, that way they can't get it wrong.
> creates a password-less ssh private key, puts the public
I'm a fan of password-less private keys. Before the screaming begins, let me
explain the wrong way to do it. Rocks creates a password-less key for each
user, plops it in ~/.ssh. Unfortunately they seem very resistant to
suggestions on fixing this. The main problem is that if someone leaves
themselves logged in someone could slurp the private key and have access
forever, even if the user tries to be security conscious and uses a large
passphrase that they keep secure.
You could however point the compute nodes to a different keystore which the
head node does not look at. That way even if stolen it doesn't get you
> key in the authorized_hosts file and has relatively unfettered ssh
> access between nodes (nfs shared home directory helps a lot). This
I don't recommend allowing users to populate .ssh, instead I suggest managing
it yourself (the admin). Users tend to only add keys when they upgrade a
laptop, buy a new one, lose a laptop, get compromised, etc. So there could be
keys that end up lost, shared, or compromised. By forcing users to have one
you reduce your exposure. Last thing you want to hear is oh, that's access is
not from my current key...
> seems to be the most common approach. It is end-user setup/training
> intensive (I suppose it could be automated/audited). I consider it
> dangerous to encourage use of password-less ssh keys.
An alternative is to use host-based ssh auth for access inside the cluster,
this depends on either more labor intensive management of keys, or automating
the install/reinstall node process.
> - It looks like I can configure the cluster systems to handle local
> ssh transparently. This would involve setting setuid/setgid on ssh,
> building cluster wide authorized_keys files and other things. I
> haven't studied this closely but there are a few references available
> (http://www.snailbook.com/faq/trusted-host-howto.auto.html among
Looks pretty straight forward to me.
> I favor this last solution as being the most user transparent. I find
> is surprising that none of the cluster distributions seem to use this
> method. I would like some feedback as to how well this works in
> practice and whether there are any obvious or non-obvious gotchas
> people might have already encountered.
Works for us, I share your surprise that it's not more popular.
More information about the Beowulf