6 ms·

Sharkey: a service for managing certificates for use by OpenSSH

51 points by amenghra 10y ago

amenghra 10y ago
Sharkey is our team's intern summer project. We are open sourcing it today. In the enterprise world, engineers often ssh into hosts for the first time on a daily basis. This trains them to acknowledge the trust on first use prompt on a daily basis. Sharkey removes the prompt by signing the openssh certificates. Feel free to post questions here and I'll relay them.
- netik 10y ago
  It seems like you are reinventing the wheel here. Did you look at RFC4255? https://tools.ietf.org/html/rfc4255 https://tools.ietf.org/html/rfc4255
  - dogma1138 10y ago
    That only works if you have control over the DNS and are using it. DNS based protocols are quite flaky not every server/provider allows you to store text records and some even limit the length of the A/AAAA record. It also becomes more complicated when you are running multiple ssh services on a single host or using proxies/forwarders. I use a similar method to secure my own ssh services before that I used a tool that converts the fingerprint into a phrase but it wasn't collision resistant enough.
  - mcpherrinm 10y ago
    OpenSSH already supports certificates. This is a set of tools for issuing and managing those certificates. We could use RFC4255 instead, but we'd still have the same problems around issuing them, and we could set up sharkey to support it if we wanted to.
djmdjm 10y ago
Nice work - this solves a common problem. You might consider adding a recommended ssh_config to ensure that host names are canonicalised. This allows FQDNs in certificates to match successfully when users only supply a hostname. More details at http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-...
- mcpherrinm 10y ago
  Adding recommended ssh configs is a good idea. I'll file a ticket.
e12e 10y ago
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?
- amenghra 10y ago
  What is the use-case here, that isn't better served by simply automating the signing of ssh server certs (and user certs)? This is exactly what this tool does. We leverage our existing PKI to request the signed certificates. mcpherrinm is planning to publish the design doc, it might help clarify things. [...]shifting work around without really simplifying the work flow all that much. Sharkey currently solves one problem and does it well: removing the trust on first use prompt. When you have thousands of servers, you run into the prompt on a daily basis. In addition, some virtual machines get re-imaged on a regular basis. As a result, you train engineers to ignore the TOFU prompt and also ignore the fingerprint changed warning in some instances. The certs can be short lived. It's not strictly equivalent to a revocation system, but in practice it seems short lived certs work well. [...]expired, forgotten, compromised and lost public keys in "authorized_keys" Sharkey does not address any of these. We already have automation around our authorized_key management.
stonogo 10y ago
What would cause someone to use this instead of deploying a known-hosts file with configuration management tools?
- mcpherrinm 10y ago
  Using a CA means all users instantly trust a host, without needing to update their known hosts file. If you are frequently spinning up or reimaging hosts, you don't have to worry about constant updates to known hosts files everywhere.
nsheridan 10y ago
This is interesting. I wrote a service for issuing user ssh certs but it doesn't manage host certs. https://github.com/nsheridan/cashier https://github.com/nsheridan/cashier
markhahn 10y ago
you can put host keys in DNS, which can/should be secured. doesn't that avoid the need for this new infrastructure?
- amenghra 10y ago
  We answered this question in a sibling thread, see: https://news.ycombinator.com/item?id=12098202 https://news.ycombinator.com/item?id=12098202

51 points by amenghra 10y ago

Sharkey is our team's intern summer project. We are open sourcing it today. In the enterprise world, engineers often ssh into hosts for the first time on a daily basis. This trains them to acknowledge the trust on first use prompt on a daily basis. Sharkey removes the prompt by signing the openssh certificates. Feel free to post questions here and I'll relay them.

netik 10y ago
It seems like you are reinventing the wheel here. Did you look at RFC4255? https://tools.ietf.org/html/rfc4255 https://tools.ietf.org/html/rfc4255
- dogma1138 10y ago
  That only works if you have control over the DNS and are using it. DNS based protocols are quite flaky not every server/provider allows you to store text records and some even limit the length of the A/AAAA record. It also becomes more complicated when you are running multiple ssh services on a single host or using proxies/forwarders. I use a similar method to secure my own ssh services before that I used a tool that converts the fingerprint into a phrase but it wasn't collision resistant enough.
- mcpherrinm 10y ago
  OpenSSH already supports certificates. This is a set of tools for issuing and managing those certificates. We could use RFC4255 instead, but we'd still have the same problems around issuing them, and we could set up sharkey to support it if we wanted to.

djmdjm 10y ago

Nice work - this solves a common problem. You might consider adding a recommended ssh_config to ensure that host names are canonicalised. This allows FQDNs in certificates to match successfully when users only supply a hostname. More details at http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-...

mcpherrinm 10y ago
Adding recommended ssh configs is a good idea. I'll file a ticket.

e12e 10y ago

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?

amenghra 10y ago
What is the use-case here, that isn't better served by simply automating the signing of ssh server certs (and user certs)? This is exactly what this tool does. We leverage our existing PKI to request the signed certificates. mcpherrinm is planning to publish the design doc, it might help clarify things. [...]shifting work around without really simplifying the work flow all that much. Sharkey currently solves one problem and does it well: removing the trust on first use prompt. When you have thousands of servers, you run into the prompt on a daily basis. In addition, some virtual machines get re-imaged on a regular basis. As a result, you train engineers to ignore the TOFU prompt and also ignore the fingerprint changed warning in some instances. The certs can be short lived. It's not strictly equivalent to a revocation system, but in practice it seems short lived certs work well. [...]expired, forgotten, compromised and lost public keys in "authorized_keys" Sharkey does not address any of these. We already have automation around our authorized_key management.

stonogo 10y ago

What would cause someone to use this instead of deploying a known-hosts file with configuration management tools?

mcpherrinm 10y ago
Using a CA means all users instantly trust a host, without needing to update their known hosts file. If you are frequently spinning up or reimaging hosts, you don't have to worry about constant updates to known hosts files everywhere.

nsheridan 10y ago

This is interesting. I wrote a service for issuing user ssh certs but it doesn't manage host certs. https://github.com/nsheridan/cashier https://github.com/nsheridan/cashier

markhahn 10y ago

you can put host keys in DNS, which can/should be secured. doesn't that avoid the need for this new infrastructure?

amenghra 10y ago
We answered this question in a sibling thread, see: https://news.ycombinator.com/item?id=12098202 https://news.ycombinator.com/item?id=12098202