This thread is s classic example what we care about: names. Is there technical merit to do ssh over http3? Who caes? Who knows?
SSH3: Faster and rich secure shell using HTTP/3
121–130 of 276 posts
Re: SSH3: Faster and rich secure shell using HTTP/3
#122I don't know why it makes me a little sad that every application layer protocol is being absorbed into http.
quic is more layer 4 or close to tcp reimplementation.
Far from http layer 7.
Re: SSH3: Faster and rich secure shell using HTTP/3
#123I 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…
HTTPSSH. Why not just SSH/QUIC, what does the HTTP/3 layer add that QUIC doesn’t already have?
[deleted]
Re: SSH3: Faster and rich secure shell using HTTP/3
#124I 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…
SSH/HTTP/3
That way, when you need to use sed for editing text containing it, your pattern can be more interesting:
sed 's/SSH\/HTTP\/3/SSH over HTTP\/3/g'Re: SSH3: Faster and rich secure shell using HTTP/3
#125I 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 h…
I hate that web-enshittification of SSH is considered the solution to this problem, and many other modern application-level problems.
It's done because the web stack exists and is understood by the web/infrastructure folks, not because it represents any kind of local design optima in the non-web space.
Using the web stack draws in a huge number of dependencies on protocols and standards that are not just very complex, but far more complex than necessary for a non-web environment, because they were designed around the constraints and priorities of the web stack. Complicated, lax, text-based formats easily parsed by javascript and safe to encode in headers/json/query parameters/etc, but a pain to implement anywhere else.
Work-arounds (origin checks, CORS, etc) for the security issues inherent in untrusted browsers/javascript being able to make network connections/etc.
We'be been using kerberos and/or fetching SSH keys out of an LDAP directory to solve this problem for literal decades, and it worked fine, but if that won't cut it, solving the SSH certificate tooling problem would be a MUCH lighter-weight solution here than adopting OAuth and having to tie your ssh(1) client implementation to a goddamn web browser.
Re: SSH3: Faster and rich secure shell using HTTP/3
#126What is the usecase of using OAuth or "my github account" to login to a linux/unix machine?
Re: SSH3: Faster and rich secure shell using HTTP/3
#127> It also supports new authentication methods such as OAuth 2.0 and allows logging in to your servers using your Google/Microsoft/Github accounts.
Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.
Re: SSH3: Faster and rich secure shell using HTTP/3
#128What is the usecase of using OAuth or "my github account" to login to a linux/unix machine?
This is actually a common/desirable feature to permit a group of people to access an ephemeral machine (e.g. engineers accessing a k8s node, etc.). Authorizing "engineers" via OAuth is much more ergonomic and safe vs traditional unix auth which is designed more for non-transient or non-shared users.
Re: SSH3: Faster and rich secure shell using HTTP/3
#129> 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 p…
Head-of-line blocking is likely fully addressed by ssh3 where multiplexing several ports/connections over a single physical ssh3 connection should be faster.
Re: SSH3: Faster and rich secure shell using HTTP/3
#130An alternative way to hide your SSH server from portscanners is to put it inside a WireGuard VPN.