Similar to git config file reading lock the file only when writing.
There may still be lock conflicts on writing, but those in the worst
case result in an entry not being added and thus being asked for later
again.

Because the OpenSshServerkeyDatabase and its HostKeyFiles may be (and
usually are) shared between different SSH sessions, we still need to
ensure in-process mutual exclusion.

Bug: 559548
Change-Id: I4af97628deff9eaac2520576917c856949f2680d
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Apache MINA sshd has an implementation of this, but it doesn't comply
to RFC 8308 [1] and it is buggy. (See SSHD-1141 [2].)

Add a simpler KexExtensionHandler and if the server sends extension
server-sig-algs, use its value to re-order the chosen signature
algorithms such that the algorithms the server announced as supported
are at the front.

If the server didn't tell us anything, don't do anything. RFC 8308
suggests for RSA to default to ssh-rsa, but says once rsa-sha2-* was
"widely enough" adopted, defaulting to that might be OK.

Currently we seem to be in a transition phase; Fedora 33 has already
disabled ssh-rsa by default, and openssh is about to do so. Whatever
we might do without info from the server, it'd be good for some servers
and bad for others. So don't do anything and let the user re-order via
ssh config PubkeyAcceptedAlgorithms on a case-by-case basis.

[1] https://tools.ietf.org/html/rfc8308
[2] https://issues.apache.org/jira/browse/SSHD-1141

Bug: 572056
Change-Id: I59aa691a030ffe0fae54289df00ca5c6e165817b
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

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>

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>

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>

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>

Don't use the ~/.ssh directory as cache key for the key provider
but the configured paths of the default keys. Otherwise changes
in that list of paths are not picked up.

This is in particular a problem for EGit, where the user can modify
this list of keys interactively in the preferences. Without this
change, Eclipse needs to be restarted to pick up such changes.

Bug: 542845
Change-Id: I63432fb10729a90b3c5e14f13e39bf482aef811b
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Add tests for password and keyboard-interactive authentication.
Implement password authentication; the default provided by sshd
is non-interactive, which is not useful for JGit.

Make sure the CredentialsProvider gets reset on successive password
retrieval attempts. Otherwise it might always return the same non-
accepted password from a secure storage. (That one was discovered
by actually trying this via EGit; the JGit tests don't catch this.)

Change the default order of authentication mechanisms to prefer
password over keyboard-interactive. This is a mitigation for upstream
bug SSHD-866.[1]

Also include a fix for upstream bug SSHD-867.[2]

[1] https://issues.apache.org/jira/projects/SSHD/issues/SSHD-866
[2] https://issues.apache.org/jira/projects/SSHD/issues/SSHD-867

Bug: 520927
Change-Id: I423e548f06d3b51531016cf08938c8bd7acaa2a9
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

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>

sshd only asks exactly once for the password. C.f. upstream issue
SSHD-850.[1] So we have to work around this limitation for now.
Once we move to sshd > 2.1.0, this can be simplified somewhat.

[1] https://issues.apache.org/jira/browse/SSHD-850

Bug: 520927
Change-Id: Id65650228486c5ed30affa9c62eac982e01ae207
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

By default sshd will use its default built-in list, which matches
the one of openssh (as far as the algorithms exist in sshd at all).
But it doesn't handle HostKeyAlgorithms from the ssh config at all.

Implement this as in openssh, including the '+' and '-' modifiers
and reordering the default if there are known host keys for a
server already.

Add tests for the reordering.

Also use a more robust reader for the known hosts file. The default
aborts on the first error.

Bug: 520927
Change-Id: Ib1684440bfe2e96140536aa1a93c4bd4a0d35916
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Set the internal property on the session as defined in the ssh config.

Note that NumberOfPasswordPrompts in openssh applies independently to
both user logins in keyboard-interactive authentication _and_ to
passphrases for identity files (encrypted keys). Apache MINA sshd uses
the setting only for keyboard-interactive authentication, but not for
identity file passphrase prompts. For identity files, it asks exactly
once. This has been reported as issue SSHD-850 upstream.[1]

[1] https://issues.apache.org/jira/browse/SSHD-850

Bug: 520927
Change-Id: I390ffe9e1c52b96d3e8e28fd8edbdc73dde9edb4
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

sshd does support gssapi-with-mic on the server side, but has no
built-in client-side support for this authentication mechanism.

Add our own implementation for it, following RFC 4462.[1] To avoid
needlessly re-trying mechanisms that aren't even configured on the
client, we disable mechanisms that fail on the very first attempt
to use them.

Since we have no real Kerberos5 test setup, this cannot be fully
tested in CI. The disabling of the authentication mechanism and
that it is skipped when not successful _is_ tested.

[1] https://www.ietf.org/rfc/rfc4462.txt

Bug: 520927
Change-Id: I5d0cdb14103588a57c52f927df541b589ab88d88
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

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>