[
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)
