Fix Vagrant SSH Authentication Failure After Packaging Box

Vagrant replaces the default insecure SSH key with a new keypair during the first vagrant up. When you package that VM into a new box with vagrant package, the box contains the replacement key – but the next user who runs vagrant up from that box expects the standard insecure key. The result is an authentication loop that never resolves.

Original content from computingforgeeks.com - post 59

This guide covers multiple ways to fix the “Warning: Authentication failure. Retrying…” error when using packaged Vagrant boxes. The methods apply to any provider – VirtualBox, VMware, libvirt, or Hyper-V.

The typical error output looks like this:

==> 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: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...

Step 1: Understand Why Vagrant SSH Authentication Fails

Vagrant ships with a well-known insecure keypair. On the first vagrant up, Vagrant detects this insecure key, removes it from the guest, generates a fresh keypair, and injects the new public key into ~vagrant/.ssh/authorized_keys. The matching private key is stored locally in .vagrant/machines/default/<provider>/private_key.

When you run vagrant package to create a reusable box from that VM, the box image contains the replacement public key – not the original insecure one. Anyone who later creates a new environment from that box hits an authentication mismatch because Vagrant tries the insecure key first, and it no longer matches what the guest expects.

There are several ways to solve this. Pick the one that fits your workflow best.

Step 2: Fix by Disabling Automatic Key Insertion

The fastest fix is to tell Vagrant not to replace the insecure key at all. This keeps the default insecure keypair in place, which means every user who boots the box can authenticate immediately. This is fine for local development environments but should not be used for boxes exposed to untrusted networks.

Open your Vagrantfile:

vi Vagrantfile

Add the following line inside the Vagrant.configure block:

Vagrant.configure("2") do |config|
  config.vm.box = "your-custom-box"
  config.ssh.insert_key = false
end

With config.ssh.insert_key = false, Vagrant skips the keypair replacement process entirely. The guest keeps the insecure public key in authorized_keys, and Vagrant uses its bundled insecure private key to connect. Run vagrant up and SSH should connect without any authentication errors.

If you are building boxes for others, set this option in the Vagrantfile you embed inside the box (covered in Step 6) so consumers do not need to configure it themselves.

Step 3: Fix by Replacing the Vagrant User SSH Key Manually

If you want to keep automatic key insertion enabled but fix the current broken box, restore the insecure public key inside the guest VM. This resets the guest to the state Vagrant expects when booting a fresh box.

First, access the VM through the provider’s console. For VirtualBox, use the GUI or run:

VBoxManage startvm "vm-name" --type gui

Log in as the vagrant user (default password is vagrant) and download the official Vagrant insecure public key:

mkdir -p ~/.ssh
curl -fsSL https://raw.githubusercontent.com/hashicorp/vagrant/main/keys/vagrant.pub -o ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R vagrant:vagrant ~/.ssh

Verify the key was written correctly:

cat ~/.ssh/authorized_keys

The output should show a single SSH public key starting with ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF – this is the well-known Vagrant insecure public key:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDk... vagrant insecure public key

Shut down the VM, then boot it with Vagrant:

vagrant up

Vagrant should now authenticate using its insecure key and then automatically replace it with a new secure keypair.

Step 4: Fix by Resetting the Vagrant User Password

In cases where SSH key authentication is completely broken and you cannot restore the insecure key, you can fall back to password authentication temporarily. This lets Vagrant connect while you sort out the key situation.

Access the VM through the provider console and log in as root or use single-user mode. Reset the vagrant user password:

passwd vagrant

Set the password to vagrant (the expected default). Then edit the Vagrantfile to use password authentication:

vi Vagrantfile

Add these lines inside the Vagrant.configure block:

Vagrant.configure("2") do |config|
  config.vm.box = "your-custom-box"
  config.ssh.username = "vagrant"
  config.ssh.password = "vagrant"
end

Run vagrant up and Vagrant connects using the password instead of SSH keys. Once booted, you can SSH in with vagrant ssh and manually set up the correct SSH keys using the method from Step 3.

Make sure password authentication is enabled in the SSH daemon config on the guest. Check /etc/ssh/sshd_config for PasswordAuthentication yes and restart sshd if you change it.

Step 5: Fix the Base Box Before Packaging

The cleanest solution is to prepare the VM properly before running vagrant package. This ensures anyone who uses the resulting box gets a clean first-boot experience with no authentication issues.

Before packaging, SSH into the running VM and restore the insecure public key:

vagrant ssh

Inside the VM, replace the current authorized_keys with the Vagrant insecure public key:

curl -fsSL https://raw.githubusercontent.com/hashicorp/vagrant/main/keys/vagrant.pub -o ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Ensure the SSH daemon is configured to accept key authentication. Check the config:

sudo grep -E "^(PubkeyAuthentication|AuthorizedKeysFile|UseDNS)" /etc/ssh/sshd_config

The output should confirm that public key authentication is enabled:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
UseDNS no

If UseDNS is set to yes, change it to no – DNS lookups during SSH authentication cause timeouts that look like connection failures. Clean up any user-specific data, bash history, and temporary files before packaging:

sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
cat /dev/null > ~/.bash_history
history -c
exit

Now package the box from your host:

vagrant package --output my-custom-box.box

The resulting box contains the insecure public key, so Vagrant can authenticate on first boot and then replace it automatically. If you are building boxes with Packer, add these preparation steps to your provisioning script.

Step 6: Vagrant Box Packaging Best Practices

When packaging a box for distribution, you can embed a default Vagrantfile inside the box itself. This Vagrantfile sets defaults that apply to every environment created from the box, unless the user overrides them.

Create a Vagrantfile that will be embedded in the box:

vi /tmp/Vagrantfile.pkg

Add SSH configuration defaults that prevent authentication issues:

Vagrant.configure("2") do |config|
  config.ssh.insert_key = false
  config.ssh.username = "vagrant"
end

Package the box with the embedded Vagrantfile using the --vagrantfile flag:

vagrant package --vagrantfile /tmp/Vagrantfile.pkg --output my-custom-box.box

This embeds the Vagrantfile inside the box archive. When someone adds the box and runs vagrant up, Vagrant merges the embedded Vagrantfile with the user’s Vagrantfile. The embedded settings act as defaults that the user can override in their own Vagrantfile.

Other packaging best practices that prevent SSH problems:

• Always restore the insecure public key before packaging (Step 5)
• Set UseDNS no in /etc/ssh/sshd_config to avoid connection timeouts
• Ensure the vagrant user has passwordless sudo – add vagrant ALL=(ALL) NOPASSWD: ALL to /etc/sudoers.d/vagrant
• Remove persistent network rules so the box works across different hosts
• Zero out free disk space before packaging to reduce box file size – sudo dd if=/dev/zero of=/EMPTY bs=1M; sudo rm -f /EMPTY

Step 7: Troubleshoot Other Vagrant SSH Issues

If authentication succeeds but SSH still fails, or you see connection timeouts instead of authentication errors, check these common issues.

SSH Connection Timeout

A timeout means Vagrant cannot reach port 22 on the guest. Verify port forwarding is active:

vagrant ssh-config

This shows the SSH connection parameters Vagrant is using, including the forwarded port:

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  IdentityFile /home/user/.vagrant/machines/default/virtualbox/private_key

Test the connection manually with the details from the output above:

ssh -p 2222 -i .vagrant/machines/default/virtualbox/private_key [email protected] -o StrictHostKeyChecking=no

If the manual SSH command also times out, the issue is with the VM’s network configuration or the SSH daemon not running. Boot the VM through the provider GUI and check that sshd is active:

sudo systemctl status sshd

Port Collision

When multiple Vagrant machines run simultaneously, they can compete for port 2222. Vagrant auto-corrects by assigning a different port, but this can occasionally cause confusion. Check which port was actually assigned:

vagrant port

The output lists all forwarded ports for the VM:

The forwarded ports for the machine are listed below.
    22 (guest) => 2200 (host)

If the port has changed from the default 2222, Vagrant adjusts automatically. But if you have firewall rules or scripts that hardcode port 2222, update them to match the actual forwarded port.

Wrong Private Key Path

If you moved the Vagrant project directory or deleted .vagrant/ and re-created it, the private key stored locally may not match the public key on the guest. Delete the local machine state and re-initialize:

vagrant destroy -f
vagrant up

This creates a fresh VM from the box with a clean keypair exchange. If you need to keep the existing VM data, use the manual key replacement method from Step 3 instead.

Verbose SSH Debug Output

When none of the above fixes work, enable verbose SSH output to see exactly where authentication fails. Use the Vagrant SSH debug flag:

vagrant ssh -- -vvv

Look for lines mentioning “Trying private key”, “Authentication succeeded”, or “Permission denied” to identify whether Vagrant is sending the wrong key, the guest is rejecting keys entirely, or there is a permissions problem on ~/.ssh/authorized_keys.

Conclusion

The Vagrant SSH authentication failure after packaging is caused by the insecure key being replaced before the box is built. The simplest fix is setting config.ssh.insert_key = false in the Vagrantfile, but for boxes you distribute, restoring the insecure public key before packaging gives the cleanest result. For production environments where security matters, build your boxes with Packer and automate the key preparation in your provisioning scripts.