4 ms·

> 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

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

Denvercoder9 1y ago
> 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.
- 9dev 1y ago
  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.
  - eqvinox 1y ago
    You're both talking about web authentication, not HTTP authentication. cf. https://news.ycombinator.com/item?id=45399594 https://news.ycombinator.com/item?id=45399594
    - Denvercoder9 1y ago
      Only to obtain the token, the actual connection itself uses HTTP authentication (Bearer scheme).
9dev 1y ago
> 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.
- eqvinox 1y ago
  Everything you've said is true for web authentication, and almost nothing of what you said is true for HTTP authentication. This is HTTP authentication: https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html https://github.com/francoismichel/ssh3/blob/5b4b242db02a5cfbb9ebf9dfc5aad2c32e10f245/server_auth/auth.go#L96 https://github.com/francoismichel/ssh3/blob/5b4b242db02a5cfb... https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml https://www.iana.org/assignments/http-authschemes/http-auths... Note the OAuth listed there is OAuth 1.0. Support for "native" HTTP authentication was removed in OAuth 2.0. This discussion is about using HTTP authentication. I specifically said HTTP authentication in the root post. If you want to do SSH + web authentication, that's a different thread. Rule of thumb: if you need HTML in any step of it —and that includes as part of generating a token— it's web auth, not HTTP.

Denvercoder9 1y ago

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

9dev 1y ago
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.
- eqvinox 1y ago
  You're both talking about web authentication, not HTTP authentication. cf. https://news.ycombinator.com/item?id=45399594 https://news.ycombinator.com/item?id=45399594
  - Denvercoder9 1y ago
    Only to obtain the token, the actual connection itself uses HTTP authentication (Bearer scheme).

9dev 1y ago

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

eqvinox 1y ago
Everything you've said is true for web authentication, and almost nothing of what you said is true for HTTP authentication. This is HTTP authentication: https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html https://github.com/francoismichel/ssh3/blob/5b4b242db02a5cfbb9ebf9dfc5aad2c32e10f245/server_auth/auth.go#L96 https://github.com/francoismichel/ssh3/blob/5b4b242db02a5cfb... https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml https://www.iana.org/assignments/http-authschemes/http-auths... Note the OAuth listed there is OAuth 1.0. Support for "native" HTTP authentication was removed in OAuth 2.0. This discussion is about using HTTP authentication. I specifically said HTTP authentication in the root post. If you want to do SSH + web authentication, that's a different thread. Rule of thumb: if you need HTML in any step of it —and that includes as part of generating a token— it's web auth, not HTTP.