SSH is the de facto standard for connecting to a Linux or Unix system at the command-line.  This Secure SHell protocol is surprisingly complicated under the hood.

When I started with Unix, we only had telnet, which was brain-dead simple.  All it did was connected a tty given by the server to the client, and everything after that was handled by the OS.  SSH does a lot more, because it needs to negotiate and properly encrypt the connection.

And while telnet is largely unchanged today, SSH evolves constantly.  There’s no less than three different encryption components, and all of them are under constant cryptanalysis.  What is considered a strong cipher today may be weak by the time you read this.

How can you stay on top of this?  To some extent, you don’t have to.  SSH is regularly patched and updated, though it’s likely that your particular distro’s SSH is a bit behind the latest release.  For example, on Debian 12, the current version is 9.2, whereas OpenSSH 10 was released about 4 months ago.  Nevertheless, the changing in and out of ciphers and algorithms (and more mundane bug squishing) happens routinely, so the SSH you run on your server today is probably quite different than the one you ran five years ago.

But if you want to go a step further, you can run ssh-audit.

First, let’s briefly discuss how SSH works.

How SSH Does What It Does

When your client opens a connection to a server (e.g., “ssh server.example.com”), the server responds with some basic info including the software version string.  Then both parties discuss what they’re going to use for the following:

• Key exchange algorithm (examples: curve25519-sha256, diffie-hellman-group14-sha256)

• Encryption algorithm (examples: chacha20-poly1305, aes256)

• Message authentication code (MAC) algorithm (examples: hmac-sha2-256, hmac-sha2-512)

• Compression (on or off)

The server has a preferred list of these algorithms, and will start with its first choice and work down the list until it finds one the client also supports.

Once a key exchange (kex) algorithm is chosen, the server and client derive a shared session key (encryption algorithm) and MAC.  These are then put in use, so from this point forward, the communication is encrypted, even though there’s been no authentication yet.

And that’s the next step.  The server proves who it is through its host key, and the client either accepts this authentication or warns the user.  Likewise, the user’s key (or passphrase) is used to authenticate the user.

Assuming everyone is who they say they are, client and server now begin exchanging encrypted packets, using the chosen encryption algorithm and validated with the chosen MAC.

All of this happens in the blink of an eye, but if you run ssh with -vv flag, you’ll see the complex procedure needed to establish a safe communication channel.

Audit!

Let’s take a look at ssh-audit.  It’s available in apt, so just

apt update && apt -y install ssh-audit

You can run it by pointing it at an address.  You probably want to point it at your server’s localhost:

ssh-audit 127.0.0.1

If you’ve changed SSH ports, then use the -p flag:

ssh-audit -p 2222 127.0.0.1

Here’s the output from a freshly updated Debian 12 system:

All that red!  So what does this mean?

• There are some weak key exchange algorithms in use
• There’s a weak host key algorithm in use

Does this mean I’m going to be hacked!?!?

Not necessarily.  A weak encryption algorithm doesn’t mean that it’s vulnerable, just that it’s not as strong as others.  Cryptography is one of those fields where the subject matter is so complicated that best practice is to err way on the side of safety.

The cool thing is that you can go to the guide provided, click your OS, and it will give you the commands to fix all the problems.  These involve regenerating keys using more secure ciphers, changing which keys are used, and restricting which algorithms are offered for use.

Also, you can implement improvements on the client side as well.  If the client refuses to use weak algorithms, then the server won’t use them either.  This is also covered in the guide.

I was curious how OpenBSD would perform, since OpenBSD is the home of the OpenSSH project.  I fired up an OpenBSD 7.7, which was released on April 28, 2025 and includes OpenSSH 10.0.  Here’s the report:

So not perfect either.

raindog308

Raindog308 is a longtime LowEndTalk community administrator, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, Raindog runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, Raindog is a lover of German Shepherds, high-quality knives, target shooting, theology, tabletop RPGs, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.