SSH3: SSHv2 using HTTP/3 and QUIC • Hacker News Board

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#91

Post by jofla_net » Sat, Dec 16, 2023, 6:27 PM UTC

vlovich123 wrote: post #20

alphazard wrote: post #7

This is pretty neat, definitely better to move to UDP, so that we can have the proper response to unauthorized contact--no response. QUIC is fine as is though, no need to layer HTTP3 on top of it.

The reason they’re using HTTP is to allow for hiding the SSH server so that it pretends to be a dummy HTTP server that responds to 404 on all requests unless you know the special random URL that hosts the SSH capabilities. It’s a neat idea but overkill when you’re not using that capability (didn’t dig into the code so maybe it is bypassed if you don’t ask for a secret URL). It does make me hesitant as I don’t know ho…

Yeah its overkill. Its like trying to hide a meth lab by just putting up a sign that says daycare. (and if you do a special knock on the door you go to the secret room) Edit: vs having an invisible building which if you knock on it the right way, materializes...

The best thing about QUIC if its udp is definately that it could be made un portscannable.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#92

Post by extraduder_ire » Sat, Dec 16, 2023, 6:29 PM UTC

xyst wrote: post #76

wackget wrote: post #65

What if you already run a web server which uses port 443? Strange that the readme doesn't mention that scenario because it's extremely common. Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.

Front load service with nginx server or load balancer… nginx exposed on 443: if route is /web then route to web service on port 1234 if route is /ssh3-secret-string -> route to ssh3 server service on port 1265 if route doesn’t exist then 404 …

Can nginx proxy-pass encrypted data now? I tried this before and failed pretty hard, had to use HAproxy at the time and pass based on the hostname in the SNI header. Was still pretty unreliable.

If so, I assume the encryption on the SSH is handled separately from the http headers.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#93

Post by codetrotter » Sat, Dec 16, 2023, 6:32 PM UTC

withinboredom wrote: post #49

vlovich123 wrote: post #20

Earlier quoted context omitted.

The reason they’re using HTTP is to allow for hiding the SSH server so that it pretends to be a dummy HTTP server that responds to 404 on all requests unless you know the special random URL that hosts the SSH capabilities. It’s a neat idea but overkill when you’re not using that capability (didn’t dig into the code so maybe it is bypassed if you don’t ask for a secret URL). It does make me hesitant as I don’t know ho…

It's likely the URL can be discovered via basic timing attacks as virtually zero routers do constant-time comparisons for route matching.

If the URL path is meant to be kept secret, such as here, they should use a password hashing algorithm such as for example bcrypt or scrypt for the URL path and hash the path of every incoming request and then check the hash of the path instead of the path itself

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#94

Post by rubyfan » Sat, Dec 16, 2023, 6:32 PM UTC

Something about calling this SSH3 feels like when Comcast named a thing 10G.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#95

Post by mcfedr » Sat, Dec 16, 2023, 6:38 PM UTC

jeroenhd wrote: post #57

mkesper wrote: post #54

Earlier quoted context omitted.

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…

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

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#96

Post by mcfedr » Sat, Dec 16, 2023, 6:39 PM UTC

k__ wrote: post #9

How does it compare to Mosh?

Sounds like it as to solve completely different set of problems

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#97

Post by r1ch » Sat, Dec 16, 2023, 6:40 PM UTC

I feel like they're missing some benchmarks here, show off the benefit that QUIC brings! OpenSSH's fixed window size significantly bottlenecks throughput on long fat links. I'd love to see ssh+rsync running at 2+ gbps.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#98

Post by InvaderFizz » Sat, Dec 16, 2023, 6:41 PM UTC

Ayesh wrote: post #46

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 no…

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.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#99

Post by cortesoft » Sat, Dec 16, 2023, 6:42 PM UTC

mkesper wrote: post #54

Ayesh wrote: post #46

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 no…

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

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

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#100

Post by ironhaven » Sat, Dec 16, 2023, 6:49 PM UTC

Why is there http/3 in the middle? SSH over QUIC makes a lot of sense and was something I thought about before.

The SSH protocol is designed to multiplex many “channels” over an encrypted tcp socket. Over each channel you can run things like a shell or SFTP.

It would need some engineering but you could keep the same SSH features but replace the multiplexing channels over tcp with QUIC channels over udp. Where does HTTP/3 fit in besides to add overhead?