William Lam brought up some feedback on Socialcast the other day. The story was of a customer who updated to ESXi 6.0 Update 2 and the SSH keys he was using no longer worked. The customer was advocating for changing the file /etc/sshd_config so that he could continue to use the keys on his ESXi server. IMHO, that’s the wrong course of action.
ESXi 6.0 Update 2 has shipped with an updated version of OpenSSH. The version has been updated to 7.1p1. One of the major changes in this release is the disablement of “ssh-dss” and “ssh-dss-cert-*” (a.k.a DSA) keys. They have also announced the future deprecation of legacy cryptography. I urge you to read more about these changes as they may impact you in other places in your infrastructure.
Now, the customer had added dss keys to the /etc/authorized_keys file so that he could easily log into his ESXi system. Ok, I get that. Adding authorized keys is a supported configuration outlined in this KB.
What happened is that now that ESXi 6.0 U2 is running the new OpenSSH bits his SSH connections were refused. This is expected behavior! This issue could be remediated by generating new keys using RSA keys. As I said above, that is the wrong course of action. You put your ESXi host at risk for convenience?
Please don’t bring up the “but DSA keys are faster/less overhead/etc” argument. I’m pretty darned sure that OpenSSH is using AES-NI instructions (I looked) that are plenty fast for a simple SSH session. Performance is no longer an excuse to use less security! It’s 2016.
Bottom line, if you are using Authorized Keys on your ESXi server and they were generated with DSA keys, it’s time to be proactive and re-generate them with RSA keys.
Final note: Limit who can log into your ESXi host. Only those you trust the most should have access. If you are logging in to “run scripts and stuff” (as many customers tell me they do) then you might want to look into using tools like the vSphere API and scripting tools like PowerCLI or Python.
If you have something you CAN’T do via API or scripting, please let us know! Reply here or send email.
Thanks for reading!
If you liked these posts, please let me know! If you have comments, please reply here, to @vspheresecurity or @mikefoley on Twitter or via email to mfoley@VMware.com or firstname.lastname@example.org