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 still hesitate to replace my SSH daemon.
(FWIW, I say all of this hoping to be wrong; an alternative implementation, if equally secure, would be great to have.)
* CVE-2016-10012: https://www.cvedetails.com/cve/CVE-2016-10012/
* CVE-2016-0777: https://www.cvedetails.com/cve/CVE-2016-0777/
A list of all CVE is available here: https://www.cvedetails.com/vulnerability-list/vendor_id-97/p...
most of the other server-side bugs on the list relate to non-standard configs (of varying obscurity)
the fact that - in an era of increasingly hostile cyber threats - years had gone by without any serious threats says it all really.
for most people, they should just run normal SSH, enable public-key only authentication and get on with their lives.
I see no reason why anyone should jump ship to some shiny new untested ssh server. Especially as , when others have pointed out, the people behind OpenSSH are the same people behind OpenBSd and LibreSSL.
Caddy CVE: https://www.cvedetails.com/cve/CVE-2018-21246/ Kubernetes CVEs: https://www.cvedetails.com/vulnerability-list/vendor_id-1586...
No silver bullets! Though some have less lead in them. OpenSSH, along with other software developed by OpenBSD, has earned the highest level of trust in something written in C. C can be dangerous, but there is a chasm between such careful works and the typical offenders like OpenSSL (OpenBSD's alternative is LibreSSL, confusingly).
That said, I don't say this to discourage the project. I wish it all the best and hope that they continue to work out the issues involved. I'm speaking more here to dampen the set of programmers and/or ops I know who will read something like this and immediately begin converting their entire fleet, because this looks new and hot and uses $TECH I like and must therefore be better than the old and busted using $BADTECH I don't like. Hey, I'm on the cutting edge of hating C and thinking almost anything written in it should be banned from the network, but OpenSSH does have a pretty good track record and that shouldn't be chucked overboard for new untested hotness.
Best wishes to Caddy-SSH. I would encourage a bit of trying it out, just, you know, don't go crazy. I don't think they'd want you to either!
if this helps us get away from the scenario where literally everybody uses the same SSH server implementation, i think it's a great thing.
That said, I wonder how many crypto libraries are shared between Caddy-SSH and OpenSSH?
Finally, I really hope this is a separate daemon. SSH served by a web server invokes a certain systemd feeling.
None, because Caddy-SSH is written in Go, and uses Go stdlib crypto libs which are their own thing. See https://pkg.go.dev/golang.org/x/crypto
> Finally, I really hope this is a separate daemon. SSH served by a web server invokes a certain systemd feeling
That's entirely up to you. Caddy v2 is designed as an "app platform"; the HTTP app is just one such app that Caddy happens to ship with, but anything else can be plugged in, like an SSH app in this case. You don't have to run both HTTP and SSH in the same process, you could run two instances of Caddy each with their own purpose, if you feel like. https://caddyserver.com/docs/architecture
But yeah, just for the time when you're hammered with traffic that you want to investigate, you don't want your web server and SSH session to go through the same loop.
For additional context, since the gp mentioned that:
> the OpenBSD folks, who have a shockingly good track record
Not only is OpenSSH a BSD project, but so is LibreSSL (the OpenSSL fork that was a response to Heartbleed). Before LibreSSL, BSD folk were also working on assl - similarly an OpenSSL alternative motivated by the BSD guys having concerns about OpenSSL's codebase. So they very much have a solid track record of being pro-actively on top of this type of stuff.
This has been my stress-reliever for the past ~2 years. I'm sticking around, so feel free to ask any questions.
Github Repo: https://github.com/mohammed90/caddy-ssh
Feel free to file a discussion issue over on GitHub at microsoft/terminal, or email me at duhowett@(corporate domain name).
I suspect what you need is CreatePseudoConsoleAsUser… which we should have offered as a public API.
Licensing / Multi-user access / CAL | https://github.com/PowerShell/Win32-OpenSSH/issues/926 (Oct 2017)
Considering memory corruption vulnerabilities have been pretty much the vast rarity in the OpenSSH codebase, and other classes of vulnerabilties have been more common, I'm curious to know what you're doing to address those classes of vulnerabilities as well as support for other best practices like SSH certificates? [2]
I think I see the appeal of an entirely memory-safe OS running an entirely memory-safe SSH implementation because if we're talking about eliminating that class of vulnerability, you might as well go the whole hog - I just don't see that close to the point of being battle tested yet nor taking care of stuff like side channel attacks or tricking people into thinking their TOFU isn't smelly. I like your project because I think that this stuff is important, I think it's just like "how do you improve on the original" may actually be more than just eliminating one class of vuln.
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh [2] https://smallstep.com/blog/use-ssh-certificates/
https://github.com/mohammed90/caddy-ssh/blob/master/internal...
Obviously, security of that Redis or Consul would have to be tight and prevent public access.
So, if I get this right, this should be a drop-in replacement for current SSH servers? I get that an adapter has to be built to support sshd config files, but is that the ultimate goal here? Is security the main selling point of this project?
They are literally called Pluggable Authentication Modules (PAM) and it's a core part of any Linux distribution. (I'm not aware of any modern UNIX or Linux that do not offer PAM, but perhaps some embedded distros.)
They can be configured for many types of server software, not just OpenSSH. (For example, mail servers like Dovecot and Postfix support PAM, database servers like Postgresql and MySQL, etc.)
That's not exactly fair. The entire point of this exercise is to move away from C code, by implementing it in a memory safe language (Go).
Since PAM uses shared-libraries to operate, that's fundamentally incompatible here since Go is statically compiled (unless you use some CGO like in https://github.com/msteinert/pam) so implementing auth via Caddy's module system is the way to go for this project.
I'm a bit curious what this ends up meaning for projects like GitLab and Gitea. Gitea's docs [1] indicate that it can either use the system sshd or one that it "provides", but it's not clear whether the provided one is Go-implemented or just a statically-compiled instance that it runs as a subprocess.
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:
- 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?
- 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?
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
Compatibility was the consideration. The presence of the password based authentication does not mean it is enabled by default. In fact, if you don't enable any of the authentication flows and don't explicitly set `no_client_auth` to `true`, the server will not accept any request at all! You have to explicitly set `no_client_auth` to `true` for the server to allow unauthenticated users to login. The default is: none of the authentication methods are configured, and `no_client_auth` is false (meaning do not allow clients without authentication).
> - 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?
That was just an example, but the implementation doesn't only support github. It supports any HTTP/S URL you provide. The point was that the source of the keys may even be an internal HTTPS service within your network that applies its own logic for keys issuance and generation.
Nobody said anything about requiring certificates in SSH, just public keys as authentication.
If you give you public key to be installed to allow access, even if the host (or any system you are using to build/interact with it) is compromised your private key and any other hosts that accept authentication that way are fine.
How much difference this makes to you depends upon your threat model and how much extra threat you are willing to accept for a little convenience, of course, but key based auth is demonstrably more secure than passwords for some circumstances and no less secure in others.
Then again given that very few people bother actually checking host fingerprints on first connection, then proceed to send important data to that unverified host, is the password/key issue the first thing we need to fix?
Re-using an insecure password is easy, using a key wrong is harder.
I've created tracking issue: https://github.com/mohammed90/caddy-ssh/issues/10
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!
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 ]
And Caddy can get certificates via more than just ACME, it's completely extensible, so it will work with... anything I guess.
The teleport daemon falls over due to memory stress and other issues that sshd doesn't fall over during, and when do you often need CLI access to a node? When it's under stress....
Goodbye automation.
It's a good idea, but it's made ssh and the problems I solve with ssh worse for me.
If you wouldn't use Microsoft SSO for local login, you should not thus configure your sshd that way.
If your sshd consults Microsoft servers to check a key, Microsoft can serve it any file they wish (or are forced to), such as a list of Equation Group pubkeys.
See https://caddyserver.com/docs/architecture
You don't have to run both the HTTP app and the SSH app in the same process, you could have two separate Caddy processes configured to each do their own thing, if you're at all concerned.
Given the name I'd at first figured it was an official Caddy project, but that does not seem to be the case.
Caddy provides the module system and the config management backed by powerful REST API for config query and patching. If it wasn't for Caddy, I would've had to build all of that from scratch. That's too much to own.
Here are some random domains taken from the Caddy Forum threads:
https://lastfree.space/.git/HEAD
https://www.aspecthq.com/.git/HEAD
Those people are unaware of serving their git (or .env files or other secrets) over the internet, probably because are used to other webservers that just block this behaviour by default.
And it's ok to not do or be like the others, but this should at least be mentioned in the docs.
