3 ms·
The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an
by csirac2 12y ago
The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?
- devonkim 12y agoI'm not quite sure what you mean with this concern but Kerberos is really flexible and a Kerberos realm could act a lot more like roles than by domains (which is the typical correlation). Most enterprise networks I've worked with are extremely fragmented from decades of competing business units rolling their own thing and so the default in most enterprise networks is already quite restricted in many respects, and that is ironically a bit of a help for security by reducing the impact crater of an intrusion. Also, we have plenty of different accounts used by one physical user all the time, so nothing keeps administrators from requiring different accounts for different roles on top of realms. I don't necessarily mean that you need to create user1.support and user1.dev in the same domain but Kerberos solves a lot of problems that ssh alone just doesn't answer, which is a big reason why I reach for that after I have an ok ssh setup. Nothing says you can't put resources in multiple Kerberos realms either. Then you can establish a digraph of trust chains across Kerberos realms to transfer tickets across realms based upon some business rules. There's many reasons that Active Directory (LDAP + Kerberos + some magical bits of quirks and features) is the gold standard for large corporations and the reason is not "nobody got fired for buying Microsoft."