[HN Gopher] SSH3: Faster and rich secure shell using HTTP/3
___________________________________________________________________
SSH3: Faster and rich secure shell using HTTP/3
Author : tempaccount420
Score : 288 points
Date : 2025-09-27 14:27 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Zambyte wrote:
| I was skeptical of the claim that it's faster than traditional
| SSH, but the README specifies that it is faster at establishing a
| connection, and that active connections are the same speed. That
| makes a lot of sense and seems like a reasonable claim to make.
| wolrah wrote:
| It also tracks with HTTP/3 and QUIC as a whole, as one of the
| main "selling points" has always been reduced round trips
| leading to faster connection setup.
| notepad0x90 wrote:
| Although, dollars-to-donuts my bet is that this tool/protocol
| is much faster than SSH over high-latency links, simply by
| virtue of using UDP. Not waiting for ack's before sending more
| data might be a significant boost for things like scp'ing large
| files from part of the world to the another.
| xorcist wrote:
| Of course it has ACKs. There are protocols without ACKs but
| they are exotic and HTTP3 is not one of them.
| IshKebab wrote:
| He said not _waiting_ for ACKs.
| xorcist wrote:
| That makes even less sense, unless we are talking about
| XMODEM every protocol uses windowing to avoid getting
| stuck waiting for ACKs.
|
| Of course you need to wait for ACKs at _some_ point
| though, otherwise they would be useless. That 's how we
| detect, and potentially recover from, broken links. They
| are a _feature_. And HTTP3 has that feature.
|
| Is it better implemented than the various TCP algorithms
| we use underneath regular SSH? Perhaps. That remains to
| be seen. The use case of SSH (long lived connections with
| shorter lived channels) is vastly different from the
| short lived bursts of many connections that QUIC was
| intented for. My best guess is that it could go both
| ways, depending on the actual implementation. The devil
| is in the details, and there are many details here.
|
| Should you find yourself limited by the default buffering
| of SSH (10+Gbit intercontinental links), that's called
| "long fat links" in network lingo, and is not what TCP
| was built for. Look at pages like this Linux Tuning for
| High Latency networks: https://fasterdata.es.net/host-
| tuning/linux/
|
| There is also the HPN-SSH project which increases the
| buffers of SSH even more than what is standard. It is
| seldom needed anymore since both Linux and OpenSSH has
| improved, but can still be useful.
| IOT_Apprentice wrote:
| Well, you could peruse the code. Then see what it does
| and explain it.
| finaard wrote:
| Not really that relevant - anybody regularly using SSH over
| high latency links is using SSH+mosh already anyway.
| oefrha wrote:
| 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.
| esseph wrote:
| "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.
| nh2 wrote:
| SSH has low throughput on high latency links, but not because
| it uses TCP. It is because SSH hardcodes a too-small maximum
| window size in its protocol, in addition to the one of TCP.
|
| This SSH window size limit is per ssh "stream", so it could
| be overcome by many parallel streams, but most programs do
| not make use of that (scp, rsync, piping data through the ssh
| command), so they are much slower than plain TCP as measured
| eg by iperf3.
|
| I think it's silly that this exists. They should just let TCP
| handle this.
| fanf2 wrote:
| Yeah, the longstanding hpn-ssh fork started off by
| adjusting ssh's window sizes for long fat pipes.
|
| https://github.com/rapier1/hpn-ssh
| Operyl wrote:
| Off the top of your head do you know of any file transfer
| tools that do utilize multiple streams?
| bravetraveler wrote:
| I tend to use _' rclone'_, does SSH/more. The _'
| --transfers'_ arg is useful for handling several files,
| lol. One, if I recall correctly, isn't parallelized.
| fanf2 wrote:
| Yeah, there's a replacement for scp that uses ssh for setup
| and QUIC for bulk data transfer, which is much faster over
| high-latency paths.
|
| https://github.com/crazyscot/qcp
| bcrl wrote:
| That's why mosh exists, as it is purpose built for terminals
| over high latency / high packet loss links.
| s-macke wrote:
| It is not faster in this sense. However, an SSH connection can
| have multiple substreams, especially for port forwarding. Over
| a single classical connection, this can lead to head-of-line
| blocking, where an issue in one stream slows everything down.
| QUIC/HTTP3 protocol can solve this.
| thayne wrote:
| Does this implementation do that do, or does it just use a
| single h3 stream?
| s-macke wrote:
| The answer is yes according to code and documentation [0]:
|
| > The stream multiplexing capabilities of QUIC allow
| reducing the head-of-line blocking that SSHv2 encounters
| when multiplexing several SSH channels over the same TCP
| connection
|
| ....
|
| > Each channel runs over a bidirectional HTTP/3 stream and
| is attached to a single remote terminal session
|
| [0] https://www.ietf.org/archive/id/draft-michel-remote-
| terminal...
| ahlCVA wrote:
| Previously: https://news.ycombinator.com/item?id=38664729
| temp0826 wrote:
| I don't know why it makes me a little sad that every application
| layer protocol is being absorbed into http.
| chrisfosterelli wrote:
| It feels a little like a kludge as long as we keep calling it
| http. The premise makes sense -- best practices for connection
| initialization have become very complex and a lot of protocols
| need the same building blocks, so its beneficial to piggyback
| on the approach taken by one of the most battle tested
| protocols -- but it's not really hypertext we're using it to
| transfer anymore so it feels funny.
| xg15 wrote:
| Yeah, building it on top of QUIC is reasonable, but trying to
| shoehorn SSH into HTTP semantics feels silly.
| conradludgate wrote:
| 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 scanners.
| While security through obscurity is not security, there's
| no doubt that it reduces the CPU overhead that many
| scanners might incur if they discover your SSH server and
| try a bunch of login attempts.
|
| Running over HTTP3 has an additional benefit. It becomes
| harder to block. If your ssh traffic just looks like you're
| on some website with lots of network traffic, eg google
| meet, then it becomes a lot harder to block it without
| blocking all web traffic over http3. Even if you do that,
| you could likely still get a working but suboptimal
| emulation over http1 CONNECT
| MrDarcy wrote:
| Google Cloud's identity aware proxy underpinning the
| gcloud compute ssh command works the same way, as an http
| CONNECT upgrade.
| thayne wrote:
| > 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.
| xg15 wrote:
| If this were really the case, it would indeed be sad, as the
| standard HTTP request/response model is both too restrictive
| and too overengineered for many usecases.
|
| But both HTTP/2 and QUIC (the "transport layer" of HTTP/3) are
| so general-purpose that I'm not sure the HTTP part really has a
| lot of meaning anymore. At least QUIC is relatively openly
| promoted as an alternative to TCP, with HTTP its primary
| usecase.
| singpolyma3 wrote:
| Indeed. "Using quic with a handshake that smells like http3"
| is hardly "using http" imo
| fulafel wrote:
| Is there some indication that this is going to be adopted? The
| linked ietf submission is an expired individual draft (which
| anyone can send in) and not from the ssh spec working group,
| sounds like this is from some reseachers that used SSH3 as an
| optimistic name.
| MrDarcy wrote:
| It's a necessary evil resulting from misguided corporate
| security teams blocking and intercepting everything else.
|
| Looking at you, teams who run Zscaler with tls man in the
| middle attack mode enabled.
| zenmac wrote:
| Yeah we got those good old network ppl or their corporate
| (don't knows much about tech) overlord to thank for that.
|
| If you ever using wifi in the airport or even some hotel with
| work suite unit around the world, you will notice that Apple
| Mail can't send or receive emails. It is probably some company
| wide policy to first block port 25 (that is even the case with
| some hosting providers) all in the name of fighting SPAM.
| Pretty soon, 143, 587, 993, 995.... are all blocked. Guess 80
| and 443 are the only ones that can go through any firewalls now
| days. It is a shame really. Hopefully v6 will do better.
|
| So there you go. And know EU wants to do ChatControl!!!! Please
| stop this none-sense, listen to the people who actually knows
| tech.
| Telemakhos wrote:
| Port 25 is insecure and unencrypted; EU doesn't even need
| ChatControl to hoover up that data, and you'd better believe
| anything going through an airport wifi router unencrypted is
| being hoovered by someone no matter what jurisdiction you're
| in. Apple mail prefers 587 for secure SMTP and 993 for secure
| IMAP.
|
| People were (wisely) blocking port 25 twenty years ago.
| zenmac wrote:
| Ah thanks for the correction. Just changed my post above to
| 587. What I mean is why block all the ports, just keep it
| open let the user decide if they want to use it. And linux
| people can always use ufw on their side to be safe. Back in
| the dot com days, there were people also using telnet, but
| that got changed to ssh.
|
| Is it because it is hard to detect what type of the request
| that is being sent? Stream vs Non Stream etc?
| Fnoord wrote:
| > People were (wisely) blocking port 25 twenty years ago.
|
| 20 years ago (2005) STARTTLS was still widely in use.
| Clients can be configured to call it when STARTTLS isn't
| available. But clients can also be served bogus or snake
| oil TLS certs. Certificate pinning wasn't widely in use for
| SMTP in 2005.
|
| Seems STARTTLS is deprecated since 2018 [1]
|
| Quote: For email in particular, in January 2018 RFC 8314
| was released, which explicitly recommends that "Implicit
| TLS" be used in preference to the STARTTLS mechanism for
| IMAP, POP3, and SMTP submissions.
|
| [1] https://serverfault.com/questions/523804/is-starttls-
| less-sa...
| oofbey wrote:
| I hear you that it feels like something is off. The lack of
| diversity feels like we're losing robustness in the ecosystem.
| But it can be a good thing too. A lot of security issues are
| concentrated into one stack that is very well maintained. So
| that means everything built on top of it shares the same attack
| surface. Which yes means it can all come crashing down at once,
| but also that there are many eyes looking for vulnerabilities
| and they'll get fixed quickly. Similarly perf optimizations are
| all shared, and when thing get this popular can get pushed down
| into hardware even.
|
| It's not like we see a lot of downsides that the world
| collectively agreed on TCP/IP over IPX/SPX or DECNet or X.25.
| Or that the linux kernel is everywhere.
| temp0826 wrote:
| Humbug. I feel an urge to implement token ring over fiber.
| Excuse me while I yell at clouds.
| attentive wrote:
| quic is more layer 4 or close to tcp reimplementation. Far from
| http layer 7.
| AshamedCaptain wrote:
| Sure, someone paranoid about his SSH server being continuously
| proved by bots is going to excitedly jump to a new HTTP-SSH
| server that is going to be continuously proved by even more bots
| for HTTP exploits (easily an order of magnitude more traffic) AND
| whatever new fangled "HTTP-SSH" exploits appear.
| she46BiOmUerPVj wrote:
| So with HTTP requests you can see the domain name in the header
| and forward it to the correct host. That was never a thing you
| could do with SSH, does this allow that to work?
| billfor wrote:
| You can forward any ssh traffic based on the domain name with
| SNI redirection. You can also use that with, lets say the nginx
| stream module, to run ssh and http server on the same port.
| finaard wrote:
| But that wasn't really a thing that was an issue with SSH.
|
| Host *.internal.example.com ProxyCommand ssh -q
| -W %h:%p hop.internal.example.com
|
| in the SSH client config would make everything in that domain
| hop over that hop server. It's one extra connection - but with
| everything correctly configured that should be barely
| noticeable. Auth is also proxied through.
| doubled112 wrote:
| If you don't need to do anything complicated, ProxyJump is
| easier to remember. Host
| *.internal.example.com ProxyJump
| hop.internal.example.com
| chupasaurus wrote:
| ProxyJump was implemented a decade ago to replace that
| specific string.
| unsnap_biceps wrote:
| Newer versions of ssh support ProxyJump ssh
| -J hop.internal.example.com foo.internal.example.com
| she46BiOmUerPVj wrote:
| I'm aware of proxy jump and other client side config but I'd
| rather that not every single client need to do this
| configuration.
| kbolino wrote:
| Is there a way to configure the jump (hop) server to reroute
| the request based on the value of %h and/or %p? Otherwise,
| it's going to be quite difficult to configure something like
| HTTP virtual hosts.
|
| EDIT: Looking at the relevant RFC [1] and the OpenSSH
| sshd_config manual [2], it looks like the answer is that the
| _protocol_ supports having the jump server decide what to do
| with the host /port information, but the OpenSSH server
| _software_ doesn 't present any relevant configuration knobs.
|
| [1]: https://www.rfc-editor.org/rfc/rfc4254.html#section-7.2
|
| [2]: https://man7.org/linux/man-pages/man5/sshd_config.5.html
| t-3 wrote:
| Yes, but it's not in the sshd config, it's in the ssh
| config. See ssh_config(5), search for Remote to find the
| most relevant sections.
| projektfu wrote:
| "Proxy jump
|
| "It is often the case that some SSH hosts can only be accessed
| through a gateway. SSH3 allows you to perform a Proxy Jump
| similarly to what is proposed by OpenSSH. You can connect from
| A to C using B as a gateway/proxy. B and C must both be running
| a valid SSH3 server. This works by establishing UDP port
| forwarding on B to forward QUIC packets from A to C. The
| connection from A to C is therefore fully end-to-end and B
| cannot decrypt or alter the SSH3 traffic between A and C."
|
| More or less, maybe but not automatically like you suggest, I
| think. I don't see why you couldn't configure a generic proxy
| to set it up, though.
| miduil wrote:
| I wonder what the current plans are with the project, it's been
| over a year since the last release - yet alone commits or other
| activity on GitHub. As they've started working on the project
| with a paper - I guess they'll might be continuously working on
| other associated aspects?
| jhatemyjob wrote:
| Thanks for pointing that out. I'm gonna assume it's a dead
| project. It has only 239 commits, basically a proof of concept.
| Nothing to take seriously. OpenBSD on the other hand is
| extremely active, there's no way OpenSSH will be dethroned
| anytime soon.
|
| https://github.com/openbsd/src/commits/master/
| psanford wrote:
| 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 HTTP/3"), but we need some time to come
| up with a nice permanent name.
| zdw wrote:
| Same - this feels equivalent of some rando making a repo called
| "Windows 12" or "Linux 7".
| bravetraveler wrote:
| LDAP2 or nextVFS... but point awarded. _Feels_ that way
| because it _is_. Though my examples aren 't great. These
| things just _are_ ; not really versioned. I don't know if
| major differences would call for ++
|
| A better _' working name'_ would be something like sshttp3,
| lol. Obviously not the successor to SSH2
| asveikau wrote:
| You mean like cryptocurrency bros naming something "web 3.0"?
| teddyh wrote:
| C.f. "JSON5".
| formerly_proven wrote:
| Easy: hhs instead of ssh (since the even more obvious shh is
| essentially impossible to google). Stands for, idk, HTTP/3
| Hardened Shell or something ("host shell"? sounds like windows)
| catlifeonmars wrote:
| hss? Http/3 Secure Shell?
| moralestapia wrote:
| 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 :).
| literalAardvark wrote:
| No... They're one rung up from evil and dumb doers.
| theandrewbailey wrote:
| Maybe SSH/3 instead ( _SSH_ + HTTP _/ 3_)?
| techscruggs wrote:
| I like this idea!
|
| Having SSH in the name helps developers quickly understand
| the problem domain it improves upon.
| throwaway127482 wrote:
| Doesn't /3 mean v3? I mean, for HTTP itself, doesn't the
| HTTP/3 == HTTPv3? If so, I don't see how this is any better
| than SSH3 - both SSH3 and SSH/3 read to me like "SSH v3"
| theandrewbailey wrote:
| Yes, but HTTP is about the only thing that versions with a
| slash. By writing it SSH/3, it would emphasize its
| relationship with HTTP/3, instead of it being the third
| version of SSH.
| guerrilla wrote:
| Yeah, that's not cool.
| noman-land wrote:
| SSHTTP
| zaik wrote:
| HTTPSS for more confusion
| throwaway127482 wrote:
| SecureHyperTextShell (SHTS)
|
| I meant this in jest but now that I think about it, it
| actually could be a decent name (?)
| BrightOne wrote:
| I think it's too similar to HSTS: https://en.m.wikipedia.
| org/wiki/HTTP_Strict_Transport_Securi...
| speed_spread wrote:
| QUICSH/T
| irq-1 wrote:
| Hyper Secure Shell (HSS)
| oofbey wrote:
| SSHTTP3
| IgorPartola wrote:
| Secure Shell Hyper Text Transfer Protocol Version 3. Yikes.
| em-bee wrote:
| remove the hyper text:
|
| SSHTP/3 "Secure Shell Transfer Protocol Version 3"
|
| or even:
|
| SSHP/3 "Secure Shell Protocol Version 3"
|
| pronounced: shoop
| ok123456 wrote:
| SSH over 3: SO(3). Like the rotation group.
| p1mrx wrote:
| SSHoH
| Titan2189 wrote:
| SSHoH3
|
| Pronounced "Shoe"
| CharlesW wrote:
| h3sh | hush3 | qs | qsh | shh | shh3
| mnsc wrote:
| SSQ
| NewJazz wrote:
| Anything with a 3 in it is a nightmare to type quickly. shh
| looks like you typo'd ssh.
|
| qsh might be taken by QShell
|
| https://en.m.wikipedia.org/wiki/Qshell
|
| There's a whole github issue where the issue was bike shed to
| death.
| diego_sandoval wrote:
| SSHoHTTP3
| thayne wrote:
| qrs for Quic Remote Shell?
|
| Or h3s for HTTP 3 Shell?
|
| H3rs for http3 remote shell?
| ape4 wrote:
| How about Tortoise Shell - a little joke because its so fast
| piannucci wrote:
| How about rthym or some variation?
| NewJazz wrote:
| https://github.com/francoismichel/ssh3/issues/79#issuecommen...
| pdmccormick wrote:
| HTTPSSH.
|
| Why not just SSH/QUIC, what does the HTTP/3 layer add that QUIC
| doesn't already have?
| gclawes wrote:
| The ability to use HTTP authentication methods, HTTP headers,
| etc?
| arka2147483647 wrote:
| QuickShell - it should be called
| jacooper wrote:
| Quicshell*
| bscphil wrote:
| QSH?
| cpuguy83 wrote:
| That's already a project (library for building a desktop
| environment).
| attentive wrote:
| ussh (for udp)
| KronisLV wrote:
| 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'
| Wicher wrote:
| try: sed 's:SSH/HTTP/3:SSH over HTTP/3:g'
|
| At least with GNU sed, you can use different separators so
| dodge the need for exscaping. | works as well.
| 0x6c6f6c wrote:
| SSH over QUIC
|
| so, maybe SSHoQ or SoQ
|
| soq reads better for the CLI I suppose.
| antod wrote:
| HTTP under SSH, or hussh for short.
| paulryanrogers wrote:
| HTTP3 Shell or H3S
| unclet wrote:
| Why not HSH, or HTTPS Shell.
| Velocifyer wrote:
| Does this still support standard SSH encryption and
| authentication (on both client and server)?
| projektfu wrote:
| The proposed architecture uses TLS for encryption/secure
| channel but can use SSH connection
| establishment/authentication.
|
| https://www.ietf.org/archive/id/draft-michel-ssh3-00.html
|
| However, it can also use HTTP mechanisms for
| authentication/authorization.
| ur-whale wrote:
| Knee-jerk reaction: if it aint broke ...
| axiolite wrote:
| Telnet, FTP and rlogin wasn't broke, either. They had their own
| encrypted variants before SSH came along.
|
| Listing all the deficiencies of something, and putting together
| a thing that fixes all of them, is the kind of "designed by
| committee" project that everyone hates. Real progress requires
| someone to put together a quick project, with new features they
| think are useful, and letting the public decide if it is useful
| or not.
| Too wrote:
| 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.
| Imustaskforhelp wrote:
| Yes, Yes, Yes.
|
| Firstly, I love the satirical name of tempaccount420, I was also
| just watching memes and this post is literally me (ryan gosling)
|
| As I was also thinking about this thing literally yesterday being
| a bit delusional on hoping to create a better ssh using http/3 or
| something or some minor improvement because I made a comment
| about tor routing and linking it to things like serveo, I was
| thinking of enhancing that idea or something lol.
|
| Actually, it seems that I have already starred this project but I
| had forgotten about it, this is primarily the reason why I star
| github project and this might be where I might have got some
| inspiration of http/3 in the first place with SSH.
|
| Seems like a really great project (I think)
|
| Now, one question that I have is could SSH be made modular in the
| sense that we can split the transport layer apart from SSH as
| this project does, without too much worries?
|
| Like, I want to create a SSH-ish something to lets say something
| like iroh being the transport layer, are there any libraries or
| resources which can do something like that? (I won't do it for
| iroh but I always like mixing and matching and I am thinking of
| some different ideas like SSH over matrix/xmpp/signal too/ the
| possibilities could be limitless!)
| nick_travels wrote:
| built in OIDC authentication - YES, love it!
| pvsnp wrote:
| Shouldn't this be called SSH over HTTP/3?
| eqvinox wrote:
| 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...
| 9dev wrote:
| 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.
| eqvinox wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| You're both talking about web authentication, not HTTP
| authentication. cf.
| https://news.ycombinator.com/item?id=45399594
| 9dev wrote:
| > 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 wrote:
| 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://github.com/francoismichel/ssh3/blob/5b4b242db02a5
| cfb...
|
| 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.
| frumplestlatz wrote:
| 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.
| 9dev wrote:
| I see your point, but I think you're missing the broader
| picture here. Web protocols are not just used because they
| are there, but because the stack is very elegantly layered
| and extensible, well understood and tested, and offer
| strong security guarantees. It's not like encryption hasn't
| been tacked onto HTTP retroactively, but at least that
| happened using proper staples instead of a bunch of duct
| tape and hope as with other protocols.
|
| All of that isn't really important, though. What makes a
| major point for using HTTP w/ TLS as a transport layer is
| the ecosystem and tooling around it. You'll get
| authorization protocols like OIDC, client certificate
| authentication, connection resumption and migration,
| caching, metadata fields, and much more, out of the box.
| eqvinox wrote:
| > the stack is very elegantly layered and extensible
|
| I have to disagree pretty strongly on this one. Case in
| point: WebSockets. That protocol switch is "nifty" but
| breaks fundamental assumptions about HTTP and to this day
| causes headaches in some types of server deployments.
| axiolite wrote:
| That has been around for years:
|
| https://github.com/moul/quicssh
| eqvinox wrote:
| 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.
| nwmcsween wrote:
| I recently looked into this at it looks like the IETF(?) RFC
| draft for SSH3 was abandoned? It's great this exists but I think
| the standard needs to be done as well.
| bullen wrote:
| YAMP
| Fnoord wrote:
| Written in Go. Terrible name, already discussed in various other
| comments and author acknowledges.
|
| The secret path, otherwise giving 404 would need brute-force
| protection (on HTTPd level?). I think it is easier to run SSH on
| a non-standard port on IPv6, but it remains true that anyone with
| network read access between the endpoints can figure it out.
|
| What isn't explained is why would one care about 100 ms latency
| during auth? I rather have mosh which has resuming support and
| will work on high latency (tho IIRC won't work over TOR?). But
| even then, with LTE and NG, my connections over mobile have
| become very stable here in NL (YMMV).
| fsiefken wrote:
| yes, but in NL sometimes I am just on the edge of a wifi
| network coverage and then mosh can be handy. it's an edge case
| though!
| odie5533 wrote:
| Faster SSH in Rust when?
| rootnod3 wrote:
| Don't get me wrong, this might likely be a fantastic tool. But
| something as essential as a secure connection would definitely
| need a good pair of eyes for audit before I'd use that for
| anything in production.
|
| But it's a good start. Props to exploring that kind of space that
| needs improvement but is difficult to get a foothold in.
| kelnos wrote:
| > _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.
| thethimble wrote:
| Head-of-line blocking is likely fully addressed by ssh3 where
| multiplexing several ports/connections over a single physical
| ssh3 connection should be faster.
| john01dav wrote:
| Calling anything here "physical" is strange and confusing to
| me. Surely you don't mean the physical layer?
| athrowaway3z wrote:
| If you are looking for a smoother UX: https://mosh.org/
| gdevenyi wrote:
| Sadly this project looks dead.
| fsiefken wrote:
| still works great though, there's a lot great software I
| use that hasn't had an update in years or even decades
| Levitating wrote:
| > Connection setup time has never been an annoyance for me.
|
| It has always bothered me somewhat. I sometimes use ssh to
| directly execute a command on a remote host.
| E39M5S62 wrote:
| If you're doing repeated connections to the same host to run
| one-off commands, SSH multiplexing would be helpful for you.
| SSH in and it'll open up a local unix domain socket. Point
| additional client connections to the UDS and they'll just go
| over the existing connection with out requiring round trips
| or remote authentication. The socket can be configured to
| keep itself alive for a while and then close after
| inactivity. Huge huge speed boost over repeated fresh TCP
| connections.
| pancsta wrote:
| UDP tunnels are the main feature, way lighter than wireguard,
| also OpenID auth.
| staplung wrote:
| 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/
| eqvinox wrote:
| AIUI connection migration (as well as multipath handling) is a
| QUIC feature. And how would that roaming feature differ from
| "built-in tmux"? I'm not sure the built-in part there would
| really be an advantage...
| namibj wrote:
| Mosh connections don't drop from merely wifi flipping around;
| you get replies back to the address and port the last uplink
| packet came from. You can just continue typing and a switch
| between Wi-Fi and mobile data (for example on a phone while
| sitting on public transit) shows as merely a lag spike during
| which typed characters will be predictive echoed by
| underlining them after an initial delay that serves to avoid
| flickering from rapidly retracted/changed predictions
| (predictions are underlined) during low-latency steady-state.
|
| Mosh is like vnc or rdp for terminal contents: natively
| variable frame rate and somewhat adaptive predictive local
| echo for reducing latency perception; think client side
| cursor handling with vnc or with rdp I'd even assume there
| might be capability for client-side text echo rendering.
|
| If you haven't tried mosh in situations with a mobile device
| that have you experience connection changes during usage, you
| don't know just how much better it is than "mere tmux over
| ssh".
|
| I honestly don't know of a more resilient protocol than mosh
| that's in regular usage, other than possibly link-layer
| 802.11n aka "the Wi-Fi that got these 150 Mbit and those 300
| Mbit and some 450 Mbit speed claims advertised onto the
| marker", where link-layer retransmissions and adaptive
| negotiation of coding parameters and actively-multipath-
| exploiting MIMO-OFDM (and AES crypto from WPA2) combine for a
| setup that hides radio interference to not be visible to
| higher level protocols beyond the unavoidable jitter of the
| retransmissions and varying throughput potentials from
| varying radio conditions.
|
| Oh, I think when viewed regarding computers not the
| congestion control schemes adjusting the individual
| connection speeds, there'd also be BitTorrent with DHT and
| PEX that only needs an infohash: with 160 bits of hash a
| client seeded into the (mainline) DHT swarm can go and
| retrieve a (folder of) files from an infohash-specific swarm
| that's at least partially connected to the DHT (PEX takes
| care of broadening the connectivity among those that care
| about the specific infohash).
|
| In the realm of digital coding schemes that are widely used
| but aren't of the "transmission" variety, there's also
| Redbook CD audio that starts off easy with lossless error
| correction, followed by perceptually effective lossy
| interpolation to cover severe scratches to the disc's
| surface.
| eqvinox wrote:
| I'm not sure why you're explaining mosh (I know what it is
| and have used it before), I was asking what there is other
| than migration (= handled by QUIC) and resumption (= tmux).
|
| Local line editing, I guess. Forgot about that.
| d3Xt3r wrote:
| One of the things I really like about Mosh is the
| responsiveness - there's no lag when typing text, if feels like
| you're really working on a local shell.
|
| I'm guessing SSH3 doesn't do anything to improve that aspect?
| (although I guess QUIC will help a bit, but isn't quite the
| same as Mosh is it?)
| CommanderData wrote:
| X.509 certificates & PKI....
|
| Hopefully provides a way to pin certs or at least pin certificate
| authorities && has PFS.
|
| My conspiracy hat doesn't trust all the cert auths out there.
| hulitu wrote:
| > SSH3: Faster and rich secure shell using HTTP/3
|
| Maybe they shall teach naming projects in CS.
|
| Why not Windows 12 ? /s
| ricardobeat wrote:
| > the keystroke latency during a session remains unchanged
|
| That's a shame. Lowered latency (and persistent sessions, so you
| don't pay the connection cost each time) are the best things
| about Mosh (https://mosh.org/).
| nine_k wrote:
| Lowered _perceived_ latency.
| alsosprachben wrote:
| 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.
| esseph wrote:
| The ssh3 name feels like cloutchasing
| Dwedit wrote:
| Can it tunnel arbitrary TCP ports?
| dev_l1x_be wrote:
| This thread is s classic example what we care about: names. Is
| there technical merit to do ssh over http3? Who caes? Who knows?
| littlecranky67 wrote:
| What is the usecase of using OAuth or "my github account" to
| login to a linux/unix machine?
| thethimble wrote:
| 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.
| frumplestlatz wrote:
| > 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.
| Meneth wrote:
| An alternative way to hide your SSH server from portscanners is
| to put it inside a WireGuard VPN.
| encom wrote:
| TFA says "port scanning attacks", but in my opinion it's not.
| It's barely jiggling the door knob. Securing SSH isn't hard to
| do properly, and port scans or connection attempts isn't
| something anyone needs to be concerned about whatsoever.
|
| I am concerned however about the tedious trend of cramming
| absolutely everything into HTTP. DNS-over-HTTP is already very
| dumb, and I'm quite sure SSH-over-HTTP is not something I'm
| going to be interested in at all.
| vladdoster wrote:
| given last commit was 1+ year ago, anyone know what the status of
| the project is?
| Avamander wrote:
| I like the idea, especially if it can be proxied by a regular H3
| proxy.
|
| If it also solved connection multipath/migration and fixes for
| TCP-related blocking issues, that'd already be amazing.
___________________________________________________________________
(page generated 2025-09-27 23:00 UTC)