Minikube: vmwarefusion: handshake failed: ssh: unable to authenticate, no supported methods remain

Created on 27 Oct 2017  ·  23Comments  ·  Source: kubernetes/minikube

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

BUG REPORT

Please provide the following details:

Environment:

Minikube version (use minikube version):

  • OS: minikube version: v0.23.0
  • VM Driver: vmwarefusion
  • ISO version: file:///Users/kchung/.minikube/cache/iso/minikube-v0.23.6.iso
  • Install tools:
  • Others:
    The above can be generated in one go with the following commands (can be copied and pasted directly into your terminal):

What happened:

Running minikube start --vm-driver=vmwarefusion gets stuck:

~
❯ minikube start --vm-driver=vmwarefusion
Starting local Kubernetes v1.8.0 cluster...
Starting VM...
Downloading Minikube ISO
 140.01 MB / 140.01 MB [============================================] 100.00% 0s
E1027 02:31:16.971076    3294 start.go:150] Error starting host: Error creating host: Error executing step: Provisioning VM.
: Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain.

 Retrying.
E1027 02:31:16.971774    3294 start.go:156] Error starting host:  Error creating host: Error executing step: Provisioning VM.
: Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
================================================================================
An error has occurred. Would you like to opt in to sending anonymized crash
information to minikube to help prevent future errors?
To opt out of these messages, run the command:
    minikube config set WantReportErrorPrompt false
================================================================================
Please enter your response [Y/n]:

What you expected to happen:

Using the previous release of minikube makes it further and seems to work better.

~
❯ minikube start --vm-driver=vmwarefusion
There is a newer version of minikube available (v0.23.0).  Download it here:
https://github.com/kubernetes/minikube/releases/tag/v0.23.0

To disable this notification, run the following:
minikube config set WantUpdateNotification false
Starting local Kubernetes v1.7.5 cluster...
Starting VM...
Downloading Minikube ISO
 139.09 MB / 139.09 MB [============================================] 100.00% 0s
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.

How to reproduce it (as minimally and precisely as possible):

See above. minikube start --vm-driver=vmwarefusion

Output of minikube logs (if applicable):

~ 8m 51s
❯ minikube logs
F1027 02:33:49.237101    3360 logs.go:50] Error getting cluster bootstrapper: getting localkube bootstrapper: getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Anything else do we need to know:

cvmwarefusion essh-auth kinbug lifecyclstale omacos prioritawaiting-more-evidence triagobsolete

Most helpful comment

It looks like the authorized ssh keys are not set up properly for the docker user in the VM.
While the handshake failures are logged, I issued the following command in another terminal, and the startup of minikube finished successfully:

"/Applications/VMware Fusion.app/Contents/Library/vmrun" -gu docker -gp tcuser runScriptInGuest /Users/$USER/.minikube/machines/minikube/minikube.vmx /bin/sh "mkdir /home/docker/.ssh; cp /Users/$USER/.minikube/machines/minikube/id_rsa.pub /home/docker/.ssh/authorized_keys; chown -R docker:staff /home/docker/.ssh"

All 23 comments

IP found in DHCP lease table: 172.16.165.128
Using SSH client type: native
&{{{<nil> 0 [] [] []} docker [0x14376e0] 0x1437690  [] 0s} 172.16.165.128 22 <nil> <nil>}
About to run SSH command:
sudo hostname minikube && echo "minikube" | sudo tee /etc/hostname
Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Some more information from minikube start --vm-driver=vmwarefusion --v 10 --logtostderr

Try to run

minikube delete
rm -rf ~/.minikube
minikube start --vm-driver=vmwarefusion

Solved the problem for me

It looks like the authorized ssh keys are not set up properly for the docker user in the VM.
While the handshake failures are logged, I issued the following command in another terminal, and the startup of minikube finished successfully:

"/Applications/VMware Fusion.app/Contents/Library/vmrun" -gu docker -gp tcuser runScriptInGuest /Users/$USER/.minikube/machines/minikube/minikube.vmx /bin/sh "mkdir /home/docker/.ssh; cp /Users/$USER/.minikube/machines/minikube/id_rsa.pub /home/docker/.ssh/authorized_keys; chown -R docker:staff /home/docker/.ssh"

I'm encountering the same issue and @msieper's fix worked for me. I think it may be a breaking change with VMWare Fusion 10.x. I'm unable to reproduce the issue in Fusion 8.5.

I'm still using Fusion 8.5.8.

The command suggested by @msieper itself did not work entirely for me but I manually created authorized_keys and added the public key and ran the chown command in the VM.

I'm still unable to properly run minikube.

Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

EDIT: Actually this did work but it seems like the timing of running the command is important. I completely deleted my .minikube folder and during the creation of the VM I ran the command it finished setting up.

Had the same issue. Confirmed @msieper 's solution works. I am not sure since when this is broken, but we need to fix it. It's hard to fix it in vmwarefusion because it locates in docker/machine where they are basically inactive. I will make sure when #2118 gets merged, it doesn't have this issue.

I used this from issue #1382 - thanks @urbaniak

@johnbyrneio, you may be correct. I'm running VMWare Fusion 10.0.1. I had the issue and @msieper's script made it work.

Confirmed to happen in VMWare Fusion 8.5.3 too - @msieper fix did work and I could continue installation.

Hi guys, I had same issue and lost 2 hours looking for solution. @msieper fix works for me. Michael huge thank you! :)

I did this _slightly_ differently based on @msieper's solution:

'/Applications/VMware Fusion.app/Contents/Library/vmrun' -gu docker -gp tcuser \
  createDirectoryInGuest ~/.minikube/machines/minikube/minikube.vmx \
  /home/docker/.ssh

'/Applications/VMware Fusion.app/Contents/Library/vmrun' -gu docker -gp tcuser \
  CopyFileFromHostToGuest ~/.minikube/machines/minikube/minikube.vmx \
  ~/.minikube/machines/minikube/id_rsa.pub /home/docker/.ssh/authorized_keys

Worked for me on VMware Fusion 8.5.8.

Yeah, I ran this while doing a minikube start

 while true; do "/Applications/VMware Fusion.app/Contents/Library/vmrun" -gu docker -gp tcuser runScriptInGuest /Users/$USER/.minikube/machines/minikube/minikube.vmx /bin/sh "mkdir /home/docker/.ssh; cp /Users/$USER/.minikube/machines/minikube/id_rsa.pub /home/docker/.ssh/authorized_keys; chown -R docker:staff /home/docker/.ssh"; sleep 5; done

This issue has been fixed in v0.25.0.

This issue is still happening with the following configuration
OSX: 10.13.4
VMWare Fusion: 8.5.10
Minikube: 0.26.0

@msieper's fix seems to work to a point, but it looks like there may be other problems with the vmware fusion driver.

H @msieper i,

I am facing same issue, trying to start minikube in VM created in VMware worksattion

[root@server3 ~]# minikube logs
F0703 08:17:09.992600 9559 logs.go:50] Error getting cluster bootstrapper: getting localkube bootstrapper: getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain

the above command is not working for me,

my OS: CentOS release 6.9 (Final)

VirtulaBox: /usr/bin/VBoxManage --version
5.2.12r122591

Minikube: minikube version: v0.23.0

Can you please help me, got stuck with this.

Thank you.

Hi I am facing this issue while using

.minikube.exe start --kubernetes-version="v1.10.0" --vm-driver="hyperv" --hyperv-virtual-switch="My Virtual Switch" --v=7 --alsologtostderr

Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Please help,

Thank you

This is still happening with v.29 and the chain of "ssh bug during install" issues ends here. If I use the v.27 iso (with the argument --iso-url "https://storage.googleapis.com/minikube/iso/minikube-v0.26.0.iso") it works, but any of the v.28+ isos stall during install with the recurring "Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain" error. Occasionally the error turns into "Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain" as well, whether I am using the native Go ssh client or the one at https://github.com/PowerShell/Win32-OpenSSH .

I'm seeing the same issue with v0.29 and v0.28 on Windows 10 with hyperv. v0.27 is ok.

I had the same issue on Windows 10 with hyper-v.
In my case, it was caused because the key file (.minikube/machines/minikube/id_rsa) is not secure, so I changed permissions as below and then resolved.
https://superuser.com/questions/1296024/windows-ssh-permissions-for-private-key-are-too-open

Today, this issue happened again. Then I built minikube on my local modifying to using external ssh client and tried minikube ssh with it.
Load key "C:\\Users\\Name\\.minikube\\machines\\minikube\\id_rsa": invalid format
Why is it invalid??

I suspect this is obsolete, especially now that there is a new driver (--vm-driver=vmware instead of --vm-driver=vmware-fusion). Has anyone seen this in a recent release?

note: Hyper-V issues are unrelated to this and a separate issue. I suspect this is due to firewall/proxy interference in those cases.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Was this page helpful?
0 / 5 - 0 ratings