For example x509 seems to be a disadvantage to me. I do not want anyone with a cheap DigiCert certificate be able to log in to my server, even as a result of some fat finger misconfiguration. OAuth assumes that both client and service provider can reach identity provider. Is it so for most serves? I am used to see pretty restricted setups, where many servers have no internet access and only update from a private package repository.

From one side, I really like the idea of reusing HTTP. Who does new protocols these days? Everything is JSON or XML over HTTP. And it's good enough for most cases. But is it good enough for SSH? WinRM works over HTTP, but it uses Kerberos for authentication.

Are there any significant real practical advantages? I don't see any. Are there any vulnerabilities, possibilities for misconfiguration, architectural flaws? Quite possible.

> For our part, the most recent release of step & step-ca (v0.12.0) adds basic SSH certificate support. In other words:

> step-ca is now an SSH CA (in addition to being an X.509 CA)

> step makes it easy for users and hosts to get certificates from step-ca

It's a tool that do x509 ca for x509 things and ssh ca for ssh.

My business brain understands why, but my engineer’s heart laments.

You could use client credentials flow with a certificate. Then all you need is to register the public key with the server, much like good old SSH.

The SSH protocol is designed to multiplex many “channels” over an encrypted tcp socket. Over each channel you can run things like a shell or SFTP.

It would need some engineering but you could keep the same SSH features but replace the multiplexing channels over tcp with QUIC channels over udp. Where does HTTP/3 fit in besides to add overhead?

I don't see any advantage of layering HTTP/3 here. It adds more friction, and the only advantage it brings is being able to "hide" the SSH server over a URL path. I guess x.509 certificates would be fine, but SSH hostkeys, SSHFP or TOFU is enough and far more secure (because it implicitly pins the server public key).

It's a relatively new project from the looks of it, so I'd definitely not use it anywhere half important having to create something interesting with QUIC and HTTP/3.

https://github.com/salesforce/pam_oidc

https://github.com/EOSC-synergy/ssh-oidc

I didn't see it stated in the documentation, it this feels like something that might work for that setup.

I get that CloudFlare has been a well behaved netizen so far, but let's be real, it won't last forever. It never does. Eventually the shareholders start turning the screws and CloudFlare is going to succumb to the same pressures every company does and they're going to start extracting advertising value from their "customers".

How about we save the CDNs for the serious stuff and just run our SSH servers and low traffic HTTP sites ourselves?

[1] https://aye.sh/blog/sshfp-verification

* There are still resolvers that can't handle Ed25519

* Being able to use Ed25519 was never the ops problem with getting DNSSEC rolled out!

* It's weird to assume that people would want to enroll their server integrity --- something that doesn't in any way depend on an Internet PKI designed to allow strangers to verify your identity, and that enlists de facto government support to make that use case work --- in a global PKI, especially when SSH already has a perfectly good certificate system that solves the same problem without any of the above liabilities.

What boggles my mind, and I mean this sincerely, not as snark, is that anybody in the entire world takes SSHFP seriously. Even if you stipulate that DNSSEC (and/or DANE) works, just arguendo, it's still a totally different use case than resolving SSH key continuity problems.

You could configure something delightfully atrocious like https://github.com/mjg59/ssh_pki but I think for most use cases where you connect to loads of SSH servers, host keys and certificate authorities will work just fine. We can do with an ACME-like protocol for distributing these certificates, though.

I've done ssh over websocket before (to bypass a corp proxy)... been thinking about it a lot lately. I would love if mosh got support for different transports than just udp and it would be cool if the initial handshake could be done over http instead of ssh.

SNI-like metadata might have some adverse security implications, but a fancier ProxyJump with session routing would be nice.

> HPN-SSH is a series of modifications to OpenSSH, the predominant implementation of the ssh protocol. It was originally developed to address performance issues when using ssh on high speed long distance networks (also known as Long Fat Networks: LFNs). By taking advantage of automatically optimized receive buffers HPN-SSH could improve performance dramatically on these paths. Later advances include; disabling encryption after authentication to transport non-sensitive bulk data, modifying the AES-CTR cipher to use multiple CPU cores, more detailed connection logging, and peak throughput values in the scp progress bar. More information can be found on HPN-SSH page on the PSC website.

Maybe not 100gig, but I routinely transfer data over 10gig links. I used to be a heavy user of HPN, but Gentoo pretty much stopped supporting it because the multithreading is supposedly broken.

Yes, this is not SSHv3 as defined by a standards body. It is very much SSHv2 over HTTP/3. (Which sorta sounds like how HTTP/3 is actually HTTP/2 over QUIC)

But there is lots of SSH servers and clients, such as Dropbear SSH, OpenSSH, libssh, libssh2 (which is very different from libssh which also supports sshv2), and more. So I don't blame the creators from putting SSH in the name.

The code itself looks like mostly glue code to other more well established libraries. I'm not saying that they didn't introduce new flaws, just that they did not roll their own crypto here.

Their paper on their work is pretty interesting: https://arxiv.org/pdf/2312.08396.pdf

I kinda hope this succeeds. The faster connection time is nice, but really OpenSSH is so change adverse that it's painful.

IE, I have to have a pretty large patch sets to open SSH, one of them being HPN ssh for getting any kind of reasonable throughput over high latency links. This patch set is decades old and the problems well known, but OpenSSH maintainers do not care. Replacing the transport layer would force things like having reasonable window scaling.

Another is loadbalancing and routing SSH connections. You cannot know where a client wants to connect to till after they done a full hand shake. This is pretty painful. If we had something like SNI we could route clients to the correct servers using only a single IP and port.

I fully welcome these ideas and am glad a group is working on testing these concepts.

Please don't dismiss things too hard too soon.

In naming; Francois also explains SSH3 is a concatenation of SSH and HTTP/3 — we can not like that here on HN (due seemingly to the lack of IETF involvement?) but it’s what the project creators picked.

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ov... https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht...

Still early stages, but it looks promising! Notably it supports multiple streams and unreliable datagrams since it goes over QUIC

Because WireGuard and SSH are at different layers of the network stack, it might be necessary (though slow) to bridge two WireGuard networks through a single TCP socket port-forwarded by SSH. I'm actually curious now what tools would best be used to accomplish this, how much effort would be needed to configure things, and how badly performance would suffer when faced with normal internet traffic congestion.

“Tunnel UDP over SSH”

https://superuser.com/questions/53103/udp-traffic-through-ss... has some suggestions

QUIC is fine as is though, no need to layer HTTP3 on top of it.

(Only “almost” indistinguishable, because it’s possible to decrypt the first packets of the client’s handshake and examine the ALPN parameters used to negotiate an application protocol. And QUIC may be further distinguishable from other UDP traffic through statistical analysis of packet sizes and response latencies, as well as the few unencrypted header bits.)

It's not really hidden as if you initiate a connection with ssh it will reveal itself, but if you try https it will reply as a webserver

It world by looking at the first few bytes and deciding what to do based on that

At one point I was running https/ssh/openvpn/custom-tcp all on one port..

Here is someone else explaining how to do it, I don't think I ever wrote it up

https://news.ycombinator.com/item?id=8925938

The best thing about QUIC if its udp is definately that it could be made un portscannable.

Seems like it’s primarily to implement the masking feature to pretend to be a normal HTTP server hosted on a port until the shared secret URL is knocked.

Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.

nginx exposed on 443:

if route is /web then route to web service on port 1234

if route is /ssh3-secret-string -> route to ssh3 server service on port 1265

if route doesn’t exist then 404

…

If so, I assume the encryption on the SSH is handled separately from the http headers.

Since 1.25.0

[for instance, I run Kestrel and it really isn't designed to target more than one site; I do it, but it's like bending that Lego brick to make it fit where it shouldn't go]

Assuming one could connect to an SSH server this way and tunnel ports, could this allow for a means to bypass China's GFW?

China's firewall allows http and https connections through however VPNs, SSH and similar are detected upon connection and blocked on demand.

Hiding a VPN connection by tunneling to a remote SSH server over HTTP/3, forwarding the VPN port and connecting to it might fly under the radar as it could be perceived as regular web traffic.

Would be an interesting thing to try.

Protecting against the potential for confusion from and/or abuses like this is what trademarks are for.

    # ~/.ssh/config
    # Place at the *End-of-file*
    Host *
      ControlMaster auto
      ControlPath ~/.ssh/sockets/%C.sock
      ControlPersist 600

      ServerAliveInterval 60
      ServerAliveCountMax 10
      IPQoS throughput
      TCPKeepAlive yes

      # :: Security Exception :: Purposeful for UX usability of machine-to-machine hops
      ForwardAgent yes

      # ssh-audit recommendations https://www.ssh-audit.com/hardening_guides.html 
      #
      CASignatureAlgorithms [email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256
      HostKeyAlgorithms [email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256
      HostbasedAcceptedAlgorithms [email protected],[email protected],[email protected],ssh-ed25519,[email protected],rsa-sha2-512,[email protected],rsa-sha2-256
      PubkeyAcceptedAlgorithms [email protected],[email protected],[email protected],ssh-ed25519,[email protected],rsa-sha2-512,[email protected],rsa-sha2-256
      KexAlgorithms [email protected],curve25519-sha256,[email protected]
      MACs [email protected],[email protected],[email protected]
      Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
      # GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-group14-sha256-,gss-group16-sha512-

- SSH3 is a bad name: this isn't a successor to SSHv2 and will only cause confusion

- The authors don't seem to understand that SSHv2 predates all of their chosen technologies, and provides "robust and time-tested mechanisms" they claim to be adding

- How is "hiding your server behind a secret link" a feature? This is, at best, security through obscurity, which can be layered on any network protocol (e.g. https://en.wikipedia.org/wiki/Port_knocking); this implies that the authors don't have much of a security background...?

- ...Which explains why they think something as complicated as OpenID Connect is a good thing to add to SSH (i.e. https://security.stackexchange.com/questions/148292/why-is-o...)

- The abstract in the linked paper seems to conflate SSHv1 and SSHv2; I couldn't really bring myself to read much past that

In summary: this seems bad.

> Some SSH implementations such as OpenSSH or Tectia support other ways to authenticate users. Among them is the certificate-based user authentication: only users in possession of a certificate signed by a trusted certificate authority (CA) can gain access to the remote server [12]. Available for more than 10 years, this authentication method requires setting up a CA and distributing the certificates to new users and is still not commonly used nowadays.

Somebody had an agenda to make SSH look as bad as possible. You can implement OIDC authentication with keyboard-interactive, no need for HTTP/3 for that. However, it gets very tricky if you want automated / script access, so it doesn't solve the authentication problem.

As an aside, Tatu Ylonen, the original author of the SSH protocol, published a paper in 2019 titled "SSH Key Management Challenges and Requirements"[1], which is an interesting read. It would seem the authors of this paper should have at least read it.

[1] https://www.ylonen.org/papers/ssh-key-challenges.pdf

This isn't security through obscurity. The url would be a secret. This is a form of capability security, where to connect to the server you must be able to name the server.

A URL with a secret is, in my opinion, far more sane than port knocking, and will be much more efficient as well.

> (i.e. https://security.stackexchange.com/questions/148292/why-is-o...)

Your link doesn't support your statement at all. No one there answers "here's why oid is less secure", they say the opposite.

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

I, for one, can say that sometimes session establishment can take a little while but not to the extent that it would be a selling point (so to speak) for me to adopt SSH3.

"Security by obscurity" is only a thing if you're relying on that mechanism for security. People already configure SSH port knocking as you noted. It can be considered attack surface reduction and is a good feature given they're not using a secret link for any security control.

One benefit of their approach might be how you can use TLS pki now instead if setting up ssh-ca's. Potentially you would need to manage less pki.

But a criticism I have is how http* has much more vulns and new attack techniques being developed all the time unlike ssh. I can imagine LFI or request smuggling on the same http/2 web server causing RCE via their protocol.

Mosh uses regular TCP SSHv2 to authenticate and setup the udp connection. As such your initial connection time is actually slower than just normal v2, and you cannot auth with something like oauth.

Mosh is heavily focused on interactive sessions. You could not use mosh for batch programs easily.

Correct, the goals are better human interaction with a high delay internet or server. Effectively allowing the client side to guess a bit as to where your input went (it does decently at it). But the key thing that I've loved is even if my client machine goes to sleep and I go to a different building I'm still connected to the server. That is wonderful. Agreed the connection time is slower. Mosh = Mobile shell.

Right there, Eternal doesn't even try to cover the same use case as Mosh. It might be an alternative, same way regular SSH is an alternative, but there's no way it can be "better"

I have used Mosh for years and recently heard of ET, but when I tried it I experienced noticeable hangs that I don’t get with Mosh, and I went back.

I heard from several people that “ET is the new Mosh”, but it won’t be for me unless I can figure out/resolve those hangs

> While mosh provides the same core functionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).

A PhD project from Belgium that combines several Golang libraries to offer HTTP-based authentication on top of backwards compatibility with OpenSSH keys, configuration, agents, etc. -- it looks pretty solid but the associated paper titled "Towards SSH3" acknowledges "This article is a first step" in the conclusion.

The project is associated with the Louvain university; I would rate the risk of outright malicious tomfoolery to be quite low.

But to even consider calling it SSH3 is really quite silly, first impression doesn't exactly inspire confidence.

Just a bad look / first impression.

Disclaimer: I write network packet parsers for XNS/IPS/IDS for a living, to look for "bad things".

Is there a 5-10 year future where you just can’t do this as a middlebox?

It seems that at the time these features were dropped, most middleboxes have ignored features like exporting keys or configuring static RSA keys and went for CA-MitM attacks instead. You should expect these tools to break if they're actively trying to subvert protocols to do things they're not designed to support.

I don't really see what changed, though. I guess static keys were dropped to provide forward secrecy, but other than that running your own rogue CA is as possible as it was 20 years ago. Middleboxes lagging behind in support for features like HTTP/3 is probably annoying, but that's because of a lack of implementation more than anything.

You can still use your domain tools/MDM configuration/settings to configure an HTTPS proxy and firewall off the normal ports if you want to MitM your network reliably. If yiur prozy doesnt support http/3, it will happily downgrade your connection to HTTP/1.1 for you. Android's insistence on not actually applying user-installed certificates is a pain for many apps, but other operating systems will happily and silently drop security measures like certificate transparency when they encounter a user-operated MitM CA.

The lack of MitMability comes down to Android being fussy, IoT devices you had no chance of ever controlling needing workarounds, and devices you don't have permissions to manage not being manageable. I really do wish Android would let MDM solutions inject certificates into the system store (though I can see why they don't with the wide range of stalkerware in the wild).

It is the "others".

In my opinion its short sighted, because if we care about security, then we should care about user security and privacy as well. Because if the security admin has the ability to packet inspect stuff, so does a potential malicious app.

SSH3 is a complete revisit of the SSH protocol, mapping its semantics on top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for secure channel establishment and the HTTP Authorization mechanisms for user authentication.

So, it has nothing to do with SSH2; more about HTTP/3-QUIC security theater: hostname is still being sent over TLS/1.3 negotiation.

But I don't see how this is worse than SSHv2. In both cases retrieving the hostname / IP is obviously trivial since you just instrument DNS for the hostname and, of course, the IP is cleartext.

Malicious apps and attackers should not.

Major cloud providers are still shaking issues out of HTTP/2 like "Rapid Reset" 2 months ago, the nesting and layers open gaps and new edge cases as naive implementations were clearly not yet battle hardened even against old attack families like amplification/resource exhaustion.

https://news.ycombinator.com/item?id=37830987 The novel HTTP/2 'Rapid Reset' DDoS attack

https://news.ycombinator.com/item?id=37837043 HAProxy is not affected by the HTTP/2 Rapid Reset Attack

Is this "a secure shell" (as in, somebody's personal spin on the topic) or like a new "official" direction?

The readme isn't clear on these aspects.

Anyway, SSH authentication is extremely inflexible, and the protocol is not particularly performant, especially on large bandwidth-delay links. Moving to HTTP3 seems like an excellent idea if it’s implemented well.

(Although… we really need a way to do TLS/QUIC to an endpoint without a domain name.)

On the other hand, all Cloudflare configuration seems incoherent, and it gets more so over time. I was recently highly entertained when I tried to access one of the Zero Trust [0] pages. The UI cheerfully informed me that only the new UI could configure Zero Trust, and it redirected me to a new domain that was IIRC “one.dash.cloudflare.com”. You can’t make this up — maybe it’s called One Trust internally? The new panel looked quite a lot like the old one except that the Zero Trust pages worked.

Well, “worked”. None of the Zero Trust config makes any sense.

[0] Is there any logic at all to what lives under the Zero Trust umbrella?

Generate self-signed cert, let the client TOFU. And skip the HTTP part. Just like SSH. There's no reason to do things like a browser.

But it really ought to be possible to securely configure locally-connected devices with a browser, and this is not really possible today.