Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH3: SSHv2 using HTTP/3 and QUIC

github.com

Post reply on HN
Print view View original

11–20 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#11

Post by lnxg33k1 »

uxp8u61q wrote: post #6
amluto wrote: post #5

Earlier quoted context omitted.

What does “official” mean? The OpenSSH team? IETF? Anyway, SSH authentication is extremely inflexible, and the protocol is not particularly performant, especially on large bandwidth-delay links. Moving to HTTP3 seems like an excellent idea if it’s implemented well. (Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.)

The RFCs for SSH2 were all published by IETF, so I would definitely expect IETF to be involved in a project that claims to be "SSH3". If some random person started an OS project and called it "Windows 12", people would rightfully be confused.

Agree I also think that we should leave naming stuff SSH to IETF and OpenSSH to OpenBSD, in this case the maintainer seems to be unrelated to both

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#12

Post by georgyo »

out_of_protocol wrote: post #10

If you want SSH via UDP, try mosh. If you have it installed on both client and server side, it just works, re-using auth, sessions etc fron ssh itself and only replacing sending actual session bytes back and forth. Don't break on unstable connections, have way lower latency

Mosh and this project have fairly different goals.

Mosh uses regular TCP SSHv2 to authenticate and setup the udp connection. As such your initial connection time is actually slower than just normal v2, and you cannot auth with something like oauth.

Mosh is heavily focused on interactive sessions. You could not use mosh for batch programs easily.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#13

Post by tlivolsi »

uxp8u61q wrote: post #6
amluto wrote: post #5

Earlier quoted context omitted.

What does “official” mean? The OpenSSH team? IETF? Anyway, SSH authentication is extremely inflexible, and the protocol is not particularly performant, especially on large bandwidth-delay links. Moving to HTTP3 seems like an excellent idea if it’s implemented well. (Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.)

The RFCs for SSH2 were all published by IETF, so I would definitely expect IETF to be involved in a project that claims to be "SSH3". If some random person started an OS project and called it "Windows 12", people would rightfully be confused.

Agreed. The name is terribly misleading.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#16

Post by aseipp »

amluto wrote: post #5
znpy wrote: post #2

Is this wayland all over again? We do three or four new things well, and everybody is supposed to just stop doing everything else ? Is this "a secure shell" (as in, somebody's personal spin on the topic) or like a new "official" direction? The readme isn't clear on these aspects.

What does “official” mean? The OpenSSH team? IETF? Anyway, SSH authentication is extremely inflexible, and the protocol is not particularly performant, especially on large bandwidth-delay links. Moving to HTTP3 seems like an excellent idea if it’s implemented well. (Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.)

Yeah, right now for auth, if you want to use e.g. OIDC I think the best you can do is to essentially shove everything in the square hole using very short-lived SSH certificates and OOB auth flow; e.g. "open this browser link to get a cert for the next 15 minutes/24 hours." So, you're basically treating short-lived certs like session tokens, more or less. I got this working with my own homegrown SSH CA infrastructure last year, but never took it out of prototype stage. Even slightly more flexible authentication would be very welcome.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#18

Post by v3ss0n »

out_of_protocol wrote: post #10

If you want SSH via UDP, try mosh. If you have it installed on both client and server side, it just works, re-using auth, sessions etc fron ssh itself and only replacing sending actual session bytes back and forth. Don't break on unstable connections, have way lower latency

eternal is better than mosh https://eternalterminal.dev/

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#20

Post by vlovich123 »

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 how secure Go’s HTTP stack is since an exploit there could expose quite a bit and I don’t know that it’s been hardened to host directly, but it is an interesting idea. May be worth hand-rolling a custom server to do the routing but at the same time it makes it easier to fingerprint. I think it makes more sense to separate the routing secret to a standard reverse proxy that’s harder to fingerprint. One could imagine that the secret URL idea in a normal HTTP stack is susceptible to scanning techniques since there’s only one route to guess.
Post reply on HN