SSHD using insecure ciphers

NethServer Version: 7.8.2003
Module: base

Problem: /etc/ssh/sshd_config contains NO cipher definitions, leaving SSHD to pick/use the defaults. Since the SSH server is configured to support Cipher Block Chaining (CBC) encryption, this may allow an attacker to recover the plaintext message from the ciphertext.


The cockpit doesn’t have any allowance for cipher selections or a ‘secure’ profile. Curiously, you [NS] recommend changing the port instead of using the fail2ban app, and don’t have any method to dismiss the alert presented. It’s an unusual way to face security.

No allowance is made to adjust ciphers here.

Solution: edit the /etc/ssh/sshd_config file to add a line:
ciphers aes128-ctr,aes192-ctr,aes256-ctr,,
Unfortunately, this will get overwritten if anyone adjusts the daemon through the gui.

Recommendation: Just add the ciphers line as part of a security patch. Alternately, add a check mark to use more secure ciphers.

On a personal note, I think security through obscurity is bad. If the problem (ciphers, tls, whatever) is fixed/hardened, then there’s no need to use a non-standard port.


this sounds good :smiley:

We have in the past made some security changes to openssl, but IIRC we rolled back. Maybe it is time to think also on it

I totally agree on this.
I asked to improve SSH cipher selection a couple of times, but my requests have been ignored :smiley:

I will try to add it back to the roadmap, but I do not know when it will be done.
Please feel free to open a PR to implement such feature!

Edit. Please remind that you can harden your configuration with a template-custom.

1 Like

Mostly agree, though I don’t see that using a non-standard port is bad as such–just not nearly as helpful as some people seem to assume. But I do wish the manager would let you dismiss these notifications.

According to the above link, OpenSSH was mitigated against that vulnerability in RHEL 5 ( At that time it was rated “low”.

Is it a real threat for us?

Some “weak” ciphers are fast. Sometimes faster encryption is needed, expecially to transfer large amount of data over a secure (enough) network.

You are right! Sadly, someone still prefers it…

…Maybe the same that are locked out of their servers because of F2B?


To make ik quick (and dirty) persistent:

mkdir -p /etc/e-smith/templates-custom/etc/ssh/sshd_config
echo 'ciphers aes128-ctr,aes192-ctr,aes256-ctr,,' > /etc/e-smith/templates-custom/etc/ssh/sshd_config/21Cyphers
signal-event nethserver-openssh-update

F2B has a 15 minute timer option so if someone was locked out, just wait. Alternately, whitelist your networks appropiately during config, or just don’t screw it up and get banned. :smiley:

Remove this space.

If I could I would. It seems I am not able to edit my post…
Maybe a helpfull moderator can do it. It does not show, but the space is there.

It was fixed the same day it was reported. I don’t see the space.

1 Like

where does come this solution, I can read that it could not be enough

In the past we did this but we rolled back

from :


It’s enough just to limit the ciphers in use to satisfy the security scans and eliminate the problems based on the CVEs.

it enables

# Require strong Encryption
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-256,hmac-sha2-512

braves asked for testing :