Got vagrant@127.0.0.1: Permission denied (publickey). message after upgrade to 2.3.4

[chan15]

Three of my computers, Windows 11 x 1 and Windows 10 x 2 all got this message after upgrading vagrant to 2.3.4, even downgrading back to 2.3.3 it's still there.

VirtualBox version: 7.0.4

vagrant ssh --debug got:

DEBUG virtualbox_7_0:   - [1, "ssh", 2222, 22, "127.0.0.1"]
 INFO subprocess: Starting process: ["C:\\Windows\\System32\\OpenSSH\\/ssh.EXE"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 255
 INFO ssh: Invoking SSH: C:\Windows\System32\OpenSSH\/ssh.EXE ["vagrant@127.0.0.1", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-i", "D:/vagrant/ubuntu22/.vagrant/machines/default/virtualbox/private_key"]
DEBUG safe_exec: Converting command and arguments to common UTF-8 encoding for exec.
DEBUG safe_exec: Command: `"C:\\Windows\\System32\\OpenSSH\\/ssh.EXE"` Args: `["vagrant@127.0.0.1", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-i", "D:/vagrant/ubuntu22/.vagrant/machines/default/virtualbox/private_key"]`
DEBUG safe_exec: Converted - Command: `"C:\\Windows\\System32\\OpenSSH\\/ssh.EXE"` Args: `["vagrant@127.0.0.1", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-i", "D:/vagrant/ubuntu22/.vagrant/machines/default/virtualbox/private_key"]`
vagrant@127.0.0.1: Permission denied (publickey).

If I set config.ssh.insert_key = false then I can access the VM, but I want everything back to normal just like before.

It's happened in several different versions of Ubuntu and Centos with basic config, so I think I don't need to give the Vagrantfile.

[chrisroberts]

Hi there,

Would you please provide a minimal Vagrantfile which reproduces the behavior you are experiencing along with a gist of the debug output from a failed vagrant up --debug.

Thanks!

[chan15]

Hi there,

Would you please provide a minimal Vagrantfile which reproduces the behavior you are experiencing along with a gist of the debug output from a failed vagrant up --debug.

Thanks!

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/jammy64"
  config.vm.network "private_network", ip: "10.10.10.22"
  config.vm.synced_folder "./data", "/data"
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "1024"
    vb.name = "ubuntu22"
  end
end

Just simply, as I said, the permission issue started after upgrading to 2.3.4, all my VM have that message, so I think it's nothing to do with the Vagrantfile, and it's happened on three of my pc with two windows 10 and one windows 11, so I think it's nothing to do with the OS too.

[PaulNeumann]

I've seen the same behavior, but I don't think it's a Vagrant issue. I think it's due to a fairly recent update to OpenSSH on Windows.

The latest version of OpenSSH on Windows doesn't trust private keys/identity files unless they're accessible ONLY by the user running the command. So, unless the Vagrantfile is somewhere under your user profile (usually C:\Users\username), OpenSSH won't trust the Vagrant private key, and it will refuse to connect.

From the output of vagrant ssh --debug that you posted above, the Vagrantfile is in the directory D:\vagrant\ubuntu22. Since this isn't under your user profile, I suspect that's the problem.

To fix this, you can either move the ubuntu22 directory to a location that's under your user profile, or use Vagrant's embedded ssh instead of Windows ssh.

To use Vagrant's embedded ssh, set the VAGRANT_PREFER_SYSTEM_BIN environment variable to 0 before running vagrant ssh. If you're using a Command Prompt, you can do that by running SET VAGRANT_PREFER_SYSTEM_BIN=0. If you're using PowerShell, then run $Env:VAGRANT_PREFER_SYSTEM_BIN = 0.

I hope this helps.

[chan15]

I've seen the same behavior, but I don't think it's a Vagrant issue. I think it's due to a fairly recent update to OpenSSH on Windows.

The latest version of OpenSSH on Windows doesn't trust private keys/identity files unless they're accessible ONLY by the user running the command. So, unless the Vagrantfile is somewhere under your user profile (usually C:\Users\username), OpenSSH won't trust the Vagrant private key, and it will refuse to connect.

From the output of vagrant ssh --debug that you posted above, the Vagrantfile is in the directory D:\vagrant\ubuntu22. Since this isn't under your user profile, I suspect that's the problem.

To fix this, you can either move the ubuntu22 directory to a location that's under your user profile, or use Vagrant's embedded ssh instead of Windows ssh.

To use Vagrant's embedded ssh, set the VAGRANT_PREFER_SYSTEM_BIN environment variable to 0 before running vagrant ssh. If you're using a Command Prompt, you can do that by running SET VAGRANT_PREFER_SYSTEM_BIN=0. If you're using PowerShell, then run $Env:VAGRANT_PREFER_SYSTEM_BIN = 0.

I hope this helps.

$Env:VAGRANT_PREFER_SYSTEM_BIN = 0 works, thanks

[PaulNeumann]

@chan15 Excellent! I'm glad it's working now.

@chrisroberts Although this isn't really a Vagrant issue, it's likely to affect a lot of people. It'd be good to address it in the documentation.

[chrisroberts]

@PaulNeumann 👍 i'm also having a look to see if we can include a permission check so we can surface an actionable error message

[chan15]

Thanks for your contribution. :)