can you force ssh/d to *only* use AES?

[DiTBho]

ssh/d can be configured to use a variety of different symmetrical cipher systems { AES, BlowFish, 3DES, CAST128, Arcfour, ... }.

The server "sshd" and client "ssh" can both decide (negotiate?) on a list of their supported ciphers, ordered by preference.

Most widely used encryption methods in ssh/d are { AES, BlowFish, ... }, but on my router, by default, BlowFish is used if supported by the server, and according to my logs, it looks the only supported method.

Weird ... perhaps, because with an "embedded GNU/Linux server" profile ... AES encryption requires significant processor overhead, so someone forced a software method that requires less CPU resources 

Anyway, my router comes with Crypto-hw-Accelerator, but it doesn't implement BlowFish, and from testing ... no way! no ssh and no ssh tunnel will be hw-accelerated, although AES is supported by CryptoDev

Code: [Select]

looking for /dev/crypto0 ... found, ok
Got cbc(aes) with driver cbc-aes-hifn0
CryptoDev AES Test passed

On the same router, OpenVPN perfectly works with cbc-aes-hifn0, so the problem is somewhere with ssh/d.

Is it possible - somehow - to force ssh/d to ***only*** use AES?
If so, how?

[shapirus]

man sshd_config
(and man ssh_config, for the client)

/Ciphers

[DiTBho]

man sshd_config
(and man ssh_config, for the client)

already selected Ciphers { aes128-ctr, aes192-ctr, aes256-ctr, aes128-cbc } in both { /etc/ssh/sshd_config, /etc/ssh/ssh_config }, but it didn't help.

still say, AES not supported, and proposes BlowFish.

Is there a flag you have to configure when you compile OpenSSH?

[shapirus]

Well yes, apparently you will have to recompile the client or server that says that AES isn't supported to enable AES support. I guess that's some embedded system build which was compiled with a limited set of supported ciphers, for whatever reason.

[golden_labels]

What does `ssh -Q cipher` say?

[DiTBho]

What does `ssh -Q cipher` say?

on my GNU/Linux laptop

Code: [Select]

# ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
(note blowfish-cbc is missing)

on my router

Code: [Select]

# ssh -Q cipher
blowfish-cbc
(note blowfish-cbc is the only one listed)

I checked out, but do not see a definitive method for selecting AES specifically when using the command line or the settings in /etc/ssh/ssh_client.conf. The connection seems to default to blowfish no matter what you do, probably because it's the only one implemented, which sounds crazy, anyway: what if the client does not support blowfish-cbc?!? you are unable to connect?!?

According to this configuration, it really seems that this AES-* cipher is not available because I'm afraid not even implemented, otherwise it would be listed

Tired of fighting with what other people have done with their autobuilds, I am going to configure with a self made profile (Overlay) and re-compile net-misc/openssh (v9.2) from scratch both client and server, even if I am more interested about /usr/sbin/sshd (the server) as secure remote shell service the router needs.

And before I touch things in /etc/ssh/*config again with the new build, as proof-test I'll try to force ssh to use AES by something like

Code: [Select]

laptop# ssh -c aes128-cbc ucrouter

the hw-crypto processor in my router supports
aes128
aes192
aes256

so repeating the same test with the crypto-accelerator disabled and then enabled, I should see acceleration as well

Will it work, let's check it out 

[shapirus]

Code: [Select]

# ssh -Q cipher
blowfish-cbc
(note blowfish-cbc is the only one listed)

This is ssh client. However, I guess it can be assumed that the server is built with the same set of ciphers (only one cipher actually) too.

So blowfish-cbc has been disabled in ssh for a very long time now (since 2014) for being unsafe. Not sure if it's even still in code and just disabled as a compile-time option, or has been removed completely.

Apparently your router is very old. The best way to solve it would be to compile (or find a pre-built binary of) a more recent version of ssh server for your router that supports at least one of the ciphers that your ssh client supports. Second best would be to find/build an older standalone ssh binary for your computer that you can use to ssh into your router.

[DiTBho]

This is ssh client. However, I guess it can be assumed that the server is built with the same set of ciphers (only one cipher actually) too.

yup, on the router, both belongs to the same net-misc/openssh ebuild, both were compiled with the same profile.

So blowfish-cbc has been disabled in ssh for a very long time now (since 2014) for being unsafe. Not sure if it's even still in code and just disabled as a compile-time option, or has been removed completely.

that's what I have to understand.
a) enabled/disabled due to a compile-time configure flag?
b) enabled/disabled due to a compile-time patch?

I see a lot of patches applied to net-misc/openssh

Code: [Select]

HPN_VER="15.2"
HPN_PATCHES=
(
        ${PN}-${HPN_PV/./_}-hpn-DynWinNoneSwitch-${HPN_VER}.diff
        ${PN}-${HPN_PV/./_}-hpn-AES-CTR-${HPN_VER}.diff
        ${PN}-${HPN_PV/./_}-hpn-PeakTput-${HPN_VER}.diff
)
HPN_GLUE_PATCH="${PN}-9.2_p1-hpn-${HPN_VER}-glue.patch"
HPN_PATCH_DIR="HPN-SSH%%20${HPN_VER/./v}%%20${HPN_PV/_P/p}"

SCTP_VER="1.2"
SCTP_PATCH="${PARCH}-sctp-${SCTP_VER}.patch.xz"

X509_VER="14.1"
X509_PATCH="${PARCH}+x509-${X509_VER}.diff.gz"
X509_GLUE_PATCH="${P}-X509-glue-${X509_VER}.patch"
X509_HPN_GLUE_PATCH="${PN}-9.2_p1-hpn-${HPN_VER}-X509-${X509_VER}-glue.patch"

DESCRIPTION="Port of OpenBSD's free SSH release"
HOMEPAGE="https://www.openssh.com/"
SRC_URI="mirror://openbsd/OpenSSH/portable/${PARCH}.tar.gz
        ${SCTP_PATCH:+sctp? ( [url]https://dev.gentoo.org/~chutzpah/dist/openssh/[/url]${SCTP_PATCH} )}

PATCHES=
(
        "${FILESDIR}/${PN}-7.9_p1-include-stdlib.patch"
        "${FILESDIR}/${PN}-8.7_p1-GSSAPI-dns.patch" #165444 integrated into gsskex
        "${FILESDIR}/${PN}-6.7_p1-openssl-ignore-status.patch"
        "${FILESDIR}/${PN}-7.5_p1-disable-conch-interop-tests.patch"
        "${FILESDIR}/${PN}-8.0_p1-fix-putty-tests.patch"
        "${FILESDIR}/${PN}-8.0_p1-deny-shmget-shmat-shmdt-in-preauth-privsep-child.patch"
        "${FILESDIR}/${PN}-8.9_p1-allow-ppoll_time64.patch" #834019
        "${FILESDIR}/${PN}-8.9_p1-gss-use-HOST_NAME_MAX.patch" #834044
)
(basic patches)

plus other patches for the "hardened" profile
plus other patches for the "embedded" profile

****** too many patches, d'oh  ******

Apparently your router is very old

2023-03 built:

=net-misc/openssh-v9.2
=dev-libs/openssl-v3.0.8

according to current profile, they are 39 days older; probably it's the profile that is *VERY* old, so the person who prepared the Catalyst profile, used a very old profile on recent packages.

The best way to solve it would be to compile

I always compile things myself, this time I didn't look at the profile used for { net-misc/openssh,
dev-libs/openssl, sys-libs/zlib, ... } ssh and I simply "copied" (never copy&paste --> never, don't be lazy!!!) it and added it to the things Catalyst had to compile, with the result that whoever prepared it ... evidently made some strange choices and not documented.

So, I don't know what? why? how? ... but this time I'm taking two days to write my own profile, and recompile the whole set of packages.

[DiTBho]

Found an interesting note

The cipher called "blowfish" was only in the old protocol ssh-v1.
There is no cipher called "blowfish" in ssh-v2.
The new ssh-v2 has cipher called "blowfish-cbc".

[DiTBho]

for testing purposes, is there a way to force ssh (client and server) to use a "dummy cipher"?

Code: [Select]

dummy_cipher(x)
{
    return x;
}


[shapirus]

for testing purposes, is there a way to force ssh (client and server) to use a "dummy cipher"?

Code: [Select]

dummy_cipher(x)
{
    return x;
}


There used to be, but disabled since. I don't remember how it was called.

It looks like the "embedded" patch set is what you're after to disable. Its name implies that it might be removing "unnecessary" stuff to reduce the (both disk and memory) size of the binaries.

[golden_labels]

I believe it was OpenSSL that had a no-encryption cipher,⁽¹⁾ not OpenSSH.

Blowfish was neither turned off or patched out. It was never implemented in the first place for version 2 of the SSH protocol. And OpenSSH support for SSH version 1 was deleted in 2017. I do not know about implementations other than OpenSSH.

My guess is that the router uses software cut down as much as possible to save space. Why did they choose that set of features is a mystery to me: SSHv1 and Blowfish were known to be sinking fast even before OpenSSH removed it.

If you are going to recompile, consider the GCM mode instead of CBC or CTR. Unless you have a particular reason not to. GCM mode offers message authentication, so there is no need to apply a separate MAC.

⁽¹⁾  In OpenSSL it is NULL.

[DiTBho]

Blowfish was neither turned off or patched out. It was never implemented in the first place for version 2 of the SSH protocol.

Code: [Select]

src # unpack /distfiles/openssh-9.2p1.tar.gz
src # cd openssh-9.2p1
src/openssh-9.2p1 # grep blowfish * -r
openbsd-compat/Makefile.in:     blowfish.o \
openbsd-compat/blf.h: * Warning: For normal blowfish encryption only 56 bytes
openbsd-compat/blowfish.c:/* $OpenBSD: blowfish.c,v 1.20 2021/11/29 01:04:45 djm Exp $ */
regress/conch-ciphers.sh:         cast128-cbc blowfish 3des-cbc ; do

I haven't yet looked at these files, but it seems blowfish is still there, perhaps hidden 

[DiTBho]

If you are going to recompile, consider the GCM mode instead of CBC or CTR. Unless you have a particular reason not to. GCM mode offers message authentication, so there is no need to apply a separate MAC.

Thanks!

I am also considering a multi-profile, one with hpn enabled.

/usr/bin/ssh, /usr/sbin/sshd <---------------- common OpenSSH using ssl
/usr/bin/hpn-ssh, /usr/sbin/hpn-sshd <------ HPN-SSH is a series of modifications to OpenSSH

For this interesting feature:

Automatically resume failed transfers
There is nothing quite as frustrating as having scp or sftp fail in the middle of a large transfer. Currently ssh does not have a mechanism to allow for failed transfers to restart from the point of failure. HPN-SSH is proposing to develop a mechanism to reliably resume failed transfers. We expect to do this by computing a hash of the partial file and compare it to a corresponding byte range of the original file. If these match then HPN-SSH will append the missing information to the partial file. If they do not match then the entire file will be transferred.

[golden_labels]

I haven't yet looked at these files, but it seems blowfish is still there, perhaps hidden 

This seems to me like an implementation of Blowfish as a cryptographic primitive, not a cipher as used by SSH for encrypting connections. As a primitive it must be present for bcrypt (see “openbsd-compat/bcrypt_pbkdf.c”).

[DiTBho]

so, there is a "weak-ssl-ciphers" patch to disable all the support for SSL/TLS ciphers that are considered "weak"

A weak cipher is defined as an encryption/decryption algorithm that uses a key of insufficient length. Using an insufficient length for a key in an encryption/decryption algorithm opens up the possibility or probability that the encryption scheme could be broken and cracked.

[DiTBho]

Code: [Select]

2023-03-31--12-50-26---2023-04-01--00-19-54 - [ net-misc/openssh ] - success - root@dev2.40.0/4.8.3
successfully rebuilt, all tests passed

Code: [Select]

# ssh -Q cipher cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr

now it looks good!


while editing profile, I found an interesting note 

Warning, SSH is a commonly attacked service, it's strongly recommended to utilize Tools such as app-admin/sshguard and net-analyzer/fail2ban to monitor logs and to black-list remote users who have repeatedly attempted, yet failed to login.

[shapirus]

yeah, heed that warning.

pay attention to your passwords (just make them ridiculously long and use a password manager), stop using passwords at all and use key authentication, disable your ssh port for anything beyond a whitelisted set of addresses.

[golden_labels]

Warning, SSH is a commonly attacked service, it's strongly recommended to utilize Tools such as app-admin/sshguard and net-analyzer/fail2ban to monitor logs and to black-list remote users who have repeatedly attempted, yet failed to login.

Not allowing password authentication and disabling root makes the attacks almost impossible too. Moving the service to a non-default port is also a good idea. It does not provide real security, but drops amount of spam in logs to almost zero.

[ejeffrey]

I wouldn't bother with changing the port, and even stuff like fail2ban are pretty questionable.  These only block the low sophistication attacks and if you rely on them you will get hacked by high sophistication attacks.  If you protect against high sophistication attacks you don't need to worry about the easy stuff

There were botnets 15 years ago already that did distributed SSH brute force at a low rate to avoid IP based rate limiting.  But i've been locked out plenty of times by overzealous fail2ban use.  Rate limiting is a great idea it's just important to think about how to avoid turning into a DoS.

Disabling root login and disabling password login if you can't ensure users use strong and unique passwords is real security and if you have that you don't really need to bother with the other stuff.

[DiTBho]

This note about dev-libs/openssl is also interesting

2022/10, OpenSSL < v1.1.1 are EOL and contain known vulnerabilities, users should migrate to a newer branch.

Basically -> v1.1.1 ---> v3.0.8 

[golden_labels]

I wouldn't bother with changing the port, and even stuff like fail2ban are pretty questionable.  These only block the low sophistication attacks and if you rely on them you will get hacked by high sophistication attacks.  If you protect against high sophistication attacks you don't need to worry about the easy stuff

It was very clearly stated, that changing port is not meant to increase security. It can’t block “low sophistication attacks” either, as it does not affect the attack, once one is already being conducted. The purpose of changing the port to an uncommon value is — I will repeat that part too — removing noise from logs. The only security benefit is reducing discoverability in untargeted scans, and whatever one gets from higher quality logs.

[abeyer]

This note about dev-libs/openssl is also interesting

2022/10, OpenSSL < v1.1.1 are EOL and contain known vulnerabilities, users should migrate to a newer branch.

Basically -> v1.1.1 ---> v3.0.8 

Given the known insecurities you've already found, I'd question everything else on there, too. If you aren't able/willing to upgrade the distro altogether, I'd at least suggest looking at every version of every installed package and check again known issues.

[golden_labels]

Basically -> v1.1.1 ---> v3.0.8 

Do not be too scared, though. While OpenSSL 1.x is reaching EOL in September 2023 and it should be replaced, there was no gap. 3.0 is the first release available after 1.1.1. It’s also the LTS version, so there is no security implications of not going to 3.1 line. The bigger issue would be to have a low letter at the end of 1.1.1 version.

[DiTBho]

3.0 is the first release available after 1.1.1. It’s also the LTS version, so there is no security implications of not going to 3.1 line. The bigger issue would be to have a low letter at the end of 1.1.1 version.

Code: [Select]

rU dev-libs/openssl            v3.0.8-r3    v1.1.1s
rU dev-lang/python             v3.10.10_p3  v3.10.9-r1
rR net-misc/rsync              v3.2.4-r3
rR net-misc/wget               v1.21.3-r1
rU dev-lang/python             v3.11.2_p2   v3.11.1-r1
rR net-misc/curl               v7.87.0-r2
rU net-misc/openssh            v9.2_p1-r2   v9.1_p1
rU app-portage/portage-utils   v0.95        v0.94.3
rR net-vpn/vtun                v3.0.4-r2

This is the dev-libs/openssl update impact analysis.

Not bad, and it only costs a day to cross-compile on a tiny mac-mini/x86 cluster