Fixing macOS Sierra/OpenSSH 7.x Compatibility

aaa cliI’ve seen this question come up several times from users of macOS Sierra who use SSH after upgrading. It usually goes something like, “Has anyone seen this since upgrading to Sierra?”

Unable to negotiate with port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Another issue you might come across is your public key ceasing to work. If you connect with the verbose option (ssh -v hostname), you might catch a bit like this in the output:

Skipping ssh-dss key /Users/scottm/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

These aren’t a Sierra issue per-se, but is more specifically related to the upgrade from OpenSSH 6.9 in El Capitan to OpenSSH 7.2 in Sierra. OpenSSH deprecated a number of methods and algorithms in 7.0. They are still supported, but are disabled by default. For more information, check out OpenSSH: Legacy Options.

That’s all fine and dandy, but what you really want is a solution. You probably have some security appliance, router, or similar that doesn’t support any other methods and you just need it to work. Perhaps like me, you have an older private key that isn’t up to the new requirements, but you still need to use it. The options to fix these issues are KexAlgorithms +diffie-hellman-group1-sha1 and PubkeyAcceptedKeyTypes=+ssh-dss. You can add these at the command line (ssh -o PubkeyAcceptedKeyTypes=+ssh-dss hostname), but that’s kind of a pain.

A more convenient way to use them is to add these options to your ~/.ssh/config file. If you don’t already have this config file, it’s a plain text file you can create with your text editor of choice. At the top of the file, add:

# Settings for all hosts
KexAlgorithms +diffie-hellman-group1-sha1

Now your public key and the key exchange algorithm will work anywhere you connect. Perhaps you’d like a bit more granularity?

# Settings for all hosts

# Host specific settings
Host *
 KexAlgorithms +diffie-hellman-group1-sha1
 User username

This allows the public key for all hosts, but only allows the diffie-hellman-group1-sha1 algorithm to be used with hosts matching the wildcard. Additionally, this example shows using a different username than your login on your local machine. There are a lot of options available, but these are the ones I use most. You might also find Compression yes to be useful if you connect to hosts with low bandwidth links.

As an aside, if you are a macOS user using Terminal, I highly recommend checking out iTerm2. It’s far superior to Terminal and has many features to improve the experience of using the shell.


Networking Vendor Heartbleed Security Notices

In case you’ve been under a rock, there’s a new security vulnerability in town that impacts OpenSSL, which is the defacto standard implementation for SSL/TLS support. It’s called Heartbleed and it impacts anything using OpenSSL 1.0.1 – 1.0.1f or the 1.0.2 beta (though nothing really should be using the beta).

This is a list of networking vendor notices or statements I have found regarding the vulnerability of their products to Heartbleed. I was originally going to put this into a tweet, but it got too long really quick…

Aerohive Networks: Aerohive not vulnerable to Heartbleed

APC: They say nothing is vulnerable. Their KB defies links to it. Search for document “FA228282” at APC Support.

Aruba Networks: OpenSSL 1.0.1 library (Heartbleed) vulnerability

Bluecoat: OpenSSL heartbeat information disclosure (CVE-2014-0160)

Cisco: OpenSSL Heartbeat Extension Vulnerability in Multiple Cisco Products

Citrix: Citrix Security Advisory for CVE-2014-0160, aka the Heartbleed vulnerability

F5: SOL15159: OpenSSL vulnerability CVE-2014-0160

HP: HP Networking Communication: OpenSSL HeartBleed Vulnerability

Juniper: 2014-04 Out of Cycle Security Bulletin: Multiple products affected by OpenSSL “Heartbleed” issue (CVE-2014-0160)


VMware: Response to OpenSSL security issue CVE-2014-0160/CVE-2014-0346 a.k.a: “Heartbleed” (2076225)

Hope this helps you out!

[Edits: 4/11 – Added Bluecoat, Corrected Meraki link]


AAA Poll: Local, TACACS+, or RADIUS?

We are currently authenticating with local users, which is suboptimal for a variety of reasons, though it is simple. I’m deploying centralized authentication using RADIUS with Active Directory, and was curious what other people are doing. I was going to ask on Twitter, but then I thought some people might not want to say in public how they secure their network. It also thought it might be nice if everyone was able to see the results, so here is a poll so we can see how others are doing it.