This looks very interesting, but I'm not quite sure I see what it really adds to the mix. This is a client/server service, that bootstraps ssh host certificates, from long-lived TLS x509 client certs for the SSH servers?

And users still log in using bare keys, not certificates? (Ie: no real key revocation, expiry for user keys?)

What is the use-case here, that isn't better served by simply automating the signing of ssh server certs (and user certs)? Is it moving the authorization from install/key-gen time to run-time, and from the individual ssh servers to the central "ssh authorization service"?

I was initially hoping this is what I've been mulling over making for myself (a tool to make it easier to maintain ssh user and server certificates, along with an issuer log and revocation list (I take it the life time of these server certs are set so that a revocation list is only needed for the TLS certificates involved) -- but it seems like it might be a bit of a "horizontal abstraction" -- shifting work around without really simplifying the work flow all that much.

I'm sorry to come off negative, I love to see tools that help leverage the possibilities that's already within ssh to make something better than "TOFU" and a mess of expired, forgotten, compromised and lost public keys in "authorized_keys" -- but I really think the only sane way to do that is to use full ssh certs for both hosts and users... And for that to scale, one would need some scripts/a "ssh CA" utility or something.

I suppose this project might be useful if one already has a TLS/x509 CA in-house that is used for authentication and authorization -- and one doesn't want to patch ssh to use x509 certs directly?

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