Hacker News Reader

Comment by g_p | Hacker News Reader

This looks very interesting. Is there any support (or plans) for SSH certificates? They help to manage some of the revocation and access control challenges, as well as the issues around trust-on-first-use and similar. (And also the fragility of syncing around authorized-keys files, or relying on LDAP for login, in infrastructure type environments).

View on HN

The plans are there! I focused on implementing the absolute necessary parts of every layer before taking round-2 for the more in-depth implementation. I actually have both the linked thread and the article saved aside to study when I'm ready to implement certificate-based authentication. Knowing Gitea already has it implemented, I had plans to study their implementation to know what I'm venturing into. If anybody else is interested in picking it up, please feel free to tackle it! I'd love to see that PR.

I've created tracking issue: https://github.com/mohammed90/caddy-ssh/issues/10

Great to hear, and nice work with the project so far!

I think it definitely makes sense to focus on getting the minimum viable feature set ready first - the only reason for suggesting certificates was it seemed like the kind of area where a caddy-based setup could really help simplify the process for users, and make it easier. Users hate trying to manually define quirky configs, but I could see some well-thought-through caddyfile syntax based on extractors and pattern matching with some useful defaults proving very useful for a range of scenarios that would make it very quick to deploy.

Things like "fetch the username from this field, let the user log into anything with that username", then expanding to say "... As long as the server thinks it's in a group that the user certificate lists", and "let them log in as any user, but only to hosts in a group listed here in the certificate". With user, group and hostname you likely have a lot of what people would need, aside from sane defaults like checking expiry and validity, checking signature on the certificate, and some kind of usable revocation checking, which is always an annoying pain point for any long lived certificate-based system, but which a system like caddy could make into child's play!

You're not wrong -- Caddy has a PKI app built-in, which is basically a wrapper around Smallstep's CA libs. That could be used to issue SSH certs as well, probably.

I had to think of exactly this post as well and I started to wonder, whether Caddy-SSH couldn't even handle this using Caddy's built-in ACME support?

It could, if there was an ACME server doling out SSH certificates.

And Caddy can get certificates via more than just ACME, it's completely extensible, so it will work with... anything I guess.

Although the word "Certificate" is in the name of this feature and the expansion of ACME, they don't really have much in common.

ACME is similar to, and different from the Internet's other certificate protocols, both in ways that are not helpful for a SSH server.

Firstly ACME is similar in that it's about X.509 certificates roughly PKIX flavoured, whereas certificates in SSH don't use X.509 and thus don't use PKIX

Then it's different in that ACME solves the proof-of-control problem for the Web PKI, it was actually built in parallel with what became the "10 Blessed Methods" for the Web PKI (but today there are not ten of them). But almost nobody wants public SSH servers for random people from the Internet to access, so the Web PKI is largely irrelevant to certificates for SSH servers.

[ The Web PKI is the name for the PKI that makes your web browser work, unlike SSH you actually do use web browsers to connect to random public stuff - lots of other things rely on the Web PKI, not just the Web but there are good reasons it is called the Web PKI anyway ]

Reply on news.ycombinator.com