Fixing “Corrupted MAC on input” Error in Windows OpenSSH Client: SSH Authentication Failed


2 views

The "Corrupted MAC on input" error typically occurs when there's a mismatch between the Message Authentication Code (MAC) algorithms used by the SSH client and server. This is particularly common when using Windows' built-in OpenSSH client compared to third-party clients like PuTTY.

PuTTY often uses different default encryption settings than OpenSSH. While PuTTY might successfully negotiate a connection with older servers, Windows' OpenSSH client enforces stricter security standards by default.

# Example of PuTTY's default configuration (in registry):
[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshCiphers]
"KeyExchange"=hex(7):64,00,66,00,66,00,31,00,34,00,2d,00,73,00,68,00,61,00,32,00,\
  35,00,36,00,00,00,00,00

The most reliable fix is to explicitly specify compatible MAC algorithms in your SSH configuration:

# Create or modify ~/.ssh/config
Host your_server
    HostName 1.2.3.4
    User my_user
    MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1

If you have server access, updating the server's SSH configuration is more maintainable:

# Edit /etc/ssh/sshd_config
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
     hmac-sha2-512,hmac-sha2-256,hmac-sha1

Enable verbose output to identify the exact point of failure:

ssh -vvv my_user@1.2.3.4

Look for lines showing the MAC algorithm negotiation:

debug2: mac_setup: found hmac-sha1
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none

Windows OpenSSH might require additional configuration for proper crypto provider support:

# Check supported algorithms
ssh -Q mac

# Example output:
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512

While adding older MAC algorithms like hmac-sha1 works, consider the security trade-offs. For production systems, upgrading the server to support modern algorithms is preferable.

Here's a comprehensive client configuration that works with most servers:

Host *
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
         hmac-sha2-512,hmac-sha2-256,hmac-sha1
    KexAlgorithms diffie-hellman-group-exchange-sha256
    Ciphers aes256-ctr,aes192-ctr,aes128-ctr

When working with OpenSSH on Windows, you might encounter this specific error during authentication:

Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to x.x.x.x port 22: message authentication code incorrect

The puzzling part? The same connection works flawlessly through PuTTY. This discrepancy points to fundamental differences in how these clients handle encryption.

The error occurs during the Message Authentication Code (MAC) verification phase. Modern OpenSSH implementations have stricter cryptographic requirements than some older server configurations. The main culprits are typically:

  • Mismatched encryption algorithms between client and server
  • Incompatible MAC algorithms being negotiated
  • Windows-specific OpenSSH implementation quirks

First, check what algorithms your server supports by running this command from a working SSH client:

ssh -Q mac x.x.x.x
ssh -Q cipher x.x.x.x

Compare this with what your Windows OpenSSH client supports by running:

ssh -Q mac
ssh -Q cipher

Create or modify your ~/.ssh/config file with these directives:

Host your_server
    HostName x.x.x.x
    User your_username
    MACs hmac-sha2-256,hmac-sha1
    Ciphers aes256-ctr,aes192-ctr,aes128-ctr
    KexAlgorithms diffie-hellman-group-exchange-sha256

For temporary testing, you can specify these directly in your command:

ssh -o "MACs hmac-sha2-256" -o "Ciphers aes256-ctr" user@x.x.x.x

Enable verbose output to pinpoint exactly where the handshake fails:

ssh -vvv user@x.x.x.x

Look for these key negotiation phases in the output:

debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none

For legacy systems that absolutely won't cooperate, you can force older (less secure) protocols as a last resort:

Host legacy_server
    HostName x.x.x.x
    KexAlgorithms diffie-hellman-group1-sha1
    Ciphers 3des-cbc
    MACs hmac-sha1

Note: This should only be used for troubleshooting and never in production environments.

PuTTY's cryptographic preferences differ from OpenSSH's defaults. PuTTY:

  • Uses different algorithm preferences by default
  • Has more lenient protocol version handling
  • Includes workarounds for non-compliant servers

To make OpenSSH behave more like PuTTY, you might need to explicitly configure algorithm preferences as shown earlier.