Apache MINA SSHD: a Java SSH library with swappable transports and optional subsystems

A library for Java applications, not a drop-in sshd

The scope statement in the project documentation is short and deliberate: Apache MINA SSHD is a 100% pure Java library supporting the SSH protocols on both the client and the server side, and it does not aim at being a replacement for the SSH client or SSH server from Unix operating systems. That sentence is the most useful thing in the README, because the name invites the opposite assumption.

What it is for is a Java application that has to speak SSH as part of its own job. A deployment tool that pushes files to a host over SFTP, a service that accepts incoming SSH connections from automation, a test suite that needs to exercise SSH semantics, a Git server that needs SSH session handling. In each of those cases the interesting part is that the SSH logic runs inside your JVM, in the same process, under your own configuration, with your own objects and event listeners, rather than in a separate daemon you shell out to.

The runtime floor is Java 8 or newer, stated as applying since version 2.3, and Java 17 or newer at build time since version 2.14. The only hard dependency is the core abstract `slf4j-api` module; which logging implementation you use is left to the many existing adaptors. That is a small surface for a library of this size, and it means embedding the client or server does not drag in a logging stack of its own.

The transport is a swappable plug-in, not a hard-wired choice

The mechanism that shapes the whole design is the transport layer. The library can run on several I/O back-ends. The default transport is built in and uses Java's `AsynchronousSocketChannel` classes, the NIO2 model. Alternatively, Apache MINA, described as a scalable and high performance asynchronous I/O library, can be used, and the Netty asynchronous event-driven network framework is also supported.

In the artifact structure that maps to `sshd-core`, which contains the basic SSH client and server code implementing connection, transport, channels and forwarding, plus two sibling artifacts, `sshd-mina` and `sshd-netty`, described as replacements for the default NIO2 connector. The transport is a connector you substitute, not an abstraction you have to fight.

This matters more than it first appears, because SSH concurrency is the hard part of an SSH server. A server that opens a session per connection, each with channels and port forwards, can end up with a lot of concurrent asynchronous work, and choosing between the JDK's own async sockets, MINA and Netty is a decision about how that work is scheduled. The project also documents deeper internals separately, with pages on key exchange, TCP/IP port forwarding, global requests, and an Android support page, which is the level of detail you need when you are embedding rather than just calling.

Capabilities are separate artifacts, so the dependency graph stays small

The library is split into many Maven artifacts, and the split follows capability. `sshd-common` holds the basic classes used throughout the project plus code that does not require client or server network support. `sshd-core` is the SSH client and server itself. `sshd-sftp` contains the server side SFTP subsystem and the SFTP client code, and `sshd-scp` contains the server side SCP command handler and the SCP client code. `sshd-spring-sftp` is a Spring Integration compatible SFTP adapter.

The peripheral artifacts are more interesting. `sshd-ldap` provides server-side password and public key authenticators that use an LDAP server, which is the piece most deployments are missing when they write their own SSH server. `sshd-git` provides replacements for the JGit SSH session factory. `sshd-putty` parses PuTTY key files and `sshd-openpgp` parses OpenPGP key files, the latter with limitations the documentation points out. `sshd-osgi` combines `sshd-common` and `sshd-core` into one artifact so it can be deployed in OSGi environments.

Two artifacts come with explicit warnings. `sshd-contrib` is experimental code currently under review that may end up in another artifact or become a new one, with `sshd-putty` given as the precedent. `sshd-benchmarks` holds JMH benchmarks for SSH operations that are meant to be run locally by developers; the artifact is not part of the binary distribution and is not deployed to any Maven repository. For a production dependency set, that means the artifacts you can actually resolve are the released ones, and `sshd-contrib` is a moving target.

Building the source tree with Maven

The quick reference gives two build commands, and the difference between them is worth understanding before you run one in CI. The first builds everything including tests:

mvn clean install

The second skips the tests via the `quick` profile:

mvn -Pquick clean install

The repository ships the Maven wrapper, with `mvnw` and `mvnw.cmd` at the top level alongside `pom.xml` and a `.mvn/` directory, so you can build without a system-wide Maven installation. The top level also carries the usual Apache tooling: `assembly/` for the distribution archives, `sshd-sources/`, the `NOTICE.txt` and `NOTICE-bin.txt` files, `LICENSE.txt`, and a set of static analysis configurations such as `sshd-checkstyle.xml`, `sshd-pmd-ruleset.xml`, and `sshd-findbugs.xml`.

Release artifacts go out in two shapes. `tar.gz` and ZIP source and binary distributions are published on the project download site, and the released Maven artifacts are available on Maven Central under the `org.apache.sshd` group. Snapshot releases are published to the Apache Snapshot repository on each push or merge to the main branch, but only if the tests pass successfully, which is a useful signal about what a snapshot means.

The 2.x line and the 3.0 milestone are released side by side

Two release lines are in flight, and that has direct consequences for an upgrade. On 2026-09-28 the project published sshd-2.20.0, and on the same day it published sshd-3.0.0-M6. Before that, sshd-2.19.0 arrived on 2026-07-09. The last push to the repository was on 2026-10-13.

A milestone release with an M suffix is a pre-release of the next major version, so 3.0.0-M6 is not a drop-in target for a production service that depends on 2.20.0. Practically, that means an application choosing Apache MINA SSHD has to pick a line deliberately and expect to make that choice again later. A 2.x to 3.0 move is a major version change, which in Java terms means a compatibility review of the API surface your code touches, not just a version bump.

Release notes live in `CHANGES.md` at the repository root, which is where the differences between 2.19.0, 2.20.0 and the 3.0 milestones are recorded. The default branch is `master`, while the release notes and snapshot description refer to the main branch, a naming detail that can confuse anyone scripting against the repository.

Two documentation links in the README are the fastest way to a working setup: a page for setting up an SSH client in five minutes and a page for embedding an SSHD server instance in five minutes, both under `docs/`.

Why the system ssh binary is a different approach, not a worse one

The realistic alternative to embedding this library is to shell out to the `ssh` and `scp` commands that ship with the operating system, which is what most tooling did before SSH libraries existed. The difference in approach is where the protocol lives. The system binaries are separate processes that implement the full SSH stack, hardened and audited for general use, and you interact with them through a command line and exit codes. Apache MINA SSHD puts the protocol inside your JVM, so you can construct a session, open a channel, forward a port, register a command factory, and react to events through your own listener objects.

That buys you fine-grained integration: no process spawning per operation, no temporary key files on disk, no parsing of human-readable error text, and the ability to answer a channel request inside the same application that owns the business logic. The cost is that you own the hardening. Key generation and storage, algorithm selection, host key verification, and the decision about which authentication methods to permit are all your responsibility once the library is embedded. A system sshd has a decades-old configuration surface and a familiar security model; this library gives you building blocks and a reference documentation set.

The library also refuses to replace the daemon in a second way. The project explicitly frames itself as support for Java based applications requiring SSH support. If your requirement is a hardened multi-tenant login server, this is the wrong shape of tool.

Apache-2.0 governance, two issue trackers, and a private channel for vulnerabilities

The licence is Apache-2.0, with `LICENSE.txt` at the repository root and the accompanying `NOTICE.txt` and `NOTICE-bin.txt` files that the Apache release process requires. The project is an Apache Software Foundation project, with `.asf.yaml` and `assembly/` at the repository root, so the licence obligations are the familiar ones and the code can be embedded in a commercial product under the standard grant.

Bug reports and feature requests can be filed at either the GitHub issue tracker or the Apache JIRA issue tracker under the SSHD project. That dual arrangement is common for ASF projects and creates a known annoyance: a report filed in one place may not be visible in the other, so searching both is worthwhile before filing a duplicate. Security vulnerabilities are a separate matter. The documentation states that sensitive issues such as security vulnerabilities must be reported through private channels as described in `SECURITY.md`, not via either issue tracker. A `security.txt` file also sits at the repository root.

The maintainer base is broader than a single person, which for a protocol implementation is the point. The project also documents the standards it supports in `docs/standards.md`, and the how-to pages collect recipes that do not fit the main documentation set, including extension modules, configuration and data files parsing support, and event listeners and handlers.

Editorial conclusion

Apache MINA SSHD fits a Java application that needs to speak SSH as a client or a server inside its own process: a deployment tool, a backup agent, an SFTP service, a Git hosting backend, or a test harness for SSH behaviour. It does not fit an operator who wants a hardened general purpose SSH daemon on a host, because the project states outright that it is not a replacement for the Unix ssh client and server, and it does not fit a project that must run on a JRE older than Java 8. Before you adopt it, pick the 2.x or 3.x line deliberately, since 2.20.0 and 3.0.0-M6 were published on the same day, and add only the artifacts such as sshd-sftp or sshd-ldap that you actually need.

Frequently asked questions

Official sources

1. apache/mina-sshd on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases