I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.
It is not faster in this sense. However, an SSH connection can have multiple substreams, especially for port forwarding. Over a single classical connection, this can lead to head-of-line blocking, where an issue in one stream slows everything down. QUIC/HTTP3 protocol can solve this.
Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.
SSH is actually really slow on high latency high bandwidth links (this is what HPN-SSH patches fix: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq). It's very apparent if you try running rsync between two datacenters on different contients.
HTTP/3 (and hopefully this project) does not have this problem.
It also tracks with HTTP/3 and QUIC as a whole, as one of the main "selling points" has always been reduced round trips leading to faster connection setup.
If by being faster at making a connection it would reduce latency even if a little, it would mean a really big improvement for other protocols built on top of it like rsync. If Rsync reuses an active connection to stream the files and calculate changes then the impact might be negligible.
openssh is generally not praised for its speed but its security track record. i hope this thing doesnt sacrefice it for a little more speed in something that generally doesn't require more speed..
I use ssh everywhere, maybe establish 200+ SSH sessions a day for my entire career of 20 years and never once have I thought “I wish establishing this connection was faster”
> Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged.
Bummer. From a user perspective, I don't see the appeal. Connection setup time has never been an annoyance for me.
SSH is battle-tested. This feels risky to trust, even whenever they end up declaring it production-ready.
I do hate the name ssh3. I was glad to see this at the top of the repo:
> SSH3 is probably going to change its name. It is still the SSH Connection Protocol (RFC4254) running on top of HTTP/3 Extended connect, but the required changes are heavy and too distant from the philosophy of popular SSH implementations to be considered for integration. The specification draft has already been renamed ("Remote Terminals over HTTP/3"), but we need some time to come up with a nice permanent name.
Easy: hhs instead of ssh (since the even more obvious shh is essentially impossible to google). Stands for, idk, HTTP/3 Hardened Shell or something ("host shell"? sounds like windows)
my autism plays out also in the world of words, i.e. names of things, and my comment here is more a reply to all my surrounding comments than to yours:
ssh is not a shell and ssh is not a terminal, so please everybody stop suggesting name improvements that more deeply embed that confusion.
back in the day, we had actual terminals, and running inside was our shell which was sh. then there was also csh. then there was the idea of "remote" so rsh from your $SHELL would give you a remote $SHELL on another machine. rsh was not a shell, and it was not a terminal. There were a whole bunch of r- prefixed commands, it was a family, and nobody was confused, these tools were not the thing after the r-, these tools were just the r- part.
then it was realized that open protocols were too insecure so all of the r- remote tools became s- secure remote tools.
http is a network protocol that enables other things and gets updated from time to time, and it is not html or css, or javascript; so is ssh a network protocol, and as I said, not a shell and not a terminal.
just try to keep it in mind when thinking of new names for new variants.
and if somebody wants to reply that tcp/ip is actually the network protocol, that's great, more clarification is always good, just don't lose sight of the ball.
SSH is slow, but in my experience the primary cause of slowdown is session setup.
Be it PAM, or whatever OpenBSD is doing, the session setup kills performance, whether you're re-using the SSH connection or not, every time you start something within that connection.
Now obviously for long running stuff, that doesn't matter as much as the total overhead. But if you're doing long running ssh you're probably using SSH for its remote terminal purposes and you don't care if it takes 0.5 seconds or 1 second before you can do anything. And if you want file transfer, we already had a HTTP/3 version of that - it's called HTTP/3.
Ansible, for example, performs really poorly in my experience precisely because of this overhead.
Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.
It's cool that SSH is getting some love but I'm a little sad they're not being a little more ambitious with regard to new features, considering it seems like they're more or less creating a new thing. Looks like they're going to support connection migration but it would be cool (to me anyway) if they supported some of the roaming/intermittent connectivity of Mosh[1].
I wonder what the current plans are with the project, it's been over a year since the last release - yet alone commits or other activity on GitHub. As they've started working on the project with a paper - I guess they'll might be continuously working on other associated aspects?
I feel like this should really be SSH over QUIC, without the HTTP authorization mechanisms. Apart from the latter not really being used at all for users (only for API calls, Bearer auth), shell logins have a whole truckload of their own semantics. e.g. you'd be in a rather large amount of pain trying to wire PAM TOTP (or even just password+OTP) into HTTP auth…
I view it orthogonally: Making it easier to use our single company identity we use for every single service for SSH as well would make it so much easier to handle authorization and RBAC properly for Linux server management. Right now, we have to juggle SSH keys; I always wanted to move to SSH certificates instead, but there's not a lot of software around that yet (anyone interested in building some? Contact me).
So having the ease of mind that when I block someone in Entra ID, they will also be locked out of all servers immediately—that would be great actually.
> PAM TOTP (or even just password+OTP) into HTTP auth
But why would you? Before initiating a session, users will have to authorise to the IdP, which probably includes MFA or Passkeys anyway. No need for PAM anymore at all.
So with HTTP requests you can see the domain name in the header and forward it to the correct host. That was never a thing you could do with SSH, does this allow that to work?
"It is often the case that some SSH hosts can only be accessed through a gateway. SSH3 allows you to perform a Proxy Jump similarly to what is proposed by OpenSSH. You can connect from A to C using B as a gateway/proxy. B and C must both be running a valid SSH3 server. This works by establishing UDP port forwarding on B to forward QUIC packets from A to C. The connection from A to C is therefore fully end-to-end and B cannot decrypt or alter the SSH3 traffic between A and C."
More or less, maybe but not automatically like you suggest, I think. I don't see why you couldn't configure a generic proxy to set it up, though.
in the SSH client config would make everything in that domain hop over that hop server. It's one extra connection - but with everything correctly configured that should be barely noticeable. Auth is also proxied through.
You can forward any ssh traffic based on the domain name with SNI redirection. You can also use that with, lets say the nginx stream module, to run ssh and http server on the same port.
I haven’t seen anyone yet comment on the design constraint that SSH uses a lot of separation in its multiplexing for the purpose of sandboxing/isolation. Would want transport to be as straightforward as possible. SSH needs to be the reliable, secure tunnel that you can use to manage your high performance gateways. It has a lot of ways to turn things off to avoid attack surface. HTTP protocols have a lot of base requirements. Different problems.
Don't get me wrong, this might likely be a fantastic tool. But something as essential as a secure connection would definitely need a good pair of eyes for audit before I'd use that for anything in production.
But it's a good start. Props to exploring that kind of space that needs improvement but is difficult to get a foothold in.
> the keystroke latency during a session remains unchanged
That’s a shame. Lowered latency (and persistent sessions, so you don’t pay the connection cost each time) are the best things about Mosh (https://mosh.org/).
So does this mean that you can't self sign anything and have to involve corporate CAs for your ssh now? Because QUIC cannot do anything without CA TLS approval being involved.
[+] [-] Zambyte|5 months ago|reply
[+] [-] s-macke|5 months ago|reply
[+] [-] notepad0x90|5 months ago|reply
[+] [-] zielmicha|5 months ago|reply
HTTP/3 (and hopefully this project) does not have this problem.
[+] [-] wolrah|5 months ago|reply
[+] [-] gchamonlive|5 months ago|reply
[+] [-] nine_k|5 months ago|reply
[+] [-] sim7c00|5 months ago|reply
[+] [-] malux85|5 months ago|reply
I use ssh everywhere, maybe establish 200+ SSH sessions a day for my entire career of 20 years and never once have I thought “I wish establishing this connection was faster”
[+] [-] unknown|5 months ago|reply
[deleted]
[+] [-] temp0826|5 months ago|reply
[+] [-] kelnos|5 months ago|reply
Bummer. From a user perspective, I don't see the appeal. Connection setup time has never been an annoyance for me.
SSH is battle-tested. This feels risky to trust, even whenever they end up declaring it production-ready.
[+] [-] psanford|5 months ago|reply
> SSH3 is probably going to change its name. It is still the SSH Connection Protocol (RFC4254) running on top of HTTP/3 Extended connect, but the required changes are heavy and too distant from the philosophy of popular SSH implementations to be considered for integration. The specification draft has already been renamed ("Remote Terminals over HTTP/3"), but we need some time to come up with a nice permanent name.
[+] [-] zdw|5 months ago|reply
[+] [-] cozzyd|5 months ago|reply
[+] [-] theandrewbailey|5 months ago|reply
[+] [-] nine_k|5 months ago|reply
[+] [-] formerly_proven|5 months ago|reply
[+] [-] pdmccormick|5 months ago|reply
Why not just SSH/QUIC, what does the HTTP/3 layer add that QUIC doesn’t already have?
[+] [-] p1mrx|5 months ago|reply
[+] [-] noman-land|5 months ago|reply
[+] [-] thayne|5 months ago|reply
Or h3s for HTTP 3 Shell?
H3rs for http3 remote shell?
[+] [-] fsckboy|5 months ago|reply
ssh is not a shell and ssh is not a terminal, so please everybody stop suggesting name improvements that more deeply embed that confusion.
back in the day, we had actual terminals, and running inside was our shell which was sh. then there was also csh. then there was the idea of "remote" so rsh from your $SHELL would give you a remote $SHELL on another machine. rsh was not a shell, and it was not a terminal. There were a whole bunch of r- prefixed commands, it was a family, and nobody was confused, these tools were not the thing after the r-, these tools were just the r- part.
then it was realized that open protocols were too insecure so all of the r- remote tools became s- secure remote tools.
http is a network protocol that enables other things and gets updated from time to time, and it is not html or css, or javascript; so is ssh a network protocol, and as I said, not a shell and not a terminal.
just try to keep it in mind when thinking of new names for new variants.
and if somebody wants to reply that tcp/ip is actually the network protocol, that's great, more clarification is always good, just don't lose sight of the ball.
[+] [-] unclet|5 months ago|reply
[+] [-] 0x6c6f6c|5 months ago|reply
so, maybe SSHoQ or SoQ
soq reads better for the CLI I suppose.
[+] [-] manwe150|5 months ago|reply
[+] [-] NewJazz|5 months ago|reply
[+] [-] KronisLV|5 months ago|reply
That way, when you need to use sed for editing text containing it, your pattern can be more interesting:
[+] [-] CharlesW|5 months ago|reply
[+] [-] Arch-TK|5 months ago|reply
Be it PAM, or whatever OpenBSD is doing, the session setup kills performance, whether you're re-using the SSH connection or not, every time you start something within that connection.
Now obviously for long running stuff, that doesn't matter as much as the total overhead. But if you're doing long running ssh you're probably using SSH for its remote terminal purposes and you don't care if it takes 0.5 seconds or 1 second before you can do anything. And if you want file transfer, we already had a HTTP/3 version of that - it's called HTTP/3.
Ansible, for example, performs really poorly in my experience precisely because of this overhead.
Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.
[+] [-] staplung|5 months ago|reply
1: https://mosh.org/
[+] [-] miduil|5 months ago|reply
[+] [-] ahlCVA|5 months ago|reply
[+] [-] eqvinox|5 months ago|reply
[+] [-] 9dev|5 months ago|reply
So having the ease of mind that when I block someone in Entra ID, they will also be locked out of all servers immediately—that would be great actually.
> PAM TOTP (or even just password+OTP) into HTTP auth
But why would you? Before initiating a session, users will have to authorise to the IdP, which probably includes MFA or Passkeys anyway. No need for PAM anymore at all.
[+] [-] axiolite|5 months ago|reply
https://github.com/moul/quicssh
[+] [-] she46BiOmUerPVj|5 months ago|reply
[+] [-] projektfu|5 months ago|reply
"It is often the case that some SSH hosts can only be accessed through a gateway. SSH3 allows you to perform a Proxy Jump similarly to what is proposed by OpenSSH. You can connect from A to C using B as a gateway/proxy. B and C must both be running a valid SSH3 server. This works by establishing UDP port forwarding on B to forward QUIC packets from A to C. The connection from A to C is therefore fully end-to-end and B cannot decrypt or alter the SSH3 traffic between A and C."
More or less, maybe but not automatically like you suggest, I think. I don't see why you couldn't configure a generic proxy to set it up, though.
[+] [-] finaard|5 months ago|reply
Host *.internal.example.com
in the SSH client config would make everything in that domain hop over that hop server. It's one extra connection - but with everything correctly configured that should be barely noticeable. Auth is also proxied through.[+] [-] billfor|5 months ago|reply
[+] [-] vladdoster|5 months ago|reply
[+] [-] dev_l1x_be|5 months ago|reply
[+] [-] alsosprachben|5 months ago|reply
[+] [-] computersuck|5 months ago|reply
[+] [-] rootnod3|5 months ago|reply
But it's a good start. Props to exploring that kind of space that needs improvement but is difficult to get a foothold in.
[+] [-] ricardobeat|5 months ago|reply
That’s a shame. Lowered latency (and persistent sessions, so you don’t pay the connection cost each time) are the best things about Mosh (https://mosh.org/).
[+] [-] supjeff|5 months ago|reply
so, new undiscovered vulnerabilities
[+] [-] superkuh|5 months ago|reply
[+] [-] Avamander|5 months ago|reply
If it also solved connection multipath/migration and fixes for TCP-related blocking issues, that'd already be amazing.
[+] [-] ryangibb|5 months ago|reply