Hacker News Reader

Comment by mrintegrity | Hacker News Reader

Why not store the public key in a users ldap profile, then when they login ssh can pull that with the AuthorizedKeyCommand option to sshd config. As it's in AD / ldap you can allow them to manage their own public keys via a simple portal. When a user quits or is fired, their account is disabled and this will stop the key from being used.

View on HN

The blast radius of storing ssh keys in LDAP is very big, if your LDAP is down you cannot ssh into your servers anymore.

To overcome this issue, you end up storing a set of public keys in the servers themselves, thereby going back to where you started.

A common way to implement this is through SSSD which can cache keys locally when the LDAP server is not responding.

https://access.redhat.com/documentation/en-us/red_hat_enterp...

You can have backdoor keys for the root account that you configure during provisioning. The use of these keys/account would trigger a security alert and only be for break glass scenarios. Other situations would use LDAP stored keys for authn/authz and LDAP stored sudo rules for additional authz.

If LDAP is down in an LDAP environment, you cannot authenticate anyway.

Our systems people get local accounts on machines for disasters like LDAP-down. Everyone else is LDAP-only, including ssh keys.

This is nowhere close to "where we started". Now we have a handful of privileged accounts and centralized auth management across thousands of other accounts.

Centralized logging and centralized auth are pretty much mandatory above some size. Without them, you literally do not know who is doing what.

A way to work around this is to normally work with short term certificate (24h) and allow your systems people to generate longer term certificates (one month) that are stored encrypted on their laptop or usb key.

That way you get both emergency access in case LDAP is broken, as well as a way to make sure old personal access gets revoked after one month.

Yep. I'm a big fan of Hashicorp Vault; that's the next step.

There are of course also DR considerations for that, as always, it is turtles all the way down.

Where I work if LDAP (AD) is down, the world stops. In 16 years AD "got stupid" once. So this is a good solution for us.

Well absolutely there has to be an alternative way in, be it serial console or a dedicated admin user who does not have keys in ldap. With sshd you would specify a local key instead of ldap for that specific user, for example

Yep, pretty neat solution.

This occasionally pops up at reddit and the "key in ldap" way feels surprisingly unknown/uncommon. Many use ansible.. but it requires guaranteed cleanup of revoked keys....

I’m using Ansible for this for my personal servers on a small scale, but revocation is pretty easy for me. I have all keys I want to distribute in my Playbook and I remove all authorized keys from the server and write only the ones in the playbook.

Well, the simple objection would be that the more remote network services you include in admin login management,the more likely you're going to have a problem when you least can afford it.

SSH configs in distros are moving towards not even doing rDNS lookups (which generally just delay logins for the timeout period when there's a problem).

That doesn't mean some hybrid solution doesn't have merit though.

If you go this route, why not go all the way and do Kerberos SSO so you don't need to fiddle with ssh keys at all.

That only works smoothly in a Windows environment. Sure you can do it from a Linux workstation too. But it's like a square peg in a round hole. Only on Windows Kerberos works so well it's natural to use it.

I have been using OpenSSH and OpenLDAP to do password authentication for decades and just recently discovered this as an option. It is pretty simple to setup. Basically just extend your ldap schema with the public key attribute and then tell openssh to use it.

I'm not sure I'd call AD or it's portal simple...

If we're talking about internal servers, isn't an existing ldap/AD infrastructure so uncommon? There would be almost no additional work to implement this(depending on the size..)

The discussed sining flow probably works better with cloud infrastructure. Afaik it's one of the ways hashicorps vault can be used for SSH.

I think that if you already have all users in a authz/authn system then anything will feel easy compared to the alternative, but I'd definitely not call them simple.

Reply on news.ycombinator.com