4 ms·

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

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.

SahAssar 6y ago
I'm not sure I'd call AD or it's portal simple...
- marvion 6y ago
  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.
  - SahAssar 6y ago
    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.
marvion 6y ago
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....
- ViViDboarder 6y ago
  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.
quicksilver03 6y ago
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.
- ctrlc-root 6y ago
  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_enterprise_linux/6/html/deployment_guide/openssh-sssd https://access.redhat.com/documentation/en-us/red_hat_enterp...
- CameronNemo 6y ago
  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.
- _jal 6y ago
  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.
  - antoinealb 6y ago
    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.
kbenson 6y ago
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.
linuxdaemon 6y ago
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.
zokier 6y ago
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.
- GekkePrutser 6y ago
  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.

SahAssar 6y ago

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

marvion 6y ago
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.
- SahAssar 6y ago
  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.

marvion 6y ago

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....

ViViDboarder 6y ago
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.

quicksilver03 6y ago

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.

ctrlc-root 6y ago
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_enterprise_linux/6/html/deployment_guide/openssh-sssd https://access.redhat.com/documentation/en-us/red_hat_enterp...
CameronNemo 6y ago
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.
_jal 6y ago
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.
- antoinealb 6y ago
  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.

kbenson 6y ago

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.

linuxdaemon 6y ago

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.

zokier 6y ago

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.

GekkePrutser 6y ago
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.