Live data from Hacker News

SSH3: SSHv2 using HTTP/3 and QUIC

github.com

41–50 of 206 posts

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#41
post #18

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/

Do you happen to know where I can read about how ET and Mosh each establish their connections?

I have used Mosh for years and recently heard of ET, but when I tried it I experienced noticeable hangs that I don’t get with Mosh, and I went back.

I heard from several people that “ET is the new Mosh”, but it won’t be for me unless I can figure out/resolve those hangs

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#43
SSH3 seems a bit of a clickbait project name, it's not clear to me that this project uses anything protocol-wise from SSH though it offers similar functionality.

A PhD project from Belgium that combines several Golang libraries to offer HTTP-based authentication on top of backwards compatibility with OpenSSH keys, configuration, agents, etc. -- it looks pretty solid but the associated paper titled "Towards SSH3" acknowledges "This article is a first step" in the conclusion.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#44
post #8

Not going there with anything HTTP/3. Disclaimer: I write network packet parsers for XNS/IPS/IDS for a living, to look for "bad things".

The standards bodies don’t seem to buy the “bad things” argument and appear resolute on making it harder to MITM traffic on the wire and attempting to force IDS/IPS to all be run on the client.

Is there a 5-10 year future where you just can’t do this as a middlebox?

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#45
post #35

WARNING: This is not ssh3. This is someone’s project. Install at your own risk.

Anyone should treat any new crypto project which hasn't seen a lot of testing from others as such, no matter who it came from. Even if this was some sort of proposal of the OpenSSH people. The project is associated with the Louvain university; I would rate the risk of outright malicious tomfoolery to be quite low.

Well, if it was a proposal of the OpenSSH people you'd bet it would get a lot of testing from others real quick.

But to even consider calling it SSH3 is really quite silly, first impression doesn't exactly inspire confidence.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#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 not use it anywhere half important having to create something interesting with QUIC and HTTP/3.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#47
post #33
post #31

People are being perhaps a little too over dramatic here. Yes, this is not SSHv3 as defined by a standards body. It is very much SSHv2 over HTTP/3. (Which sorta sounds like how HTTP/3 is actually HTTP/2 over QUIC) But there is lots of SSH servers and clients, such as Dropbear SSH, OpenSSH, libssh, libssh2 (which is very different from libssh which also supports sshv2), and more. So I don't blame the creators from put…

Ok, I've put SSHv2 in the title to make that clearer. If there's a better way, we can change it again.

I don’t think this is SSHv2 though the GitHub talks about reimplementation on HTTP semantics, and the paper illustrates SSHv2 vs SSH3 as being extremely different for session setup.

In naming; Francois also explains SSH3 is a concatenation of SSH and HTTP/3 — we can not like that here on HN (due seemingly to the lack of IETF involvement?) but it’s what the project creators picked.

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#49

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…

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

Re: SSH3: SSHv2 using HTTP/3 and QUIC

#50
post #47
post #33

Earlier quoted context omitted.

Ok, I've put SSHv2 in the title to make that clearer. If there's a better way, we can change it again.

I don’t think this is SSHv2 though the GitHub talks about reimplementation on HTTP semantics, and the paper illustrates SSHv2 vs SSH3 as being extremely different for session setup. In naming; Francois also explains SSH3 is a concatenation of SSH and HTTP/3 — we can not like that here on HN (due seemingly to the lack of IETF involvement?) but it’s what the project creators picked.

Would SSHTTP3 have been more adequate for the project's name?
Post reply on HN