Windows client fails to bootstrap due to strict host checking failure

Trying to use the Windows Client 2.8.1 and bootstrap a new controller. I currently have an issue with having to call out the instance-type, but I’m tracking that in another thread. This one is to report the issue that the client has, trying to SSH into the controller during bootstrap.

So assuming I have called out the instance-type in order to avoid the “The requested size for resource…is currently not available in location…” error, I issue the following bootstrap command.

juju bootstrap azure/southcentralus test-controller --credential azure-dev-platform-sub --constraints instance-type=Standard_D2s_v3 --debug

Everything goes great up until Juju tries to connect to the controller instance it just created. I then see the following in the logs…

## This is normal while waiting for the machine to open up network access.

17:44:42 DEBUG juju.provider.common bootstrap.go:615 connection attempt for failed: ssh: connect to host port 22: Connection timed out
## But once we get connectivity, I get the following 
## which repeats until the timeout period is up and the operation fails and rolls back

17:45:44 DEBUG juju.provider.common bootstrap.go:615 connection attempt for failed: No RSA host key is known for and you have requested strict checking.
Host key verification failed.

Things I’ve tried

  • I can manually add the host keys while this is occurring, with no different result
  • I can SSH using command line parameters to bypass strict host checking to connect to the host successfully
  • I can update my ~/.ssh/config to bypass strict host checking

All these things allow me to connect from my local SSH client, but I assume that the client is using a bundled OpenSSH client which is not reading my local SSH settings. Because none of these produce a successful bootstrap.

I think this is a bug with the Windows client only. But I am not able to try using the Linux or Mac clients. I almost could test using the Linux client by running in a container, but the container is only able to run 2.7.6 right now due to availability of the Linux binary. I suppose I could build the Linux binary into a container, but I don’t have the cycles to do that now.

I’m hoping that someone else can reproduce this on a Windows client to verify this is a bug and not just a problem on my system.

I can reproduce this on a Windows VM.

The VM is running:
Windows 10 Home
Version 1903
build 18362.959

I believe the CI system is running on older versions of Windows (also not Home), so this might be a default that changed in Windows.

What version of Windows are you running?

Windows 10 Pro
Version 2004 (19041.450)

I filed a bug tracking the issue here: Bug #1892886 “Juju client cannot bootstrap from Windows 10” : Bugs : juju

Thx, @danhaws for bringing this to our attention.

My pleasure @petevg! Thanks for responding so promptly. Appreciate the support.