|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Best practices inquiry: tracking SSH host keys
--On Thursday, July 06, 2006 18:22:48 -0700 Jeremy Chadwick <[email protected]> wrote: Speaking purely from a system administration point of view, Kerberos is also a nightmare. Not only does the single-point-of-failure induce red flags in most SAs I know (myself included), If a deployed kerberos environment has a single point of failure then its been deployed poorly. Kerberos has replication mechanisms to provide redundancy. The only think you can't replicate in K5 is the actual master, meaning that if the master is down you can't change passwords, create users, etc. While thats a single point of failure its not typically a real-time critical one. but having to "kerberise" every authentication-oriented binary on the system that you have is also a total nightmare. As you pointed out, one trivial rebuttal to that is PAM, another is GSSAPI and SASL. Authentication oriented systems shouldn't be hard coding a single auth method these days, they should be using an abstraction layer GSSAPI or SASL. If they are then the GSSAPI Kerberos auth mechanisms should just work. GSSAPI/SASL enabled versions of many major applications are available (Thunderbird, Mail.app, openssh, putty, oracle calendar). (Sadly Microsoft applications are fairly lacking in this category, which is surprising considering that AD servers use Kerberos heavily under the hood.) Kerberos 4 is also completely incompatible with 5. Not true. With a correctly setup environment K5 tickets can be used to get K4 ticket automatically for those few legacy applications that require K4. But really there are very few K4 only applications left. Let's also not bring up the issue of globally-readable Kerberos tickets laying around /tmp on machines which use Kerberos, okay? ;-) Again, thats an indicator of a poorly setup system. Ticket files should be readable only by the user. If they're readable by anyone else except root something isn't setup right. And on OS'es that support it the tickets are often stored in a more protected location. i.e. on OSX the tickets are stored in a memory-based credential cache. The bottom line is that SSH is "easier", so more people will use it. That may not be the best attitude, I'll admit, but that's reality. I think the bottom line for the original poster was that ssh was the only secure mechanism support by the devices he was using. For network switches this is common. I think the only answer there is to either make gathering the ssh key from the device part of your build/deployment process, or design your network in a way that reduces the opportunity for man-in-the-middle ssh key exchange attacks and pray. -David
|