Skip to content

Gitblit SSH fails with modern OpenSSH RSA-SHA2 public key authentication #1488

Description

@dkhokhlov

Summary

Gitblit's SSH transport does not interoperate correctly with modern OpenSSH clients when authenticating with RSA public keys using RSA-SHA2 signatures.

In practice, Git over SSH can fail even when the RSA key itself is valid and accepted by current OpenSSH clients and servers.

Observed behavior

With a current OpenSSH client, SSH/Git authentication against Gitblit's SSH endpoint fails during public key authentication with an RSA key.

A representative client-side failure is:

send_pubkey_test: no mutual signature algorithm

In the upgraded test/debug path, the underlying issue is broader than just negotiation: the legacy SSH stack and some command/test-path assumptions do not match modern SSH client/server behavior.

## Expected behavior

Gitblit SSH should accept modern RSA public key authentication using:

- rsa-sha2-256
- rsa-sha2-512

without requiring clients to re-enable legacy ssh-rsa.

## Why this matters

Modern OpenSSH disables legacy ssh-rsa by default because it uses SHA-1. RSA keys themselves are still valid, but they are expected to authenticate with RSA-SHA2 signatures.

That means Gitblit's current SSH behavior breaks a normal modern client setup and forces either:

- insecure per-host compatibility overrides, or
- switching users away from existing RSA keys just to work around the server

## Likely cause

Gitblit is still using an old Apache MINA SSHD version in its SSH transport. The SSH stack appears too old for reliable interoperability with modern OpenSSH RSA-SHA2 authentication behavior.

## Reproduction

1. Configure Gitblit SSH on a non-zero SSH port.
2. Add a valid RSA public key to a Gitblit user.
3. Connect with a current OpenSSH client using that RSA key.
4. Attempt SSH auth or a Git operation over SSH.

Example symptoms:

- SSH auth fails
- Git over SSH fails
- the client reports RSA signature negotiation or authentication failure

## Additional notes

While investigating this, I also found that once the SSH stack is updated, a few SSH-related tests and command-path issues are exposed:

- embedded SSH test harness restart/state handling
- command alias resolution in the SSH dispatcher path

PR #1487 addresses the transport upgrade and the directly related fixes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions