I've never done multiple domains on a kerberos system, but it should not be
terribly difficult as long as the users are comfortable using the kerberos
tools. You just can't use to as part of the automated login process. There
is nothing stopping you after you login to add more credentials manually
though using the command line.
2) If someone has my password and ssh key, doesn't kerberos not do anything to protect at that point? That's why we're thinking hardware key, but some of our admins are very opposed to it.
Yes. Your screwed. But if you think about it the only way that happens normally is if the attacker has violated your user's desktop, right? So your going to be screwed pretty much no matter what. If the machine your coming in on is rooted then your f-ed pretty much no matter what.
The weakest link is always going to be the user's password. You can make the system and the desktop as secure as possible, but the number one security problem nowadays stem generally from users.
If your worried about weak passwords then use PAM in combination with a one-time pad/password. The pad can be generated by hardware, which is probably the thing your looking at, or manually entered in combination with a java applet on a phone or key dongle or something like that. That way you get your 2-factor authentication.. the password generated by the user and the password generated by one-time-pad-thingy. There are a few projects like that.
But that is a pretty easy way to piss off your end users. Being fairly nazi about password policies, implementing kerberos, and disabling shared key support is probably the best/safest bet for a organization. There is not really much you can do to get around this human-based weakest link.
For a small number of machines and if you got a small group (say 3-4, probably less then 10) then ssh keys make sense.
Also there are other things you can do. For example on my machines for a while I stored a 'key' on a USB drive and used that. There are PAM modules that will look for that key and allow me to log in or not in addition to me having the correct password, but that requires physical access to the machine, so it is very hateful.
If anything other then keys are just unacceptable then there are third party patches to that will actually add PKI support to OpenSSH, but there is good reasons why the OpenBSD folks are refusing to accept them into the normal OpenSSH source code distribution. I'd probably take some time to understand those reasons before deploying a PKI OpenSSH solution.
All of this is just my opinion, of course. And only really is relevant in the broad sense, even if I am not wrong. Don't take it as gospel no matter what you do!! Each Org is different with different requirements and different needs!
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds