Hi everyone! Author here<p>This has been my stress-reliever for the past ~2 years. I'm sticking around, so feel free to ask any questions.<p>Github Repo: <a href="https://github.com/mohammed90/caddy-ssh" rel="nofollow">https://github.com/mohammed90/caddy-ssh</a>
What's the benefit of this being built on top of Caddy, which unless I'm mistaken has historically been an HTTP(S) server? Maybe there's someone intrinsically great about how Caddy works for this, but on first glance it feels like the scope creep in servers like Apache, or Curl's support for querying every data source under the sun. It can be handy having a single tool that does everything, but at the same time that gives an ever larger attack surface where suddenly your machine has been compromised via instructions from an MQTT server because Curl was installed.
> The ISRG estimates ~80% of the vulnerabilities exploited in the wild are memory safety bugs.<p>Okay, but 1. How many vulnerabilities has openssh shipped, and 2. How many of those were memory issues? I would usually be tentatively on board, but you're competing with the OpenBSD folks, who have a shockingly good track record regardless of using C. No offense, but you could write in a formally verified Ada subset and I'd <i>still</i> hesitate to replace my SSH daemon.<p>(FWIW, I say all of this hoping to be wrong; an alternative implementation, if equally secure, would be great to have.)
Note that outsourcing your key list to a live GitHub URL gives Microsoft unfettered access to your box, should they (or anyone who can compel them, such as the US armed forces) ever want or need it.<p>If you wouldn't use Microsoft SSO for local login, you should not thus configure your sshd that way.
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).<p>See also - <a href="https://news.ycombinator.com/item?id=30788544" rel="nofollow">https://news.ycombinator.com/item?id=30788544</a>
I'm not sure I fully understand, what's the advantage of getting Caddy involved here versus a fully standalone app?<p>Given the name I'd at first figured it was an official Caddy project, but that does not seem to be the case.
Biggest obstacle to proper SSH usage tends to be the creation and management of people's private keys. The number of times people have to google for instructions for doing this right is insane. Let's get someone working on that.
First and foremost, congratulations on bringing the project to this stage - I think it's an impressive piece of work.<p>I am in no way qualified to trample on your parade but two things came to my mind that pinch a personal nerve of mine and I would really like to have alleviated by you or the folks who know that stuff:<p>- if your Goal was "secure by default", why did you allow passwords in the first place? Following Caddys recipe would be more like SSH-Keys only, wouldn't it? Is there a reason other than compatibility?<p>- In that same avenue? Why allow such a thing as downloading authorized keys from a third party? Domain takeovers or account compromises on say Github are a thing - so again while it may be a nice usability aspect isn't that contrary to the secure by default pradigm?<p>Again thank you for your work and congratulations on the project - those above are just honest questions that came to mind which I would really like to be educated on