Enforcing strong SSH message authentication code (MAC) algorithms protects management traffic against tampering and forgeries, ensuring configuration changes, file transfers, and administrative commands are not silently modified in transit. Tight MAC selection reduces exposure to older constructions with weaker integrity properties and aligns remote access with modern cryptographic policy baselines.
In OpenSSH, MAC negotiation occurs alongside key exchange and ciphers; the server proposes its configured MACs list, the client sends its own preferences, and both sides agree on a common algorithm. The MACs directive in /etc/ssh/sshd_config controls which algorithms the server is willing to use, so explicitly defining a hardened set prevents fallback to weaker options such as hmac-sha1 or legacy MD5-based modes.
Restricting MAC algorithms can affect compatibility with older clients, embedded systems, and network appliances that do not support modern hmac-sha2-256 or hmac-sha2-512 variants or the newer encrypt-then-MAC constructions. Before enforcing a strict MAC policy, ensure console or out-of-band access exists, take backups of SSH configuration, and plan a maintenance window so misconfiguration or client incompatibility does not cause an extended lockout.
Related: How to change SSH ciphers
Related: How to enforce strong SSH key exchange algorithms
$ whoami user
$ sudo sshd -T | grep macs macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
The sshd -T output shows the effective configuration after all includes and defaults are applied.
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%F)
Accidentally removing all acceptable authentication or MAC options in /etc/ssh/sshd_config can prevent new SSH logins until the backup is restored locally.
$ sudo nano /etc/ssh/sshd_config
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
Removing hmac-sha1 and older algorithms may block legacy clients that have not been updated to support hmac-sha2* MACs.
Ensure no additional MACs directives remain elsewhere in the file to avoid confusion about which setting is effective.
$ sudo sshd -t
No output from sshd -t indicates the configuration passes syntax checks.
$ sudo systemctl reload ssh
On systems where the service is named sshd instead of ssh, run sudo systemctl reload sshd.
$ ssh -vv user@host.example.net exit ##### snipped ##### debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 ##### snipped #####
Verification from an independent client confirms that the hardened MACs configuration is being enforced and that at least one strong algorithm is successfully negotiated.