[WAGON-446] SSH agent authentication is no longer working in wagon-ssh 2.10

[jira-importer]

Per Landberg opened WAGON-446 and commented

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?

---

Affects: 2.10

Attachments:

• wagon-446.patch (828 bytes)

Issue Links:

• WAGON-616 Deprecate Wagon SSH Provider

[jira-importer]

Dan Tran commented

Per Landberg Hi Per could you please provide a patch?

[jira-importer]

Per Landberg commented

Sure, but...

As I see it, there are two approaches to solving this:

1. Remove the fallback behavior of ScpHelper.getPrivateKey(). This is IMHO the correct solution but it will change the semantic of using wagon-ssh and wagon-ssh-external to always require an explicit privateKey.

2. Try to expand the condition when to use the returned privateKey in AbstractJschWagon, by for example, only use the key if a passphrase is also given and not running interactively. It will certainly work for this issue but it may introduce other problems for other uses-cases.

If you give me a hint of which solution you prefer, I will try to create a patch.

BTW, would a github pull request work as well? Maybe that would be a better forum for discussion which solution is correct?

[jira-importer]

Dan Tran commented

It is very unfortunate that last commit fixed the private key authentication issue, but regress on the ssh-agent. So we can't revert. I am in the same dilemma to figure out how we can detect ssh-agent use case is in-use.

1. 1 sounds right, but it breaks the current behavior. If we do this, we will need to pump the version to 3
2. 2 is the prefer one. with careful thoughts to cover other use-cases

PR from github works

[jira-importer]

Per Landberg commented

Here is a one-line patch that ignores the private key if no passphrase is given. This will fix the current issue but has the side-effect that it will also ignore any private key that lacks a passphrase...

At the moment, the only way I can think of to handle passphrase-less keys is to examine the key itself but I'm not sure how to do that. Any ideas?

[jira-importer]

Dan Tran commented

Let me test this patch locally.Thanks

[jira-importer]

Dan Tran commented

with this patch, ssh-wagon with ssh key with no passphase no longer work since it fall into user/password authentication. looking...

[jira-importer]

Michael Osipov commented

Is this one still valid?

[jira-importer]

Per Landberg commented

I've just tested mvn site-deploy with wagon 3.1.0 and maven-site-plugin 3.7.1 using a .ssh-directory that contains an id_rsa file and agent authentication still doesn't work.

The "Using private key: <PATH TO id_rsa>" line is no longer displayed but the error message is the same as before:

Error uploading site: Cannot connect. Reason: Auth fail -> [Help 1]

Running mvn site-deploy -Dwagon.privateKeyDirectory=/tmp/wagon where /tmp/wagon is an empty directory works correctly.

[jira-importer]

Michael Osipov commented

The patch assumes that a passphrase is given, this must not always be the case with SSH keys.

Per Landberg, do you use a passphrase?`How can I reproduce it? Can you provide a patch maybe?

[jira-importer]

Per Landberg commented

My use-case is running mvn site-deploy in a maven project with distributionManagement.site.url set to use the scp-protocol. I have a SSH private key with a passphrase that I've loaded in a ssh-agent and no specific settings in my settings.xml for the target host. My expectation is that wagon-ssh should detect that i'm using a ssh-agent and use the agent  for authentication when running mvn site-deploy.

The problem is that wagon-ssh finds my private key in my .ssh-directory and always tries to use the key directlry instead of using the ssh-agent. Since I haven't configured a passphrase (and no other settings either in my .m2/settings.xml), wagson-ssh assumez that the key have no passphrase and the authentication fails. My current workaround is to configure wagon-ssh to look for private keys in an empty directory and since no private key is found, wagon-ssh will use the running ssh-agent and the authentication succeed.

Hopefully, my use-case description is enough information to reproduce the problem.

Yes, the patch breaks the use of SSH keys that lacks a passphrase. Unfortunately, the only way I remember back then how to distingush between the implicit use of the fallback private key or using the ssh-agent without compatibility problem is to examine the key to make sure that it doesn't require a passphrase. I have no idea how to perform such a test.If it's possible, I'm willing to help produce such a patch.

The correct way IMHO is to alter the behavior to always require that the private key is declared in settings.xml but as discussed above, this will break current users that depends on the implicit private key. If you like, I could provide such a patch.

[jira-importer]

Michael Osipov commented

Just checked the source code, as far as I can see, the agent support is in and the only way to tell Wagon stop using the private key from user.home is to redirect it with wagon.privateKeyDirectory as you did.

Sadly, I see no non-intrusive way to solve this properly. Does SCP External work for you btw? How does it work for it anyway? Does it try the agent first and then the rest? Maybe we could mimic this behavior with JSch? WDYT?

To solve this properly, we'd need to fully redesign the settings.xml structure.

[jira-importer]

Per Landberg commented

I've now tested maven-ssh-external and it seems to work correctly with the same use-case as above as long as ssh is working from the command line.

Looking at the source, ScpExternalWagon always seems to call ScpHelper.getPrivateKey() so if the id_rsa file is found, the private key will be added to the command line using the -i option but ssh seems to detect and use the ssh-agent if it's available.

Based on how it seems to work, what do you think about changing ScpHelper.getPrivateKey() to detect if a ssh-agent
is available and just skip the call to ScpHelper.findPrivateKey()? For wagon-ssh this will prevent the default key to be used and behave like when using an empty wagon.privateKeyDirectory. For wagon-ssh-external, the key will not be added to the command line but ssh will find the correct key itself as it normally would. This change would fix this issue and hopefully not affect any other use-cases.

Note that I have no idea how this change would affect other external ssh programs like putty.

[jira-importer]

Michael Osipov commented

First of all, thanks for testing. I have a few ideas we could try out.

... what do you think about changing ScpHelper.getPrivateKey() to detect if a ssh-agent
is available and just skip the call to ScpHelper.findPrivateKey()?

I don't want to do that because the method name says getPrivateKey() and not doAgentFiddling().
Can you provide a ssh -vv log with and without agent running? I'd like to see what ssh(1) really does. Maybe we could simply mimic this behavior, i.e., always try the agent first with JSch and if it fails go over to keys, etc. WDYT?

[jira-importer]

Michael Osipov commented

I really would like to pick this up. I think we can apply the following reasoning:

• If ssh-external is used, provide creds (password or private key) if explicitly set in settings.xml otherwise ssh(1) will do its magic
• If ssh (JSch) is used, check if reads ~/.ssh/id_* by default, if so, we can apply the same logic as for ssh if not, don't look for the private key by yourself, use settings.xml OR configure with OpenSSHConfig, i.e., behave as JSch would behave by default, no magic traversal suprises.

WDYT?

[jira-importer]

Per Landberg commented

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?