On Tue, Apr 15, 2014 at 5:29 PM, Yves Dorfsman <y...@zioup.com> wrote: > > We've been pushing ssh public keys with Ansible, but this is becoming > cumbersome: > > - it takes a significant amount of time to do so, this is growing as the > list of keys is growing (O(n) type of thing) > - keys only get pushed where somebody does a does a push, which means that > it becomes somebody job, and we still easily miss new/temporary servers > > We looked at LDAP with sshd AuthorizedKeysCommand, but beside the pain of > having to extend an ldap schema, it means maintaining our own LDAP server, > make that two to be redundant etc... The sort of things we were trying to > avoid by going to a cloud infrastructure. > > Played with sshd AuthorizedKeysCommand and S3, pulling the keys via http, > but that has its own set of safety issues, although mitigated by the fact > that our AWS instances use Amazon DNS servers.... > > What have you found that works well?
We currently use CFEngine 3 to populate /etc/ssh/authorized_keys.d/ on every host (pulling the contents down from our policy server, including purging any local files in that directory that do not exist on the policy server -- e.g. because they have been deleted), and the /etc/ssh/sshd_config file that we distribute contains the line "AuthorizedKeysFile /etc/ssh/authorized_keys.d/%u". Of course, this still has the problem that you have to maintain a policy server infrastructure, although it only needs to be up for changes to propagate, rather than for all authentication to succeed. This works well enough for us at the moment, though updates take a few minutes to propagate. Another approach I've heard about that seems quite elegant is using OpenSSH's CA support (note: this is *not* X.509), and having a system that issues user certificates that are valid for 24 hours only. That way, the only pubkeys you have to push around to all of your hosts are the CA certificates for your user CA (and host CA if you're using it to do host key signing too), and you can use 2FA or whatever other strict security you like on the system that issues the temporary 24h user certs, and it means you have much fewer places to disable access if you need to prevent a user from having further access. Obviously, if you do it that way, you've got to keep the system that issues user certs really secure. But then, if you do it some other way, you need to keep your policy server (or LDAP server, or...) really secure if you use those things to manage access. Here are some links about OpenSSH's CA support if you're interested... http://serverfault.com/questions/242434/docs-for-openssh-ca-based-certificate-based-authentication http://blog.habets.pp.se/2011/07/OpenSSH-certificates https://github.com/cloudtools/ssh-ca http://www.lorier.net/docs/ssh-ca http://en.community.dell.com/techcenter/b/techcenter/archive/2011/09/08/setting-up-certificate-authority-keys-with-openssh-version-5-4.aspx Cheers, Hazel _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
