Stuart Barkley <stua...@4gh.net> writes: > - Kerberos with ssh works fine for interactive users, but doesn't seem > to translate well to a queuing environment. Or am I missing > something?
It's quite possible to use, but you do get a ticket expiry problem. > - Each user creates a password-less ssh private key, puts the public > key in the authorized_hosts file and has relatively unfettered ssh > access between nodes (nfs shared home directory helps a lot). This > seems to be the most common approach. Yes, this is common. And a really, really BAD IDEA. Do not do this. Bad, bad, BAD. > I consider it dangerous to encourage use of password-less ssh keys. Yes, very much so. And your users will discover that they can copy that passphrase-less private key to their personal workstation and get password-less access to the cluster. (Yes, they will.) And then the key will get stolen. (Yes, it will.) And then you get http://www.us-cert.gov/current/archive/2008/09/08/archive.html#ssh_key_based_attacks Of course, you can disallow ssh key authentication from external machines to mitigate the problem, but that's just a band-aid for a mis-engineered system. In case I didn't come across clearly, let me repeat that: DO NOT USE PASSPHRASE-LESS PRIVATE KEYS! (There are some exceptions, of course, like when you want to run things in batch from cron, and similar. But then you must, must, must use proper limitations for that key in authorized_keys.) > - 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). This is the way to go. All our systems are set up this way. Works just fine. You just need a mechanism for maintaining host keys and ssh_known_hosts. (And remember that this doesn't work for root - you need separately set up ~root/.shosts and ~root/.ssh/known_hosts if you want it.) Oh, and DO NOT USE PASSPHRASE-LESS PRIVATE KEYS! Do the Internet a service and scan your users' home directories for passphrase-less private ssh keys. This is as easy as running # grep -L ENCRYPTED /home/*/.ssh/id_?sa Delete all such keys that don't have a good reason for existence. (Yes, we do so on all our systems.) -- / Swedish National Infrastructure for Computing Leif Nixon - Security officer < National Supercomputer Centre \ Nordic Data Grid Facility _______________________________________________ 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
