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.
SSH3: Faster and rich secure shell using HTTP/3
111–120 of 276 posts
Re: SSH3: Faster and rich secure shell using HTTP/3
#112Earlier quoted context omitted.
> use our single company identity we use for every single service for SSH as well How would that even work? Do you open your browser, log in, and then somehow transfer the session into your ssh client in a terminal? Does the browser assimilate the terminal? And let me remind you, HTTP authentication isn't a login form. It's the browser built-in "HTTP username + password" form and its cousins. We're talking HTTP 401.…
> Do you open your browser, log in, and then somehow transfer the session into your ssh client in a terminal? You start the ssh client in the terminal, it opens a browser to authenticate, and once you're logged in you go back to the terminal. The usual trick to exfiltrate the authentication token from the browser is that the ssh client runs an HTTP server on localhost to which you get redirected after authenticating.
That, or the SSH client opens a separate connection to the authorization server and polls for the session state until the user has completed the process; that would be the device code grant, which would solve this scenario just fine.
Re: SSH3: Faster and rich secure shell using HTTP/3
#113I 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?
The ability to use HTTP authentication methods, HTTP headers, etc?
Re: SSH3: Faster and rich secure shell using HTTP/3
#114I 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?
QuickShell - it should be called
Re: SSH3: Faster and rich secure shell using HTTP/3
#115I 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 :).
No... They're one rung up from evil and dumb doers.
Re: SSH3: Faster and rich secure shell using HTTP/3
#116Earlier quoted context omitted.
Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.
The huge downside of mosh is it handles its own rendering and destroys the scrollback buffer. (Yes I know I can add tmux for a middle ground.) But it's still irrelevant here; specifically called out in README: > The keystroke latency in a running session is unchanged.
"huge downside" (completely mitigated by using tmux)
The YouTube and social media eras made everyone so damn dramatic. :/
Mosh solves a problem. tmux provides a "solution" for some that resolves a design decision that can impact some user workflows.
I guess what I'm saying here, is it you NEED mosh, then running tmux is not even a hard ask.
Re: SSH3: Faster and rich secure shell using HTTP/3
#117The ssh3 name feels like cloutchasing
Re: SSH3: Faster and rich secure shell using HTTP/3
#118Earlier quoted context omitted.
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…
> use our single company identity we use for every single service for SSH as well How would that even work? Do you open your browser, log in, and then somehow transfer the session into your ssh client in a terminal? Does the browser assimilate the terminal? And let me remind you, HTTP authentication isn't a login form. It's the browser built-in "HTTP username + password" form and its cousins. We're talking HTTP 401.…
> How would that even work? Do you open your browser, log in, and then somehow transfer the session into your ssh client in a terminal? Does the browser assimilate the terminal?
That's pretty well covered in RFC8628 and doesn't even require a browser on the same device where the SSH client is running.
> And let me remind you, HTTP authentication isn't a login form. It's the browser built-in "HTTP username + password" form and its cousins. We're talking HTTP 401. The only places this is widely used is API bearer tokens and NTLM/Kerberos SSO.
That depends entirely on the implementation. It could also be a redirect response which the client chooses to delegate to the user's web browser for external authentication. It's just the protocol. How the client interprets responses is entirely up to the implementation.
> Unfortunately I need to pop your bubble, PAM also does session setup, you'd still need it.
I don't see why, really. It might just as well be an opaque part of a newer system to reconcile remote authorization with local identity, without any interaction with PAM itself necessary at all.
> And the other thing here is — you're solving your problem. Hard-relying on HTTP auth for this SSH successor needs to solve everyone's problem. And it's an incredibly bad fit for a whole bunch of things.
But isn't that the nice part about HTTP auth, that it's so extensible it can solve everyone's problems just fine? At least it does so on the web, daily, for billions of users.
Re: SSH3: Faster and rich secure shell using HTTP/3
#119I 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…
ussh (for udp)
Re: SSH3: Faster and rich secure shell using HTTP/3
#120Can it tunnel arbitrary TCP ports?