SSH Config not sufficient in WSL2

[mesa123123]

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

A clear and concise description of what the bug is.
I'm trying to build the default bento boxes from the tutorial on wsl2; which unlike wsl1 is a virtual machine in itself. but as I've been attempting to do this with kitchen create I'm getting the following error:

Which doesn't happen when I'm doing it on the windows side:

Version

[Version of the project installed]
I believe that the version of the gem kitchen-vagrant I'm using is 1.9.0

Environment

[Details about the environment such as the Operating System, cookbook details, etc...]
My windows build is 19043.1055
and I've kept everything upto date on the chef side of things as well as with wsl2

Scenario

[What you are trying to achieve and you can't?]

I'm trying to run kitchen create which hopefully will bring up two the <ubuntu-default 2004> box in wsl2 and it fails at trying to connect to the vm through ssh

Expected Result

[What are you expecting to happen as the consequence of above reproduction steps?]
It just gets stuck trying to connect to vm through ssh which doesn;t work

[mesa123123]

Follow up:

This was a quirk i remember about wsl2 and win10s relationship, is there a way I could set the ssh call that kitchen is making during kitchen create so that it sends it to the windows' ip rather than just going to 127.0.0.1 by default?

[mesa123123]

like what I'm imagining is getting the WIN10IP in an envrionment variable and then just using that as an option in kitchen.yml as ENV['winip'] or something similar?

[mesa123123]

Would it have something to do with creating this setting into the eventual vagrant file?

[minsis]

By default WSL2 is supposed to be forwarding localhost ports inside WSL and translate that to the Windows host. However, it seems this feature has been bugged out on and off throughout different builds.

As a work around you can get this yourself:

$> ip route | grep default | awk '{print $3}'

Then in your kitchen.yaml

---
driver:
  name: vagrant
  ssh:
    host: <IP from above>
  network:
    - ["forwarded_port", {host_ip: '0.0.0.0', host: 2222, guest: 22, auto_correct: true}]

Another option might be to use ERB as kitchen.yml is executed in the engine:

...
    host: <%= `ip route | grep default | awk '{print $3}'` %>
...

Or in your case you wanted to use an environment variable:

$> export WIN10IP=$(ip route | grep default | awk '{print $3}')

...
    host: <%= ENV['WIN10IP'] %>
...

Final Thoughts:
Seeing as there is no default port forwarding setup in the generated Vangrantfile, I'm guessing vagrant is doing this under the hood. So in this case you need to set a forwarded port to bind to 0.0.0.0. I think the only issue here is that vagrant doest care about this and still creates its own forwarded port in addition. So if vagrant is setting the bind port to 2200, your configured port here is always going to set to 2222 (unless used) and the connection isn't going to happen. You might be able to guarantee it with config.ssh.port (not tested this).

A work around is to just manually change the port forwarding to bind on 0.0.0.0 after the vagrant box has been created.

But while all these are nice work arounds, they dont really translate into a possible CI/CD pipeline. This is where it would be nice if this kitchen-vagrant could figure some of this stuff out under the hood.

Seeing as the environment variable VAGRANT_WSL_ENABLE_WINDOWS_ACCESS needs to be set in WSL for vagrant to even function, you could probably check for it and then get the underlying Windows IP address.