4 ms·
Who would use this and why would they use it? On all the servers I have access to, I manage one key, my own key. Why would I need a "SSH Access and Key Manageme
by hagbarddenstore 10y ago
Who would use this and why would they use it? On all the servers I have access to, I manage one key, my own key. Why would I need a "SSH Access and Key Management" system for a single key?
- lox 10y agoImagine a team of 20 developers sharing cloud infrastructure. Key additions and revocations ends up being time consuming.
- jamescun 10y agoGenerally this should be managed by configuration management (Chef, Puppet et al), which makes key additions and revocations trivial. Additionally OpenSSH supports CA signing of public keys with user metadata, which I've found to pair nicely with LDAP.
- amalag 10y agoCan you elaborate on the CA signing with OpenSSH? You have a CA verify keys with metadata and then use LDAP to verify that metadata? It sounds very interesting.
- Karunamon 10y agoYeah... coming at this from the standpoint of a heavily invested Saltstack user, I really don't see the reason for this to exist. It removes all the other cool things SSH does besides just giving you a shell, with a much, much worse user experience.
- teacup50 10y agoOpenSSH now also supports external authorized_key handling via AuthorizedKeysCommand, and thus simple integration with LDAP: https://github.com/AndriiGrytsenko/openssh-ldap-publickey https://github.com/AndriiGrytsenko/openssh-ldap-publickey
- vidarh 10y agoOpenssh supports certificates and signing of keys, with expiry. Couple that with LDAP for account management, and you shouldn't need to manually add keys to any servers.
- Karunamon 10y agoLDAP management on non-Windows systems is like stepping back 30 years.. last I checked, there wasn't even a supported UI for directory operations (typing DN's by hand is for the birds!) Windows AD in all its subtle brokenness is a great deal easier to use.
- jms18 10y agoCould you expand on this? > LDAP management on non-Windows systems is like stepping back 30 years. How so? And managing which components -- the directory server or the clients? > there wasn't even a supported UI for directory operations What directory operations? add/mod/del? There are quite a few packages that handle that. Or are you talking about operations on the server side? > typing DN's by hand is for the birds! I concur. Though, it's pretty rare to type in a DN anywhere. I can't think of many places where a simple RDN or search filter on a unique value (uid, mail, etc.) doesn't suffice.
- Karunamon 10y agoBoth. Again, I may be coming from a standpoint of ignorance here, but setting up a Linux client requires manual mucking about with PAM and its associated config files, with different steps required for every major distro. Same with the server side - there's no good equivalent to the Windows' "Active Directory Users & Computers". Plenty of good command line tools, but I don't think those are that useful when reasoning about a "tree" structure used in LDAP.
- teacup50 10y agoWe got hosed by PADL and rfc2307/rfc2307bis. In short: We never standardized a viable schema that covered the majority of real-world enterprise use-cases. Active Directory did. We got stuck with the broken rfc2307 (essentially NIS-in-LDAP), and the slightly better but abandoned rfc2307bis. Without a standardized schema, every management tool out there had to either expose LDAP directly, or provide a limited subset of operations supportable across random schema. We could solve this issue with a new RFC defining a modern standard server schema, including things like sshPublicKey, but I don't know if there's any UNIX/Linux vendor still alive that would invest in doing so.
- deleted 10y ago[deleted]