How to fix Corrupted MAC on input. in SSH

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

# 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:

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.

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

# 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:

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.

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

# 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

AEAD ciphers such as [email protected] and [email protected] 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:

ssh -o [email protected] user@host
ssh -o [email protected] user@host

If one works reliably, make it permanent:

# ~/.ssh/config
Host myserver.example.com
    Ciphers [email protected],[email protected]

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.

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.

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

If one works, persist it:

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

List the MAC algorithms your client supports with:

ssh -Q mac

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

# 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:

ssh -V

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