The SSH3 Dig In - The Next Standard Or The Pursuit Of Phantom Glory

SSH, as Secure Shell Protocol, is the cryptographic network protocol designed to connect machines in a secure manner. Since its introduction in 1995, the protocol has survived many years with many improvements, and in the last decade or more is the industry standard. Yes, here some Windows users will probably start to debate about how nice RDP is, but hey - this post definitely isn't only about Windows, and Windows isn't that popular on the server side. Maybe some people still remember telnel or rsh (Berkeley Remote Shell), but they should also say sad words: they all still work today and you will get the stable connection, wait a minute - the secure part is still far away from SSH.

How SSH works

To compare SSH with SSH3, we need to highlight - very briefly - the SSH protocol basics and key details. Stop, where is SSH2? The protocol was originally developed in two versions, called SSH-1 and SSH-2. Modern SSH clients mostly use SSH-2 because of a lot of problems in SSH-1, including short 2048-bit keys.

First of all, SSH uses a classic client-server framework and relies on three components:

• Transport layer for server authentication and integrity
• User authentication protocol gives the user access to the server.
• The connection protocol multiplexes the encrypted tunnel into multiple communication channels.

SSH uses public-key cryptography: a public key, a private key, and mathematics to verify who is who.

Two people share their public keys on known platforms, like their personal or work websites, Facebook, Tiktok, more platforms are even better. Then it's possible to use math to encrypt the message using a private key from one person (let's say Alice) and another person's key (hey, Bob). Thanks to the power of math and long keys (short keys aren't secure against bruteforce), it's possible to send an encrypted message from Alice to Bob, and only Bob is able to decrypt it. The reverse works the same way - this time Bob uses his private key and Alice's public key.

SSH supports several types of keys:

• RSA - integer factorization, created in 1977 by Rivest-Shamir-Adleman and based on an aglorithm of factoring large prime numbers.
• DSA - follows a similar scheme with a different algorithm: use a randomly generated number and sign the encrypted message with it and the private key.
• ECDSA - Elliptic Curve Discrete Logarithm, check the details here.
• Ed25519 - also uses Elliptic Curve discrete logarithm, but with SHA-512 hash sum and Curve25519 - elliptic curve used together with Elliptic-curve Diffie–Hellman key-agreement protocol.

Which is the best? RSA wins for portability, and Ed25519 has the best security, but requires the latest versions of SSH server and client. ECDSA is more compatible with Ed25519, but does not provide as strong security. Finally, we recommend using the latest SSH versions with Ed25519 keys.

Introduction to SSH3

The first thing you should know: SSH3 uses HTTP/3 and QUIC - modern and fast HTTP protocols, which can also be much more easily proxied over HTTP servers, widely used on galaxies of web hosting and cloud services. After 30 years since the invention of SSH only this factor is massive improvement.

Also, the protocol is described as a modern security solution without any compromises compared to SSH2. SSH3 allows organizations to provide their own identity or use the external one like Google or Github. Using HTTP3 and QUIC protocol, SSH3 allows a faster UDP port forwarding as a new feature to classic TCP forwarding.

HTTP protocol spend many years for improving his TLS extensions and make it secure for using payments, banking and e-commerce.
The another top improvements from using HTTP/3 protocol is multiplexing - it starts directly from URL level 'cause SSH instances can be accessing from the URL:

root@example.com
vs
https://example.com/org1/ssh3

HTTP/3 also allows proxies to be used as SSH gateways, where routing depends on the URL and can dynamically change the endpoint destination:

client -> https://example.com/proxy/

How the SSH3 connection works:

• The secure connection is initiated by the QUIC layer.
• SSH3 session initiated after HTTP/3 Extended CONNECT request.
• Now HTTP authentication is started.

As you can see, the design is both simple and extensible: the current HTTP authentication protocol can be changed:

• Password authentication using HTTP Basic authentication scheme - scheme basic and param with password hash encoded with base64.

• OpenID Connect - modern authentication using Google, Github or Microsoft services works thanks to HTTP OAUTHv2 and Bearer authentication scheme. To use this method successfully, you need to obtain a base64-encoded ID token from the identity provider.

• Public key authentication as in classic SSH. This method also uses the Bearer authentication scheme, but only uses the JWT token with the private key - there's no public-private exchange anymore. Note: yes, ~/.ssh/authorized_keys is also supported!

The establishment of a secure connection is faster in SSH3, and the lack of an exchange of public and private keys is the main reason why it's happening.

SSH3: how to setup it?

To use SSH3, we need the client and server to be up and running, just as in the SSH case. The easiest way is to use go install, you need to have Golang installed on your system for it to work:

go install github.com/francoismichel/ssh3/cmd/...@latest

If you want to install the binaries manually, just get them from here, extract them and run cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin.

Hiding your SSH3 server is recommended 'cause you can avoid infinite scans from Chinese IP's (thanks for this, Winnie!) and host your server on secret path - no need to use the 22nd port, port knocking or other tricks needed anymore! All you need is a secret link:

ssh3-server -bind 10.0.0.2:443 -url-path <YOUR_SECRET_PATH>

After this setup, you will be able to make SSH3 connection to 10.0.0.2:443/YOUR_SECRET_PATH, and Chinese bots can scan your server day and night without any success! They will only see 404 codes in response to their requests.

Some useful ssh3 server options:

• -bind string - bind to specific address
• -enable-password-login - password login is disabled by default, enable it if you need.
• -url-path string - hide your SSH3 server on secret path.

The killer feature - the next command is capable to generate a valid Lets Encrypt certificate:

ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3

Then this certificate can be used with the flags -cert string and -key string.

SSH3 tests

Terminal responsiveness

According to the above screenshot and public sources, there is a 0.5-1.5 second difference, and yes, SSH3 is faster! A second or two isn't a big difference, but if you have many servers and you need to connect and do some manual tasks a few times a week - you will lose a few minutes! And sitting and doing nothing before the SSH connection is established will make you nervous sometimes - this is my personal experience too.

Port Forwarding

We have tested the SSH3 and SSH connections with Linux server with 100MBit connection. The results are shown below:

• SSH connection speed over TCP - 53.4 Mbps.
• SSH3 connection speed over TCP - 31.2 Mbps.
• SSH3 connection speed over UDP - 17.9 Mbps.

SSH is faster on TCP by a large margin, and there's no way to test it on UDP because it's not supported.

Hovewer, SSH3 on UDP is significantly slower. Don't worry too much, there is time to improve SSH3 performance.

Final note

SSH3 is super perspective software, and it's fully capable to replace original SSH in 5-10 years. It's definitely not easy to beat the classic *nix software since late 70s, but let's remember what feature set we got with SSH3:

• Faster connection.
• No dedicated port required, works with HTTPS and secret or public link.
• Multiple HTTP authentication methods, including password, OAuth 2.0, and OpenID Connect.
• Forget about scanners.
• QUIC support: multipath connections and connection migration.
• UDP port forwarding.