271–276 of 276 posts
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 H…
Earlier quoted context omitted.
If you're doing repeated connections to the same host to run one-off commands, SSH multiplexing would be helpful for you. SSH in and it'll open up a local unix domain socket. Point additional client connections to the UDS and they'll just go over the existing connection with out requiring round trips or remote authentication. The socket can be configured to keep itself alive for a while and then close after inactivit…
Why isn't this the default behavior to use this UDS? How to enable this?
SSH Communications Security, Inc. owns the trademark to SSH and so this rebranding/coopting may implode suddenly with a C & D. https://uspto.report/TM/76431998
I don't know why it makes me a little sad that every application layer protocol is being absorbed into http.
kind of like if a random person created an (unaffiliated) hacker news 2.0 website.
Earlier quoted context omitted.
> I think it's silly that this exists. They should just let TCP handle this. No, unfortunately it'snecessary so that the SSH proocol can multiplex streams independently over a single established connection. If one of the multiplexed streams stalls because its receiver is blocked or slow, and the receive buffer (for that stream) fills up, then without window-based flow control, that causes head-of-line blocking of all…
Then: * Give users a config options so I can adjust it to my use case, like I can for TCP. Don't just hardcode some 2 MB (which was even raised to this in the past, showing how futile it is to hardcode it because it clearly needs adjustments to people's networks and and ever-increasing speeds). It is extremely silly that within my own networks, controlling both endpoints, I cannot achieve TCP speeds over SSH, but I c…
Or, better but more difficult, it should track the dynamic TCP window size, from the OS when possible, combined with end-to-end measurements, and ensure the SSH mux channel windows grow to accomodate the TCP window, without growing so much they starve other channels.
To your second point, you can't do data dropping and retransmission for mux'd channels over a single TCP connection. After data is sent from the application to the kernel socket, it can't be removed from the TCP transmission queue, will be retransmitted by the kernel socket as often as needed, and will reach the destination eventually, provided the TCP connection as a whole survives.
You can do mux'd data dropping and retransmission over a single UDP connection, but that's basically what QUIC is.
Earlier quoted context omitted.
UDP tunnels are the main feature, way lighter than wireguard, also OpenID auth.
Wireguard (and certainly every VPN protocol worth your attention) runs on UDP. TCP-over-TCP is a disaster, no sane person does that. And what's "lighter" than Wireguard? It's about as simple as it can get (certainly simpler than QUIC).