slachiewicz commented on issue #503:
URL: https://github.com/apache/maven-wagon/issues/503#issuecomment-5225725046

   Root cause, from reading the current code. This is a bug in wagon's own 
authentication logic, not in JSch or in the agent connector.
   
   `AbstractJschWagon.openConnectionInternal()` only consults the agent when no 
key file was found:
   
   ```java
   // can only pick one method of authentication
   if (privateKey != null && privateKey.exists()) {                 // line 127
       sch.addIdentity(privateKey.getAbsolutePath(), 
authenticationInfo.getPassphrase());
   } else {
       Connector connector = ConnectorFactory.getDefault().createConnector();   
// line 136
       ...
   }
   ```
   
   And `ScpHelper.getPrivateKey()` will almost always find one, because when no 
password is configured it falls back to a default key file and then forces an 
empty passphrase:
   
   ```java
   if (authenticationInfo.getPassword() == null) {
       ...
       privateKey = findPrivateKey();
       if (privateKey != null && privateKey.exists()) {
           if (authenticationInfo.getPassphrase() == null) {
               authenticationInfo.setPassphrase("");
           }
       }
   }
   ```
   
   with `findPrivateKey()` probing `~/.ssh/id_dsa` first, then `~/.ssh/id_rsa`.
   
   So on any machine that has a default key file, that file wins and the agent 
is never asked. If the key is passphrase-protected, the forced empty passphrase 
then fails. That matches the reported symptom and explains why pointing 
`wagon.privateKeyDirectory` at an empty directory works around it — it is the 
only way to reach the `else` branch.
   
   Two things follow.
   
   **This is not fixed by changing the SSH library.** #680 proposes moving off 
the unmaintained `com.jcraft:jsch`, which is worth doing on its own merits, but 
the `if`/`else` above would survive the swap unchanged. I linked the two issues 
in a comment on #680 earlier and want to correct that here: they are 
independent.
   
   **The probe order is its own problem.** `id_dsa` is tried before `id_rsa`, 
and nothing looks for `id_ed25519` or `id_ecdsa`. ssh-dss has been disabled by 
default in OpenSSH for years, so the first thing wagon reaches for is the one 
key type that is least likely to work.
   
   A fix would be to establish an explicit order — key configured in 
`settings.xml`, then agent identities, then default key files — and to 
modernise the default-file list while doing so. That changes authentication 
behaviour, so it wants a minor release and a release note rather than a patch.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to