Does this still support standard SSH encryption and authentication (on both client and server)?
SSH3: Faster and rich secure shell using HTTP/3
41–50 of 276 posts
Re: SSH3: Faster and rich secure shell using HTTP/3
#42Earlier quoted context omitted.
SSH has low throughput on high latency links, but not because it uses TCP. It is because SSH hardcodes a too-small maximum window size in its protocol, in addition to the one of TCP. This SSH window size limit is per ssh "stream", so it could be overcome by many parallel streams, but most programs do not make use of that (scp, rsync, piping data through the ssh command), so they are much slower than plain TCP as meas…
Off the top of your head do you know of any file transfer tools that do utilize multiple streams?
I tend to use 'rclone', does SSH/more. The '--transfers' arg is useful for handling several files, lol. One, if I recall correctly, isn't parallelized.
Re: SSH3: Faster and rich secure shell using HTTP/3
#43I 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 H…
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)
Re: SSH3: Faster and rich secure shell using HTTP/3
#44So 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?
But that wasn't really a thing that was an issue with SSH. Host *.internal.example.com ProxyCommand ssh -q -W %h:%p hop.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.
I'm aware of proxy jump and other client side config but I'd rather that not every single client need to do this configuration.
Re: SSH3: Faster and rich secure shell using HTTP/3
#45I 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 H…
Don't use it! Create your own thing and name it however you want.
Non-doers are the bottom rung of the ladder, don't ever forget that :).
Re: SSH3: Faster and rich secure shell using HTTP/3
#46Does this still support standard SSH encryption and authentication (on both client and server)?
The proposed architecture uses TLS for encryption/secure channel but can use SSH connection establishment/authentication.
https://www.ietf.org/archive/id/draft-michel-ssh3-00.html
However, it can also use HTTP mechanisms for authentication/authorization.
Re: SSH3: Faster and rich secure shell using HTTP/3
#47I 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 H…
Maybe SSH/3 instead (SSH + HTTP/3)?
Re: SSH3: Faster and rich secure shell using HTTP/3
#48So 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?
But that wasn't really a thing that was an issue with SSH. Host *.internal.example.com ProxyCommand ssh -q -W %h:%p hop.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.
Is there a way to configure the jump (hop) server to reroute the request based on the value of %h and/or %p? Otherwise, it's going to be quite difficult to configure something like HTTP virtual hosts.
EDIT: Looking at the relevant RFC [1] and the OpenSSH sshd_config manual [2], it looks like the answer is that the protocol supports having the jump server decide what to do with the host/port information, but the OpenSSH server software doesn't present any relevant configuration knobs.
[1]: https://www.rfc-editor.org/rfc/rfc4254.html#section-7.2
[2]: https://man7.org/linux/man-pages/man5/sshd_config.5.html
Re: SSH3: Faster and rich secure shell using HTTP/3
#49So 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?
"Proxy jump
"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.
Re: SSH3: Faster and rich secure shell using HTTP/3
#50I 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 H…
Maybe SSH/3 instead ( SSH + HTTP /3 )?
I like this idea!
Having SSH in the name helps developers quickly understand the problem domain it improves upon.