3 ms·

This doesn't deal with user keys at all -- we use Kerberos for users to log in. This is just an SSH CA for server certificates. We could extend it to users, i

This doesn't deal with user keys at all -- we use Kerberos for users to log in. This is just an SSH CA for server certificates. We could extend it to users, if we had a way to identify them. We have an existing x509 trust infrastructure, where keys are distributed with Keywhiz (https://github.com/square/keywhiz https://github.com/square/keywhiz). That's why we started with having hosts identify themselves with x509 client certs. We will deploy sharkey-client to all hosts, and it's automatically issued an x509 client cert. The primary purpose of this service is to allow us to move to short-lived SSH Host certificates. Instead of issuing a single permanent certificate at host imaging time, we have a client running on every server that's fetching fresh host certificates all the time. When you say "simply automating the signing of ssh server certs", what differences do you mean from this? Because that's what this is -- automating the signing of ssh server certs. Your last sentence is pretty much spot on: We use x509 everywhere, but want to use stock SSH. We also didn't use our existing secrets distribution because we wanted to decouple SSH from the rest of our infrastructure

e12e 10y ago
Ok, thank you both. Makes a lot of sense. It's not what I need, but that's fine :-) I've not really looked hard at (open)ssh and kerberos before - as far as I can tell, (open)ssh doesn't support kerberos fully - that is - it's not possible to simply use kerberos to authenticate both client and server to each other? > When you say "simply automating the signing of ssh server certs", what differences do you mean from this? Because that's what this is -- automating the signing of ssh server certs. I suppose the fact that you already have an x509 (and kerberos) infrastructure was one thing I didn't "expect" - ideally either one of those should be enough to identify server/services and users to each other -- I absolutely see the sense in leveraging that to automate ssh server cert generation - but it strikes me as a roundabout/complex way of solving the trust issue. Then again, composing a few simple tools might be better than trying to secure/get something like https://tools.ietf.org/html/rfc6187 https://tools.ietf.org/html/rfc6187 to work... In essence this places trust in the x509 infrastructure - I'm always a bit skeptical of schemes (most of which I must admit I've thought up myself at one time or another) that end up being "ad-hoc kerberos with public keys". They all feel straightforward on paper, but then I remember how many issues there were with getting kerberos to the place it is today, that is to say create an actually secure system... I suppose strictly speaking, this is automating the signing of server certs - continuously. Which is a bit more than I meant - I was more precisely thinking of automating the setup of ssh server certificates, I guess. Perhaps with the possibility to push updates from time to time. Anyway, maybe a sentence at the top of the readme along the lines of "Automating short-lived ssh server certificates on top of existing x509 infrastructure" would've made things more obvious. Now that I have a handle on what this is, and the context - I suppose a similar infrastructure might be used for generating client certificates too. Perhaps semi-manually via a web-service that uses x509 client certificates for authentication, and perhaps ldap as a backend for authorization data. It does appear that it's difficult to set up a fleet of ssh server so that there's no need to do a dynamic look-up to something like ldap, and still have sensible limits on who gets to log in to which server. I suppose one could use several CAs for signing user certs - one per group of servers - but that sounds a bit messy. I suppose the other alternative is to do something with AuthorizedPrincipalsCommand[1] - but that also feels a bit messy... For others contemplating playing with plain ssh certificates, I came across this, which is about as good a guide as I've read: https://ef.gy/hardening-ssh https://ef.gy/hardening-ssh [1] http://man.openbsd.org/sshd_config http://man.openbsd.org/sshd_config

e12e 10y ago

Ok, thank you both. Makes a lot of sense. It's not what I need, but that's fine :-) I've not really looked hard at (open)ssh and kerberos before - as far as I can tell, (open)ssh doesn't support kerberos fully - that is - it's not possible to simply use kerberos to authenticate both client and server to each other? > When you say "simply automating the signing of ssh server certs", what differences do you mean from this? Because that's what this is -- automating the signing of ssh server certs. I suppose the fact that you already have an x509 (and kerberos) infrastructure was one thing I didn't "expect" - ideally either one of those should be enough to identify server/services and users to each other -- I absolutely see the sense in leveraging that to automate ssh server cert generation - but it strikes me as a roundabout/complex way of solving the trust issue. Then again, composing a few simple tools might be better than trying to secure/get something like https://tools.ietf.org/html/rfc6187 https://tools.ietf.org/html/rfc6187 to work... In essence this places trust in the x509 infrastructure - I'm always a bit skeptical of schemes (most of which I must admit I've thought up myself at one time or another) that end up being "ad-hoc kerberos with public keys". They all feel straightforward on paper, but then I remember how many issues there were with getting kerberos to the place it is today, that is to say create an actually secure system... I suppose strictly speaking, this is automating the signing of server certs - continuously. Which is a bit more than I meant - I was more precisely thinking of automating the setup of ssh server certificates, I guess. Perhaps with the possibility to push updates from time to time. Anyway, maybe a sentence at the top of the readme along the lines of "Automating short-lived ssh server certificates on top of existing x509 infrastructure" would've made things more obvious. Now that I have a handle on what this is, and the context - I suppose a similar infrastructure might be used for generating client certificates too. Perhaps semi-manually via a web-service that uses x509 client certificates for authentication, and perhaps ldap as a backend for authorization data. It does appear that it's difficult to set up a fleet of ssh server so that there's no need to do a dynamic look-up to something like ldap, and still have sensible limits on who gets to log in to which server. I suppose one could use several CAs for signing user certs - one per group of servers - but that sounds a bit messy. I suppose the other alternative is to do something with AuthorizedPrincipalsCommand[1] - but that also feels a bit messy... For others contemplating playing with plain ssh certificates, I came across this, which is about as good a guide as I've read: https://ef.gy/hardening-ssh https://ef.gy/hardening-ssh [1] http://man.openbsd.org/sshd_config http://man.openbsd.org/sshd_config