Authentication failure after inserting new key with Vagrant 1.8.5. [PATCH]

[breisig]

I have upgraded to the latest Vagrant v1.8.5 and now running Virtualbox 5.1 on Windows and I have noticed that when setting up a new vagrant instance (aka 'vagrant up'), It seems its keeps displaying over and over "Warning: Authentication failure. Retrying...". The Vagrant VM is a CentOS 7.2 (64bit) VM.

Example:
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Remote connection disconnect. Retrying...
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
C:\vagrant

When I log onto the VM manually, I noticed the updated authorized_keys file permission that vagrant installed is incorrect. When I 'chmod 0600 ~/.ssh/authorized_keys' that file, it then starts to work.

After reviewing the git history, I noticed some code changes related to Git commit ( 4aaa600 ) caused the issue. It seems a missing "chmod 0600 ~/.ssh/authorized_keys" was forgotten.

Here's a quick fix for git

diff -uNr vagrant-original/plugins/guests/linux/cap/public_key.rb vagrant/plugins/guests/linux/cap/public_key.rb
--- vagrant-original/plugins/guests/linux/cap/public_key.rb     2016-07-19 12:06:56.575045974 -0500
+++ vagrant/plugins/guests/linux/cap/public_key.rb      2016-07-19 12:07:34.303376009 -0500
@@ -54,6 +54,7 @@
             if test -f ~/.ssh/authorized_keys; then
               grep -v -x -f '#{remote_path}' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
               mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys
+              chmod 0600 ~/.ssh/authorized_keys
             fi

             rm -f '#{remote_path}'

or on Windows I could add the fix directly to ( C:\HashiCorp\vagrant\embedded\gems\gems\vagrant-1.8.5\plugins\guests\linux\cap\public_key.rb) which fixes the issue.

One alternative (which I didn't want to use) was setting in Vagrantfile "config.ssh.insert_key = false" but that just seemed more like a workaround.

[jayhendren]

I am also having this issue and I can confirm that the patch provided fixes this issue for me. I've submitted a PR to fix the issue (#7611).

[bhops]

I experienced this as well with Virtualbox 5.1.0r108711 and Vagrant 1.8.5. This fixed the issue for me.

👍

[elventear]

I am experiencing this issue with Vagrant 1.8.5 provisioning to libvirt.

[cwt137]

I have this issue too with v1.8.5 on Windows. I hope this patch is applied and 1.8.6 ships soon.

[stephansnyt]

Also noticed this with centos6 guests.

edit: The reason for my comment was the guest/debian label on the side. I somehow missed that the original post was actually regarding a centos guest.

[DanHam]

@sethvargo

The Vagrant VM is a CentOS 7.2 (64bit) VM.

Did you mean to label as guest/redhat instead?

The fix works for me

[jayhendren]

@DanHam the issue applies to many, if not all, types of Linux guests, and there isn't a generic "guest/linux" label.

[DanHam]

@Poohblah Agreed this applies to all types of Linux guests and the fix is good. However, I'm only seeing this cause an issue with my CentOS box. Debian doesn't seem to be affected in the same way - maybe Debian is less fussy over permissions on the authorized keys file? For me, key replacement for a Debian guest works fine with no errors.

[gmacon]

I believe the difference between the linux distros is the default value of umask. Debian has 0022, resulting in 0644 on authorized_keys, which is acceptable to ssh, but RedHat has 0002, resulting in 0664, causing ssh to refuse to honor the authorized_keys file.

[scottsb]

For anybody else who could benefit, the location to manually patch on Mac is /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/plugins/guests/linux/cap/public_key.rb.

[ghost]

@Poohblah, @sethvargo, same mistype needs to be fixed in plugins/guests/bsd/cap/public_key.rb

[rbjorklin]

I mentioned it in #5186 but here goes again. For 1.8.5 I was able to work around this problem with: config.ssh.insert_key = false

[ameyaagashe]

Hello,
Seems that issue is still experienced for Vagrant 1.8.5 I had to manually ssh into VM and then chmod. Now it works fine.

[lmeyemezu]

is Vagrant 1.8.6 planned ?
cannot make 1.8.5 works on windows 10.
changed public_key.rb file but nothing changed.
still have Remote connection disconnect. Retrying... message

[lmeyemezu]

@breisig could you send a copy of C:\HashiCorp\vagrant\embedded\gems\gems\vagrant-1.8.5\plugins\guests\linux\cap\public_key.rb, please ?
it does not work for me.
Regards

[mikenerone]

Same issue. Host: Mac OS X El Capitan (10.11.6), Vagrant 1.8.5, VirtualBox 5.0.20. Guest: CentOS 7.2.

[sethvargo]

This has been fixed on master and will be present in the next release. Sorry this bug slipped in!