vagrant ssh` does not connect to vm on Windows 10 (2)

[EgonFrerich]

I found the issue 9027 but this issue is closed and there is no solution.

Vagrant version

2.1.1

Host operating system

Windows 10
PowerShell ISE

Guest operating system

Box: 'torchbox/wagtail-jessie64'

Vagrantfile

# Copy-paste your Vagrantfile here (but don't include sensitive information such as passwords, authentication tokens, or email addresses)# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.

  # Every Vagrant development environment requires a box. You can search for
  # boxes at https://atlas.hashicorp.com/search.
  config.vm.box = "torchbox/wagtail-jessie64"
  config.vm.box_version = "~> 2.0"

  # Disable automatic box update checking. If you disable this, then
  # boxes will only be checked for updates when the user runs
  # `vagrant box outdated`. This is not recommended.
  # config.vm.box_check_update = false

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8000" will access port 8000 on the guest machine.
  config.vm.network "forwarded_port", guest: 8000, host: 8000

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # config.vm.network "private_network", ip: "192.168.33.10"

  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # config.vm.network "public_network"

  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"

  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  # Example for VirtualBox:
  #
  # config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
  #   vb.gui = true
  #
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  # end
  #
  # View the documentation for the provider you are using for more
  # information on available options.

  # Define a Vagrant Push strategy for pushing to Atlas. Other push strategies
  # such as FTP and Heroku are also available. See the documentation at
  # https://docs.vagrantup.com/v2/push/atlas.html for more information.
  # config.push.define "atlas" do |push|
  #   push.app = "YOUR_ATLAS_USERNAME/YOUR_APPLICATION_NAME"
  # end

  # Enable provisioning with a shell script. Additional provisioners such as
  # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   sudo apt-get update
  #   sudo apt-get install -y apache2
  # SHELL
  config.vm.provision :shell, :path => "vagrant/provision.sh", :args => "bakerydemo"

  # Enable agent forwarding over SSH connections.
  config.ssh.forward_agent = true

  if File.exist? "Vagrantfile.local"
    instance_eval File.read("Vagrantfile.local"), "Vagrantfile.local"
  end
end

Debug output

https://gist.github.com/EgonFrerich/33e698d2dc8a1f9a0ef7a3ff27f85793

Expected behavior

There should be the prompt with the SSH session.

Actual behavior

There is no prompt so the system hangs.

Steps to reproduce

1.
2.
3.

References

Are there any other GitHub issues (open or closed) that should be linked here?
For example:

• GH-9027
• ...

[briancain]

Hi there @EgonFrerich - If you set this environment variable, are you able to see a prompt in your ssh session?

set VAGRANT_PREFER_SYSTEM_BIN=0
vagrant ssh

Thanks!

[EgonFrerich]

Am 26.06.2018 um 17:37 schrieb Brian Cain:

Hi there @EgonFrerich https://github.com/EgonFrerich - If you set this
environment variable, are you able to see a prompt in your ssh session?

|set VAGRANT_PREFER_SYSTEM_BIN=0 vagrant ssh |

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/vagrant/issues/9950#issuecomment-400355385,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOcNLhZJdrRxvYzeMEfIEDmfdQ834ZNks5uAlUggaJpZM4U3asK.

Same result!

Egon Frerich

[chrisroberts]

@EgonFrerich Would you provide the debug output again so we can see which ssh executable is being invoked: vagrant ssh --debug

Thanks!

[EgonFrerich]

This is the new session:

https://gist.github.com/EgonFrerich/324fd0573029855edeefe867caec9e7a

( I assume the set-statement is stored with vagrant.)

[chrisroberts]

@EgonFrerich Hi. No, the set statement is not stored within Vagrant. It is an environment variable that can be set and is isolated to your local environment. It looks like it is not being set based on the output in that debug gist. And it looks like you are using powershell, not cmd.exe so you'll want to use $env:

C:\some\path> $env:VAGRANT_PREFER_SYSTEM_BIN="0"
C:\some\path> vagrant ssh

[EgonFrerich]

Thank you! But again no prompt.

https://gist.github.com/EgonFrerich/cb2e26306347d9f06e39174cca3e6f12

As you can see from the log: I tried first without --debug.

[EgonFrerich]

Today I tried vagrant again. Not in PowerShell but with cmd.exe. In this environment I get the prompt.

crosoft Windows [Version 10.0.17134.112]
(c) 2018 Microsoft Corporation. Alle Rechte vorbehalten.

C:UsersEgon>cd c:tmpbakerydemo

c:tmpbakerydemo>set VAGRANT_PREFER_SYSTEM_BIN=0

c:tmpbakerydemo>vagrant up
==> vagrant: A new version of Vagrant is available: 2.1.2!
==> vagrant: To upgrade visit: https://www.vagrantup.com/downloads.html

Bringing machine 'default' up with 'virtualbox' provider...
==> default: This machine used to live in C:/tmp/bakerydemo but it's now at c:/tmp/bakerydemo.
==> default: Depending on your current provider you may need to change the name of
==> default: the machine to run it as a different machine.
==> default: Checking if box 'torchbox/wagtail-jessie64' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 8000 (guest) => 8000 (host) (adapter 1)
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> 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: Connection reset. Retrying...
default: Warning: Connection aborted. Retrying...
default: Warning: Connection reset. Retrying...
default: Warning: Connection aborted. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
default: The guest additions on this VM do not match the installed version of
default: VirtualBox! In most cases this is fine, but in rare cases it can
default: prevent things such as shared folders from working properly. If you see
default: shared folder errors, please make sure the guest additions within the
default: virtual machine match the version of VirtualBox you have installed on
default: your host and reload your VM.
default:
default: Guest Additions Version: 4.3.36
default: VirtualBox Version: 5.2
==> default: Mounting shared folders...
default: /vagrant => C:/tmp/bakerydemo
==> default: Machine already provisioned. Run vagrant provision or use the --provision
==> default: flag to force provisioning. Provisioners marked to run always will still run.

c:tmpbakerydemo>vagrant ssh

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Jul 1 07:48:54 2018 from 10.0.2.2
[bakerydemo vagrant]$ ./manage.py runserver
: No such file or directory
[bakerydemo vagrant]$ ls
app.json bakerydemodb docker-compose.yml Dockerfile Procfile requirements runtime.txt vagrant
bakerydemo contributing.md docker-entrypoint.sh manage.py readme.md requirements.txt stellar.yaml Vagrantfile
[bakerydemo vagrant]$ python manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).
July 06, 2018 - 07:40:19
Django version 2.0.6, using settings 'bakerydemo.settings.local'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

But I cannot access the website.

[chrisroberts]

Hi there. When starting the server on the guest, you will need to add configuration options so that it does not bind to localhost. And to access it from the host you will need to either use the guest's address, or forward the 8000 port from the guest to a free port on the host. You can read more about port forwarding here:

https://www.vagrantup.com/docs/networking/forwarded_ports.html

Cheers!

[ezesiza]

@EgonFrerich Hi. No, the set statement is not stored within Vagrant. It is an environment variable that can be set and is isolated to your local environment. It looks like it is not being set based on the output in that debug gist. And it looks like you are using powershell, not cmd.exe so you'll want to use $env:

C:\some\path> $env:VAGRANT_PREFER_SYSTEM_BIN="0" C:\some\path> vagrant ssh Thanks @chrisroberts you made my day!!!!!

[hashibot[bot]]

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.