It is every bit as bad. QUIC streams could map nicely to the SSH model of discrete channels. Sure, you can run it over tcp/443 and have it look like a normal TLS connection to anything that isn't monitoring the traffic patterns, but it's effectively just adding a TLS pipe which only achieves the use of QUIC's congestion control algorithm and handshake but nothing else. I would love to see an SSH implementation which uses QUIC correctly; this isn't it.

edit: it also has a hardcoded parameter to not validate certs which defeats the whole purpose of it using TLS in the first place... (https://github.com/moul/quicssh/blob/5f5a17c3431a39a8287467d...)

MOSH already exists, and it is a proper ssh-like protocol over UDP that takes advantage of the properties of UDP. It's great for use when traveling and being forced to use horrible high latency wireless connections.

MOSH is really a on-purpose "horrible SSH" as far as SSH goes, but it is instead intended to be what you actually need for remote, unstable, unreliable slow connections: a somewhat reponsive experience, a kinda of remote desktop protocol but for terminals, you only send the input and output deltas; you intentionally don't block waiting at any side for precise confirmation of every single byte in or out of a remote terminal.

I doubt e.g. OpenSSH would ever implement something like you describe though. They're seemingly very much against anything x509/WebPKI.

You imply OpenSSH is the place to do this work.

Given the protocol changes needed, it may be a new implementation. I actually expect it would be.

I believe section 7 of RFC 9000 would allow for the creation of a handshake protocol which could conform to SSH without the need for including x509.

Thanks for the tip, wasn't aware of this.