SSH-RSA key rejected with message "no mutual signature algorithm"
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms.
When attempting to use an SSH key generated using the ssh-rsa sha-1 hash algorithm, the SSH key isn't accepted (the user receives a 'Permission denied' message), and the following message is displayed when the verbose SSH output is reviewed:
debug1: send_pubkey_test: no mutual signature algorithm
- Bitbucket Data Center/Server
- Known operating systems impacted:
- Fedora 33+
- Any given system running OpenSSH 8.8 or newer as this release disables RSA signatures using the SHA-1 hash algorithm by default
When running the command
ssh -vvvv, the following output can be seen:
debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/user/.ssh/id_rsa RSA ... agent debug1: send_pubkey_test: no mutual signature algorithm <-- ssh-rsa is not enabled debug1: No more authentication methods to try. user@hostname: Permission denied (publickey).
To enable verbose SSH logging for git operations, it's also possible to set the
GIT_SSH_COMMAND environment variable, followed by the desired git command. Ex:
GIT_SSH_COMMAND="ssh -vvvv" git clone NAME_OF_REPOSITORY
The RSA SHA-1 hash algorithm is being quickly deprecated across operating systems and SSH clients because of various security vulnerabilities, with many of these technologies now outright denying the use of this algorithm.
- For example - here is the announcement from OpenSSH regarding their upcoming deprecation of the ssh-rsa algorithm.
In the event that you are using an operating system or SSH client whose version has this algorithm disabled, it's possible that any SSH keys previously generated using this algorithm will no longer be accepted by these technologies.
It is important to note that by default Bitbucket offers support for ECDSA and ED25519 algorithm. Keys generated with these algorithms are not affected by RSA deprecation.
Our team has the following recommendations for helping to resolve the problem being experienced, in both the form of a workaround and resolution:
Workaround for re-enabling RSA
(!) This workaround should only be taken if it is impossible to regenerate SSH keys with ECDSA and ED25519 algorithms. If you can generate new ECDSA and ED25519 based keys, please proceed to the Resolution using ECDSA and ED25519 algorithms right below.
In order to re-enable ssh-rsa support, inserting the following line into the affected SSH client's config file can re-enable this algorithm:
As detailed in BSERV-13013 ticket linked below, the our dev team implemented RFC 8332 so that the use of RSA-based keys can continue with SHA-256 and SHA-512 instead of SHA-1. Please review the Workarounds section from the following report before proceeding.
Resolution using ECDSA and ED25519 algorithms
To fully resolve this issue, our team recommends that these deprecated keys be re-generated using a supported and more secure algorithm such as ECDSA and ED25519:
debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/user/.ssh/id_rsa RSA ... agent debug1: send_pubkey_test: no mutual signature algorithm <-- ssh-rsa is not enabled debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 ... agent debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 ... agent <- The Ed25519 key is accepted without issue
To generate a key using this updated algorithm, it's recommended that you consult the documentation for the usual software that your team uses for SSH key generation.
ssh-keygen command in particular, the full list of algorithms for this command can be found on SSH.com: choosing an algorithm. In addition, here is an example command that creates a new SSH key using the ED25519 algorithm:
ssh-keygen -t ed25519 -C "email@example.com"