10 ms·

SSH3: Faster and rich secure shell using HTTP/3

532 points by tempaccount420 1y ago

kdmtctl 1y ago
It can be actually hidden only paired with an HTTPS server, since CT new certificate logs entries are pretty strong indicator that a host deserves to be "visited".
Zambyte 1y ago
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 1y ago
  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.
- deleted 1y ago
  [deleted]
- notepad0x90 1y ago
  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 1y ago
    Of course it has ACKs. There are protocols without ACKs but they are exotic and HTTP3 is not one of them.
    - IshKebab 1y ago
      He said not waiting for ACKs.
      - xorcist 1y ago
        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/ 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 1y ago
        Well, you could peruse the code. Then see what it does and explain it.
        formerly_proven 1y ago
        > Is it better implemented than the various TCP algorithms we use underneath regular SSH? Perhaps. That remains to be seen. SSH multiplexes multiple channels on the same TCP connection which results in head of line blocking issues. > 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. Not really, no. OpenSSH has a 2 MB window size (in the 2000s, 64K), even with just ~gigabit speeds it only takes around 10-20 ms of latency to start being limited by the BDP.
  - finaard 1y ago
    Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.
    - oefrha 1y ago
      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 1y ago
        "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.
        oefrha 1y ago
        No it’s not completely mitigated by tmux. mosh has two main use cases (that I know of) 1. High latency, maybe even packet-dropping connections; 2. You’re roaming and don’t want to get disconnected all the time. For 2, sure tmux is mostly okay, it’s not as versatile as the native buffer if you use a good terminal emulator but whatever. For 1, using tmux in mosh gives you an awful, high latency scrollback buffer compared to the local one you get with regular ssh. And you were specifically taking about 1. For read-heavy, reconnectable workloads over high latency connections I definitely choose ssh over mosh or mosh+tmux and live with the keystroke latency. So saying it’s a huge downside is not an exaggeration at all.
        esseph 1y ago
        I believe this depends on the intent of your connection!. The first sentence of your last paragraph: "For read-heavy, reconnectable workloads" - A-ha! From my stance, and where I've used mosh has been in performing quick actions on routers and servers that may have bad connections to them, or may be under DDoS, etc. "Read" is extremely limited. So from that perspective and use case, the "huge downside" has never been a problem.
  - nh2 1y ago
    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 1y ago
      Yeah, the longstanding hpn-ssh fork started off by adjusting ssh’s window sizes for long fat pipes. https://github.com/rapier1/hpn-ssh https://github.com/rapier1/hpn-ssh
    - Operyl 1y ago
      Off the top of your head do you know of any file transfer tools that do utilize multiple streams?
      - bravetraveler 1y ago
        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.
      - nh2 1y ago
        Yes, I wrote down some that do and don't support it here: https://github.com/libfuse/sshfs/issues/300 https://github.com/libfuse/sshfs/issues/300
    - jlokier 1y ago
      > I think it's silly that this exists. They should just let TCP handle this. No, unfortunately it'snecessary so that the SSH proocol can multiplex streams independently over a single established connection. If one of the multiplexed streams stalls because its receiver is blocked or slow, and the receive buffer (for that stream) fills up, then without window-based flow control, that causes head-of-line blocking of all the other streams. That's fine if you don't mind streams blocking each other, but it's a problem if they should flow independently. It's pretty much a requirement for opportunistic connection sharing by independent processes, as SSH does. In some situations, this type of multiplexed stream blockiing can even result in a deadlock, depending on what's sent over the streams. Solutions to the problem are to either use window-based flow control, separate from TCP,, or to require all stream receive buffers to expand without limit, which is normally unacceptable. HTTP/2 does something like this. I once designed a protocol without this, thinking multipexing was enough by itself, and found out the hard way when processes got stuck for no apparent reason.
  - fanf2 1y ago
    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 https://github.com/crazyscot/qcp
  - bcrl 1y ago
    That's why mosh exists, as it is purpose built for terminals over high latency / high packet loss links.
    - eichin 1y ago
      But mosh doesn't actually do any of what ssh does, let alone do it faster - it wins by changing the problem, to the vastly narrower one of "getting characters in front of human eyeballs". (Which is amazing if that's what you were trying to do - but that has nothing to do with multiple data streams...)
    - espadrine 1y ago
      mosh is hard to get into. There are many subtle bugs; a random sample that I ran into is that it fails to connect when the LC_ALL variables diverge between the client and the server[0]. On top of it, development seems abandoned. Finally, when running a terminal multiplexer, the predictive system breaks the panes, which is distracting. [0]: https://github.com/mobile-shell/mosh/issues/98 https://github.com/mobile-shell/mosh/issues/98
  - lxgr 1y ago
    That's not really a common TCP problem. Only when there's something severely weird going on in the return path (e.g. an extremely asymmetric and/or congested return path connection dropping ACKs while the forward path has enough capacity) does the ACK mechanism limit TCP. Also, HTTP/3 must obviously also be using some kind of acknowledgements, since for fairness reasons alone it must be implementing some congestion control mechanism, and I can't think of one that gets by entirely without positive acknowledgements. It could well be more efficient than TCP's default "ack every other segment", though. (This helps in the type of connection mentioned above; as far as I know, some DOCSIS modems do this via a mechanism called "ack compression", since TCP is generally tolerant of losing some ACKs.) In a sense, the win of QUIC/HTTP/3 in this sense isn’t that it’s not TCP (it actually provides all the components of TCP per stream!); it’s rather that the application layer can “provide its own TCP”, which might well be more modern than the operating system’s.
- s-macke 1y ago
  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 1y ago
    Does this implementation do that do, or does it just use a single h3 stream?
    - s-macke 1y ago
      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-http3-00.html#name-channels https://www.ietf.org/archive/id/draft-michel-remote-terminal...
  - inetknght 1y ago
    Fun fact: SSH also supports multiple streams. It's called multiplexing.
    - Aachen 1y ago
      Doesn't it run over a single TCP connection in all cases, unless you manually launch multiple and manually load-balance your clients across is? As in, it won't/can't open a new TCP connection when you open a new connection in the SOCKS proxy or port forward. They'll all share one head-of-line and block each other Not that I've ever noticed this being an issue (no matter how much we complain, internet here is pretty decent) Edit: seeing as someone downvoted your hour-old comment just as I was adding this first reply, I guess maybe they 'voted to disagree'... Would be nice if the person would comment. It wasn't me anyway
    - 1y ago
- nine_k 1y ago
  Should be genuinely faster over many VPNs, because it avoids the "TCP inside TCP" tar pit.
- malux85 1y ago
  I read this and thought “who cares”? I use ssh everywhere, maybe establish 200+ SSH sessions a day for my entire career of 20 years and never once have I thought “I wish establishing this connection was faster”
  - efitz 1y ago
    Good for you. There are a lot of automation use cases for SSH where connection setup time is a significant impediment; if you’re making dozens or hundreds of connections to hundreds or thousands of hosts, those seconds add up.
- gchamonlive 1y ago
  If by being faster at making a connection it would reduce latency even if a little, it would mean a really big improvement for other protocols built on top of it like rsync. If Rsync reuses an active connection to stream the files and calculate changes then the impact might be negligible.
- zielmicha 1y ago
  SSH is actually really slow on high latency high bandwidth links (this is what HPN-SSH patches fix: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq). It's very apparent if you try running rsync between two datacenters on different contients. HTTP/3 (and hopefully this project) does not have this problem.
  - Aachen 1y ago
    Sounds like a complex change to fix a security protocol but, reading the page, it seems to just increase the send buffer, which indeed makes sense for high-latency links
- sim7c00 1y ago
  openssh is generally not praised for its speed but its security track record. i hope this thing doesnt sacrefice it for a little more speed in something that generally doesn't require more speed..
ahlCVA 1y ago
Previously: https://news.ycombinator.com/item?id=38664729 https://news.ycombinator.com/item?id=38664729
temp0826 1y ago
I don't know why it makes me a little sad that every application layer protocol is being absorbed into http.
- m463 1y ago
  also, would someone need to have rights to ssh to call it ssh version 3? kind of like if a random person created an (unaffiliated) hacker news 2.0 website.
- chrisfosterelli 1y ago
  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 1y ago
    Yeah, building it on top of QUIC is reasonable, but trying to shoehorn SSH into HTTP semantics feels silly.
    - conradludgate 1y ago
      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
AshamedCaptain 1y ago
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 1y ago
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 1y ago
  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 1y ago
  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.
  - she46BiOmUerPVj 1y ago
    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.
  - doubled112 1y ago
    If you don't need to do anything complicated, ProxyJump is easier to remember. Host *.internal.example.com ProxyJump hop.internal.example.com
    - chupasaurus 1y ago
      ProxyJump was implemented a decade ago to replace that specific string.
  - unsnap_biceps 1y ago
    Newer versions of ssh support ProxyJump ssh -J hop.internal.example.com foo.internal.example.com
miduil 1y ago
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 1y ago
  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/ https://github.com/openbsd/src/commits/master/
slt2021 1y ago
Great project for when you want to exfiltrate data using ssh/scp, but the corporate firewall blocks outbound ssh
psanford 1y ago
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.
- cozzyd 1y ago
  Secure Hypertext Interactive TTY
  - _joel 1y ago
    That sounds a bit crap
    - pixl97 1y ago
      HITTY then.
    - BobbyTables2 1y ago
      But this SHIT is really fast! You’ll see when the logs drop!
- zdw 1y ago
  Same - this feels equivalent of some rando making a repo called "Windows 12" or "Linux 7".
  - bravetraveler 1y ago
    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
  - 1y ago
Velocifyer 1y ago
Does this still support standard SSH encryption and authentication (on both client and server)?
- projektfu 1y ago
  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 https://www.ietf.org/archive/id/draft-michel-ssh3-00.html However, it can also use HTTP mechanisms for authentication/authorization.
ur-whale 1y ago
Knee-jerk reaction: if it aint broke ...
- axiolite 1y ago
  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 1y ago
  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 1y ago
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!)
deleted 1y ago
[deleted]
nick_travels 1y ago
built in OIDC authentication - YES, love it!
eqvinox 1y ago
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 1y ago
  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 1y ago
    > 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…
pvsnp 1y ago
Shouldn’t this be called SSH over HTTP/3?
nwmcsween 1y ago
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.
- mathfailure 1y ago
  The project is abandoned as well.
bullen 1y ago
YAMP
Fnoord 1y ago
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 1y ago
  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 1y ago
Faster SSH in Rust when?
rootnod3 1y ago
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 1y ago
> 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 1y ago
  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 1y ago
    Calling anything here "physical" is strange and confusing to me. Surely you don't mean the physical layer?
    - zamadatix 1y ago
      I've seen it a lot with communication protocols for some reason, I guess it's just relatively clear it means "the non virtualized" even though it's clearly a misnomer. E.g. with VRRP a ton of people just say "the physical IP" when talking about the address that's not the VIP, even though the RFC refers to it as "the primary" IP. Arguably "primary IP" is more confusing as to which is being referred to, even though it's more technically accurate. Of course, maybe there's a perfectly obvious word which can apply to all of those kinds of situations just as clearly without being a misnomer I've just never thought to mention in reply :D.
- athrowaway3z 1y ago
  If you are looking for a smoother UX: https://mosh.org/ https://mosh.org/
  - gdevenyi 1y ago
staplung 1y ago
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/ https://mosh.org/
- eqvinox 1y ago
  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 1y ago
    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.
CommanderData 1y ago
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 1y ago
> SSH3: Faster and rich secure shell using HTTP/3 Maybe they shall teach naming projects in CS. Why not Windows 12 ? /s
ricardobeat 1y ago
> 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/ https://mosh.org/).
- nine_k 1y ago
  Lowered perceived latency.
  - ricardobeat 1y ago
    Mosh uses UDP in addition to optimistic updates, so there is an actual latency improvement.
    - nine_k 1y ago
      HTTP/3 also rides on UDP, so the effect should be comparable.
      - ricardobeat 1y ago
        > SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged. If implemented with latency in mind, yes. After a quick look at the code, it seems they are buffering data on both sides with hardcoded buffer sizes at 1500 (TCP packet size) or 30Kb, which could be negating any latency improvements.
alsosprachben 1y ago
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 1y ago
The ssh3 name feels like cloutchasing
Dwedit 1y ago
Can it tunnel arbitrary TCP ports?
dev_l1x_be 1y ago
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 1y ago
What is the usecase of using OAuth or "my github account" to login to a linux/unix machine?
- thethimble 1y ago
  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 1y ago
> 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 1y ago
An alternative way to hide your SSH server from portscanners is to put it inside a WireGuard VPN.
- encom 1y ago
  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 1y ago
given last commit was 1+ year ago, anyone know what the status of the project is?
Avamander 1y ago
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.
fijiaarone 1y ago
If it doesn’t fully implement SOAP, what’s the point? Feels like a spinning hammer meant to drive screws because somebody has never seen a drill before.
mcny 1y ago
I sincerely don't understand this obsession with short names and aliases. I absolutely dislike it. Names should be long and descriptive. I understand that in the past we needed short names because every character cost space and space was precious but it isn't the case anymore. Please don't give short abbreviated names. Useful full names for commands. Teach full names. When you present something, show full names. If this project used a full name like `remote-terminals-over-http3`, we would not be having this debate about ssh3. Of course, end users and system administrators and even package managers/distributions are free to add abbreviations but we should be teaching people to use full names. Prefer things like Set-Location over cd. Prefer npm install --global over npm i -g. Prefer remote-terminals-over-http3 over ssh3.
zaps 1y ago
idk if you should call it that
Arch-TK 1y ago
SSH is slow, but in my experience the primary cause of slowdown is session setup. Be it PAM, or whatever OpenBSD is doing, the session setup kills performance, whether you're re-using the SSH connection or not, every time you start something within that connection. Now obviously for long running stuff, that doesn't matter as much as the total overhead. But if you're doing long running ssh you're probably using SSH for its remote terminal purposes and you don't care if it takes 0.5 seconds or 1 second before you can do anything. And if you want file transfer, we already had a HTTP/3 version of that - it's called HTTP/3. Ansible, for example, performs really poorly in my experience precisely because of this overhead. Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.
- nasretdinov 1y ago
  To speed up Ansible it's sufficient to enable ControlMaster with a short timeout tbh
  - Arch-TK 1y ago
    I don't believe control master solves the problem, as long as Ansible is configured to create a new session within the long-running SSH connection then it will still have the session setup overhead. I tested this myself when prototyping the replacement. However, it looks like pipelining (and obviously forking) could do a lot to help. That being said, there were _many_ reasons for me to drop Ansible. Including poor non-linux host support, Yaml, the weird hoops you have to jump through to make a module, and difficulty achieving certain results given the abstraction choices. I think Ansible is great, it solves a problem, but my problem was very specific, Ansible was a poor fit for it, and performance was just one of many nails in the coffin for me.
- rollcat 1y ago
  > Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost. HMU on my email. I've been working on/with this since 2016, and I'd love to discuss: <https://github.com/rollcat/judo https://github.com/rollcat/judo>
supjeff 1y ago
> SSH3 is a complete revisit of the SSH protocol so, new undiscovered vulnerabilities
superkuh 1y ago
So does this mean that you can't self sign anything and have to involve corporate CAs for your ssh now? Because QUIC cannot do anything without CA TLS approval being involved.
- rollcat 1y ago
  That is my main objection as well, but perhaps it's time to also revisit TOFU. Remember when Github had to rotate its host keys? It was hitting the news far and wide, and likely broke pretty close to every single CI pipeline out there. There was little heads up because it's the friggin host key, you have to act now. It's also pretty annoying when you have to deal with that in your own infra. Even if you have a pretty good network/service map, you'll probably have silent breakage somewhere. I'm not saying CAs should be the future of SSH, but TOFU is certainly a problem at scale.
  - superkuh 1y ago
    Some day very soon everyone is going to get some uncomfortable lived experience showing just how dangerous and damaging putting all of our communications eggs in a handful of easily controlled corporate baskets is. It's now calvinball out there and distributed, not centralized, solutions are going to be required to route around the damage. The people who lived through it last time made the internet. And now that they're mostly retired or dead we're removing all the robustness they built in just to better align with employers' profit-motive use cases. But we don't have to do that. Not on our own time. Don't use QUIC unless you're getting paid to do it.
    - rollcat 1y ago
      I agree that we do need more decentralization, but for the decentralized infrastructure to scale, we need better building blocks. Internet is a much, much bigger place now. TOFU doesn't scale.
computersuck 1y ago
The added bonus that no one is talking about is that this is written in golang making it by default more memory safe and modern
thayne 1y ago
It looks like the RFC is expired.
aemonfly 1y ago
HSSH (http security shell), very similar to SSH.
exabrial 1y ago
I’d sort of rather have the opposite: http over ssh. There’d be key pinning, multi streams, and many more cool things
- burnt-resistor 1y ago
  Ah, you can already do this with tunneling. It just doesn't make any sense.
burnt-resistor 1y ago
SSH Communications Security, Inc. owns the trademark to SSH and so this rebranding/coopting may implode suddenly with a C & D. https://uspto.report/TM/76431998 https://uspto.report/TM/76431998
- switknee 1y ago
  Do you seriously believe that hasn't been genericized? Computer people talk about SSH all the time and usually mean openSSH. When they're not talking about openSSH the next most likely is dropbear on embedded hardware. Nobody ever talks about SSH Communications Security except in the context of the trademark registered in the previous century. It's cool that they were the first to develop the protocol, but they're not relevant today and have no right to harass newer projects that people actually use.
deknos 1y ago
how complex is this to understand for auditors? i fear of the ever increasing complexity of protocols which are security-relevant...
FergusArgyll 1y ago
This sounds cool, is there a way to do this with ssh? Similarly to your secret Google Drive documents, your SSH3 server can be hidden behind a secret link and only answer to authentication attempts that made an HTTP request to this specific link, like the following: ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>
- ema 1y ago
  One thing you can do is listen on a non-standard port.
  - FergusArgyll 1y ago
    yeah, I'm not worried either way. Just wondering if anyone has a hack for that
    - segfaultbuserr 1y ago
      TCP port knocking.
ryangibb 1y ago
I've got a small project that uses a Cap'N Proto capability to do the key exchange for a mosh session which might be interesting to some: https://github.com/RyanGibb/capability-shell/blob/619d26dbb1b37c00d7e1bdf3e5167fc9d66b4294/bin/shell.ml#L96-L118 https://github.com/RyanGibb/capability-shell/blob/619d26dbb1...
SuperSandro2000 1y ago
It is basically dead

It can be actually hidden only paired with an HTTPS server, since CT new certificate logs entries are pretty strong indicator that a host deserves to be "visited".

Zambyte 1y ago

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 1y ago
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.
deleted 1y ago
[deleted]
notepad0x90 1y ago
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 1y ago
  Of course it has ACKs. There are protocols without ACKs but they are exotic and HTTP3 is not one of them.
  - IshKebab 1y ago
    He said not waiting for ACKs.
    - xorcist 1y ago
      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/ 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 1y ago
        Well, you could peruse the code. Then see what it does and explain it.
      - formerly_proven 1y ago
        > Is it better implemented than the various TCP algorithms we use underneath regular SSH? Perhaps. That remains to be seen. SSH multiplexes multiple channels on the same TCP connection which results in head of line blocking issues. > 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. Not really, no. OpenSSH has a 2 MB window size (in the 2000s, 64K), even with just ~gigabit speeds it only takes around 10-20 ms of latency to start being limited by the BDP.
- finaard 1y ago
  Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.
  - oefrha 1y ago
    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 1y ago
      "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.
      - oefrha 1y ago
        No it’s not completely mitigated by tmux. mosh has two main use cases (that I know of) 1. High latency, maybe even packet-dropping connections; 2. You’re roaming and don’t want to get disconnected all the time. For 2, sure tmux is mostly okay, it’s not as versatile as the native buffer if you use a good terminal emulator but whatever. For 1, using tmux in mosh gives you an awful, high latency scrollback buffer compared to the local one you get with regular ssh. And you were specifically taking about 1. For read-heavy, reconnectable workloads over high latency connections I definitely choose ssh over mosh or mosh+tmux and live with the keystroke latency. So saying it’s a huge downside is not an exaggeration at all.
        esseph 1y ago
        I believe this depends on the intent of your connection!. The first sentence of your last paragraph: "For read-heavy, reconnectable workloads" - A-ha! From my stance, and where I've used mosh has been in performing quick actions on routers and servers that may have bad connections to them, or may be under DDoS, etc. "Read" is extremely limited. So from that perspective and use case, the "huge downside" has never been a problem.
- nh2 1y ago
  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 1y ago
    Yeah, the longstanding hpn-ssh fork started off by adjusting ssh’s window sizes for long fat pipes. https://github.com/rapier1/hpn-ssh https://github.com/rapier1/hpn-ssh
  - Operyl 1y ago
    Off the top of your head do you know of any file transfer tools that do utilize multiple streams?
    - bravetraveler 1y ago
      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.
    - nh2 1y ago
      Yes, I wrote down some that do and don't support it here: https://github.com/libfuse/sshfs/issues/300 https://github.com/libfuse/sshfs/issues/300
  - jlokier 1y ago
    > I think it's silly that this exists. They should just let TCP handle this. No, unfortunately it'snecessary so that the SSH proocol can multiplex streams independently over a single established connection. If one of the multiplexed streams stalls because its receiver is blocked or slow, and the receive buffer (for that stream) fills up, then without window-based flow control, that causes head-of-line blocking of all the other streams. That's fine if you don't mind streams blocking each other, but it's a problem if they should flow independently. It's pretty much a requirement for opportunistic connection sharing by independent processes, as SSH does. In some situations, this type of multiplexed stream blockiing can even result in a deadlock, depending on what's sent over the streams. Solutions to the problem are to either use window-based flow control, separate from TCP,, or to require all stream receive buffers to expand without limit, which is normally unacceptable. HTTP/2 does something like this. I once designed a protocol without this, thinking multipexing was enough by itself, and found out the hard way when processes got stuck for no apparent reason.
- fanf2 1y ago
  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 https://github.com/crazyscot/qcp
- bcrl 1y ago
  That's why mosh exists, as it is purpose built for terminals over high latency / high packet loss links.
  - eichin 1y ago
    But mosh doesn't actually do any of what ssh does, let alone do it faster - it wins by changing the problem, to the vastly narrower one of "getting characters in front of human eyeballs". (Which is amazing if that's what you were trying to do - but that has nothing to do with multiple data streams...)
  - espadrine 1y ago
    mosh is hard to get into. There are many subtle bugs; a random sample that I ran into is that it fails to connect when the LC_ALL variables diverge between the client and the server[0]. On top of it, development seems abandoned. Finally, when running a terminal multiplexer, the predictive system breaks the panes, which is distracting. [0]: https://github.com/mobile-shell/mosh/issues/98 https://github.com/mobile-shell/mosh/issues/98
- lxgr 1y ago
  That's not really a common TCP problem. Only when there's something severely weird going on in the return path (e.g. an extremely asymmetric and/or congested return path connection dropping ACKs while the forward path has enough capacity) does the ACK mechanism limit TCP. Also, HTTP/3 must obviously also be using some kind of acknowledgements, since for fairness reasons alone it must be implementing some congestion control mechanism, and I can't think of one that gets by entirely without positive acknowledgements. It could well be more efficient than TCP's default "ack every other segment", though. (This helps in the type of connection mentioned above; as far as I know, some DOCSIS modems do this via a mechanism called "ack compression", since TCP is generally tolerant of losing some ACKs.) In a sense, the win of QUIC/HTTP/3 in this sense isn’t that it’s not TCP (it actually provides all the components of TCP per stream!); it’s rather that the application layer can “provide its own TCP”, which might well be more modern than the operating system’s.
s-macke 1y ago
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 1y ago
  Does this implementation do that do, or does it just use a single h3 stream?
  - s-macke 1y ago
    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-http3-00.html#name-channels https://www.ietf.org/archive/id/draft-michel-remote-terminal...
- inetknght 1y ago
  Fun fact: SSH also supports multiple streams. It's called multiplexing.
  - Aachen 1y ago
    Doesn't it run over a single TCP connection in all cases, unless you manually launch multiple and manually load-balance your clients across is? As in, it won't/can't open a new TCP connection when you open a new connection in the SOCKS proxy or port forward. They'll all share one head-of-line and block each other Not that I've ever noticed this being an issue (no matter how much we complain, internet here is pretty decent) Edit: seeing as someone downvoted your hour-old comment just as I was adding this first reply, I guess maybe they 'voted to disagree'... Would be nice if the person would comment. It wasn't me anyway
  - 1y ago
nine_k 1y ago
Should be genuinely faster over many VPNs, because it avoids the "TCP inside TCP" tar pit.
malux85 1y ago
I read this and thought “who cares”? I use ssh everywhere, maybe establish 200+ SSH sessions a day for my entire career of 20 years and never once have I thought “I wish establishing this connection was faster”
- efitz 1y ago
  Good for you. There are a lot of automation use cases for SSH where connection setup time is a significant impediment; if you’re making dozens or hundreds of connections to hundreds or thousands of hosts, those seconds add up.
gchamonlive 1y ago
If by being faster at making a connection it would reduce latency even if a little, it would mean a really big improvement for other protocols built on top of it like rsync. If Rsync reuses an active connection to stream the files and calculate changes then the impact might be negligible.
zielmicha 1y ago
SSH is actually really slow on high latency high bandwidth links (this is what HPN-SSH patches fix: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq). It's very apparent if you try running rsync between two datacenters on different contients. HTTP/3 (and hopefully this project) does not have this problem.
- Aachen 1y ago
  Sounds like a complex change to fix a security protocol but, reading the page, it seems to just increase the send buffer, which indeed makes sense for high-latency links
sim7c00 1y ago
openssh is generally not praised for its speed but its security track record. i hope this thing doesnt sacrefice it for a little more speed in something that generally doesn't require more speed..

ahlCVA 1y ago

Previously: https://news.ycombinator.com/item?id=38664729 https://news.ycombinator.com/item?id=38664729

temp0826 1y ago

I don't know why it makes me a little sad that every application layer protocol is being absorbed into http.

m463 1y ago
also, would someone need to have rights to ssh to call it ssh version 3? kind of like if a random person created an (unaffiliated) hacker news 2.0 website.
chrisfosterelli 1y ago
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 1y ago
  Yeah, building it on top of QUIC is reasonable, but trying to shoehorn SSH into HTTP semantics feels silly.
  - conradludgate 1y ago
    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

AshamedCaptain 1y ago

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 1y ago

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 1y ago
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 1y ago
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.
- she46BiOmUerPVj 1y ago
  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.
- doubled112 1y ago
  If you don't need to do anything complicated, ProxyJump is easier to remember. Host *.internal.example.com ProxyJump hop.internal.example.com
  - chupasaurus 1y ago
    ProxyJump was implemented a decade ago to replace that specific string.
- unsnap_biceps 1y ago
  Newer versions of ssh support ProxyJump ssh -J hop.internal.example.com foo.internal.example.com

miduil 1y ago

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 1y ago
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/ https://github.com/openbsd/src/commits/master/

slt2021 1y ago

Great project for when you want to exfiltrate data using ssh/scp, but the corporate firewall blocks outbound ssh

psanford 1y ago

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.

cozzyd 1y ago
Secure Hypertext Interactive TTY
- _joel 1y ago
  That sounds a bit crap
  - pixl97 1y ago
    HITTY then.
  - BobbyTables2 1y ago
    But this SHIT is really fast! You’ll see when the logs drop!
zdw 1y ago
Same - this feels equivalent of some rando making a repo called "Windows 12" or "Linux 7".
- bravetraveler 1y ago
  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
- 1y ago

Velocifyer 1y ago

Does this still support standard SSH encryption and authentication (on both client and server)?

projektfu 1y ago
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 https://www.ietf.org/archive/id/draft-michel-ssh3-00.html However, it can also use HTTP mechanisms for authentication/authorization.

ur-whale 1y ago

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

axiolite 1y ago
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 1y ago
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 1y ago

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!)

deleted 1y ago

[deleted]

nick_travels 1y ago

built in OIDC authentication - YES, love it!

eqvinox 1y ago

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 1y ago
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 1y ago
  > 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…

pvsnp 1y ago

Shouldn’t this be called SSH over HTTP/3?

nwmcsween 1y ago

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.

mathfailure 1y ago
The project is abandoned as well.

bullen 1y ago

YAMP

Fnoord 1y ago

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 1y ago
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 1y ago

Faster SSH in Rust when?

rootnod3 1y ago

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 1y ago

> 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 1y ago
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 1y ago
  Calling anything here "physical" is strange and confusing to me. Surely you don't mean the physical layer?
  - zamadatix 1y ago
    I've seen it a lot with communication protocols for some reason, I guess it's just relatively clear it means "the non virtualized" even though it's clearly a misnomer. E.g. with VRRP a ton of people just say "the physical IP" when talking about the address that's not the VIP, even though the RFC refers to it as "the primary" IP. Arguably "primary IP" is more confusing as to which is being referred to, even though it's more technically accurate. Of course, maybe there's a perfectly obvious word which can apply to all of those kinds of situations just as clearly without being a misnomer I've just never thought to mention in reply :D.
athrowaway3z 1y ago
If you are looking for a smoother UX: https://mosh.org/ https://mosh.org/
- gdevenyi 1y ago

staplung 1y ago

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/ https://mosh.org/

eqvinox 1y ago
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 1y ago
  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.

CommanderData 1y ago

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 1y ago

> SSH3: Faster and rich secure shell using HTTP/3 Maybe they shall teach naming projects in CS. Why not Windows 12 ? /s

ricardobeat 1y ago

> 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/ https://mosh.org/).

nine_k 1y ago
Lowered perceived latency.
- ricardobeat 1y ago
  Mosh uses UDP in addition to optimistic updates, so there is an actual latency improvement.
  - nine_k 1y ago
    HTTP/3 also rides on UDP, so the effect should be comparable.
    - ricardobeat 1y ago
      > SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged. If implemented with latency in mind, yes. After a quick look at the code, it seems they are buffering data on both sides with hardcoded buffer sizes at 1500 (TCP packet size) or 30Kb, which could be negating any latency improvements.

alsosprachben 1y ago

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 1y ago

The ssh3 name feels like cloutchasing

Dwedit 1y ago

Can it tunnel arbitrary TCP ports?

dev_l1x_be 1y ago

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 1y ago

What is the usecase of using OAuth or "my github account" to login to a linux/unix machine?

thethimble 1y ago
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 1y ago

> 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 1y ago

An alternative way to hide your SSH server from portscanners is to put it inside a WireGuard VPN.

encom 1y ago
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 1y ago

given last commit was 1+ year ago, anyone know what the status of the project is?

Avamander 1y ago

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.

fijiaarone 1y ago

If it doesn’t fully implement SOAP, what’s the point? Feels like a spinning hammer meant to drive screws because somebody has never seen a drill before.

mcny 1y ago

I sincerely don't understand this obsession with short names and aliases. I absolutely dislike it. Names should be long and descriptive. I understand that in the past we needed short names because every character cost space and space was precious but it isn't the case anymore. Please don't give short abbreviated names. Useful full names for commands. Teach full names. When you present something, show full names. If this project used a full name like `remote-terminals-over-http3`, we would not be having this debate about ssh3. Of course, end users and system administrators and even package managers/distributions are free to add abbreviations but we should be teaching people to use full names. Prefer things like Set-Location over cd. Prefer npm install --global over npm i -g. Prefer remote-terminals-over-http3 over ssh3.

zaps 1y ago

idk if you should call it that

Arch-TK 1y ago

SSH is slow, but in my experience the primary cause of slowdown is session setup. Be it PAM, or whatever OpenBSD is doing, the session setup kills performance, whether you're re-using the SSH connection or not, every time you start something within that connection. Now obviously for long running stuff, that doesn't matter as much as the total overhead. But if you're doing long running ssh you're probably using SSH for its remote terminal purposes and you don't care if it takes 0.5 seconds or 1 second before you can do anything. And if you want file transfer, we already had a HTTP/3 version of that - it's called HTTP/3. Ansible, for example, performs really poorly in my experience precisely because of this overhead. Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.

nasretdinov 1y ago
To speed up Ansible it's sufficient to enable ControlMaster with a short timeout tbh
- Arch-TK 1y ago
  I don't believe control master solves the problem, as long as Ansible is configured to create a new session within the long-running SSH connection then it will still have the session setup overhead. I tested this myself when prototyping the replacement. However, it looks like pipelining (and obviously forking) could do a lot to help. That being said, there were _many_ reasons for me to drop Ansible. Including poor non-linux host support, Yaml, the weird hoops you have to jump through to make a module, and difficulty achieving certain results given the abstraction choices. I think Ansible is great, it solves a problem, but my problem was very specific, Ansible was a poor fit for it, and performance was just one of many nails in the coffin for me.
rollcat 1y ago
> Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost. HMU on my email. I've been working on/with this since 2016, and I'd love to discuss: <https://github.com/rollcat/judo https://github.com/rollcat/judo>

supjeff 1y ago

> SSH3 is a complete revisit of the SSH protocol so, new undiscovered vulnerabilities

superkuh 1y ago

So does this mean that you can't self sign anything and have to involve corporate CAs for your ssh now? Because QUIC cannot do anything without CA TLS approval being involved.

rollcat 1y ago
That is my main objection as well, but perhaps it's time to also revisit TOFU. Remember when Github had to rotate its host keys? It was hitting the news far and wide, and likely broke pretty close to every single CI pipeline out there. There was little heads up because it's the friggin host key, you have to act now. It's also pretty annoying when you have to deal with that in your own infra. Even if you have a pretty good network/service map, you'll probably have silent breakage somewhere. I'm not saying CAs should be the future of SSH, but TOFU is certainly a problem at scale.
- superkuh 1y ago
  Some day very soon everyone is going to get some uncomfortable lived experience showing just how dangerous and damaging putting all of our communications eggs in a handful of easily controlled corporate baskets is. It's now calvinball out there and distributed, not centralized, solutions are going to be required to route around the damage. The people who lived through it last time made the internet. And now that they're mostly retired or dead we're removing all the robustness they built in just to better align with employers' profit-motive use cases. But we don't have to do that. Not on our own time. Don't use QUIC unless you're getting paid to do it.
  - rollcat 1y ago
    I agree that we do need more decentralization, but for the decentralized infrastructure to scale, we need better building blocks. Internet is a much, much bigger place now. TOFU doesn't scale.

computersuck 1y ago

The added bonus that no one is talking about is that this is written in golang making it by default more memory safe and modern

thayne 1y ago

It looks like the RFC is expired.

aemonfly 1y ago

HSSH (http security shell), very similar to SSH.

exabrial 1y ago

I’d sort of rather have the opposite: http over ssh. There’d be key pinning, multi streams, and many more cool things

burnt-resistor 1y ago
Ah, you can already do this with tunneling. It just doesn't make any sense.

burnt-resistor 1y ago

SSH Communications Security, Inc. owns the trademark to SSH and so this rebranding/coopting may implode suddenly with a C & D. https://uspto.report/TM/76431998 https://uspto.report/TM/76431998

switknee 1y ago
Do you seriously believe that hasn't been genericized? Computer people talk about SSH all the time and usually mean openSSH. When they're not talking about openSSH the next most likely is dropbear on embedded hardware. Nobody ever talks about SSH Communications Security except in the context of the trademark registered in the previous century. It's cool that they were the first to develop the protocol, but they're not relevant today and have no right to harass newer projects that people actually use.

deknos 1y ago

how complex is this to understand for auditors? i fear of the ever increasing complexity of protocols which are security-relevant...

FergusArgyll 1y ago

This sounds cool, is there a way to do this with ssh? Similarly to your secret Google Drive documents, your SSH3 server can be hidden behind a secret link and only answer to authentication attempts that made an HTTP request to this specific link, like the following: ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>

ema 1y ago
One thing you can do is listen on a non-standard port.
- FergusArgyll 1y ago
  yeah, I'm not worried either way. Just wondering if anyone has a hack for that
  - segfaultbuserr 1y ago
    TCP port knocking.

ryangibb 1y ago

I've got a small project that uses a Cap'N Proto capability to do the key exchange for a mosh session which might be interesting to some: https://github.com/RyanGibb/capability-shell/blob/619d26dbb1b37c00d7e1bdf3e5167fc9d66b4294/bin/shell.ml#L96-L118 https://github.com/RyanGibb/capability-shell/blob/619d26dbb1...

SuperSandro2000 1y ago

It is basically dead