Posted on 25 July, 2012 by Kyle Gleed, Sr. Technical Marketing Architect, VMware
I came across this question today: “How do I setup password free SSH access to my ESXi hosts”. A quick Google search turned up a lot of good info on this topic, but I didn’t find anything on the vSphere blog so I wanted to chime with a quick post, and hopefully add to what’s already out there.
When people ask “how” to enable password free SSH, the question I always ask in return is “should" you enable password free SSH? In most situations I would dare say the answer is probably not. I often find that the decision to enable password free access is not based on any real requirement, but rather is done for the sake of convenience – admins want easy access to their vSphere hosts. In my opinion, this is a case where security should trump convenience. However, having said that I do realize that there are valid situations where SSH access is unavoidable, and depending the situation it might make sense to enable password free access. My point here is that just because you can setup password free SSH doesn’t mean it’s a good idea. Keep in mind, once you enable password free SSH:
With that I’ll jump down off my soapbox and go over the steps to enable password free SSH. It’s really pretty easy. Two basic steps:
1. On the remote host use “ssh-keygen” to create a private/public key pair. You can use an RSA or DSA token. Make sure you leave the passphrase empty/blank.
2. Next, append the user’s public key (created by the ssh-keygen tool) to the /etc/ssh/keys-root/authorized_keys file on the ESXi host. Here’s an easy way to do this (I got this nifty syntax from here):
# cat /root/.ssh/id.dsa.pub | ssh root@<esx host> ‘cat >> /etc/ssh/keys-root/authorized_keys’
With the remote host’s public key stored in the "authorized_keys" file, anytime this user SSH's to the vSphere host instead of prompting for a password the host will check the remote users public key against what's in the authorized_keys file, and if a match is found access is allowed.
Note: I've seen a few articles that mentioned the need to edit the /etc/ssh/sshd_config file. On ESXi 5.0 you do not need to edit the sshd_config file. The file is already configured to allow password free SSH. All you need to do is load the user's public keys into the /etc/ssh/keys/authorized_keys file.
Follow me on twitter @VMwareESXi
Are there any recommendations in regard to using keyless-SSH as per this article or using Fastpass authentication via the vMA? Or just whichever fits your operational processes?
It is a common misconception, that you are required to create a key without a passphrase in order to not type in a password when connecting to a remote host.
The trick is to use a key agent like Pageant for Windows or ssh agent for any OS running OpenSSH. You unlock your key to the agent by typing in your password once and don’t have to retype it for the rest of your session. Every current Linux and OS X starts an agent automatically on login, if not follow http://mah.everybody.org/docs/ssh.
The only reason to use passphrase-less keys is to connect machines with SSH. And then you should always restrict that key to forced-commands.
You know… SSH is going away. It should be disabled by default, and you should be using the PowerCli. As a Linux/Unix guy though, I love SSH and don’t want to get it go.
I would say vMA FastPass would be preferred over SSH.
I’ve never seen/heard anything about SSH going away. SSH will likely stick around as long as we have the ESXi shell.
There is no requirement to use PowerCLI. You can use vCLI. There are several customers out there who are 100% linux. For them PowerCLI is not an option.
VMA!! You really should only be ssh into an esxi host if something is blowing up.
As someone said… -fastpass
Thanks for the mention Kyle, but I can’t take credit for the “nifty syntax”, I found it somewhere long time ago while looking for a fast and reliable way to copy public key to remote host. I also agree with Ed’s comment – it’s best to use password-less logins for automation purposes and definitely not with superuser account. For fast, yet secure login better use ssh-agent or Pagent (on Windows). I made a post on how to streamline this process on Windows by making Pageant automatically load keys on startup: http://blog.shvetsov.com/2010/03/making-pageant-automatically-load-keys.html
Hi, stupid question: I generated my public key file with puttygen on a Windows PC. How do load it into the /etc/ssh/keys/authorized_keys file? I tried using copy/past (i.e., open the public key file in windows, copy the contents and edit /etc/ssh/keys/authorized_keys with vi), but that doesn’t seem to work.
Any help would be appreciated!
Cheers,
teq
Seems like a poor security practice.
Do the keys that are added to /etc/ssh/root.keys/ stay over reboots, or do I have to add it to a /bootbank/something.tgz?
Yes, for stateful hosts the SSH keys persist across reboots. For stateless deployments you are limited to one key which you add using the Host Profile (Security and Services -> Security Settings -> Security Configuration -> SSH authorized Key for root user).
According to Kyle Gleed’s instruction, I can enable password free ssh access on ESXi5.1, but can’t for non-root.
I follow steps below trying to enable non-root ssh access on ESXi5.1 and persist my configuration
- Use “ssh-keygen” to create a private/public key pair for non-root user
- Copy non-root user public key to host at persistent datastore at /vmfs/volumes/datastore1/keys-non-root/authorized_keys
- Add these lines to the /etc/rc.local file (for ESXi 5.0) and /etc/profile.local file (for ESXi 5.1):
cp -R /vmfs/volumes/datastore1/myStore/keys-oneadmin /etc/ssh
I am sure public key for non-root is persistent over reboot the host. But I can’t passwordless access on ESXi host. Anyone has experienced that situation please take time give me your advice.
I made mistake with my post. The command line be corrected as below:
cp -R /vmfs/volumes/datastore1/myStore/keys-no-root /etc/ssh
I hope some of you are not actually managing something linux-ish, the sheer amount of nonsense in this post is staggering :/
There is NOTHING wrong with using public-key authentication, while there is almost everything wrong with password authentication. Public authentication is harder to screw up actually.
You don’t want your private key unencrypted as in this example of course, this way only adds to the FUD.