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.
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.
Read the error message first — it lists exactly what the remote side supports:
Unable to negotiate with 203.0.113.10 port 22: no matching MAC found. Their offer: hmac-sha1,hmac-sha1-96Then list the MACs your client can do, in preference order:
ssh -Q macIf 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 [email protected]) — always prefer that over a legacy one.
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:
If the server only offers hmac-sha1, use that explicitly:
ssh -o MACs=hmac-sha1 [email protected]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.
For a durable fix scoped to just the affected host, edit ~/.ssh/config (Linux/macOS) or %USERPROFILE%\.ssh\config (Windows):
Host legacy-server
HostName server.example.com
User myusername
MACs +hmac-sha1The + 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:
ssh legacy-serverIf 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:
Host legacy-server
HostName server.example.com
User myusername
MACs +hmac-sha1
KexAlgorithms +diffie-hellman-group14-sha1
HostKeyAlgorithms +ssh-rsaDo 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.
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:
Host legacy-*
MACs +hmac-sha1
KexAlgorithms +diffie-hellman-group14-sha1
HostKeyAlgorithms +ssh-rsaAny host you name to match (for example legacy-switch1, legacy-fw2) picks these up:
ssh legacy-switch1
ssh legacy-fw2Keep these overrides narrowly scoped — never weaken /etc/ssh/ssh_config system-wide, since that lowers the security of every outbound connection.
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:
MACs [email protected],[email protected],hmac-sha2-512,hmac-sha2-256Validate and reload the configuration (do not kill running sessions):
sudo sshd -t # test config syntax first
sudo systemctl reload sshd # or: sudo systemctl reload sshKeep 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:
sudo apt-get update && sudo apt-get install --only-upgrade openssh-server # Debian/Ubuntu
sudo dnf upgrade openssh-server # RHEL/Fedora
ssh -V # confirm versionFor 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.
scp and sftp do NOT accept the -m flag — passing -m hmac-sha1 to them will fail. They take SSH options via -o instead:
# scp uses -o MACs=... (note: -o, not -m)
scp -o MACs=hmac-sha1 file.txt [email protected]:/destination/
# sftp uses the same form
sftp -o MACs=hmac-sha1 [email protected]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:
scp file.txt legacy-server:/destination/
sftp legacy-serverThe same applies to rsync (rsync -e 'ssh -o MACs=hmac-sha1' ...) and git, which all use the SSH client and config underneath.
Inspect the negotiation directly. Verbose output shows each side's offered MACs and where they diverge:
ssh -vvv [email protected] 2>&1 | grep -i macPrefer ETM and SHA-2 MACs. When you have a choice, *[email protected] (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.
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation
How to fix "sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation" in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
No more authentication methods to try.
How to fix "No more authentication methods to try." in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH