On 2026-01-24, Jiri Navratil <[email protected]> wrote: > > I am using OpenBSD when teaching Unix operating system on University of > Ostrava. I have been asked by IT staff to remove hmac-sha1 from OpenSSH > on two servers with OpenBSD 7.8 amd64. > > Servers reported > > mac_algorithms: (10) > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > hmac-sha2-256 > hmac-sha2-512 > hmac-sha1 > > > I added to sshd_config > > MACs [email protected],[email protected],hmac-sha2-= > 512,hmac-sha2-256 > > and got > > mac_algorithms: (4) > [email protected] > [email protected] > hmac-sha2-512 > hmac-sha2-256
For ssh algorithms/ciphers I recommend using - to remove the ones that you don't want (or + if you need to add something for old devices), rather than explicitly listing "good" ones, otherwise you won't benefit from newer ones. > I have two questions, please. > > 1) What are your recommended safe mac_algorithms? I'd stick with the defaults unless I had some compliance silliness to deal with, then I'd just turn off the ones they won't accept ... The etm (encrypt-then-mac) ones are generally regarded as safer. The umac ones are fast (beneficial for bulk transfers). > 2) Why the default installation have enabled mac_algorithm hmac-sha1, > which the vulnerability scan tool reports as week?=20 The scan tool is being overzealous here, the main concrete way this might slightly improve safety is because it prevents very old clients that don't support newer HMACs from connecting... While it is less strong than other HMACs it is not really a problem. Consider what this is protecting: live network traffic which is also encrypted (so to be of use to an attacker the encryption would need to be broken too). It's not something where an offline "try to find hash collisions" would be any use. In particular it's very different to something like "sha1 hash protecting a downloaded file". -- Please keep replies on the mailing list.
