Alcatel Unleashed

After installing Mac OS 10.11 every attempt to login via ssh to OmniSwitch 6850E is met with the following error.

Corrupted MAC on input.
ssh_packet_read: message authentication code incorrect.

This is occurring on both machines that were upgraded from Mac OS 10.10 and ones that have a clean install of Mac OS 10.11. It also affects Windows VM's running on Mac OS. It does not however occur when ssh connecting to OmniSwitch 6900, 6860 or Force10 switches. Nor does the error occur when running Windows via boot camp.

All the 6850E's are running code 6.4.6.167.R01

Any advice / suggestions would be greatly appreciated.

Yes, have the same issue as well.

Cheers.

Do not have MacOS, so i can't verify.
Have you tried specifying algorithms as in https://bugzilla.redhat.com/show_bug.cgi?id=1230992 and see whether this works?
Similar seems to be noticed at
http://forums.fedora-fr.org/viewtopic.php?id=63992 unfortunately am I unable to understand french - but here it is explicitly about alcatel switches.

Afaik (if i guess right) check whether you have an uncommeted
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
line in your ssh_config and remove the comment sign?!?

Devnull thank you, your suggestion worked. For other users what I found that worked from the information devnull suggested type the following: ssh -m hmac-md5 user@ip_address. Of course for the user@ip_address use your actual login name and ip address. You should then get the password box to complete authentication.

You can check whether you can modify you ssh config (should be /etc/ssh/ssh_config or similar) - if i guess the frech right there is probably a commented line with this parameters.. then you don't have to specifiy that all the time

devnull once again you are a great help. I found the line: MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160 in the ssh_config file was already commented out, using vim I removed the # and saved the file. Now the login works as it originally did.

Thanks for the feedback. This will help other people with the same problems.

hehe, we recently changed ssh config on servers so they could ssh and auto backup omniswitch configs, now it's el capitano :>

I can confirm that my capitan also is not able to ssh into 6400s without changes to ssh config. mine had: works when replaced with

Hi!

I have used this fix a few times, but I figured it's time to put things straight once and for all. The fix to enable the line with MACs works:

MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160

What it does is that it tells the SSH client and the switch to use hmac-md5 as the first choice, a very weak algorithm for "authenticating" the encrypted data, or "verify" the contents. As in all secure communications, one should use the best available methods that are "practical" (not too time or resource consuming). I suggest you add this to your ssh_config file (and have no other lines with MACs in it):

MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-md5

Here, I put the best algorithms first, making SSH try those first. For an OS6250-8M switch running 6.7.1.108.R04, this will mean the parties agree on hmac-sha2-256, the second choice, since the 6250 seems not to be able to do hmac-sha2-512. Fair enough, we can settle for hmac-sha2-256. It's magnitudes better than hmac-md5 selected in the first version of the "fix"

The basic problem with all this seems to be that umac-64@openssh.com is in the MAC list of both sides rather early on and this will be negotiated unless you change the ssh_config as described. Debug output from ssh:

debug2: mac_setup: setup umac-64@openssh.com
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug2: mac_setup: setup umac-64@openssh.com
debug1: kex: client->server aes128-ctr umac-64@openssh.com none

The thing is that the 6250 seems to have an implementation of umac-64@openssh.com that isn't compatible with OpenSSL's. Instead of just removing umac-64@openssh.com, I add hmac-sha2-512,hmac-sha2-256 to the beginning of the config to make sure they're used if at all possible and also re-arrange the list to make the MACs appear in some order of "strength". Preferably, one should use only the two first (hmac-sha2-512 and hmac-sha2-256) as all others are considered weak and "hackable". I will leave them in the list for backwards compatibility with old SSH implementations and they should not be selected unless the other party (SSH server) really can't handle the more secure ones.

I hope this helps someone!

/Fredrik