New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
breisig opened this Issue Jul 19, 2016 · 17 comments

Comments

Projects
None yet
@breisig

breisig commented Jul 19, 2016

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.

@Poohblah

This comment has been minimized.

Show comment
Hide comment
@Poohblah

Poohblah Jul 19, 2016

Contributor

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).

Contributor

Poohblah commented Jul 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bhops

bhops Jul 19, 2016

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

👍

bhops commented Jul 19, 2016

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

👍

@elventear

This comment has been minimized.

Show comment
Hide comment
@elventear

elventear Jul 19, 2016

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

elventear commented Jul 19, 2016

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

@cwt137

This comment has been minimized.

Show comment
Hide comment
@cwt137

cwt137 Jul 19, 2016

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

cwt137 commented Jul 19, 2016

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

@sethvargo sethvargo added this to the 1.8.6 milestone Jul 19, 2016

@sethvargo sethvargo self-assigned this Jul 19, 2016

@stephansnyt

This comment has been minimized.

Show comment
Hide comment
@stephansnyt

stephansnyt Jul 19, 2016

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.

stephansnyt commented Jul 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DanHam

DanHam Jul 19, 2016

@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

DanHam commented Jul 19, 2016

@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

@Poohblah

This comment has been minimized.

Show comment
Hide comment
@Poohblah

Poohblah Jul 19, 2016

Contributor

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

Contributor

Poohblah commented Jul 19, 2016

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

@DanHam

This comment has been minimized.

Show comment
Hide comment
@DanHam

DanHam Jul 20, 2016

@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.

DanHam commented Jul 20, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gmacon

gmacon Jul 20, 2016

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.

gmacon commented Jul 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@scottsb

scottsb Jul 20, 2016

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.

scottsb commented Jul 20, 2016

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.

@sethvargo sethvargo closed this Jul 20, 2016

@sethvargo sethvargo closed this in a6760dd Jul 20, 2016

sethvargo pushed a commit that referenced this issue Jul 20, 2016

Seth Vargo
Merge pull request #7611 from Poohblah/master
fix for #7610 (incorrect permissions on ~/.ssh/authorized_keys causes authentication failure after insecure keypair replacement)
@romik-g

This comment has been minimized.

Show comment
Hide comment
@romik-g

romik-g Jul 20, 2016

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

romik-g commented Jul 20, 2016

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

@rbjorklin

This comment has been minimized.

Show comment
Hide comment
@rbjorklin

rbjorklin Jul 21, 2016

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

rbjorklin commented Jul 21, 2016

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

gitebra pushed a commit to gitebra/vagrant that referenced this issue Jul 21, 2016

Merge commit '2418cb1e6060df44453a64804c43503836d0852a'
* commit '2418cb1e6060df44453a64804c43503836d0852a':
  added unit tests for .remove_public_key method in VagrantPlugins::GuestLinux::Cap
  s/bsd/linux/
  fixes #7610

zmt added a commit to uber-archive/vagrant that referenced this issue Jul 22, 2016

@ameyaagashe

This comment has been minimized.

Show comment
Hide comment
@ameyaagashe

ameyaagashe Jul 22, 2016

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.

ameyaagashe commented Jul 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lmeyemezu

lmeyemezu Jul 22, 2016

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 commented Jul 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lmeyemezu

lmeyemezu Jul 22, 2016

@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

lmeyemezu commented Jul 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mikenerone

mikenerone Jul 22, 2016

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

mikenerone commented Jul 22, 2016

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 comment has been minimized.

Show comment
Hide comment
@sethvargo

sethvargo Jul 22, 2016

Contributor

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

Contributor

sethvargo commented Jul 22, 2016

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

@hashicorp hashicorp locked and limited conversation to collaborators Jul 22, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.