summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.ssh.apache.test/tst
Commit message (Collapse)AuthorAgeFilesLines
* sshd: add support for ssh-agentThomas Wolf2021-11-034-12/+29
| | | | | | | | | | | | | | | | | | | | | | | | | Add a simple SSH agent connector using JNA. Include com.sum.jna and com.sun.jna.platform in the target platform. JNA is used to communicate through Unix domain sockets with ssh-agent, and if on Windows, to communicate via shared memory with Pageant. The new bundle o.e.j.ssh.apache.agent is an OSGi fragment so that the java.util.ServiceLoader can find the provided factory without further ado in OSGi environments. Adapt both maven and bazel builds to include the new bundle. Manually tested on OS X, CentOS 7, and Win10 with Pageant 0.76. Tested by installing JGit built from this change into freshly downloaded Eclipse 2021-12 M1, and then doing git fetches via SSH with different ~/.ssh/config settings (explicit IdentityFile, without any but a key in the agent, with no keys and a key in the agent and IdentitiesOnly=yes (must fail)). Bug: 541274 Bug: 541275 Change-Id: I34e85467293707dbad1eb44d1f40fc2e70ba3622 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* [sshd] Implement SSH config KexAlgorithmsThomas Wolf2021-07-161-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the used KEX algorithms configurable via the ssh config. Also implement adding algorithms not in the default set: since sshd 2.6.0 deprecated SHA1-based algorithms, it is possible that the default set has not all available algorithms, so adding algorithms makes sense. This enables users who have to use a git server that only supports old SHA1-based key exchange methods to enable those methods in the ssh config: KexAlgorithms +diffie-hellman-group1-sha1 There are two more SHA1 algorithms that are not enabled by default: diffie-hellman-group14-sha1 and diffie-hellman-group-exchange-sha1. KeyAlgorithms accepts a comma-separated list of algorithm names. Since adding algorithms is now supported, adapt the handling of signature algorithms, too. Make sure that definitions for the KEX exchange signature (HostKeyAlgorithms) don't conflict with the definition for signatures for pubkey auth (PubkeyAcceptedAlgorithms). HostKeyAlgorithms updates the signature factories set on the session to include the default factories plus any that might have been added via the SSH config. Move the handling of PubkeyAcceptedAlgorithms from the client to the JGitPubkeyAuthentication, where it can be done only if pubkey auth is attempted at all and where it can store its adapted list of factories locally. Bug: 574636 Change-Id: Ia5d5f174bbc8e5b41e10ec2c25216d861174e7c3 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* sshd: try all configured signature algorithms for a keyThomas Wolf2021-03-191-0/+38
| | | | | | | | | | | | | | | | | | | | | | | For RSA keys, there may be several configured signature algorithms: rsa-sha2-512, rsa-sha2-256, and ssh-rsa. Upstream sshd has bug SSHD-1105 [1] and always and unconditionally uses only the first configured algorithm. With the default order, this means that it cannot connect to a server that knows only ssh-rsa, like for instance Apache MINA sshd servers older than 2.6.0. This affects for instance bitbucket.org or also AWS Code Commit. Re-introduce our own pubkey authenticator that fixes this. Note that a server may impose a penalty (back-off delay) for subsequent authentication attempts with signature algorithms unknown to the server. In such cases, users can re-order the signature algorithm list via the PubkeyAcceptedAlgorithms (formerly PubkeyAcceptedKeyTypes) ssh config. [1] https://issues.apache.org/jira/browse/SSHD-1105 Bug: 572056 Change-Id: I7fb9c759ab6532e5f3b6524e9084085ddb2f30d6 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* sshd: implement ssh config PubkeyAcceptedAlgorithmsThomas Wolf2021-03-191-25/+83
| | | | | | | | | | | | | | | | | | | | Apache MINA sshd 2.6.0 appears to use only the first appropriate public key signature algorithm for a particular key. See [1]. For RSA keys, that is rsa-sha2-512. This breaks authentication at servers that only know the older (and deprecated) ssh-rsa algorithm. With PubkeyAcceptedAlgorithms, users can re-order algorithms in the ssh config file per host, if needed. Setting PubkeyAcceptedAlgorithms ^ssh-rsa will put "ssh-rsa" at the front of the list of algorithms, and then authentication at such servers with RSA keys works again. [1] https://issues.apache.org/jira/browse/SSHD-1105 Bug: 572056 Change-Id: I86c3b93f05960c68936e80642965815926bb2532 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Migrate to Apache MINA sshd 2.6.0 and Orbit I20210203173513David Ostrovsky2021-02-041-4/+3
| | | | | | | | | | | | | | | | | | Re-enable DSA, DSA_CERT, and RSA_CERT public key authentication. DSA is discouraged for a long time already, but it might still be way too disruptive to completely drop it. RSA is discouraged for far less long, and dropping that would be really disruptive. Adapt to the changed property handling. Remove work-arounds for shortcomings of earlier sshd versions. Use Orbit I20210203173513, which includes sshd 2.6.0. This also bumps apache.httpclient to 4.5.13 and apache.httpcore to 4.4.14. Change-Id: I2d24a1ce4cc9f616a94bb5c4bdaedbf20dc6638e Signed-off-by: David Ostrovsky <david@ostrovsky.org> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Client-side protocol V2 support for fetchingThomas Wolf2021-01-011-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make all transports request protocol V2 when fetching. Depending on the transport, set the GIT_PROTOCOL environment variable (file and ssh), pass the Git-Protocol header (http), or set the hidden "\0version=2\0" (git anon). We'll fall back to V0 if the server doesn't reply with a version 2 answer. A user can control which protocol the client requests via the git config protocol.version; if not set, JGit requests protocol V2 for fetching. Pushing always uses protocol V0 still. In the API, there is only a new Transport.openFetch() version that takes a collection of RefSpecs plus additional patterns to construct the Ref prefixes for the "ls-refs" command in protocol V2. If none are given, the server will still advertise all refs, even in protocol V2. BasePackConnection.readAdvertisedRefs() handles falling back to protocol V0. It newly returns true if V0 was used and the advertised refs were read, and false if V2 is used and an explicit "ls-refs" is needed. (This can't be done transparently inside readAdvertisedRefs() because a "stateless RPC" transport like TransportHttp may need to open a new connection for writing.) BasePackFetchConnection implements the changes needed for the protocol V2 "fetch" command (stateless protocol, simplified ACK handling, delimiters, section headers). In TransportHttp, change readSmartHeaders() to also recognize the "version 2" packet line as a valid smart server indication. Adapt tests, and run all the HTTP tests not only with both HTTP connection factories (JDK and Apache HttpClient) but also with both protocol V0 and V2. The SSH tests are much slower and much more focused on the SSH protocol and SSH key handling. Factor out two very simple cloning and pulling tests and make those run with protocol V2. Bug: 553083 Change-Id: I357c7f5daa7efb2872f1c64ee6f6d54229031ae1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Revert "Client-side protocol V2 support for fetching"Thomas Wolf2020-11-031-24/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit f802f06e7fd5a98f256b7b7727598491f563bf2f. I had misunderstood how protocol V2 works. This implementation only works if the negotiation during fetch is done in one round. Fixing this is substantial work in BasePackFetchConnection. Basically I think I'd have to change back negotiate to the V0 version, and have a doFetch() that does if protocol V2 doFetchV2() else doFetchV0() with doFetchV0 the old code, and doFetchV2 completely new. Plus there would need to be a HTTP test case requiring several negotiation rounds. This is a couple of days work at least, and I don't know when I will have the time to revisit this. So although the rest of the code is fine I prefer to back this out completely and not leave a only half working implementation in the code for an indeterminate time. Bug: 553083 Change-Id: Icbbbb09882b3b83f9897deac4a06d5f8dc99d84e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Client-side protocol V2 support for fetchingThomas Wolf2020-10-291-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make all transports request protocol V2 when fetching. Depending on the transport, set the GIT_PROTOCOL environment variable (file and ssh), pass the Git-Protocol header (http), or set the hidden "\0version=2\0" (git anon). We'll fall back to V0 if the server doesn't reply with a version 2 answer. A user can control which protocol the client requests via the git config protocol.version; if not set, JGit requests protocol V2 for fetching. Pushing always uses protocol V0 still. In the API, there is only a new Transport.openFetch() version that takes a collection of RefSpecs plus additional patterns to construct the Ref prefixes for the "ls-refs" command in protocol V2. If none are given, the server will still advertise all refs, even in protocol V2. BasePackConnection.readAdvertisedRefs() handles falling back to protocol V0. It newly returns true if V0 was used and the advertised refs were read, and false if V2 is used and an explicit "ls-refs" is needed. (This can't be done transparently inside readAdvertisedRefs() because a "stateless RPC" transport like TransportHttp may need to open a new connection for writing.) BasePackFetchConnection implements the changes needed for the protocol V2 "fetch" command (simplified ACK handling, delimiters, section headers). In TransportHttp, change readSmartHeaders() to also recognize the "version 2" packet line as a valid smart server indication. Adapt tests, and run all the HTTP tests not only with both HTTP connection factories (JDK and Apache HttpClient) but also with both protocol V0 and V2. Do the same for the SSH transport tests. Bug: 553083 Change-Id: Ice9866aa78020f5ca8f397cde84dc224bf5d41b4 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* sshd: support the ProxyJump ssh configThomas Wolf2020-09-191-1/+397
| | | | | | | | | | | | | | This is useful to access git repositories behind a bastion server (jump host). Add a constant for the config; rewrite the whole connection initiation to parse the value and (recursively) set up the chain of hops. Add tests for a single hop and two different ways to configure a two-hop chain. The connection timeout applies to each hop in the chain individually. Change-Id: Idd25af95aa2ec5367404587e4e530b0663c03665 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* sshd: work around a race condition in Apache MINA sshd 2.4.0/2.5.xThomas Wolf2020-08-101-6/+12
| | | | | | | | | | | | | | | | | When exceptions occur very early in the SSH connection setup, it's possible that an exception gets lost. A subsequent authentication attempt may then never be notified of the failure, and then wait indefinitely or until its timeout expires. This is caused by race conditions in sshd. The issue has been reported upstream as SSHD-1050,[1] but will be fixed at the earliest in sshd 2.6.0. [1] https://issues.apache.org/jira/projects/SSHD/issues/SSHD-1050 Bug: 565394 Change-Id: If9b62839db38f9e59a5e1137c2257039ba82de98 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* sshd: use PropertyResolver in testThomas Wolf2020-07-281-2/+3
| | | | | | | | | | Improve the SshTestGitServer API for accessing the server properties. Instead of returning the raw property map, return the proper sshd API abstraction PropertyResolver. This makes the interface more resilient against upstream changes. Change-Id: Ie5b685bddc4e59f3eb6c121026d3658d57618ca4 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Rename a test methodThomas Wolf2020-07-041-1/+1
| | | | Change-Id: Ibb0bf0b1895a07a80a1f73d2fd6df2cb2d09fd77 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Add a test for upstream bug SSHD-1028Thomas Wolf2020-07-031-0/+29
| | | | | | | | | SSHD-1028:[1] server doesn't close server-side sessions properly when client disconnects. [1] https://issues.apache.org/jira/projects/SSHD/issues/SSHD-1028 Change-Id: I0d67f49e35abe8375cb1370a494dc01d0fb2c9b1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Decouple JSch from JGit CoreMatthias Sohn2020-06-013-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Motivation: JSch serves as 'default' implementations of the SSH transport. If a client application does not use it then there is no need to pull in this dependency. Move the classes depending on JSch to an OSGi fragment extending the org.eclipse.jgit bundle and keep them in the same package as before since moving them to another package would break API. Defer moving them to a separate package to the next major release. Add a new feature org.eclipse.jgit.ssh.jsch feature to enable installation. With that users can now decide which of the ssh client integrations (JCraft JSch or Apache Mina SSHD) they want to install. We will remove the JCraft JSch integration in a later step due to the reasons discussed in bug 520927. Bug: 553625 Change-Id: I5979c8a9dbbe878a2e8ac0fbfde7230059d74dc2 Also-by: Michael Dardis <git@md-5.net> Signed-off-by: Michael Dardis <git@md-5.net> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: David Ostrovsky <david@ostrovsky.org>
* In-memory SSH keys for the "no files" sshd testsThomas Wolf2020-05-232-43/+21
| | | | | | | Avoid using a key written to a file. This makes it clearer that the test does not rely on files being present. Change-Id: I31cf4f404aab5b891c32fc4bda906b7f8fe03777 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Builder API to configure SshdSessionFactoriesThomas Wolf2020-05-232-1/+163
| | | | | | | | | | | | | A builder API provides a more convenient way to define a customized SshdSessionFactory by hiding the subclassing. Also provide a new interface SshConfigStore to abstract away the specifics of reading a ssh config file, and provide a way to customize the concrete ssh config implementation to be used. This facilitates using an alternate ssh config implementation that may or may not be based on files. Change-Id: Ib9038e8ff2a4eb3a9ce7b3554d1450befec8e1e1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Update EDL 1.0 license headers to new short SPDX compliant formatMatthias Sohn2020-01-043-114/+15
| | | | | | | | | | This is the format given by the Eclipse legal doc generator [1]. [1] https://www.eclipse.org/projects/tools/documentation.php?id=technology.jgit Bug: 548298 Change-Id: I8d8cabc998ba1b083e3f0906a8d558d391ffb6c4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* sshd: support the HashKnownHosts configurationThomas Wolf2019-09-021-1/+52
| | | | | | | | | Add the constant, and implement hashing of known host names in OpenSshServerKeyDatabase. Add a test verifying that the hashing works. Bug: 548492 Change-Id: Iabe82b666da627bd7f4d82519a366d166aa9ddd4 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* sshd: configurable server key verificationThomas Wolf2019-09-021-0/+221
| | | | | | | | | | Provide a wrapper interface and change the implementation such that a client can substitute its own database of known hosts keys instead of the default file-based mechanism. Bug: 547619 Change-Id: Ifc25a4519fa5bcf7bb8541b9f3e2de15215e3d66 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* sshd: correct the protocol version exchangeThomas Wolf2019-07-151-4/+59
| | | | | | | | | | | | | | | | | | | RFC 4253 section 4.2 allows an ssh server to send additional lines before its server identification string. Apache MINA sshd enforces for these lines the constraints specified for the server identification line, too: no NUL characters and not longer than 255 characters. That is too strict. RFC 4253 doesn't mandate this, and it also doesn't make sense given the rationale for these lines in RFC 4253: a TCP wrapper may not be aware of SSH restrictions, and may not adhere to these constraints. Be more lenient when parsing the server's protocol version. Allow NULs and longer lines in the preamble, and also handle line endings more leniently. Only enforce the restrictions for the actual server identification line. Bug: 545939 Change-Id: I75955e9d8a8daef7c04fc0f39539c2ee93514e1c Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Apache MINA sshd client: enable support for ed25519 keysThomas Wolf2018-12-021-0/+21
| | | | | | | | | | | | | | | Include the net.i2p.crypto.eddsa bundle via a hard dependency. Add tests for dealing with ed25519 host keys and user key files. Manual tests: fetching from git.eclipse.org with an ed25519 user key, and pushing this change itself using the same ed25519 key. Note that sshd 2.0.0 does not yet support encrypted ed25519 private keys. Bug: 541272 Change-Id: I7072f4014d9eca755b4a2412e19c086235e5eae9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Apache MINA sshd client: proxy supportThomas Wolf2018-11-172-1/+148
| | | | | | | | | | | | | | | | | | | | | | This is not about the ssh config ProxyCommand but about programmatic support for HTTP and SOCKS5 proxies. Eclipse allows the user to specify such proxies, and JSch at least contains code to connect through proxies. So our Apache MINA sshd client also should be able to do this. Add interfaces and provide two implementations for HTTP and SOCKS5 proxies. Adapt the core code to be able to deal with proxy connections at all. The built-in client-side support for this in sshd 2.0.0 is woefully inadequate. Tested manually by running proxies and then fetching various real- world repositories via these proxies from different servers. Proxies tested: ssh -D (SOCKS, anonymous), tinyproxy (HTTP, anonymous), and 3proxy (SOCKS & HTTP, username-password authentication). The GSS-API authentication is untested since I have no Kerberos setup. Bug: 520927 Change-Id: I1a5c34687d439b3ef8373c5d58e24004f93e63ae Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Apache MINA sshd clientThomas Wolf2018-11-131-0/+83
Add a new ssh client implementation based on Apach MINA sshd 2.0.0. This implementation uses JGit's own config file parser and host entry resolver. Code inspection of the Apache MINA implementation revealed a few bugs or idiosyncrasies that immediately would re-introduce bugs already fixed in the past in JGit. Apache MINA sshd is not without quirks either, and I had to configure and override more than I had expected. But at least it was all doable in clean ways. Apache MINA boasts support for Bouncy Castle, so in theory this should open the way to using more ssh key algorithms, such as ed25519. The implementation is in a separate bundle and is still not used in the core org.eclipse.jgit bundle. The tests re-use the ssh tests from the core test bundle. Bug: 520927 Change-Id: Ib35e73c35799140fe050d1ff4fb18d0d3596580e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 10:14:27 +0000