slachiewicz opened a new pull request, #902:
URL: https://github.com/apache/maven-wagon/pull/902
Two commits, separable: the first swaps the SSH library, the second fixes an
authentication bug that is independent of it.
Fixes #901. Fixes #503. Carries forward #680.
### 1. Move to the maintained JSch fork
`com.jcraft:jsch:0.1.55` was last released in 2018. The provider is not
merely unmaintained, it is already broken against current keys — here is 0.1.55
against two keys `ssh-keygen` produced with defaults on this machine:
```
jsch-0.1.55 enc_key -> JSchException: invalid privatekey
plain_key -> JSchException: invalid privatekey
com.github.mwiede enc_key -> OK
plain_key -> OK
```
It cannot read the OpenSSH-v1 format `ssh-keygen` has emitted by default
since OpenSSH 7.8, encrypted or not, and it has no `rsa-sha2-*`, so RSA
authentication fails against OpenSSH 8.8 and later anyway.
`com.github.mwiede:jsch:2.28.6` keeps the `com.jcraft.jsch` package, so the
API is unchanged. Its base bytecode is Java 8.
Two things needed care rather than a straight coordinate swap:
**The agent.** The `jsch.agentproxy` artifacts have no counterpart, and
their `ConnectorFactory` used to pick between agent kinds. The choice is now
explicit and still covers all three the old stack could reach —
`SSH_AUTH_SOCK`, Win32 OpenSSH, Pageant. One capability does narrow: reaching
the `SSH_AUTH_SOCK` agent needs a Unix domain socket, which the JDK provides
only from Java 16, and the fork declares no dependencies, so on Java 8–15 that
particular agent is out of reach without a helper library on the class path.
The other two need nothing. An agent holding no identities is now skipped
rather than installed as an empty repository.
**Passphrases.** `getPrivateKey()` substitutes an empty passphrase when the
settings name none. The old JSch discarded the result of `setPassphrase`, so an
encrypted key stayed encrypted and was unlocked later; the fork rejects it
instead. Left alone, that would have failed *every* encrypted key. Empty is now
translated back to none before the key is added:
```
enc_key, settings gave no passphrase -> accepted
plain_key, settings gave no passphrase -> accepted
enc_key, correct passphrase -> accepted
enc_key, wrong passphrase -> rejected
```
### 2. Stop a stray key file shadowing the agent (#503)
The agent was consulted only when no key file was found, and
`getPrivateKey()` finds one whenever no password is configured. On any machine
with a key in `~/.ssh` the agent was therefore unreachable — which is why the
reported workaround was to point `wagon.privateKeyDirectory` at an empty
directory.
The order is now: a key named in `settings.xml`, then the agent, then a key
file that merely happens to be in `~/.ssh`. Naming a key keeps today's
behaviour.
**This is a behaviour change to note in the release notes.** A reachable
agent holding identities now outranks a discovered key file, so someone whose
agent holds unrelated keys while the needed key sits unloaded in `~/.ssh` must
load it or name it. Combining both is not available to us: adding a file
identity on top of an agent repository makes JSch push that key *into* the
user's agent.
Also in this commit, key discovery looks for `id_ed25519`, `id_ecdsa`,
`id_rsa` instead of `id_dsa` then `id_rsa`. That code is in `ScpHelper`, so it
also changes which key `wagon-ssh-external` passes to `ssh -i`.
### Verification, and its limits
Modules build, `spotless:check` clean, default test run green.
**The change is not verified by the project's own SSH tests, because those
do not run.** The `-Dssh-tests` profile is excluded by default, and on the
unmodified branch point it gives 112 tests / 94 errors —
`ComponentLookupException: Unable to lookup component
'org.apache.maven.wagon.Wagon', roleHint: scp`, i.e. plexus test wiring rather
than anything SSH. My branch gives exactly the same 112 / 94, so this change
neither helps nor hurts it, but it means the embedded-MINA-server suite that
would genuinely exercise a library swap is unavailable. That harness deserves
fixing before this is relied on, and it is worth doing regardless of this PR.
What was verified directly is the key-handling matrix above, run against
both libraries.
Not yet done, and worth someone's hands before release: a real `site-deploy`
over scp and sftp against a current OpenSSH, on both Java 11 and Java 17, and
one Windows check of the agent path.
--
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]
