The "Permission denied (publickey)" error in Vagrant with the Ubuntu Jammy64 box typically stems from a mismatch between the SSH private key Vagrant expects and the one actually provisioned in the virtual machine. This authentication failure prevents the
vagrant ssh command from establishing a connection, halting development workflows. Resolving this requires synchronizing the SSH keys or resetting the VM's state to regenerate them correctly.
Understanding the Root Cause
Vagrant relies on a specific SSH key pair to authenticate with guest machines. When you run
vagrant up, Vagrant generates a unique insecure private key and injects the corresponding public key into the guest’s
~/.ssh/authorized_keys file. If this process fails, is interrupted, or if the box image has been modified externally, the keys no longer match. The SSH daemon on the Ubuntu Jammy64 guest rejects the connection because it does not recognize the presented private key, resulting in the publickey denial.
This issue is particularly common when switching between different versions of the same box or when manually altering the VM configuration outside of Vagrant. It can also occur if the VirtualBox provider encounters a state corruption where the forwarded ports or network adapters are misconfigured, though the primary symptom remains an authentication failure. For broader context on general
vagrant up errors, see
What to do when the 'vagrant up' command outputs an error.
Step-by-Step Resolution
The most reliable fix is to force Vagrant to destroy the current broken state and rebuild the environment from scratch. This ensures that fresh SSH keys are generated and properly injected into the new instance. Follow these steps carefully to restore connectivity.
- Stop any running processes: Ensure no other tools are accessing the VM files. Close your terminal sessions and IDEs connected to the project.
- Destroy the existing VM: Open your terminal in the directory containing your
Vagrantfile and run the following command:
vagrant destroy -f
The -f flag forces the destruction without prompting for confirmation. This removes the VirtualBox machine and all associated data.
- Clean up residual state files: Sometimes, stale state files in the
.vagrant directory can cause confusion during the next boot. Remove this directory manually:
rm -rf .vagrant
This step is crucial if you have previously attempted multiple fixes without success.
- Re-provision the machine: Start the VM again using the standard up command:
vagrant up
Watch the output closely. You should see Vagrant generating new SSH keys and injecting them into the guest OS.
- Test the connection: Once the VM is running, attempt to SSH into it:
vagrant ssh
If successful, you will be logged into the Ubuntu Jammy64 shell without permission errors.
Alternative Fix: Reloading Configuration
If destroying the VM is not feasible due to heavy provisioning times or custom configurations that take hours to set up, you can try reloading the Vagrant environment. This approach attempts to re-sync keys without deleting the entire disk.
Run the following command:
vagrant reload --provision
This command stops the VM, applies any changes in the
Vagrantfile, and runs the provisioners again. In many cases, the provisioner script will handle SSH key injection. However, if the underlying issue is deep within the SSH daemon configuration of the base box, this method may not succeed, and
vagrant destroy remains the definitive solution.
Preventing Future Occurrences
To avoid recurring permission issues, ensure that you do not modify the
Vagrantfile while the VM is running. Changes to network settings or synced folders often require a restart to take effect properly. Additionally, always use the official
ubuntu/jammy64 box from HashiCorp's Atlas repository rather than local copies that may have been tampered with or corrupted.
Regularly updating your Vagrant and VirtualBox installations helps maintain compatibility with the latest security protocols used by Ubuntu 22.04 LTS. Outdated versions of VirtualBox sometimes struggle with newer SSH key formats introduced in recent Linux releases. Check your current versions using
vagrant version and
vboxmanage --version.
For users experiencing SSH hangs rather than immediate permission denials after fixing the key issue, refer to
Troubleshooting SSH Hangs on Kubuntu 24.04 and Ubuntu 24.01 in VirtualBox. Network latency or firewall rules inside the guest can sometimes mask authentication successes with delays.
Frequently Asked Questions
Why does Vagrant generate a new key every time I destroy and recreate?
Vagrant creates a unique, insecure private key for each new VM instance to ensure isolation between environments. This practice prevents key reuse across different projects or teams, enhancing security. The public key is automatically distributed to the guest OS during the initial boot sequence via cloud-init or similar mechanisms.
Can I manually edit the authorized_keys file to fix this?
While technically possible, manually editing the file is not recommended because Vagrant manages these keys dynamically. Any manual changes might be overwritten during the next provision cycle or reboot. It is safer to let Vagrant handle the key distribution through its standard workflow.
What if the error persists after running vagrant destroy?
If the error continues, check for leftover VirtualBox machines with conflicting names. Run
vboxmanage list vms to identify orphaned instances and remove them manually. Also, verify that your host machine's firewall is not blocking the localhost loopback interface used for SSH forwarding.
Does this issue affect Windows hosts differently than macOS or Linux?
The core mechanism of SSH key management is identical across all host operating systems. However, Windows users might encounter additional path-related issues with Git Bash or WSL if they are not configured correctly. Ensure your SSH client is accessible from the command line where you invoke Vagrant.
How can I check if the SSH service is running inside the VM?
You can verify the SSH service status by logging into the VM via VirtualBox GUI first, then running
sudo systemctl status ssh. If the service is inactive or failed, start it with
sudo systemctl start ssh. A running SSH daemon is a prerequisite for Vagrant to establish any connection.