Commands : Failed: Unknown: Exhausted available authentication methods

[StephaneG31]

Describe the bug
Failed to use commands module (with SSH Key stored in the key store) with error like Failed: Unknown: Exhausted available authentication methods

My Rundeck detail

• Rundeck version: 5.0.1

• install type: docker

• DB Type/version: mysql

To Reproduce
Steps to reproduce the behavior:

1. Go to commands
2. Select a node
3. lanch a simple command like "ls"
4. See error

Additional context
Works well before the rundeck 5.x.x migration

[StephaneG31]

On the logs we can see

[2024-03-28T17:55:31,450] INFO  storage.events get file keys/xxx - {Rundeck-content-type=application/octet-stream, Rundeck-auth-modified-username=admin, Rundeck-content-modify-time=2023-10-16T14:21:28Z, Rundeck-content-creation-time=2023-10-16T14:21:28Z, Rundeck-content-size=1675, Rundeck-auth-created-username=admin, Rundeck-key-type=private, Rundeck-content-mask=content}
[2024-03-28T17:55:31,500] ERROR node.NodeStepPluginAdapter - Error executing node step.
com.dtolabs.rundeck.core.execution.workflow.steps.node.NodeStepException: Exhausted available authentication methods
	at jdk.internal.reflect.GeneratedConstructorAccessor819.newInstance(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]
	at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:72) ~[groovy-3.0.19.jar!/:3.0.19]
	at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105) ~[groovy-3.0.19.jar!/:3.0.19]
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:295) ~[groovy-3.0.19.jar!/:3.0.19]
	at org.rundeck.plugin.scriptnodestep.CommandNodeStepPlugin.executeNodeStep(CommandNodeStepPlugin.groovy:55) ~[?:?]
	at com.dtolabs.rundeck.core.execution.workflow.steps.node.NodeStepPluginAdapter.executeNodeStep(NodeStepPluginAdapter.java:169) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.ExecutionServiceImpl.executeNodeStep(ExecutionServiceImpl.java:207) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.dispatch.SequentialNodeDispatcher.dispatch(SequentialNodeDispatcher.java:130) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.dispatch.SequentialNodeDispatcher.dispatch(SequentialNodeDispatcher.java:61) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.ExecutionServiceImpl.dispatchToNodesWith(ExecutionServiceImpl.java:263) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.ExecutionServiceImpl.dispatchToNodes(ExecutionServiceImpl.java:234) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.workflow.steps.NodeDispatchStepExecutor.executeWorkflowStep(NodeDispatchStepExecutor.java:66) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.ExecutionServiceImpl.executeStep(ExecutionServiceImpl.java:111) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.workflow.BaseWorkflowExecutor.executeWFItem(BaseWorkflowExecutor.java:285) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.workflow.BaseWorkflowExecutor.executeWorkflowStep(BaseWorkflowExecutor.java:681) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.workflow.engine.StepCallable.apply(StepCallable.java:71) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.workflow.engine.StepOperation.apply(StepOperation.java:76) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.execution.workflow.engine.StepOperation.apply(StepOperation.java:32) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.dtolabs.rundeck.core.rules.WorkflowEngineOperationsProcessor.lambda$beginOperation$1(WorkflowEngineOperationsProcessor.java:323) ~[rundeck-core-5.0.1-20240115.jar!/:?]
	at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:131) [guava-32.0.1-jre.jar!/:?]
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:75) [guava-32.0.1-jre.jar!/:?]
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:82) [guava-32.0.1-jre.jar!/:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

[lroehrs]

Our mistake was that SSH was supposed to authenticate via key, but the key was not set up on the target system.