Add support of ssh3

[mrPsycho]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [*] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [*] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

As ssh3 released, it would be awesome to see that thing in opnsense.

Describe the solution you like

https://github.com/francoismichel/ssh3

[doktornotor]

# sshd -V
OpenSSH_9.3, OpenSSL 1.1.1w  11 Sep 2023

https://www.openssh.com/

[cluck]

Frankly I don't buy one single advantage of what SSH3 states in their readme:

• While SSHv2 defines its own protocols for user authentication and secure channel establishment, SSH3 relies on the robust and time-tested mechanisms of TLS 1.3, QUIC and HTTP

  This must be a joke: SSH-2 is from 2006, and has never been shown having a design flaw in the protocol; meanwhile, TLS 1.3 is the latest urgent update of an unfortunate series of broken protocols that needed urgent replacement: SSLv2, SSLv3/TLS 1.0, TLS 1.1 and then TLS 1.2.

• Significantly faster session establishment

  We're optimizing a few milliseconds a day here, aren't we? (and conveniently forgetting of SSH master mode). Note: if you really have delays in the order of seconds during SSH login, then fix DNS resolution on the server (both forward and reverse DNS and both for IPv4 and IPv6; and on OpenSSH check the option UseDNS).

• New HTTP authentication methods such as OAuth 2.0 and OpenID Connect in addition to classical SSH authentication

  • SSH-2 as a protocol already has device-based authentication builtin (host keys), and supports GSS-API. That is, Kerberos support is there as are other mechanisms like OAuth2 and Smartcards/PKI and can be coupled to TPMs. SSH-2 already was offering device-based authentication and MFA and enabling the road to zero trust when there wasn't any marketing term for it yet. There is no justification for a new protocol here, it's all just about placing the proper configuration files and certificates in the right place.

  • SSH access stands as a rescue when all other things like GUI access and automation scripts are out of order. Some even call it out-of-band access, and that's for a reason: it's unentangled from the rest of the infrastructure and relies on an independent trust delegation.

• Robustness to port scanning attacks: your SSH3 server can be made invisible to other Internet users

  Regular SSH is listening on a TCP port as much as an HTTP/QUIC server, both have the very same potential and limit of being hidden. Especially on a firewall.

• UDP port forwarding in addition to classical TCP port forwarding: all the features allowed by the modern QUIC protocol: including connection migration (soon) and multipath connections

  Multipath connections and connection migration are, I think, features no one needs for console access on a personal/SME firewall (and, frankly, any console there is). UDP port forwarding might be a thing, theoretically, but then there's netcat.

Finally, consider that QUIC is a protocol with rampant layering violations, and is not innovative. It is a bundle of technology that represents a viable evolution in the overly complex world of web technology, but is absolutely not needed when you design both client and server with due diligence. QUIC shouldn't be built upon if there is no strict necessity, SSH-2 is doing pretty well so far.

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.