The "Corrupted MAC on input" error occurs when SSH's Message Authentication Code (MAC) verification fails during connection, indicating either network packet corruption, MAC algorithm incompatibility between client and server, or hardware issues. This error prevents successful SSH authentication and can usually be resolved by changing the MAC algorithm or investigating network stability.
SSH uses Message Authentication Codes (MACs) to verify that data packets haven't been corrupted or tampered with during transmission. The MAC is a cryptographic checksum calculated on each packet. When the MAC verification fails, it means the received packet's checksum doesn't match the expected value. This can happen due to several reasons: the packet was corrupted in transit, the client and server negotiated incompatible MAC algorithms, or there's a mismatch in how the MAC is being computed. The error is a security measureโSSH drops the connection to prevent data integrity issues.
The most common fix is to specify a known-compatible MAC algorithm on the client. Try using different MAC algorithms with the -o MACs option:
ssh -o MACs=hmac-sha2-512 user@host
ssh -o MACs=hmac-sha2-256 user@host
ssh -o MACs=hmac-sha1 user@hostIf one of these works, add it to your SSH config to make it permanent:
# Add to ~/.ssh/config
Host *
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1Or for a specific host:
Host myserver.example.com
MACs hmac-sha2-512,hmac-sha2-256This tells SSH to prefer these MAC algorithms in order, avoiding problematic ones.
Packet corruption often indicates hardware problems. Test your network connection:
# Check for dropped packets or errors on your interface
ip -s link show
# or on older systems:
ifconfig eth0
# Run a ping test to check for packet loss
ping -c 100 host.example.comLook for:
- Packet drops
- CRC errors
- Collisions
- High latency or timeouts
If you see errors, try:
1. Using a wired connection instead of WiFi
2. Checking cable connections
3. Testing with a different network port
4. Restarting your network interface:
sudo ifdown eth0 && sudo ifup eth0MTU (Maximum Transmission Unit) mismatches can cause packets to be fragmented and corrupted. Try lowering the MTU:
# Check current MTU
ip link show eth0
# Temporarily lower MTU for testing
sudo ip link set eth0 mtu 1400
# Test SSH
ssh user@hostIf this fixes the issue, make it permanent. For most Linux systems:
# Edit your network configuration (varies by distro)
# Ubuntu/Debian: /etc/network/interfaces
# CentOS/RHEL: /etc/sysconfig/network-scripts/ifcfg-eth0
# Add to interface config:
mtu 1400Standard MTU is 1500. Lowering to 1400-1280 can help with certain VPN or firewall configurations.
Older versions of OpenSSH and OpenSSL have known MAC algorithm bugs. Update your SSH software:
# On Ubuntu/Debian
sudo apt-get update
sudo apt-get install openssh-client openssh-server
# On CentOS/RHEL
sudo yum update openssh-clients openssh-server
# On macOS (with Homebrew)
brew install opensshCheck your current version:
ssh -VFor servers, also verify the remote host is running an updated OpenSSH version. Contact your server administrator if it's outdated.
If changing the MAC algorithm doesn't help, try specifying a different cipher along with the MAC:
ssh -o MACs=hmac-sha2-256 -o Ciphers=aes128-ctr user@host
ssh -o MACs=hmac-sha2-256 -o Ciphers=aes256-ctr user@hostAdd both to your SSH config for persistence:
Host myserver.example.com
MACs hmac-sha2-256
Ciphers aes128-ctr,aes256-ctrSometimes the combination of cipher and MAC matters more than either alone.
VPNs and firewalls can interfere with SSH packet integrity. Test if they're the cause:
# Temporarily disable VPN and try SSH
ssh user@host
# If it works without VPN, the issue is your VPN/firewallIf the VPN is required:
1. Contact your VPN provider about SSH compatibility
2. Try a different VPN protocol (OpenVPN vs. WireGuard, etc.)
3. Check if your firewall has SSH acceleration or deep packet inspection enabled
4. Consider using SSH over a different port or SSH tunneling as a workaround
MAC errors can occur if the system is under heavy load. Check system resources:
Client side:
# Check CPU, memory, disk usage
top
free -h
df -hServer side (if you have access):
uptime
free -h
df -hIf either system is near capacity, free up resources:
- Close unnecessary applications
- Kill zombie processes
- Clear disk space
- Reduce background services
Try SSH again after freeing resources. If problems persist, it's likely a network or hardware issue rather than resource contention.
Advanced troubleshooting:
Windows OpenSSH Specific Issue: Windows SSH (Win32-OpenSSH) has a known issue with UMAC-based algorithms ([email protected], [email protected]). Always use HMAC algorithms (hmac-sha2-512, hmac-sha2-256) when connecting from Windows.
SELinux and AppArmor: On hardened Linux systems, security modules might interfere with SSH packet processing. Check if your connection works with SELinux in permissive mode:
sudo setenforce 0 # Temporarily disable SELinux
ssh user@host
sudo setenforce 1 # Re-enableIf it works, you may need to adjust your SELinux policy.
Intermittent MAC Errors: If the error occurs sporadically, it's likely a network stability issue (WiFi dropping packets, ISP issues). Consider using SSH connection multiplexing to reduce the number of handshakes:
# Add to ~/.ssh/config
Host *
ControlMaster auto
ControlPath ~/.ssh/control-%h-%p-%r
ControlPersist 600ProFTPD SSH Subsystem: If running ProFTPD with SFTP, MAC incompatibilities can appear. Check your ProFTPD configuration and explicitly set compatible MACs in sftp protocol settings.
Testing MAC Algorithms: To see what MACs your server supports, try connecting with maximum verbosity:
ssh -vvv -o MACs=none user@host 2>&1 | grep -i macThis shows negotiated algorithms without actually connecting.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH