[jira] [Comment Edited] (WAGON-446) SSH agent authentication is no longer working in wagon-ssh 2.10

["Per Landberg (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WAGON-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16697277#comment-16697277 ] 

Per Landberg edited comment on WAGON-446 at 11/23/18 3:21 PM:
--------------------------------------------------------------

Sorry for taking so long to reply... I'm also interested in having this issue sorted out.

I completely agree with item #1 and as it would be easier to understand and should behave correctly.

Regarding item #2: the key here is applying the same logic as ssh. I have tested six different use-cases using ssh -vv and no .ssh/config file against a ssh server that only allows public key authentication
 * With ssh-agent and no -i option:
 Authentication succeeds and the list of keys contains first the keys from the agent and a default list of known keys is added last. The known keys are  id_rsa , id_dsa, id_ecdsa, id_ed25519.
 * With ssh-agent and -i <existing-key-non-default-name>
 Authentication succeeds and the explicit key is added last to the list of agent keys and default list.
 * With ssh-agent and -i <non-existing-key>
 Authentication succeeds and the explicit key is ignored. Only the keys in the agent and default list are considered.
 * No ssh-agent and no -i option:
 Authentication fails since ssh didn't find any keys in it's default list
 * No ssh-agent and -i <existing-key>
 The only key in the list is the  given key. Ssh prompts for a passphrase.
 * No ssh-agent and -i <non-existing-key>
 Authentication fails since ssh didn't find the non-existsing key. No other keys are considered.

Based on the tests above, I would say that if an agent is available, all keys from the agent is added first to the list of keys to try. If an explicit key is found it's added last in the list.
 If no agent is available, ssh will create a candidate list of known keys and any explicit keys last and if any of those are found, it will ask for a passphrase.

So, if wagon-ssh should follow ssh's behavior, it definitely should look for a ssh-agent first and only call getPrivateKey if the agent has no usable keys so this probably means that wagon-ssh needs to try to authenticate when an agent is available and it that fails, perform another attempt with the result of getPrivateKey(). Is this doable?


was (Author: perlan):
Sorry for taking so long to reply... I'm also interested in having this issue sorted out.

I completely agree with that it would be easier to understand and should behave correctly.

Regarding item #2: the key here is applying the same logic as ssh. I have tested six different use-cases using ssh -vv and no .ssh/config file against a ssh server that only allows public key authentication
 * With ssh-agent and no -i option:
Authentication succeeds and the list of keys contains first the keys from the agent and a default list of known keys is added last. The known keys are  id_rsa , id_dsa, id_ecdsa, id_ed25519.
 * With ssh-agent and -i <existing-key-non-default-name>
Authentication succeeds and the explicit key is added last to the list of agent keys and default list.
 * With ssh-agent and -i <non-existing-key>
Authentication succeeds and the explicit key is ignored. Only the keys in the agent and default list are considered.
 * No ssh-agent and no -i option:
Authentication fails since ssh didn't find any keys in it's default list
 * No ssh-agent and -i <existing-key>
The only key in the list is the  given key. Ssh prompts for a passphrase.
 * No ssh-agent and -i <non-existing-key>
Authentication fails since ssh didn't find the non-existsing key. No other keys are considered.

Based on the tests above, I would say that if an agent is available, all keys from the agent is added first to the list of keys to try. If an explicit key is found it's added last in the list.
If no agent is available, ssh will create a candidate list of known keys and any explicit keys last and if any of those are found, it will ask for a passphrase.

So, if wagon-ssh should follow ssh's behavior, it definitely should look for a ssh-agent first and only call getPrivateKey if the agent has no usable keys so this probably means that wagon-ssh needs to try to authenticate when an agent is available and it that fails, perform another attempt with the result of getPrivateKey(). Is this doable?

> SSH agent authentication is no longer working in wagon-ssh 2.10
> ---------------------------------------------------------------
>
>                 Key: WAGON-446
>                 URL: https://issues.apache.org/jira/browse/WAGON-446
>             Project: Maven Wagon
>          Issue Type: Bug
>          Components: wagon-ssh
>    Affects Versions: 2.10
>            Reporter: Per Landberg
>            Assignee: Dan Tran
>            Priority: Major
>             Fix For: waiting-for-feedback
>
>         Attachments: wagon-446.patch
>
>
> After upgrading to wagon-2.10,  SSH Agent authentication doesn't seems to work anymore. I got the following error when trying to publish a site, using maven-site-plugin 3.4:
> Using private key: <PATH TO id_rsa>
> : Error uploading site: Cannot connect. Reason: Auth fail -> [Help 1]
> I have no server for this site defined in my settings.xml
> After some investigation, I suspect that the cause is WAGON-413 since the  logic in AbstractJschWagon was changed to not use the agent if ScpHelper.getPrivateKey() returns a File. 
> Unfortunate, ScpHelper.getPrivateKey() seems to have a fallback behavior that always returns the id_rsa key (if one exists) even when no matching server element exists in settings.xml and the effect is that the agent is never consulted. 
> The authentication will then fail since no server element provides a key password.
> My current workaround is to set the wagon.privateKeyDirectory System Property to an empty directory. This will prevent the ScpHelper.getPrivateKey() fallback to kick in.
> Has anybody else got SSH agent working in combination with existing id_rsa files?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)