Hacker News Reader

Comment by Ayesh | Hacker News Reader

SSH over QUIC would be nice.

I don't see any advantage of layering HTTP/3 here. It adds more friction, and the only advantage it brings is being able to "hide" the SSH server over a URL path. I guess x.509 certificates would be fine, but SSH hostkeys, SSHFP or TOFU is enough and far more secure (because it implicitly pins the server public key).

It's a relatively new project from the looks of it, so I'd definitely not use it anywhere half important having to create something interesting with QUIC and HTTP/3.

View on HN

They list other advantages in the README such as tying into the web authentication model, which is pretty big for enterprise use as everything moves towards OIDC. If they could eventually use passkeys that’d be really nice.

SSH supports passkeys: https://developers.yubico.com/SSH/#_fido2

With hardware tokens, yes, I use that. I was thinking that building it on a web server would be really handy with an integrated client you could use with iCloud, Windows Hello, etc.

This already exists too

With /passkeys/, actually! It's more generic than just hardware keys. I don't know of any good implementation yet, but there were a few projects on github mentioned in some passkey-related discussions here. I do not use anything like iCloud or Windows Hello and I don't know what these services actually use, but if they implement these open standards, it's only a matter of adding some glue code. I'd say it's likely that Putty will implement this over on Windows eventually. That is my speculation, as I said, I don't actually use any of this.

I mentioned those because key management is the hard part and most people are going to be using platform authenticators for that reason. In some cases there are APIs (this was one of the features in the last macOS / iOS release) but I was also thinking that moving it closer to a browser is interesting because between platform passkeys and SSO, there are a lot of people who have all of their credentials & MFA ready in a browser and would like to reuse that.

Some searching suggests there’s at least one implementation of the SSH agent protocol using Windows Hello, which is great.

I already already use passkeys for ssh. libfido.

You can already do all of this with ssh

For oidic there's at least:

https://github.com/salesforce/pam_oidc

https://github.com/EOSC-synergy/ssh-oidc

It sure would be nice to be able to easily throw up a CDN like Cloudflare in front of my ssh server with no client side special sauce required.

I didn't see it stated in the documentation, it this feels like something that might work for that setup.

Why are people obsessed with implanting CloudFlare right in the middle of everything they do? There is absolutely nobody that needs DDoS for their SSH server.

I get that CloudFlare has been a well behaved netizen so far, but let's be real, it won't last forever. It never does. Eventually the shareholders start turning the screws and CloudFlare is going to succumb to the same pressures every company does and they're going to start extracting advertising value from their "customers".

How about we save the CDNs for the serious stuff and just run our SSH servers and low traffic HTTP sites ourselves?

Every personal blog is low traffic until it lands at the top of HN

Which still means that the HTTP-server can be behind CloudFlare, but nobody accesses your blog through SSH (hence not necessary to put it behind CloudFlare).

You don't need buttflare to handle HN levels of traffic. And even if your wordpress or other shitty blog software falls over for a couple of hours? So what, it's a personal website.

Why would you intentionally MITM your SSH connection?

Absolutely nothing to do with DDoS in my case. I want censorship regimes to have to break large portions of the internet for their citizens to stop even the most simple leak vector. Let them block Cloudflare, Akamai, and Cloudfront.

I'm pretty sure even if CF went rouge you'd be able to keep your SSH connections ad free for a low $1.99/month subscription.

In the 90s it was commonplace to design a new protocol on top of TCP/IP. These days, all the tooling and infrastructure is for HTTP. Designing a new protocol, you'd be starting from scratch; HTTP is much, much easier to build an application on top of.

I doubt QUIC is easier than TCP to build on. But it's much easier to get your new protocol through firewalls and other middleware when using port 443 than trying to introduce a new port (or worse: a new protocol number)

Which sounds like more of a disadvantage if you are running a firewall.

If your firewall drops unknown protocols, then it is broken. Internet is designed to be default-open, not default-closed.

Ssh hostkeys offer no solution for first connect to ephemeral hosts.

If hosts are configured with SSH certificates as part or their setup, you can definitely skip TOFU and determine trust on the first connection. That won't work for the "I need to connect to a random IP address" scenario, but any cloud server exposing SSH can be configured with a certificate signed by a company/personal SSH certificate authority.

You could configure something delightfully atrocious like https://github.com/mjg59/ssh_pki but I think for most use cases where you connect to loads of SSH servers, host keys and certificate authorities will work just fine. We can do with an ACME-like protocol for distributing these certificates, though.

Given how rare this is, using https seems like a great idea

Strict SSHFP can theoretically solve it [1], assuming it's used in the first place and has DNSSEC. I personally use it for all servers I manage purely because I like the additional security, but it not at all common and DNSSEC isn't all that perfect either.

[1] https://aye.sh/blog/sshfp-verification

It's crazy that SSHFP hasn't taken off, I don't think a single person on earth has ever verified a host key before attempting to connect, and deploying DNSSEC is trivial now that you can use ECC and ED25519.

* Deploying DNSSEC is obviously not trivial, as doing so has taken some of the largest companies on the Internet fully off the Internet for multiple hours, within the last year, so much so that it has become a running joke when companies have prolonged outages to suggest that DNSSEC is the culprit.

* There are still resolvers that can't handle Ed25519

* Being able to use Ed25519 was never the ops problem with getting DNSSEC rolled out!

* It's weird to assume that people would want to enroll their server integrity --- something that doesn't in any way depend on an Internet PKI designed to allow strangers to verify your identity, and that enlists de facto government support to make that use case work --- in a global PKI, especially when SSH already has a perfectly good certificate system that solves the same problem without any of the above liabilities.

What boggles my mind, and I mean this sincerely, not as snark, is that anybody in the entire world takes SSHFP seriously. Even if you stipulate that DNSSEC (and/or DANE) works, just arguendo, it's still a totally different use case than resolving SSH key continuity problems.

My favorite thing about normal ssh keys is the way it does not come with the obnoxious assumption that if I don’t rent my cert from some rent-seeker, it is super scary and invalid. And yet it gives me both identity verification and encryption. I get the reasons we got there for HTTPS due to how unsophisticated the least experienced users are, but I am glad this idea here won’t catch on in real life, because we don’t need any of this stuff for SSH — mainly because it already has these features.

TLS certificates are free. Unsigned certificates are super scary and invalid. SSH and TLS do not work with the same threat model; first-contacts with SSH servers are comparatively rare (if they aren't, you should be worried about your SSH threat model, too).

Certificates aren't "free." They cost time at minimum, and complexity (you're forced to add a bunch of tooling to renew them) to satisfy the arbitrary requirements based around the fact that somehow their bits get old. The "free" ones think they get old in 90 days, and Apple decided for the whole world that I think one or two years is the absolute limit and anything longer-lasting is also "invalid."

A cert signed by your own CA isn't scary. You can trust and install your own CA, and unless you're an idiot and publish your private key you're not harming your security profile one bit, but like I said, I understand how we got here because if it were easy and not presented as scary, naive users would be tricked into installing new CAs every day. It's just annoying how it has (in practice) imposed this external prerequisite to use TLS encryption itself, which I think is pretty obviously the reason it took like 15 years for SSL to become ubiquitous.

You can set up your ephemeral hosts to come up with properly signed host keys.

SSh hosts have supported certs for at least a decade.

Reply on news.ycombinator.com