Linux P2V with vCenter Converter Standalone

I was recently speaking with someone who was encountering an Access Denied issue when trying to P2V an older CentOS physical machine. The specific error they were getting was The thumbprint of the remote host you are connecting to is: Access denied. Screenshot below for reference:

I was able to recreate this error in a lab, in this post we’ll explore the cause of the problem and a couple of possible solutions.

Looking at the documentation (https://docs.vmware.com/en/vCenter-Converter-Standalone/6.6/vcenter-converter/GUID-E6C55568-EE61-4D1F-A3DC-71269790D9FD.html), we see a few prerequisites to prepare the source Linux machine. The first two are:

• Enable SSH on the source Linux machine.
• Make sure that you use the root account or account with sudo privileges without password prompt for all commands to convert a powered on Linux machine.

The initial error of “The thumbprint of the remote host you are connecting to is: Access denied.” occurred when using the root account for a host where PermitRootLogin was set to no.

There are two possible solutions for this issue, described in that second bullet. We can either get the root account functional (over SSH), or switch to a user with sudo access.

Enabling SSH for the root user

Many sshd_config files have the ability to login as root over SSH disabled by default. You typically need to login as a regular user and then switch to root (su -) or prefix commands with sudo. To keep things as secure as possible, while temporarily satisfying this requirement, we can add a couple of lines to the very end of our sshd_config file:

Match Address 192.168.127.194,192.168.127.81
     PermitRootLogin yes

Once we’ve saved our config file changes, we’ll reload the SSHD config to make this change active. For this older CentOS test system, the command is service sshd reload.

This allows us to enable root login over SSH, but only for two client systems. The first IP I have listed is the Windows system where I’m running the VMware vCenter Converter Standalone client. This client logs in to view the source machine details while we are configuring the job. The second IP address listed is the temporary IP address assigned to the helper VM. I’m using a static IP address for the helper VM, which allows me to put that specific IP address in my sshd config. If I were using a DHCP address, I could list the subnet instead, for example: 192.168.127.0/24. For reference, failure to list this helper VM address results in the error Permission denied, please try again.

Once the P2V migration is complete, we can edit the /etc/ssh/sshd_config file again, this time removing the two lines added. We’ll reload the config, again with service sshd reload.

sudo without password prompt

If the preference is to designate a specific account to use instead of root, that can be done instead. The account will need to be able to execute all commands with sudo privileges without password. In this example, we will create a specific user just to do the P2V:

sudo useradd myp2vuser
sudo passwd myp2vuser # set a password for this user

Once our specific user is created, we’ll edit the /etc/sudoers file to add the following line:

myp2vuser  ALL=(ALL)  NOPASSWD: ALL

Once we’ve saved the changes to our sudoers file, we’ll attempt to login over ssh. We should be able to login without issue. To test that sudo is working, I like to run a command like cat /etc/shadow. It should fail with a permission denied error. We can then run sudo cat /etc/shadow, which should work without being prompted for a password.

Once the migration is complete, we can remove our temporary user with the command userdel myp2vuser and remove the entry added to the /etc/sudoers file.

Conclusion

With either of the above options from the product documentation, we are able to complete a P2V migration without the ‘Access Denied’ error previously reported. Hopefully this helps if you run into a similar issue!