[mvkg]

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

[bcrl]

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.

[ElectricalUnion]

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.

[Avamander]

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

[ilc]

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.

[mvkg]

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.

[tankenmate]

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