Arch Linux

Zatena

Member

Registered: 2023-08-06

Posts: 37

SSH Cipher Hardening

Good Morning,

in Ubuntu envinments I use the tools ssh-audit in order to check the ssh cipher. Then I increase the cipher by using the following guide
https://www.ssh-audit.com/hardening_gui … _22_04_lts

Unfortunately when I use the following command in order to create the allowed cipher list I am not able to start sshd.

echo -e "\n# Restrict key exchange, cipher, and MAC algorithms, as per sshaudit.com\n# hardening guide.\nKexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,gss-curve25519-sha256-,diffie-hellman-group16-sha512,gss-group16-sha512-,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256\nCiphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\nMACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com\nHostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com" > /etc/ssh/sshd_config.d/ssh-audit_hardening.conf

I already renamed the ssh-audit_hardening.conf to 01-ssh-audit_hardening.conf but it didn't help. Does anyone an idea for me ?

frostschutz

Member

Registered: 2013-11-15

Posts: 1,486

Re: SSH Cipher Hardening

Mozilla also has some recommendations with explanations - https://infosec.mozilla.org/guidelines/openssh

Your link uses sed and awk, which might only work if a very specific configuration is already present. So it might not work outside the specific Ubuntu/Debian versions they're listing. You should check with `diff -u` whether it applied those changes correctly, or just edit files by hand.

If your SSH server does not have to be available to the public, consider putting it behind Wireguard/OpenVPN or use a firewall with ip limitation and/or port knocking. While it's still important to configure SSH itself correctly, it makes any attack so much harder if it's all wrapped in a VPN.

Zatena

Member

Registered: 2023-08-06

Posts: 37

Re: SSH Cipher Hardening

Hello,

I noticed the following line in the journal

Aug 14 09:34:05 bluetiger sshd[6361]: Unsupported KEX algorithm "gss-curve25519-sha256-"

Does anyone know why there is no support and how would I add the support ?

Zatena

Member

Registered: 2023-08-06

Posts: 37

Re: SSH Cipher Hardening

Mozilla also has some recommendations with explanations - https://infosec.mozilla.org/guidelines/openssh

If your SSH server does not have to be available to the public, consider putting it behind Wireguard/OpenVPN or use a firewall with ip limitation and/or port knocking. While it's still important to configure SSH itself correctly, it makes any attack so much harder if it's all wrapped in a VPN.

Hello Frostschutz,

vielen Dank für deine Info.

I didn't see your email before I wrote my comment. The configuration is made for my notebook that I will take with me to some conferences. It will also include fail2ban. I usually (on Ubuntu) do a complete hardening which includes to disable the ciphers. The ssh-audit tool is more flexible because it shows the "good" cipher and the guide I referenced is the best practice referenced by this tool.

Last edited by Zatena (2023-08-14 07:45:10)

Zatena

Member

Registered: 2023-08-06

Posts: 37

Re: SSH Cipher Hardening

So if I delete "gss-curve25519-sha256-" from the cipher list. I am able to connect to ssh again.
I didn't even know that it is possible to not support a cipher via ssh.

Does anyone know how I could add the support ?

frostschutz

Member

Registered: 2013-11-15

Posts: 1,486

Re: SSH Cipher Hardening

This seems to come from a patch that Debian/Ubuntu based distros are using.

http://archive.ubuntu.com/ubuntu/pool/m … ian.tar.xz :: debian/patches/gssapi.patch

This patch has been rejected upstream: "None of the OpenSSH developers are
in favour of adding this, and this situation has not changed for several
years.  This is not a slight on Simon's patch, which is of fine quality, but
just that a) we don't trust GSSAPI implementations that much and b) we don't
like adding new KEX since they are pre-auth attack surface.  This one is
particularly scary, since it requires hooks out to typically root-owned
system resources."

However, quite a lot of people rely on this in Debian, and it's better to
have it merged into the main openssh package rather than having separate
-krb5 packages (as we used to have).  It seems to have a generally good
security history.

https://sources.debian.org/patches/open … api.patch/

If ArchLinux is not using this same patch, you have to build your own, or simply go without supporting these ciphers.

Last edited by frostschutz (2023-08-14 08:32:07)

3beb6e7c46a615a

Member

Registered: 2021-03-27

Posts: 165

Re: SSH Cipher Hardening

You can't. The openssh version shipped in Arch does not support this algorithm.

Arch ships the latest upstream release of openssh which is considerably newer than the 8.9 version shipped in Ubuntu 22.04.  Expect issues if you try to apply suggestions for Ubuntu 22.04 to an Arch system literally.

Last edited by 3beb6e7c46a615a (2023-08-14 08:52:38)

schard

Forum Moderator

From: Hannover

Registered: 2016-05-06

Posts: 2,152

Website

Re: SSH Cipher Hardening

If you want to use a Curve25519 based key exchange cipher, OpenSSH ships a few you can select from:

0 ✓ neumann@workstation ~ $ ssh -Q kex | grep 25519
curve25519-sha256
curve25519-sha256@libssh.org
sntrup761x25519-sha512@openssh.com
0 ✓ neumann@workstation ~ $ 

---

Inofficial first vice president of the Rust Evangelism Strike Force

loqs

Member

Registered: 2014-03-06

Posts: 18,224

Re: SSH Cipher Hardening

For comparison
Default KexAlgorithms as of openssh 9.4p1-2

sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

ssh-audit.com KexAlgorithms

sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,gss-curve25519-sha256-,diffie-hellman-group16-sha512,gss-group16-sha512-,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256

So ssh-audit.com drops ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256 and adds gss-curve25519-sha256-,gss-group16-sha512-
Do you anticipate someone logging in via ssh using a key stored in a kerberos server?

Zatena

Member

Registered: 2023-08-06

Posts: 37

Re: SSH Cipher Hardening

For comparison
So ssh-audit.com drops ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256 and adds gss-curve25519-sha256-,gss-group16-sha512-
Do you anticipate someone logging in via ssh using a key stored in a kerberos server?

No, I don't think that think that someone will logging in via ssh using a key stored in a kerberos server.

loqs

Member

Registered: 2014-03-06

Posts: 18,224

Re: SSH Cipher Hardening

Do you anticipate someone logging in via ssh using a key stored in a kerberos server?

No, I don't think that think that someone will logging in via ssh using a key stored in a kerberos server.

Then if you agree with the ssh-audit.com's reasons for the deletions from the default KexAlgorithms just use those without the additions which can arguably be seen as  increasing the attack surface rather than hardening particularly as arch does not ship openssh patched for GSSAPI support.

mpan

Member

Registered: 2012-08-01

Posts: 1,366

Website

Re: SSH Cipher Hardening

A general note.

While setting cryptographic primitives for SSH, and in particular while applying choices suggested by third parties, mind there are two very distinct scenarios.

Multi-user server, where you must both set SSH to use reasonably secure primitives and to not be too restrictive at the same time. These two factors are opposing each other and can never be in agreement. This is what recommendations are about, usually. Finding the middle ground between accessibility and security, across users connecting from many different platforms.

Single-user server, where you are the sole person connecting. Often, though not always, just a single machine. In which case you can just choose a single set of primitives to use across your entire environment. For that recommendations will focus on what is secure enough, without caring much about portability. You simply choose, what fits you and you only. The risk is locking yourself out of a remote machine.

Do not use recommendations without recognizing, which scenario you are dealing with. Even the perfect suggestion is wrong, if applied to the wrong case.

---

Sometimes I seem a bit harsh — don’t get offended too easily!