How to fix Unable to negotiate with hostname port 22: no matching MAC found. in SSH

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 368 views

SSH fails when client and server share no common MAC algorithm during negotiation, usually because a modern client dropped the legacy MACs an old server or device still offers.

Quick fix

Fixes Unable to negotiate with hostname port 22: no matching MAC found.

Unable to negotiate with 203.0.113.10 port 22: no matching MAC found. Their offer: hmac-sha1,hmac-sha1-96
  1. Inspect the server's MAC offer and your client's supported MACs
  2. Make a one-time connection by enabling a compatible MAC
  3. Add a per-host entry to your SSH client config (recommended client-side fix)
  4. Scope legacy algorithms to a group of hosts with a wildcard
ssh — error
Unable to negotiate with 203.0.113.10 port 22: no matching MAC found. Their offer: hmac-sha1,hmac-sha1-96
Unable to negotiate with hostname port 22: no matching MAC found.

What this error means

SSH uses Message Authentication Codes (MACs) to verify the integrity and authenticity of every encrypted packet. During the connection handshake the client and server each advertise the MAC algorithms they support and pick the first mutual match. If they have no algorithm in common, negotiation aborts with "no matching MAC found". In practice this almost always happens when a modern SSH client (OpenSSH 7.x+) connects to an older server, embedded device, or network appliance that only offers legacy algorithms such as hmac-sha1. Recent OpenSSH releases have narrowed their default MAC list and prefer encrypt-then-MAC (ETM) variants and SHA-2 MACs, so the legacy peer's offer no longer overlaps the client's defaults. The error string includes a "Their offer:" list showing exactly which MACs the remote side supports. The correct fix is to make the two sides agree on an algorithm both can do — ideally by enabling a stronger MAC on the server, or as a stopgap by re-enabling a specific legacy MAC on the client only for that host.

Typical symptoms

  • Connection aborts immediately with 'Unable to negotiate ... no matching MAC found'
  • The error includes a 'Their offer:' list of the remote side's supported MAC algorithms
  • Connecting from an older machine works, but the same host fails from a newer machine with up-to-date OpenSSH
  • scp, sftp, rsync-over-ssh, and git-over-ssh to the same host all fail identically
  • CI/CD jobs fail when connecting to legacy servers or network appliances
  • Connecting to switches, routers, firewalls, or load balancers fails while normal Linux hosts work

Common causes

  1. A modern SSH client (OpenSSH 7.x+) connects to a legacy server or appliance that only offers older MACs such as hmac-sha1, which the client no longer enables by default.
  2. The remote is network equipment (switch, router, firewall, load balancer) or an embedded device whose SSH stack has not been updated and offers only deprecated algorithms.
  3. A site or organisation hardening policy (e.g. a custom MACs line in ssh_config or sshd_config) removed the algorithm the other side requires.
  4. An SSH/crypto upgrade on one side changed the default algorithm set so the two peers no longer overlap.
  5. A middlebox (SSH-aware firewall or proxy) is interfering with or rewriting the algorithm negotiation.

How to fix "Unable to negotiate with hostname port 22: no matching MAC found."

1Inspect the server's MAC offer and your client's supported MACs

Read the error message first — it lists exactly what the remote side supports:

bash
Unable to negotiate with 203.0.113.10 port 22: no matching MAC found. Their offer: hmac-sha1,hmac-sha1-96

Then list the MACs your client can do, in preference order:

bash
ssh -Q mac

If the server's offer and your client's list share no entry, you have confirmed the cause. Note any modern algorithm the server offers (for example hmac-sha2-256 or hmac-sha2-256-etm@openssh.com) — always prefer that over a legacy one.

2Make a one-time connection by enabling a compatible MAC

Pick the strongest algorithm from the server's offer and enable it for this single connection. Prefer a SHA-2 ETM MAC if the server offers one:

bash
ssh -o MACs=hmac-sha2-256-etm@openssh.com user@server.example.com

If the server only offers hmac-sha1, use that explicitly:

bash
ssh -o MACs=hmac-sha1 user@server.example.com

Note: ssh also accepts the shorthand -m hmac-sha1, but -o MACs=... is the portable form that also works for scp and sftp (see step 6), so prefer it. hmac-sha1 is weaker than the SHA-2 MACs and should only be used when the peer offers nothing better.

3Add a per-host entry to your SSH client config (recommended client-side fix)

For a durable fix scoped to just the affected host, edit ~/.ssh/config (Linux/macOS) or %USERPROFILE%\.ssh\config (Windows):

bash
Host legacy-server
    HostName server.example.com
    User myusername
    MACs +hmac-sha1

The + prefix appends hmac-sha1 to your client's existing (modern) defaults instead of replacing them, so strong algorithms are still preferred and the legacy one is used only when nothing better is available. Then connect with:

bash
ssh legacy-server

If the server is very old you may also need to re-enable a legacy key-exchange or host-key algorithm. Use group14 (2048-bit) rather than the broken group1, and only add what the server actually requires:

bash
Host legacy-server
    HostName server.example.com
    User myusername
    MACs +hmac-sha1
    KexAlgorithms +diffie-hellman-group14-sha1
    HostKeyAlgorithms +ssh-rsa

Do not add hmac-md5 (cryptographically broken) or diffie-hellman-group1-sha1 (1024-bit, considered broken). If a device truly offers nothing stronger, treat it as untrusted: isolate it on a management network and replace or upgrade it.

4Scope legacy algorithms to a group of hosts with a wildcard

If you regularly reach several legacy hosts, use a wildcard Host block in ~/.ssh/config so the relaxed settings apply only to those hosts and never globally:

bash
Host legacy-*
    MACs +hmac-sha1
    KexAlgorithms +diffie-hellman-group14-sha1
    HostKeyAlgorithms +ssh-rsa

Any host you name to match (for example legacy-switch1, legacy-fw2) picks these up:

bash
ssh legacy-switch1
ssh legacy-fw2

Keep these overrides narrowly scoped — never weaken /etc/ssh/ssh_config system-wide, since that lowers the security of every outbound connection.

5Fix the root cause: enable a modern MAC on the server

The real fix is to stop the server from offering only legacy algorithms. On the remote host, add or update the MACs line in /etc/ssh/sshd_config to include strong SHA-2 MACs:

bash
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

Validate and reload the configuration (do not kill running sessions):

bash
sudo sshd -t                     # test config syntax first
sudo systemctl reload sshd        # or: sudo systemctl reload ssh

Keep an existing session open while you test a fresh connection, so a config mistake can't lock you out. If the SSH daemon is too old to support SHA-2 MACs at all, upgrade OpenSSH:

bash
sudo apt-get update && sudo apt-get install --only-upgrade openssh-server   # Debian/Ubuntu
sudo dnf upgrade openssh-server                                              # RHEL/Fedora
ssh -V                                                                       # confirm version

For network appliances, apply the vendor firmware update or enable stronger MACs in the device's crypto/SSH settings. This removes the need for any client-side workaround.

6Apply the same option to scp and sftp

scp and sftp do NOT accept the -m flag — passing -m hmac-sha1 to them will fail. They take SSH options via -o instead:

bash
# scp uses -o MACs=... (note: -o, not -m)
scp -o MACs=hmac-sha1 file.txt user@server.example.com:/destination/

# sftp uses the same form
sftp -o MACs=hmac-sha1 user@server.example.com

Better still, add the Host entry from step 3 to ~/.ssh/config — then scp and sftp pick up the MACs setting automatically and you don't pass any algorithm flags:

bash
scp file.txt legacy-server:/destination/
sftp legacy-server

The same applies to rsync (rsync -e 'ssh -o MACs=hmac-sha1' ...) and git, which all use the SSH client and config underneath.

Advanced notes

Inspect the negotiation directly. Verbose output shows each side's offered MACs and where they diverge:

bash
ssh -vvv user@server.example.com 2>&1 | grep -i mac

Prefer ETM and SHA-2 MACs. When you have a choice, *-etm@openssh.com (encrypt-then-MAC) SHA-2 variants are stronger than the older encrypt-and-MAC modes and far stronger than hmac-sha1. Only fall back to hmac-sha1 when the peer offers nothing better, and never use hmac-md5 (collision-broken) — OpenSSH disabled it for good reason.

Terrapin (CVE-2023-48795) is a separate issue. That prefix-truncation attack concerns ChaCha20-Poly1305 and ETM MACs combined with certain handshake conditions, and is mitigated by the "strict KEX" feature in modern OpenSSH on both ends. It is unrelated to "no matching MAC found"; do not downgrade algorithms to work around it.

Treat legacy-only peers as a risk. A device that can offer only hmac-sha1 (or worse) is running outdated crypto. Patch or replace it, restrict access to a dedicated management network, or reach it through a hardened bastion host rather than relaxing your client defaults globally.

Windows and PuTTY. Native OpenSSH on Windows 10/11 behaves like the Linux client and reads ~/.ssh/config. PuTTY maintains its own algorithm list and may negotiate with some legacy devices when OpenSSH won't, but the right long-term answer is still to update the server or device.

Frequently asked questions

What does "Unable to negotiate with hostname port 22: no matching MAC found." mean?
SSH uses Message Authentication Codes (MACs) to verify the integrity and authenticity of every encrypted packet. During the connection handshake the client and server each advertise the MAC algorithms they support and pick the first mutual match. If they have no algorithm in common, negotiation aborts with "no matching MAC found".
How do I fix "Unable to negotiate with hostname port 22: no matching MAC found."?
SSH fails when client and server share no common MAC algorithm during negotiation, usually because a modern client dropped the legacy MACs an old server or device still offers.
What causes "Unable to negotiate with hostname port 22: no matching MAC found."?
A modern SSH client (OpenSSH 7.x+) connects to a legacy server or appliance that only offers older MACs such as hmac-sha1, which the client no longer enables by default. The remote is network equipment (switch, router, firewall, load balancer) or an embedded device whose SSH stack has not been updated and offers only deprecated algorithms. A site or organisation hardening policy (e.g. a custom MACs line in ssh_config or sshd_config) removed the algorithm the other side requires.
Is the "Unable to negotiate with hostname port 22: no matching MAC found." error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading