precedence order in hardening and ssh-audit tool

[perkelix]

Looking at the preferred order for algorithms in the hardening guide and ssh-audit policies, I notice that the stronger variant isn't always the first one. For instance, the MAC policy prefers hmac-sha2-256-etm@openssh.com, followed by the 512 variant. Ditto for the diffie-hellman KEX.

At the very least, I think that ssh-audit scanning by policy should not fail if the administrator decided to put the stronger variant first. Just as long as all expected variants are enabled, it should pass the audit.

[egberts]

SHA2 contains different sizes of hash values:

• a default hash value size and
• a fallback of various smaller size hash value.

Typically, we go with SHA512 firstly and all other variants of 512 hash types before we slip down to SHA2.

SHA2 uses keys of varying lengths, including 224, 256, 384, and 512 to encrypt the data. SHA512 uses a 512 bit key for the purpose of encryption.

Offtopic: what is more secured hash functiom than SHA512 (as well as its lesser SHA2) are given in strongest to weakest order: Argon2, BCRYPT, and SCRYPT.

https://codesigningstore.com/what-is-the-best-hashing-algorithm#:~:text=To%20protect%20passwords%2C%20experts%20suggest,your%20best%20hashing%20algorithm%20choices.

Yes, I agree with the OP.

[jtesta]

For instance, the MAC policy prefers hmac-sha2-256-etm@openssh.com, followed by the 512 variant.

I made that decision for efficiency purposes. In my opinion, the 512-bit hash adds much more performance overhead than it gives back in security strength (as the longer hash tag needs to be transmitted along with all data packets). I recognize that others may have differing opinions on this. In that case, custom policies would be of interest; you can re-define the priority of the algorithms to accommodate your preference.

[perkelix]

As I wrote:

"At the very least, I think that ssh-audit scanning by policy should not fail if the administrator decided to put the stronger variant first. Just as long as all expected variants are enabled, it should pass the audit."

I really don't see how closing the bug fixed this.

[jtesta]

At the very least, I think that ssh-audit scanning by policy should not fail if the administrator decided to put the stronger variant first. Just as long as all expected variants are enabled, it should pass the audit.

I'd prefer to keep the built-in policies as-is due to my opinion on the efficiency/security tradeoff. But anyone of a different opinion can certainly use the custom policy framework, instead.