Category: CommunitySysadmins Should Update SSH Clients Immediately

Share this post...Tweet about this on TwitterShare on Google+0Share on Facebook0

Update SSH Clients ImmediatelyWith the announcement of a new vulnerability that could lead to the leaking of OpenSSH clients’ private keys, SSH users should update. All versions of OpenSSH from 5.4 to 7.1 are vulnerable.

Patches were made available within three days of the discovery of the vulnerability by Qualys, and most Linux distributions have incorporated them into their SSH packages. Most recent Linux distributions are vulnerable. Users of CentOS 5 and 6 using the default OpenSSH packages should be safe, because those distributions use an earlier version of OpenSSH without the affected code. Users of CentOS 7 are vulnerable and should update at their earliest convenience.

If, for some unfortunate reason, you are unable to install the latest version of OpenSSH for your distribution, you can also mitigate the risk of the vulnerability with a configuration change. The vulnerability was discovered in code for the undocumented — and activated by default — roaming functionality of OpenSSH, and can be fixed by setting the “UseRoaming” option to “No”.

The following command should do the trick:

echo 'UseRoaming no' | sudo tee -a /etc/ssh/ssh_config

It’s important to note that although we’re talking about an exploitable vulnerability here, it’s nowhere near as serious as Heartbleed and other showstopper vulnerabilities. Only client-side OpenSSH installations include the faulty code — it was never added to the server code, which means that exploitation is far more difficult.

Essentially, the vulnerability could allow an attacker in control of a malicious SSH server to harvest the private keys of SSH clients connecting to that server. Unless you go around randomly SSHing into servers or DNS routing has been compromised, this isn’t likely to impact you. However, attackers could steal the private keys of clients who connect to servers compromised by some other means. Once they have the private keys, they will be able to re-compromise the server even if their original point of entry is discovered and closed.

Let’s say the server on which your WordPress site is hosted is compromised by an attacker. They could exploit the information leak vulnerability to steal the private SSH keys that your SSH client uses to authenticate itself to the server. When you eventually discover that your server has been compromised and kick the attacker out, unless you regenerate the private keys that your server recognizes, the attacker will simply be able to use those keys to re-compromise your server.

This is particularly likely to be a problem for large websites with server clusters who’s administrators use the same keys for SSH authentication across multiple servers. If any of those servers has been compromised prior to sysadmin OpenSSH installations being patched, you might want to consider regenerating SSH keys for those who have access.

Image: Flickr/blondinrikard

Jan 21, 2016, 12:30 pmBy: Corey Northcutt (0) Comments

Leave a Reply
Surround code blocks with <pre>code</pre>

Your email address will not be published.


Sign up to receive periodic InterWorx news, updates and promos!

New Comments

Current Poll

  • This field is for validation purposes and should be left unchanged.