vagrant@127.0.0.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

[atulanandnitt]

Vagrant version

vagrant 2.1.1

Host operating system

This is the operating system that you run locally.

Guest operating system

I have used this cmd to get guest OS.
git clone https://github.com/oracle/vagrant-boxes

Expected behavior

once this cmd is executed:
$ vagrant ssh
It should go fine.

Actual behavior

vagrant@127.0.0.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Steps to reproduce

1. install windows 7 as host OS.
   2 cd /vagrant-boxes/Kubernetes (master)
   3: execute : vagrant up master
   Bringing machine 'master' up with 'virtualbox' provider...
   ==> master: Machine already provisioned. Run vagrant provision or use the --provision
   ==> master: flag to force provisioning. Provisioners marked to run always will still run.

main Issue
step4: $ vagrant ssh
vagrant@127.0.0.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

References

similar to issue: #9433.
Only difference is I am using Windows 7 as host instead of win10 in that issue.

[leem32]

I had the same issue on a Windows 7 Host every time I tried to vagrant ssh. For me, the problem was caused by openssh installed on the host. Once I uninstalled I could vagrant ssh no problem. I didn't figure out how to get it working along with openssh though because I didn't need it anymore anyway.

[atulanandnitt]

But I dont have openssh installed.What may be the reason of error in my case ?

Note: I have PuTTy and TigerVNC installed.

[leem32]

Try checking your PATH in environment variables to see if there are any ssh executables in the directories.
I'd be surprised if putty was causing the issue but you could try temporarily removing it from the PATH and run vagrant from Powershell instead. I use Powershell 5.1 without issues so it may also be worth you updating to that. Same for TigerVNC remove it from your PATH and try again.

[chrisroberts]

Would you please provide a gist of the debug output. Thanks.

vagrant ssh --debug

[JuPlutonic]

vagrant ssh -- -vvv gives better information
RE @atulanandnitt Note: I have PuTTy and TigerVNC installed.
prereq. - use private_key.ppk generated by PUTTYGEN
steps:

1. delete private_key file from VAGRANT_FILE_PLACED_IN_DIRECTORY\.vagrant\blah\blah\blah\
2. change Vagrantfile - delete all lines except one ssh related record
   config.ssh.insert_key = false
   if you have config.vm.synced_folder "PATH_DOT_SSH", "/home/vagrant/.ssh" don't remove this line
3. open Ora...VirtualBox. In list of VMs right click on the machine and choose Show. Login: vagrant Password: vagrant
4. next you should write this:
   curl https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub > ~/.ssh/authorized_keys
   [Enter], then right click to get out from VM
5. Finally restart VM, and you can use putty to login over ssh (or use vagrant putty if you know how to add this plugin to vagrant)
   private_keyPPK.zip

[JuPlutonic]

I had the same environment and sitation/bug. I think it happend (Permission denied (publickey)) because of config.vm.synced_folder "/../root_projects/.ssh", "/home/vagrant/.ssh". After I long way of chmoding chowning and in changing rights in Win7 (adding only Adimistrators and my user, using icacls as ls -l analog) I found what actionally it seems to be synced_folders bug.

[kuops]

after windows 10 update 1803 has an error in wsl

vagrant up

==> default: Rsyncing folder: /mnt/d/vagrant-home/kubernetes/ => /vagrant
There was an error when attempting to rsync a synced folder.
Please inspect the error message below for more info.

Host path: /mnt/d/vagrant-home/kubernetes/
Guest path: /vagrant
Command: "rsync" "--verbose" "--archive" "--delete" "-z" "--copy-links" "--no-owner" "--no-group" "--rsync-path" "sudo rsync" "-e" "ssh -p 2222 -o LogLevel=FATAL  -o ControlMaster=auto -o ControlPath=/tmp/ssh.80 -o ControlPersist=10m  -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i '/mnt/d/vagrant-home/kubernetes/.vagrant/machines/default/virtualbox/private_key'" "--exclude" ".vagrant/" "/mnt/d/vagrant-home/kubernetes/" "vagrant@127.0.0.1:/vagrant"
Error: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]

[John3]

Hi! win10 has include a ssh client. You just need to remove it from "settings => apps => apps and features => Optional features". I not see this as a real issue from vagrant.

[darkn3rd]

I noticed C:\WINDOWS\System32\OpenSSH\ssh.EXE when doing debug, and sure enough, it was that feature that breaks vagrant. Is there a way to remove this feature? Once it is removed, the following is used: C:\HashiCorp\Vagrant\embedded\usr\bin/ssh.EXE

[chrisroberts]

Generated private key permissions should be fixed in the latest Vagrant release (updated in 2.1.2). You can also tell vagrant to prefer the embedded tools using an environment variable:

https://www.vagrantup.com/docs/other/environmental-variables.html#vagrant_prefer_system_bin

Cheers!

[dvgamerr]

Hi! win10 has include a ssh client. You just need to remove it from "apps and features => Optional features". I not see this as a real issue from vagrant.

Where is "apps and features => Optional features"???

[munkiepus]

If you're on windows 10 powershell. Just set the environment variable like this:
$Env:VAGRANT_PREFER_SYSTEM_BIN += 0
This will tell vagrant to use the builtin vagrant ssh rather than using C:\WINDOWS\System32\OpenSSH\/ssh.EXE

[emayssat]

What is probably happening is that you cannot ssh in the box because you deleted the vagrant entry in ~vagrant/.ssh/authorized_keys in the vagrant box.
On your host, the private_key you use (vagrant ssh --debug) should have the corresponding public key in the authorized_keys in the vagrant box.

So if somehow you still have a session open, modify the authorized_key accordingly (or cut and past a private key from vagrant box to host)

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.