ISSUE DESCRIPTION
You might encounter the following blocking message after a vagrant up of a previously packaged box:
Warning: Authentication failure. Retrying.. Warning: Authentication failure. Retrying.. Warning: Authentication failure. Retrying.. etc.
To prevent this problem from occurring, there are two options before packaging (it is not possible a priori to correct the problem once the box has been packaged) :
1. Before the first vagrant up of the VM, and therefore before packaging :
Do not let Vagrant insert its random public key into the following file of the VM :
/home/vagrant/.ssh/authorized_keys
<hostname>: Vagrant insecure key detected. Vagrant will automatically replace <hostname>: this with a newly generated keypair for better security. <hostname>: Inserting generated public key within guest... <hostname>: Removing insecure key from the guest if it's present... <hostname>: Key inserted! Disconnecting and reconnecting using new SSH key... ==> <hostname>: Machine booted and ready!
This is linked to the random private key stored in the following file :
.vagrant\machines\virtualbox\private_key
To do this, add the following line to the Vagrantfile of the future VM :
config.ssh.insert_key = false
This will instead add the unsecured public key known to all working in tandem with the private key provided by the Vagrant installation and generally stored under Windows in the following file :
C:\Users\.vagrant.d\insecure_private_key
Then usual procedure :
vagrant up vagrant halt vagrant package [...] vagrant box add [...]
2. After the first vagrant up, but still before packaging :
Replace the random generated public key that was inserted in the following file :
/home/vagrant/.ssh/authorized_keys
<hostname>: Vagrant insecure key detected. Vagrant will automatically replace <hostname>: this with a newly generated keypair for better security. <hostname>: Inserting generated public key within guest... <hostname>: Removing insecure key from the guest if it's present... <hostname>: Key inserted! Disconnecting and reconnecting using new SSH key... ==> <hostname>: Machine booted and ready!
With the official Vagrant public key :
https://github.com/hashicorp/vagrant/blob/master/keys/vagrant.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ== vagrant insecure public key
This is working in tandem with the private key provided by the Vagrant installation and generally stored under Windows in the following file :
C:\Users\.Vagrant.d\insecure_private_key
Procedure :
vagrant ssh <hostname> wget https://raw.githubusercontent.com/hashicorp/vagrant/master/keys/vagrant.pub -O .ssh/authorized_keys exit
Then usual procedure:
vagrant halt
==> mylms: Attempting graceful shutdown of VM...
mylms: Guest communication could not be established! This is usually because
mylms: SSH is not running, the authentication information was changed,
mylms: or some other networking issue. Vagrant will force halt, if
mylms: capable.
==> mylms: Forcing shutdown of VM...
vagrant package [...] vagrant box add [...]
SOURCES