Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH3: Faster and rich secure shell using HTTP/3

github.com

Post reply on HN
Print view View original

91–100 of 276 posts

Re: SSH3: Faster and rich secure shell using HTTP/3

#91

Post by Too »

ur-whale wrote: post #54

Knee-jerk reaction: if it aint broke ...

I thought the same until I read the page and realized that ssh is quite broken if you think about it.

With ssh everybody does TOFU or copies host fingerprints around, vs https where setting up letsencrypt is a no-brainer and you’re a weirdo of you even think about self-signed certs. Now you can do the same with ssh but do you?

For authentication, ssh relies on long lived keys rather than short lived tokens. Yes, I know about ssh certificates but again, it’s a hassle to set up compared to using any of a million IdP with oauth2 support. This enables central place to manage access and mandate MFA.

Finally, you better hope your corporate IT has not blocked the SSH port as a a security threat.

Re: SSH3: Faster and rich secure shell using HTTP/3

#92

Post by thayne »

conradludgate wrote: post #28
xg15 wrote: post #12

Earlier quoted context omitted.

Yeah, building it on top of QUIC is reasonable, but trying to shoehorn SSH into HTTP semantics feels silly.

It's on top of HTTP CONNECT, which is intended for converting an existing request (QUIC stream) into a transparent byte stream. This removes the need to deal with request/response semantics. The reasons states to use http3 and not QUIC directly makes sense with littlest downside - you can run it behind any standard http3 reverse proxy, under some subdomain or path of your choosing, without standing out to port scanne…

> you can run it behind any standard http3 reverse proxy

As long as said proxy supports a http CONNECT to a bi-directional connection. Which most I know of do, but may require additional configuration.

Another advantage of using http/3 is it makes it easier to authenticate using something like oauth 2, oidc, saml, etc. since it can use the normal http flow instead of needing to copy a token from the http flow to a different flow.

Re: SSH3: Faster and rich secure shell using HTTP/3

#93

Post by ape4 »

thayne wrote: post #79
psanford wrote: post #19

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…

qrs for Quic Remote Shell? Or h3s for HTTP 3 Shell? H3rs for http3 remote shell?

How about Tortoise Shell - a little joke because its so fast

Re: SSH3: Faster and rich secure shell using HTTP/3

#94

Post by kelnos »

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

Re: SSH3: Faster and rich secure shell using HTTP/3

#95

Post by mnsc »

CharlesW wrote: post #71
psanford wrote: post #19

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…

h3sh | hush3 | qs | qsh | shh | shh3

SSQ

Re: SSH3: Faster and rich secure shell using HTTP/3

#96

Post by staplung »

It's cool that SSH is getting some love but I'm a little sad they're not being a little more ambitious with regard to new features, considering it seems like they're more or less creating a new thing. Looks like they're going to support connection migration but it would be cool (to me anyway) if they supported some of the roaming/intermittent connectivity of Mosh[1].

1: https://mosh.org/

Re: SSH3: Faster and rich secure shell using HTTP/3

#97

Post by eqvinox »

9dev wrote: post #67
eqvinox wrote: post #66

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

Re: SSH3: Faster and rich secure shell using HTTP/3

#98

Post by BrightOne »

throwaway127482 wrote: post #70
zaik wrote: post #62

Earlier quoted context omitted.

HTTPSS for more confusion

SecureHyperTextShell (SHTS) I meant this in jest but now that I think about it, it actually could be a decent name (?)

I think it's too similar to HSTS: https://en.m.wikipedia.org/wiki/HTTP_Strict_Transport_Securi...

Re: SSH3: Faster and rich secure shell using HTTP/3

#100

Post by eqvinox »

axiolite wrote: post #87
eqvinox wrote: post #66

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…

That has been around for years: https://github.com/moul/quicssh

I guess it didn't get traction… whether that happens honestly feels like a fickle, random thing.

To be fair, a go project as sole implementation (I assume it is that?) is a no-go, for example we couldn't even deploy it on all our systems since last I checked Go doesn't support ppc64. (BE, not ppc64le)

I also don't see a protocol specification in there.

[edit] actually, no, this is not SSH over QUIC. This is SSH over single bidi stream transport over QUIC, it's just a ProxyCommand. That's not how SSH over QUIC should behave, it needs to be natively QUIC so it can take advantage of the multi-stream features. And the built-in TLS.

Post reply on HN