Hello, you can worry all you want about algorithm hardening, but if you have an old openssh version without strict-kex I think ssh-audit does not validate if the CVEs it complains are fixed in a vendor version, but I would also check with Redhat if you have applied those errate as well. Given that your system also is missing the terrapin fix.. Kaushal Shriyan wrote on 27.01.2024 16:24 (GMT +01:00): > Starting audit of 192.168.0.108:22... > # general > (gen) banner: SSH-2.0-OpenSSH_8.0 > (gen) software: OpenSSH 8.0 > (gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+ > (gen) compression: enabled (zlib@xxxxxxxxxxx) > > # security > (cve) CVE-2021-41617 -- (CVSSv2: 7.0) privilege > escalation via supplemental groups > (cve) CVE-2020-15778 -- (CVSSv2: 7.8) command > injection via anomalous argument transfers > (cve) CVE-2019-16905 -- (CVSSv2: 7.8) memory > corruption and local code execution via pre-authentication integer > overflow > (cve) CVE-2016-20012 -- (CVSSv2: 5.3) enumerate > usernames via challenge response > > # key exchange algorithms ... > (NB: it is supposed to list this at the end: (kex) kex-strict-s-v00@xxxxxxxxxxx -- [info] pseudo-algorithm that denotes the peer...(CVE-2023-48795) Having said that none of the pre-made RHEL crypto policies can be considered optimal for SSH hardening, you would need to modify single algorithms, however i would recomment dont waste your tie with it and get your software updated instead. gruss bernd _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
