How to fix Corrupted MAC on input. in SSH

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 539 views

"Corrupted MAC on input" appears when SSH detects that a packet's Message Authentication Code does not match after the connection is already established. Because the MAC is verified per packet during the session, this almost always means data was corrupted on the wire by flaky hardware, MTU/offload issues, or a middlebox mangling packets — not a real algorithm mismatch. Fix it by isolating the faulty link or device, lowering MTU, or switching to an AEAD cipher.

Quick fix

Fixes Corrupted MAC on input.

# Check for drops, CRC/frame errors on your interface
ip -s link show
# or on older systems:
ifconfig eth0

# Run a sustained ping to check for loss or corruption
ping -c 100 host.example.com
  1. Check for network hardware and packet errors first
  2. Lower the MTU and rule out hardware offload
  3. Isolate VPNs, firewalls, and middleboxes
  4. Switch to an AEAD cipher
ssh — error
# Check for drops, CRC/frame errors on your interface
ip -s link show
# or on older systems:
ifconfig eth0
# Run a sustained ping to check for loss or corruption
ping -c 100 host.example.com
Corrupted MAC on input.

What this error means

SSH attaches a Message Authentication Code (MAC) to every packet so the receiver can verify the data arrived unmodified. "Corrupted MAC on input" means a packet was received but its MAC did not match the value SSH computed locally, so SSH aborts the connection to protect integrity. Critically, MAC verification happens per packet during an already-negotiated session, not during the initial algorithm handshake. That is why this message overwhelmingly points to packets being altered in transit (bad NIC/driver, cable/SFP, MTU or hardware-offload problems, or a firewall/VPN/middlebox rewriting traffic) rather than to a true MAC algorithm incompatibility. A genuine algorithm mismatch fails earlier in negotiation with a different message such as "no matching MAC found" — it does not produce corrupted-MAC-on-input.

Typical symptoms

  • SSH session drops mid-connection with 'Corrupted MAC on input' followed by 'ssh_dispatch_run_fatal: message authentication code incorrect'
  • Failures are intermittent — the connection works sometimes and breaks at other times
  • Only happens with specific networks, paths, or when going through a VPN/proxy, but works fine on others
  • Larger transfers (scp, sftp, git over ssh) trigger it while small interactive sessions seem fine
  • Manual SSH shows the error, but other protocols (HTTP, HTTPS) appear to work
  • Windows SSH client (Win32-OpenSSH) connecting to Linux servers fails with the MAC error

Common causes

  1. On-path data corruption from faulty network hardware: a flaky NIC or driver, a bad cable, or a failing SFP/switch port altering bytes in transit
  2. MTU mismatch or broken hardware offload (TSO/GSO/GRO/checksum offload) causing packets to be fragmented or mangled before SSH sees them
  3. A firewall, NAT, or middlebox performing deep packet inspection or 'SSH acceleration' that rewrites or corrupts SSH packets
  4. A VPN or proxy layer corrupting or reordering SSH protocol data
  5. Win32-OpenSSH using a UMAC-based MAC (umac-64/umac-128) that has had reliability bugs against some servers
  6. Outdated OpenSSH/OpenSSL with known packet-handling bugs
  7. A true MAC algorithm incompatibility — rare here, and it usually fails during negotiation with 'no matching MAC found' rather than this corrupted-MAC message

How to fix "Corrupted MAC on input."

1Check for network hardware and packet errors first

Because this error means a packet was altered on the wire, start by checking the physical/link layer — this is the most likely culprit.

bash
# Check for drops, CRC/frame errors on your interface
ip -s link show
# or on older systems:
ifconfig eth0

# Run a sustained ping to check for loss or corruption
ping -c 100 host.example.com

Look for non-zero CRC errors, drops, or collisions. If you see them, try:
1. A wired connection instead of WiFi
2. A different cable, port, or SFP
3. Reseating connections at both ends
4. Restarting the interface:

bash
sudo ip link set eth0 down && sudo ip link set eth0 up

If errors disappear on a different cable/port/NIC, you have found the root cause.

2Lower the MTU and rule out hardware offload

MTU mismatches and broken NIC offload features are a frequent source of corrupted packets, especially across VPNs and tunnels.

bash
# Check current MTU
ip link show eth0

# Temporarily lower MTU for testing
sudo ip link set eth0 mtu 1400

# Test SSH again
ssh user@host

If lowering MTU helps, also try disabling offload features, which can corrupt frames on some NICs/drivers:

bash
sudo ethtool -K eth0 tso off gso off gro off rx off tx off

If this stops the errors, make the MTU and/or offload settings permanent in your distro's network configuration (e.g. /etc/network/interfaces on Debian/Ubuntu, /etc/NetworkManager or netplan, or NIC config on RHEL). Standard MTU is 1500; 1400 or 1280 often resolves VPN/firewall paths.

3Isolate VPNs, firewalls, and middleboxes

VPNs, NAT devices, and firewalls with deep packet inspection or 'SSH acceleration' can rewrite or corrupt SSH packets in transit.

bash
# Temporarily disconnect the VPN and try again
ssh user@host

If it works without the VPN, the tunnel or a middlebox is corrupting traffic. Then:
1. Disable any SSH/ALG inspection or 'acceleration' features on the firewall
2. Try a different VPN protocol (e.g. WireGuard vs OpenVPN)
3. Lower the tunnel MTU
4. Test from a different network path to confirm where corruption is introduced

4Switch to an AEAD cipher

AEAD ciphers such as aes256-gcm@openssh.com and chacha20-poly1305@openssh.com perform authentication as part of the cipher and do not negotiate a separate MAC at all. Because of that, switching to an AEAD cipher is directly relevant to a MAC-on-input error and is a better experiment than changing the MAC list:

bash
ssh -o Ciphers=chacha20-poly1305@openssh.com user@host
ssh -o Ciphers=aes256-gcm@openssh.com user@host

If one works reliably, make it permanent:

bash
# ~/.ssh/config
Host myserver.example.com
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

Note this changes which integrity primitive is used; it does not fix corrupted hardware. If an AEAD cipher resolves the error while HMAC suites fail, suspect a UMAC/MAC implementation bug (see advanced notes) rather than the network.

5Try an explicit HMAC algorithm (mainly for Windows/UMAC issues)

If you connect from Win32-OpenSSH or suspect a UMAC-related bug, force a plain HMAC algorithm. This is a workaround for implementation quirks, not the primary fix for true on-path corruption.

bash
ssh -o MACs=hmac-sha2-512 user@host
ssh -o MACs=hmac-sha2-256 user@host

If one works, persist it:

bash
# ~/.ssh/config
Host myserver.example.com
    MACs hmac-sha2-512,hmac-sha2-256

List the MAC algorithms your client supports with:

bash
ssh -Q mac
6Update OpenSSH and OpenSSL

Older OpenSSH/OpenSSL releases have had packet-handling and UMAC bugs. Update both ends where possible.

bash
# Debian/Ubuntu
sudo apt-get update && sudo apt-get install openssh-client openssh-server

# RHEL/CentOS
sudo yum update openssh-clients openssh-server

# macOS (Homebrew)
brew install openssh

Check your version:

bash
ssh -V

Ask the server administrator to update too if the remote OpenSSH is old.

Advanced notes

Windows OpenSSH / UMAC (common real trigger): Win32-OpenSSH has had reliability problems with UMAC-based MACs (umac-128-etm@openssh.com, umac-64-etm@openssh.com). When connecting from Windows, prefer a plain HMAC (hmac-sha2-512, hmac-sha2-256) or an AEAD cipher (aes256-gcm@openssh.com, chacha20-poly1305@openssh.com), which avoids a separate MAC entirely.

Debugging negotiation: List the MAC algorithms your build supports with ssh -Q mac (and ssh -Q cipher for ciphers). To watch what actually gets negotiated, use verbose mode — note that -vvv *does* connect, it does not just print algorithms:

bash
ssh -Q mac
ssh -vvv user@host 2>&1 | grep -i 'mac\|cipher\|kex'

There is no MACs=none in stock OpenSSH; disabling integrity is not an option, and it would not be a valid fix anyway.

Intermittent errors: Sporadic corrupted-MAC failures almost always indicate an unstable link (WiFi loss, failing hardware, ISP issues). Capture interface error counters over time with watch -n5 'ip -s link show eth0' while reproducing, and compare across network paths to localize the bad segment.

ProFTPD SFTP subsystem: If running ProFTPD's mod_sftp, confirm its configured ciphers/MACs are current and consider enabling AEAD ciphers there as well.

Frequently asked questions

What does "Corrupted MAC on input." mean?
SSH attaches a Message Authentication Code (MAC) to every packet so the receiver can verify the data arrived unmodified. "Corrupted MAC on input" means a packet was received but its MAC did not match the value SSH computed locally, so SSH aborts the connection to protect integrity. Critically, MAC verification happens per packet during an already-negotiated session, not during the initial algorithm handshake.
How do I fix "Corrupted MAC on input."?
"Corrupted MAC on input" appears when SSH detects that a packet's Message Authentication Code does not match after the connection is already established. Because the MAC is verified per packet during the session, this almost always means data was corrupted on the wire by flaky hardware, MTU/offload issues, or a middlebox mangling packets — not a real algorithm mismatch. Fix it by isolating the faulty link or device, lowering MTU, or switching to an AEAD cipher.
What causes "Corrupted MAC on input."?
On-path data corruption from faulty network hardware: a flaky NIC or driver, a bad cable, or a failing SFP/switch port altering bytes in transit MTU mismatch or broken hardware offload (TSO/GSO/GRO/checksum offload) causing packets to be fragmented or mangled before SSH sees them A firewall, NAT, or middlebox performing deep packet inspection or 'SSH acceleration' that rewrites or corrupts SSH packets
Is the "Corrupted MAC on input." error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading