SSH3: Faster and rich secure shell using HTTP/3

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.

> 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. The only places this is widely used is API bearer tokens and NTLM/Kerberos SSO.

> 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.

Unfortunately I need to pop your bubble, PAM also does session setup, you'd still need it. 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.

Coincidentally, SSH's mechanisms are also an incredibly bad fit; password authentication is in there as a "hard" feature; it's not an interactive dialog and you can't do password+TOTP there either. For that you need keyboard-interactive auth, which I'm not sure but feels like it was bolted on afterwards to fix this. Going with HTTP auth would probably repeat history quite exactly here, with at some point something else getting bolted to the side…

> 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.