Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vagrant ssh on Windows 11 does not use the system ssh executable #13634

Closed
adhaliwal34 opened this issue Mar 29, 2025 · 4 comments
Closed

vagrant ssh on Windows 11 does not use the system ssh executable #13634

adhaliwal34 opened this issue Mar 29, 2025 · 4 comments

Comments

@adhaliwal34
Copy link

adhaliwal34 commented Mar 29, 2025

Debug output

https://gist.github.com/adhaliwal34/0f3f2e62dff6238c0a9248ab8b3aed22

Expected behavior

vagrant ssh should use the system ssh executable (C:\Windows\System32\OpenSSH\ssh.exe for me) on Windows as stated in the documentation.

Actual behavior

C:\Program Files (x86)\Vagrant\embedded\usr\bin\ssh.EXE is used

Reproduction information

Vagrant version

Vagrant 2.4.3

VirtualBox version

VirtualBox 7.1.6 r167084

Host operating system

Windows 11 Pro 23H2

Guest operating system

Ubuntu Jammy 64

Steps to reproduce

  1. cd to your project directory. (cd C:\Users\adhaliwal\MyVirtualMachines for me)
  2. mkdir ubuntu_jammy
  3. cd .\ubuntu_jammy\
  4. vagrant init ubuntu/jammy64 --box-version 20241002.0.0
  5. vagrant up
  6. vagrant ssh --debug

Vagrantfile

# -*- 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://vagrantcloud.com/search.
  config.vm.box = "ubuntu/jammy64"
  config.vm.box_version = "20241002.0.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:8080" will access port 80 on the guest machine.
  # NOTE: This will enable public access to the opened port
  # config.vm.network "forwarded_port", guest: 80, host: 8080

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine and only allow access
  # via 127.0.0.1 to disable public access
  # config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1"

  # 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"

  # Disable the default share of the current code directory. Doing this
  # provides improved isolation between the vagrant box and your host
  # by making sure your Vagrantfile isn't accessible to the vagrant box.
  # If you use this you may want to enable additional shared subfolders as
  # shown above.
  # config.vm.synced_folder ".", "/vagrant", disabled: true

  # 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.

  # Enable provisioning with a shell script. Additional provisioners such as
  # Ansible, Chef, Docker, Puppet and Salt are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   apt-get update
  #   apt-get install -y apache2
  # SHELL
end
@adhaliwal34
Copy link
Author

In the debug output we can see the correct ssh exe is found. See here.

INFO global: VAGRANT_PREFER_SYSTEM_BIN="1"
INFO global: VAGRANT_SSH_CLIENT="C:\\Windows\\System32\\OpenSSH\\ssh.exe"

But the embedded ssh executable is still used. See here.

INFO ssh: Invoking SSH: C:\Program Files (x86)\Vagrant\embedded\usr\bin/ssh.EXE ...

@chrisroberts
Copy link
Member

Hi there,

The VAGRANT_SSH_CLIENT environment variable is not something that Vagrant uses internally, and thus will not affect the SSH client that is used when connecting to a guest. If you would like Vagrant to prefer using system tools instead of the embedded tools, use the VAGRANT_PREFER_SYSTEM_BIN environment variable.

Cheers!

@adhaliwal34
Copy link
Author

Hi @chrisroberts ,

VAGRANT_PREFER_SYSTEM_BIN="1" should be the default setting on Windows. This is stated in the docs.

My previous comment is showing the debug output. The debug output shows the necessary settings are found but not followed.

@adhaliwal34
Copy link
Author

From the document you linked

Vagrant will default to using a system provided ssh on Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants