Vagrant 1.8.5. ( default: Warning: Authentication failure. Retrying...)
First of all the issue was fixed. (https://github.com/mitchellh/vagrant/issues/7610)
If you encounter the same problem, chance is you are using vagrant version 1.8.5. At the time of writing, a newer version hasn't released yet. If you don't want to downgrade to a lower versions, a quick fix is simply a matter of one line of code.
\\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.5\plugins\guests\linux\cap\public_key.rb
from line 54 onward
Original version
That is all you need. This should fix the problem and you are good to go.
Nevertheless, what I want to do here is to share a joy experience on troubleshooting vagrant before getting myself to the final solution. Which is not only help to fix the problem but also getting us into a bit deeper into vagrant's anatomy. Let start form the beginning.
That was what pause my pulse a moment of panic. It happens on centos/7 but surprisingly not for ubuntu/trusty64. This trapped me into thinking of the culprit goes into the box ie. how it was built and not properly built. Of course , my first attempt was to try to update the box.
As you might guess, it doesn't solve the problem though . The problem still there. Let's debug vagrant then.
The output logs narrow down the scope. which is clearly related to ssh. If I try to vagrant ssh manually,
Similar to putty error.
One thing we could do here is to check with Vagrant document. An interesting configuration that is useful in here is ssh.insert_key . From official document
By adding config.ssh.insert_key=false in Vagrantfile. It will prevent vagrant from insert a new key inside vm. But only if security is not in concern.
For any further code tracking , get the latest code from https://github.com/mitchellh/vagrant
If you encounter the same problem, chance is you are using vagrant version 1.8.5. At the time of writing, a newer version hasn't released yet. If you don't want to downgrade to a lower versions, a quick fix is simply a matter of one line of code.
\\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.8.5\plugins\guests\linux\cap\public_key.rb
from line 54 onward
Original version
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
fi
Fixed version 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
That is all you need. This should fix the problem and you are good to go.
Nevertheless, what I want to do here is to share a joy experience on troubleshooting vagrant before getting myself to the final solution. Which is not only help to fix the problem but also getting us into a bit deeper into vagrant's anatomy. Let start form the beginning.
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...
That was what pause my pulse a moment of panic. It happens on centos/7 but surprisingly not for ubuntu/trusty64. This trapped me into thinking of the culprit goes into the box ie. how it was built and not properly built. Of course , my first attempt was to try to update the box.
> vagrant box list centos/7 (virtualbox, 1603.01) > vagrant box update --box centos/7 Checking for updates to 'centos/7' Latest installed version: 1603.01 Version constraints: > 1603.01 Provider: virtualbox Updating 'centos/7' with provider 'virtualbox' from version '1603.01' to '1607.01'... Loading metadata for box 'https://atlas.hashicorp.com/centos/7?access_token=T4yOz3ICKoFiAw.atlasv1.0xu5UUGvdB86xBz7YmsQWTNDYkE5EoZ0MhA9UrXHt7uHMQ2Hj8Yrv4gzDfK1GAEPJks' Adding box 'centos/7' (v1607.01) for provider: virtualbox Downloading: https://atlas.hashicorp.com/centos/boxes/7/versions/1607.01/providers/virtualbox.box Progress: 100% (Rate: 195k/s, Estimated time remaining: --:--:--) Successfully added box 'centos/7' (v1607.01) for 'virtualbox'!
As you might guess, it doesn't solve the problem though . The problem still there. Let's debug vagrant then.
> set VAGRANT_LOG=debug > vagrant up
D, [2016-08-14T21:03:01.501911 #13540] DEBUG -- net.ssh.authentication.methods.publickey[1b5f6b8]: trying publickey (7d:45:4e:21:1e:85:29:fc:f2:5a:99:64:bd:c0:43:65)
D, [2016-08-14T21:03:01.501911 #13540] DEBUG -- socket[25f1e44]: queueing packet nr 6 type 50 len 348
D, [2016-08-14T21:03:01.501911 #13540] DEBUG -- socket[25f1e44]: sent 372 bytes
D, [2016-08-14T21:03:01.512663 #13540] DEBUG -- socket[25f1e44]: read 84 bytes
D, [2016-08-14T21:03:01.512663 #13540] DEBUG -- socket[25f1e44]: received packet nr 6 type 51 len 60
D, [2016-08-14T21:03:01.512663 #13540] DEBUG -- net.ssh.authentication.session[2576268]: allowed methods: publickey,gssapi-keyex,gssapi-with-mic,password
E, [2016-08-14T21:03:01.512663 #13540] ERROR -- net.ssh.authentication.session[2576268]: all authorization methods failed (tried none, publickey)
DEBUG ssh: == Net-SSH connection debug-level log END ==
INFO ssh: SSH not ready: #<Vagrant::Errors::SSHAuthenticationFailed: SSH authentication failed! This is typically caused by the public/private
keypair for the SSH user not being properly set on the guest VM. Please
verify that the guest VM is setup with the proper public key, and that
the private key path for Vagrant is setup properly as well.>
INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "7661fe80-88a8-4463-82da-ac71c7a6c9ba", "--machinereadable"]
INFO subprocess: Command not in installer, restoring original environment...
ERROR warden: Error occurred: 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.
The output logs narrow down the scope. which is clearly related to ssh. If I try to vagrant ssh manually,
> vagrant ssh Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Similar to putty error.
One thing we could do here is to check with Vagrant document. An interesting configuration that is useful in here is ssh.insert_key . From official document
config.ssh.insert_key - If true, Vagrant will automatically insert a keypair to use for SSH, replacing Vagrant's default insecure key inside the machine if detected. By default, this is true.
By adding config.ssh.insert_key=false in Vagrantfile. It will prevent vagrant from insert a new key inside vm. But only if security is not in concern.
For any further code tracking , get the latest code from https://github.com/mitchellh/vagrant
