Vagrant: `vagrant ssh` does not connect to vm on Windows 10
Please note that the Vagrant issue tracker is reserved for bug reports and
enhancements. For general usage questions, please use the Vagrant mailing list:
https://groups.google.com/forum/#!forum/vagrant-up. Thank you!
Vagrant version
λ vagrant -v
Vagrant 2.0.0
Host operating system
Microsoft Windows 10 Enterprise
Version 10.0.14393 Build 14393
Guest operating system
Ubuntu 16.04 (Xenial)
Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure('2') do |config|
config.vm.box = 'kmm/ubuntu-xenial64'
config.vm.network :public_network, bridge: 'vm-nat'
config.vm.synced_folder '.', '/vagrant', type: 'smb', smb_username: ENV['HOST_USER'], smb_password: ENV['HOST_SECRET'], mount_options: ["domain=#{ENV['USERDNSDOMAIN']}"]
config.vm.provider :hyperv do |hyperv|
hyperv.cpus = 2
hyperv.memory = 512
end
end
Debug output
Note that the bug does not occur when running with --debug flag!
https://gist.github.com/pyranja/5b798ef8e0efcdd2bb102b85685185fa
Expected behavior
vagrant ssh should open a ssh connection to the running VM.
Actual behavior
vagrant ssh returns to the host shell, the ssh connection is not established. The VM ssh server does not log a connection attempt. Note that injection of private keys and provisioning during vagrant up does work. Unfortunately (?) vagrant --debug ssh does work as expected, i.e. the debug output may be misleading...
λ vagrant up
Bringing machine 'default' up with 'hyperv' provider...
==> default: Verifying Hyper-V is enabled...
==> default: Starting the machine...
==> default: Waiting for the machine to report its IP address...
default: Timeout: 120 seconds
default: IP: 10.0.76.30
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 10.0.76.30:22
default: SSH username: vagrant
default: SSH auth method: private key
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Preparing SMB shared folders...
==> default: Mounting SMB shared folders...
default: C:/Users/boch/tmp/vagrant-bug => /vagrant
C:\Users\boch\tmp\vagrant-bug
λ vagrant ssh
C:\Users\boch\tmp\vagrant-bug
λ
Steps to reproduce
vagrant upa VMvagrant sshyields no shell on the guest machinevagrant --debug sshdoes work!
References
pyranja
All 33 comments
Works as expected in v1.9.8
pyranja
on 3 Oct 2017
+1
tamanishi
on 25 Oct 2017
@pyranja Would you please provide the --debug output from the ssh command. Even though it _does_ work, where it fails without the flag, I'd like to inspect the output to see if there are any clues pointing at the root cause. Thanks!
chrisroberts
on 25 Oct 2017
It's in the linked gist: https://gist.github.com/pyranja/5b798ef8e0efcdd2bb102b85685185fa
pyranja
on 26 Oct 2017
@pyranja Ah, apologies! I missed the link in the body of the original issue. Thanks!
chrisroberts
on 26 Oct 2017
+1
petrparolek
on 12 Nov 2017
+1 Same issue on win7 x64 vagrant v2.0.0 as well
d3vel0per
on 26 Nov 2017
+1 This is quite a serious issue can this be looked into?
james-s-nduka
on 30 Nov 2017
Is there a way to increase the log level without using --debug ? Maybe that could provide some clues.
pyranja
on 30 Nov 2017
For anyone looking to just get something working with windows 10, as @pyranja mentioned above it works with v1.9.8 and virtualbox 5.1
slinlee
on 6 Dec 2017
+1
grabbyGrabowski
on 13 Dec 2017
Windows 10 Version 1709
Vagrant 2.0.1
VirtualBox 5.2.2
Same problem here.
Log example.
vzabawski
on 14 Dec 2017
+1
joseareland
on 14 Dec 2017
Windows 10 Version 1709
Vagrant 2.0.1
VirtualBox 5.2.2
i got the problem by "vagrant ssh"
tput: No value for $TERM and no -T specified
i seems ok , but i cannot type any command
zach007
on 15 Dec 2017
I had the same issue with Windows 10
VirtualBox 5.2.5
Vagrant 2.01.
Changed terminals from GitBash to cmd and now it works perfectly fine.
ozonsozons
on 23 Jan 2018
I've got the following output when I extract and run ssh command directly
`C:\HashiCorp\Vagrant\embedded\bin/ssh.EXE "[email protected]" "-p" "22" "-o" "LogLevel=INFO" "-o" "Compression=yes" -o DSAAuthentication=yes "-o" "IdentitiesOnly=yes" "-o" "StrictHostKeyChecking=no" "-o" "UserKnownHostsFile=/dev/null" -o IdentityFile=c:/MY_PATH/hyperv/private_key
Warning: Permanently added '192.168.202.131' (ECDSA) to the list of known hosts.
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions for 'c:/MY_PATH/hyperv/private_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "c:/MY_PATH/hyperv/private_key": bad permissions`
Removing AUTHENTICATED_USERS and adding CREATOR_OWNER user with RWX permissionin permissions tab for the file solved the problem.
I guess this needs to be done somehow in the code for Enterprise versions of windows
nicetuxedo
on 5 Feb 2018
Looks like vagrant ssh doesn't work from GitBash, though works fine from cmd.
BELOW is the output from GitBash
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_5_1: - [1, "ssh", 2222, 22, "127.0.0.1"]
INFO subprocess: Starting process: ["C:\HashiCorp\Vagrant\embedded\usr\bin/ssh.EXE"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stderr: usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
[-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
[user@]hostname [command]
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 255
INFO ssh: Invoking SSH: ssh ["[email protected]", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentityFile="C:/Users/schaturvedi/vagrant_vm/vagrantdev01/.vagrant/machines/default/virtualbox/private_key""]
DEBUG safe_exec: Converting command and arguments to common UTF-8 encoding for exec.
DEBUG safe_exec: Command: "ssh" Args: ["[email protected]", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentityFile=\"C:/Users/schaturvedi/vagrant_vm/vagrantdev01/.vagrant/machines/default/virtualbox/private_key\""]
DEBUG safe_exec: Converted - Command: "ssh" Args: ["[email protected]", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentityFile=\"C:/Users/schaturvedi/vagrant_vm/vagrantdev01/.vagrant/machines/default/virtualbox/private_key\""]
schaturvedi@SCHATURVEDI-PC MINGW64 ~/vagrant_vm/vagrantdev01
Now, Below is the output from cmd
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_5_1: - [1, "ssh", 2222, 22, "127.0.0.1"]
INFO subprocess: Starting process: ["C:\HashiCorp\Vagrant\embedded\usr\bin/ssh.EXE"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stderr: usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
[-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
[user@]hostname [command]
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31998
DEBUG subprocess: Exit status: 255
INFO ssh: Invoking SSH: ssh ["[email protected]", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentityFile="C:/Users/schaturvedi/vagrant_vm/vagrantdev01/.vagrant/machines/default/virtualbox/private_key""]
DEBUG safe_exec: Converting command and arguments to common UTF-8 encoding for exec.
DEBUG safe_exec: Command: "ssh" Args: ["[email protected]", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentityFile=\"C:/Users/schaturvedi/vagrant_vm/vagrantdev01/.vagrant/machines/default/virtualbox/private_key\""]
DEBUG safe_exec: Converted - Command: "ssh" Args: ["[email protected]", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentityFile=\"C:/Users/schaturvedi/vagrant_vm/vagrantdev01/.vagrant/machines/default/virtualbox/private_key\""]
[vagrant@vagrantdev01 ~]$
ChaturvediSulabh
on 8 Feb 2018
I have the same issue on a brand new install of windows 10 (Enterprise edition) Using vagrant version 2.0.2 with virtual box 5.2.6 and the ubuntu/trusty64 box.
C:\Program Files (x86)\HashiCorp\Vagrant\embedded\bin>ssh.exe "[email protected]" "-p" "22" "-o" "LogLevel=INFO" "-o" "Compression=yes" -o DSAAuthentication=yes "-o" "IdentitiesOnly=yes" "-o" "StrictHostKeyChecking=no" "-o" "UserKnownHostsFile=/dev/null" -o IdentityFile=F:/Lab/.vagrant/machines/default/virtualbox/private_key
Warning: Permanently added '192.168.33.10' (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'F:/Lab/.vagrant/machines/default/virtualbox/private_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "F:/Lab/.vagrant/machines/default/virtualbox/private_key": bad permissions
[email protected]'s password:
carbontwelve
on 16 Feb 2018
To get it working I had to do as @nicetuxedo suggested and remove all inherited permissions before setting the private_key as accessible by my user and SYSTEM
carbontwelve
on 16 Feb 2018
I'm having the same issue on Windows 8, vagrant 2.0.2, virtualbox 5.2.6
It looks like the issues are caused by bundled ssh client, while running vagrant ssh from git-bash works fine.
For some reason bundled ssh client does some additional permission checks on private_key file, while ssh client from git-bash does not do those checks.
Funny thing is that private_key file is created by vagrant itself and permissions are set (or not set) by vagrant, so it's strange that bundled has issues.
In addition to that if some plugins are used like vagrant-hostmanager which are ssh-ing into the box internally then they fail anyway even when vagrant up is started from git-bash.
dhampik
on 25 Feb 2018
IMO, this is, as rational as it seems to be, a showstopper.
Imagine, someone (like me) comes from the "Getting started guide" and executes
vagrant init <some>
vagrant up
vagrant ssh
which fails because the test folder is coincidentally not located below %USERPROFILE% (why should it - it's too deep a folder structure) but somewhere else - no error message besides "denied".
You have to go the whole way though vagrant --debug ssh or vagrant ssh -- -vvv just to find out there's no solution other than changing NTFS permissions. That's no too obvious, unfortunately. And it becomes tedious, if working as an AD domain user without extended privileges (well, I could finally set it to Creator/Owner, but that's not the point).
Is there any "official" statement regarding this problem?
jeffrson
on 27 Feb 2018
If they are unable to modify the ssh.exe to be less restrictive I would personally suggest for Vagrant to warn the user and maybe link to documentation saying how to fix the issue.
carbontwelve
on 27 Feb 2018
Another solution: let vagrant up change access rights of private_key after creating it (might call cacls or icacls for that).
icacls private_key /inheritance:r
icacls private_key /grant:r *S-1-3-0:F
If you have multiple vms, this will work as well -
(Get-ChildItem -filter 'private_key' -recurse -path .\.vagrant).FullName | % {
icacls $_ /inheritance:r
icacls $_ /grant:r *S-1-3-0:F
}
penguin02007
on 8 Mar 2018
Hi there,
This has been resolved with the 2.0.3 release using the embedded ssh. The 2.0.4 release will include updated permissions on the private key so ssh executables enforcing the permissions checks will not fail.
Cheers!
chrisroberts
on 27 Mar 2018
issues still persists...none of the solution mentioned is working on windows 10
pratikbhopal
on 21 Apr 2018
The problem is still not solved in latest version 2.0.4. I tried every solution. Nothing works.
montao
on 23 Apr 2018
If the issue still persists you may need to destroy the guest and up it again. The new key pair generation happens during the initial up of the guest, and at that point the permissions on the file will be updated. If you do not want to destroy the guest, manually updating the permissions on the private_key file should be sufficient.
Cheers!
chrisroberts
on 23 Apr 2018
I had this same issue, I tried to change the name of the box from it's original packaged name when importing it into vagrant. As soon as I changed the name back the private keys worked. Beware altering the VM's name from what is was when it was packaged.
matttrach
on 1 May 2018
Run into this issue with the latest Windows Update 1308, this worked: https://github.com/hashicorp/vagrant/issues/9027#issuecomment-363248245
fnagel
on 14 May 2018
Same issue here...
lexdevelop
on 29 May 2018
I've got the following output when I extract and run ssh command directly
`C:HashiCorpVagrantembeddedbin/ssh.EXE "[email protected]" "-p" "22" "-o" "LogLevel=INFO" "-o" "Compression=yes" -o DSAAuthentication=yes "-o" "IdentitiesOnly=yes" "-o" "StrictHostKeyChecking=no" "-o" "UserKnownHostsFile=/dev/null" -o IdentityFile=c:/MY_PATH/hyperv/private_key
Warning: Permanently added '192.168.202.131' (ECDSA) to the list of known hosts.@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions for 'c:/MY_PATH/hyperv/private_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "c:/MY_PATH/hyperv/private_key": bad permissions`Removing AUTHENTICATED_USERS and adding CREATOR_OWNER user with RWX permissionin permissions tab for the file solved the problem.
I guess this needs to be done somehow in the code for Enterprise versions of windows
@nicetuxedo: Root cause fixed by this & it worked.
P.S: This happened Today for me with a working setup of vagrant when creating a new VM, earlier VM's didn't faced this issue with same box.
OS: Windows 10
Vagrant version: 2.2.4
rishibamba
on 19 Jun 2019
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.
![hashibot[bot] picture](https://avatars.githubusercontent.com/in/8332?v=4&s=40)
hashibot[bot]
on 28 Jan 2020
Related issues
dorinlazar
·
3Comments
lebogan
·
3Comments
gwagner
·
3Comments
OtezVikentiy
·
3Comments
DreadPirateShawn
·
3Comments
Most helpful comment
Windows 10 Version 1709
Vagrant 2.0.1
VirtualBox 5.2.2
Same problem here.
Log example.