Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by snuxoll on Sunday March 18, 2018 @07:42PM
(#16615207)
FreeIPA - I wish more people knew about this. You can tie a public SSH key to a user (users can also self-register them) and it is automatically recognized on all hosts joined to the IPA domain, if you want to limit who has access to what the integrated RBAC facilities are there to handle that as well.
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by chrisweekly on Sunday March 18, 2018 @08:21PM
(#16615335)
Cool! Thanks for the tip! :)
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by manigandham on Sunday March 18, 2018 @08:25PM
(#16615348)
Have you looked at ScaleFT? https://www.scaleft.com
They apply BeyondCorp style management for both server and web access.
There is also Teleport by Gravitational: https://gravitational.com/teleport/
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by mjlee on Sunday March 18, 2018 @06:31PM
(#16614863)
I love vault's functionality around this:
https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert...
Along with something like Packer to bake the cert right into the image.
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by aren on Monday March 19, 2018 @12:31AM
(#16616202)
We (Foxpass, https://www.foxpass.com/) are a YCS15 company offering a SaaS (or on-prem) service to handle SSH key management & rotation, plus user and group management.
With our API, some customers are creating dynamic access rules (for example, an on-caller might have 'sudo' during their on-call week, but not at other times).
Like a hosted FreeIPA, but more powerful.
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by sz4kerto on Sunday March 18, 2018 @07:17PM
(#16615086)
If you're managing large amount of servers and don't want to update configs on the servers themselves then use e.g. OpenLDAP.
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by tr0ut on Sunday March 18, 2018 @07:38PM
(#16615185)
There is a security issue with using AD/OpenLDAP. That being passwords. An example is you can debug/trace the SSH process and see(log) passwords in clear text.
Now of course this is both a trust and a escalated privilege issue. But a lot harder(impossible) with keys.
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by vertex-four on Monday March 19, 2018 @06:07AM
(#16617257)
There's various methods to put SSH keys in LDAP. LDAP is an extensible database, so you can add a schema to attach SSH keys to a user (various schemas exist) - and the AuthorizedKeysCommand in your sshd_config can be hooked up to any program which can retrieve keys for a given user from anywhere (again, various programs exist).
As an example already put together: https://github.com/jirutka/ssh-ldap-pubkey
Re:Show HN: SSH Permit A38 – Central Managment and Deploymen...
by subway on Sunday March 18, 2018 @10:45PM
(#16615907)
If you're using straight passwords, sure, an ssh key (ideally in a directory) is going to beat a password-only login, but that ssh key is still subject to credential theft. I'm in the process of migrating an environment off of ssh-key authentication over to password+otp based kerberos (FreeIPA, though AD makes this easy too). A single password+otp login gets an 8 hour (non-renwable, in this environment) ticket. At the end of those 8 hours, users have to obtain another ticket with a password+otp. What's particularly nifty about this scheme is that it's useful for not only ssh access, but internal https services as well.
An alternative (but also imperfect) solution that I've relied on in the past is using certificate-based authentication:
https://www.digitalocean.com/community/tutorials/how-to-crea...
This still requires the generation of certificates for users but it doesn't require updating the key material on the servers themselves. Having short-lived user certificates then gives the admin an easy way to revoke access to a server without changing any keys there by simply not issuing a new certificate to the user (and in urgent cases to also revoke the certificate as well before it expires, which requires intervention on the server though).
I really hope that OpenSSH keeps improving their (still largely incomplete) PKI implementation, as I think it's a great feature for larger organizations.