I decided to harden one of our servers tonight after seeing your reply. You should always eat your own cooking! :-)
Original Message:
Sent: Tue October 07, 2025 02:06 PM
From: Sarvan Veluppillai
Subject: Weak ciphers and macs
Thank you Scott
Thank you all for the assistance! Based on the guidance provided by members Scott Schollenberger, and Satid, I've been able to successfully disable the weak ciphersm, KEX and MACs algorithms on my IBM i systems.
Here's the final configuration that resolved the issue:
Made changes to file:- sshd_config
# Include only the strong Kex algorythims
KexAlgorithms 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
# Include only the strong MACs algorythims
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
# Include only the strong Ciphers suites
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr
Systems Value changes: QSSLCSL
Includes the following ciphers
- *AES_128_GCM_SHA256
- *AES_256_GCM_SHA384
- *CHACHA20_POLY1305_SHA256
- *ECDHE_ECDSA_AES_128_GCM_SHA256
- *ECDHE_ECDSA_AES_256_GCM_SHA384
- *ECDHE_RSA_AES_128_GCM_SHA256
- *ECDHE_RSA_AES_256_GCM_SHA384
- *ECDHE_ECDSA_CHACHA20_POLY1305_SHA256
- *ECDHE_RSA_CHACHA20_POLY1305_SHA256
I tested the way Scott suggested –
ssh -vvv -o Ciphers=aes256-ctr -o MACs=hmac-sha1 user@systems
The connection was refused. Error message:
Unable to negotiate with <ip> port 22: no matching MAC found. Their offer: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
In addition, I made the following changes in TLSCONFIG using STRSST
· TLS Default Signature Algorithm Certificate List : TLSCONFIG -defaultSignatureAlgorithmCertificateList:36,35,34,86,85,84,16,15,14
· TLS Supported Signature Algorithm Certificate List: TLSCONFIG -supportedSignatureAlgorithmCertificateList:36,35,34,86,85,84,16,15,14
· TLS Default Signature Algorithm List : TLSCONFIG -defaultSignatureAlgorithmList:36,35,34,86,85,84,16,15,14
· TLS Supported Signature Algorithm List: TLSCONFIG -supportedSignatureAlgorithmList:36,35,34,86,85,84,16,15,14
· TLS Eligible Default Cipher Suites: TLSCONFIG -eligibleDefaultCipherSuites:YF,YG,YB,YC,YD,YE,YH,YI,YJ
· TLS Default Cipher Suite List : CHGSYSVAL SYSVAL(QSSLCSL) VALUE('*AES_256_GCM_SHA384 *AES_128_GCM_SHA256)
TLS Cipher Suites:
YF - AES_128_GCM_SHA256
YG - AES_256_GCM_SHA384
YB - ECDHE_ECDSA_AES_128_GCM_SHA256*
YC - ECDHE_ECDSA_AES_256_GCM_SHA384*
YD - ECDHE_RSA_AES_128_GCM_SHA256*
YE - ECDHE_RSA_AES_256_GCM_SHA384*
YH - CHACHA20_POLY1305_SHA256*
YI - ECDHE_ECDSA_CHACHA20_POLY1305_SHA25
YJ - ECDHE_RSA_CHACHA20_POLY1305_SHA256
TLS Signature Algorithm List:
36 - ECDSA with SHA512
35 - ECDSA with SHA384
34 - ECDSA with SHA256
86 - RSA PSS with SHA512
85 - RSA PSS with SHA384
84 - RSA PSS with SHA256
16 - RSA with SHA512
15 - RSA with SHA384
14 - RSA with SHA256
STRSST menu option:
- 1. Start a service tool
- 4. Display/Alter/Dump
- 1. Display/Alter storage
- 2. Licensed Internal Code (LIC) data
- 14. Advanced analysis
This thread can be closed as resolved.
Thank you all.
------------------------------
Sarvan Veluppillai
Original Message:
Sent: Tue October 07, 2025 01:13 PM
From: Scott Schollenberger
Subject: Weak ciphers and macs
So what is your final configuration? Close the problem with the final solution so to speak.
------------------------------
Scott Schollenberger
Original Message:
Sent: Tue October 07, 2025 12:31 PM
From: Sarvan Veluppillai
Subject: Weak ciphers and macs
Hi Scott
Your suggestion worked.. Thanks a lot for the help..
Thanks
Original Message:
Sent: 10/7/2025 11:02:00 AM
From: Scott Schollenberger
Subject: RE: Weak ciphers and macs
Doing some more research online and with ChatGPT, your issue points to this explanation:
Short version: your MACs "isn't working" because your sessions are almost certainly negotiating an AEAD cipher (e.g., chacha20-poly1305@openssh.com
or aes*-gcm@openssh.com
). With AEAD, there is no separate MAC-so the client's -o MACs=hmac-sha1
is ignored and the connection still succeeds. MAC rules only apply when you use non-AEAD ciphers like aes*-ctr
.
What to do
Prove it's AEAD (and thus bypassing MACs):
Test MAC enforcement correctly (force non-AEAD):
This should fail if your server MACs are set to only SHA-2 variants:
ssh -vvv \ -o Ciphers=aes256-ctr \ -o MACs=hmac-sha1 \ user@host
Because aes256-ctr
is non-AEAD, the MAC now matters-and since the server allows only hmac-sha2-*
, it should refuse.
This should succeed (allowed MAC + non-AEAD):
ssh -vvv \ -o Ciphers=aes256-ctr \ -o MACs=hmac-sha2-256 \ user@host
If you want to guarantee MAC enforcement always "shows up," temporarily remove AEAD ciphers on the server while testing:
Ciphers aes256-ctr,aes128-ctr
Then restart SSHD and retest with -o MACs=...
. Put AEAD ciphers back when you're done; they're preferred.
Double-check the server's effective config:
/usr/sbin/sshd -T | /QOpenSys/usr/bin/grep -E '^(ciphers|macs|kexalgorithms)'
Make sure macs
contains only your SHA-2 choices and there isn't a later Include
or Match
block re-enabling hmac-sha1
.
Common gotchas (quick checklist)
You tested with AEAD cipher in use → MAC list doesn't apply. ✅
Multiple MACs
lines → only the last one takes effect.
Edited the wrong file (ssh_config
is client; you want sshd_config
).
Didn't restart cleanly (ENDTCPSVR SERVER(*SSHD)
then STRTCPSVR SERVER(*SSHD)
).
An Include
or Match
block later in the file overrides your global MACs
.
Bottom line: nothing's "wrong" with your MACs
setting. You were just negotiating AEAD, which makes separate MAC choices moot. Force a non-AEAD cipher during testing (or temporarily remove AEAD on the server), and you'll see MAC enforcement behave exactly as expected.
While I haven't change my IBM i sshd configuration as you have, doing the ssh -vvv user@system against my server did show that the AEAD cipher were used:
debug1: kex: algorithm: curve25519-sha256debug1: kex: host key algorithm: ssh-ed25519debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: nonedebug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
Here is a good write-up I found explaining best practices and it started from the same premise as your current project -- reviewing the sshd configuration and hardening it
https://security.stackexchange.com/questions/257670/ssh-server-configuration-best-practices?newreg=ac3bdc84496b42f69a26a4a4633c7466
------------------------------
Scott Schollenberger
Original Message:
Sent: Tue October 07, 2025 09:23 AM
From: Sarvan Veluppillai
Subject: Weak ciphers and macs
Hi Scott and Satid,
As per you comments, I made changes to system value.
I removed multiple lines as follows.
# Include only the strong Kex algorythims
KexAlgorithms 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
# Include only the strong MACs algorythims
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
# Include only the strong Ciphers suites
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr
I was able to test Kex and ciphers successfully. But I when I tested macs for ssh, it was not blocking.
This is how I tested it
ssh -o MACs=hmac-sha1 user@as400systems.sbn
I am at 7.4.
Any idea what I missed..
Thanks
Original Message:
Sent: 10/2/2025 10:25:00 PM
From: Scott Schollenberger
Subject: RE: Weak ciphers and macs
Don't repeat the same keyword on multiple lines in the sshd_config file; only the last one is used.
You have three KexAlgorithms lines – only the last will be effective.
Put everything on one line:
KexAlgorithms 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
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr
I saw another port about the QSSL* system values. No expert here, but I don't believe they have any effect on OpenSSH. They are only related to the TLS cipher suites that apply to the IBM servers like FTP, Telnet, HTTP, etc.
Scott A. Schollenberger
Original Message:
Sent: 10/2/2025 7:37:00 PM
From: Sarvan Veluppillai
Subject: Weak ciphers and macs
I need to disable weak ciphers and macs algorithm for ssh on IBMi systems.
I have edited /qopensys/QIBM/UserData/SC1/OpenSSH/etc/sshd_config
Added the following:
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Restarted the ssh server using - strTCPSVR SERVER(*SSHD)
I test it using - ssh -vvv -0 MACs=hmac-sha1 <user@systems.name>
It is still accepting the macs defined here.
How can I disables weak ciphers, MACs and KEX algorithm.
Thanks
------------------------------
Sarvan Veluppillai
------------------------------