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 cluster acccess. > 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 > others). 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. _______________________________________________ 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