This bundle provides an implementation of git transport over SSH implemented via Apache MINA sshd.
This bundle declares a service for the java.util.ServiceLoader
for interface org.eclipse.jgit.transport.ssh.SshSessionFactory
. The core JGit bundle uses the service loader to pick up an implementation of that interface.
Note that JGit simply uses the first SshSessionFactory
provided by the ServiceLoader
.
If the service loader cannot find the session factory, either ensure that the service declaration is on the Classpath of bundle org.eclipse.jgit
, or set the factory explicitly (see below).
In an OSGi environment, one might need a service loader bridge, or have a little OSGi fragment for bundle org.eclipse.jgit
that puts the right service declaration onto the Classpath of that bundle. (OSGi fragments become part of the Classpath of their host bundle.)
The simplest way to set an SSH implementation for JGit is to install it globally via SshSessionFactory.setInstance()
. This instance will be used by JGit for all SSH connections by default.
It is also possible to set the SSH implementation individually for any git command that needs a transport (TransportCommand
) via a org.eclipse.jgit.api.TransportConfigCallback
.
To do so, set the wanted SshSessionFactory
on the SSH transport, like:
SshSessionFactory customFactory = ...; // Get it from wherever FetchCommand fetch = git.fetch() .setTransportConfigCallback(transport -> { if (transport instanceof SshTransport) { ((SshTransport) transport).setSshSessionFactory(customFactory); } }) ... .call();
There exist two IETF draft RFCs for communication with an SSH agent:
JGit only supports the newer OpenSSH protocol.
Communication with an SSH agent can occur over any transport protocol, and different SSH agents may use different transports for local communication. JGit provides some transports via the org.eclipse.jgit.ssh.apache.agent fragment, which are discovered from org.eclipse.jgit.ssh.apache
also via the ServiceLoader
mechanism; the SPI (service provider interface) is org.eclipse.jgit.transport.sshd.agent.ConnectorFactory
.
If such a ConnectorFactory
implementation is found, JGit may use an SSH agent. If none is available, JGit cannot communicate with an SSH agent, and will not attempt to use one.
There are several SSH properties that can be used in the ~/.ssh/config
file to configure the use of an SSH agent. For the details, see the OpenBSD ssh-config documentation.
no
, yes
, or ask
. If set to yes
, keys will be added to the agent if they're not yet in the agent. If set to ask
, the user will be prompted before doing so, and can opt out of adding the key. JGit also supports the additional settings confirm
and key lifetimes.none
to explicitly switch off using an SSH agent at all.yes
and an SSH agent is used, only keys from the agent that are also listed in an IdentityFile
property will be considered. (It'll also switch off trying default key names, such as ~/.ssh/id_rsa
or ~/.ssh/id_ed25519
; only keys listed explicitly will be used.)As mentioned above JGit only implements the newer OpenSSH protocol. OpenSSH fully implements this, but some other SSH agents only offer partial implementations. In particular on Windows, neither Pageant nor Win32-OpenSSH implement the confirm
or lifetime constraints for AddKeysToAgent
. With such SSH agents, these settings should not be used in ~/.ssh/config
. GPG's gpg-agent can be run with option enable_putty_support
and can then be used as a Pageant replacement. gpg-agent appears to support these key constraints.
OpenSSH does not implement ed448 keys, and neither does Apache MINA sshd, and hence such keys are not supported in JGit if its built-in SSH implementation is used. ed448 or other unsupported keys provided by an SSH agent are ignored.
To use a different SSH implementation:
org.eclipse.jgit
,SshSessionFactory
for JGit explicitly (see above).JGit has built-in support for not using any Java SSH implementation but an external SSH executable. To use an external SSH executable, set environment variable GIT_SSH to the path of the executable. JGit will create a sub-process to run the executable and communicate with this sub-process to perform the git operation.