ssh: no authentication methods

[jtagcat]

What Happened?

Can't connect to ssh machine in any way.

Expected: I specify an ssh host (for example, helium) and it picks up ~/.ssh/config
Expected alternatively: auth would work, maybe it rejects right away because it needs touch on yubikey.

Attach the log file

Without logs, it just hangs like this for minutes:

😄  minikube v1.26.0 on Fedora 36
✨  Using the ssh driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🏃  Updating the running ssh "minikube" bare metal machine ...
^C

(have had it break and recreate VMs multiple times, especially on early interrupts, so was really hesitant to cancel it on non-VM)

I0818 03:14:13.278607  348663 main.go:134] libmachine: Waiting for SSH to be available...
I0818 03:14:13.278635  348663 main.go:134] libmachine: Getting to WaitForSSH function...
I0818 03:14:13.278741  348663 main.go:134] libmachine: Using SSH client type: native
I0818 03:14:13.278807  348663 main.go:134] libmachine: &{{{<nil> 0 [] [] []} root [] 0x7ddf20 <nil>  [] 0s} helium.c7.ee 22 <nil> <nil>}
I0818 03:14:13.278824  348663 main.go:134] libmachine: About to run SSH command:
exit 0
I0818 03:14:13.374388  348663 main.go:134] libmachine: Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
I0818 03:14:16.477501  348663 main.go:134] libmachine: Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain

Without native exits almost immediately:

I0818 03:21:29.574299  349256 main.go:134] libmachine: Waiting for SSH to be available...
I0818 03:21:29.574333  349256 main.go:134] libmachine: Getting to WaitForSSH function...
I0818 03:21:29.574561  349256 main.go:134] libmachine: Using SSH client type: external
I0818 03:21:29.574758  349256 main.go:134] libmachine: &{[-F /dev/null -o ConnectionAttempts=3 -o ConnectTimeout=10 -o ControlMaster=no -o ControlPath=none -o LogLevel=quiet -o PasswordAuthentication=no -o ServerAliveInterval=60 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@helium.c7.ee -p 22] /usr/bin/ssh <nil>}
I0818 03:21:29.574815  349256 main.go:134] libmachine: About to run SSH command:
exit 0
I0818 03:21:29.813629  349256 main.go:134] libmachine: SSH cmd err, output: exit status 255:
I0818 03:21:29.813675  349256 main.go:134] libmachine: Error getting ssh command 'exit 0' : ssh command error:
command : exit 0
err     : exit status 255
output  :

log.txt

Operating System

Redhat/Fedora

Driver

SSH

[afbjorklund]

maybe it rejects right away because it needs touch on yubikey

only non-interactive keys are supported by the current implementation

• ssh: add support for extension negotiation (rfc 8308) golang/crypto#197

You would need to add a second software key, just for minikube ssh ...

Possibly try --native-ssh=false, for a potential future workaround ?

[afbjorklund]

Another approach is to log in to the remove server, and use the "none" driver.

Then the cluster would not be (directly) available from the host/laptop, though.

[jtagcat]

@afbjorklund: --native-ssh=false results in output as shown on first post, under Without native exits almost immediately:

[afbjorklund]

Can't actually see the output, so maybe needs to be run manually (or some LogLevel flags tweaked)

Most likely is that ssh didn't find any keys with a crypto that it liked, so it just exited early (error 255).

     ssh exits with the exit status of the remote command or with 255 if an error occurred.

Either way, to support yubikey it probably also should support "notouch" - or it is likely to time out ?

[afbjorklund]

Note also that most of this is handled by libmachine, that isn't really seeing much development...

https://github.com/docker/machine/blob/master/libmachine/ssh/client.go

But I can't really see any private keys being passed to the command at all, in the logs you posted.

So I guess it was expecting ssh-agent ?

[afbjorklund]

@jtagcat also, ~/.ssh/config isn't used here (as per directive -F /dev/null)

 -F configfile
         Specifies an alternative per-user configuration file.  If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will
         be ignored.  The default for the per-user configuration file is ~/.ssh/config.

Only the flags passed by the library are in play... Usually, the Auth.Keys.

[jtagcat]

@jtagcat also, ~/.ssh/config isn't used here (as per directive -F /dev/null)

 -F configfile
         Specifies an alternative per-user configuration file.  If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will
         be ignored.  The default for the per-user configuration file is ~/.ssh/config.

Only the flags passed by the library are in play... Usually, the Auth.Keys.

aha, that's probably it. Anygay, I have the none driver working. Let me know if you need anything.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.