How to fix sign_and_send_pubkey: no mutual signature supported in SSH

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 491 views

SSH public-key auth fails because client and server cannot agree on a signature algorithm, usually after OpenSSH 8.8+ disabled the SHA-1-based ssh-rsa algorithm for RSA keys.

Quick fix

Fixes sign_and_send_pubkey: no mutual signature supported

ssh-keygen -t ed25519 -C "your-email@example.com"
  1. Generate a new SSH key using Ed25519 (recommended long-term fix)
  2. Verify your current key type and algorithm
  3. Temporarily re-enable ssh-rsa on the client to connect (workaround, not a permanent fix)
  4. Update the remote server's SSH configuration (preferred server-side fix)
ssh — error
ssh-keygen -t ed25519 -C "your-email@example.com"
sign_and_send_pubkey: no mutual signature supported

What this error means

When you authenticate using public key cryptography, the SSH client and server must agree on which signature algorithm to use for proving ownership of the key. OpenSSH 8.8 and newer deprecated the "ssh-rsa" signature algorithm (which relies on the weak SHA-1 hash) for security reasons. This error appears when: the client offers only ssh-rsa (deprecated), the server accepts only ssh-rsa but the client has disabled it, or neither party advertises a common algorithm for the offered key. The two sides cannot find mutual ground, so the key is rejected during signature negotiation. Note this is specifically a signature-algorithm mismatch for an RSA key — it is not a host-key or key-exchange negotiation failure, which produce different messages.

Typical symptoms

  • SSH connection fails with 'sign_and_send_pubkey: no mutual signature supported' when using public key authentication
  • Password-based authentication still works (falls back to a 'Password:' prompt), but key-based auth fails
  • The negotiation failure is most visible in verbose mode: ssh -v or -vv shows the RSA key being skipped
  • Connecting to older servers (RHEL 6, CentOS 6, or other legacy systems) from newer clients fails
  • Connecting from older clients to newer servers fails when the old client only supports ssh-rsa
  • Authentication works when connecting from one system but fails from another with the same key

Common causes

  1. Client running OpenSSH 8.8+ which disabled the ssh-rsa (SHA-1) signature algorithm by default, while the server only accepts ssh-rsa
  2. Server running OpenSSH 8.8+ which disabled ssh-rsa, while the client offers only ssh-rsa (e.g. an old or unusual RSA key)
  3. Legacy SSH server or custom SSH implementation that supports only ssh-rsa with SHA-1 and not the newer rsa-sha2-256 / rsa-sha2-512 algorithms
  4. Server has disabled ssh-rsa in sshd_config (PubkeyAcceptedAlgorithms) via security hardening, leaving no common RSA signature algorithm
  5. One side does not support the modern rsa-sha2-256 / rsa-sha2-512 RSA signature algorithms, so an RSA key cannot be used at all

How to fix "sign_and_send_pubkey: no mutual signature supported"

1Generate a new SSH key using Ed25519 (recommended long-term fix)

The most future-proof solution is to use an Ed25519 key, which is modern, secure, and widely supported on current systems:

bash
ssh-keygen -t ed25519 -C "your-email@example.com"

When prompted for the file location, press Enter to use the default (~/.ssh/id_ed25519).
When prompted for a passphrase, either press Enter for none or set one (recommended).

Then add your public key to the remote server:

bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Test the connection:

bash
ssh -i ~/.ssh/id_ed25519 user@remote-host

Ed25519 keys sidestep the RSA signature-algorithm negotiation entirely, since they use their own dedicated ssh-ed25519 algorithm.

2Verify your current key type and algorithm

First, understand what key type you're offering:

bash
ssh-keygen -l -f ~/.ssh/id_rsa

Example output:

bash
2048 SHA256:abc123... user@host (RSA)

If it says (RSA), you're using the key type affected by this error. If it says (ED25519) or (ECDSA), you have a modern key and the problem likely lies in the server or client algorithm configuration rather than the key itself.

Also check what keys you have:

bash
ls -la ~/.ssh/

If you see id_rsa or id_dsa, consider migrating to Ed25519.

3Temporarily re-enable ssh-rsa on the client to connect (workaround, not a permanent fix)

If you cannot immediately upgrade keys or the server, you can re-enable the legacy ssh-rsa signature algorithm for a specific host. This is a stopgap: ssh-rsa relies on SHA-1, so scope it narrowly and remove it once the server is fixed.

Edit or create ~/.ssh/config:

bash
nano ~/.ssh/config

Add a block for the specific host only:

bash
Host legacy-server
    HostName 192.168.1.100
    User ubuntu
    IdentityFile ~/.ssh/id_rsa
    PubkeyAcceptedAlgorithms +ssh-rsa
    HostKeyAlgorithms +ssh-rsa

Then connect using the alias:

bash
ssh legacy-server

Or enable it for a single command:

bash
ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa user@host

The leading + *adds* ssh-rsa to the existing list rather than replacing it, so your other algorithms stay enabled. Prefer fixing the server (next step) over leaving this in place.

4Update the remote server's SSH configuration (preferred server-side fix)

If you control the remote server, the best fix is to enable the SHA-2 RSA signature algorithms (rsa-sha2-256 / rsa-sha2-512) rather than falling back to weak ssh-rsa. Your existing RSA keys keep working — only the signature hash changes.

SSH into the server (using password auth if needed) and edit the daemon config:

bash
sudo nano /etc/ssh/sshd_config

Ensure modern algorithms are accepted (leave ssh-rsa out unless a legacy client truly requires it):

bash
PubkeyAcceptedAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp256
HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp256

Save and exit (Ctrl+X, then Y, then Enter in nano).

Validate the config before applying it so a typo doesn't lock you out:

bash
sudo sshd -t

If it reports no errors, restart the daemon:

bash
sudo systemctl restart sshd

Or on older systems:

bash
sudo service sshd restart

Keep your existing session open and test a new connection in a separate terminal before closing it.

5Upgrade OpenSSH on the client (if running an old version)

If your SSH client is too old to support the SHA-2 RSA algorithms, upgrade it.

Check your version:

bash
ssh -V

rsa-sha2 support landed in OpenSSH 7.2; anything older should be upgraded. Instructions vary by OS:

macOS (Homebrew):

bash
brew install openssh

Ubuntu/Debian:

bash
sudo apt update && sudo apt upgrade openssh-client

CentOS/RHEL:

bash
sudo yum update openssh

Windows: Use the bundled OpenSSH (Settings > Optional Features), Windows Subsystem for Linux (WSL), or install from https://github.com/PowerShell/Win32-OpenSSH

6Use an ECDSA key if the server is too old for Ed25519

On a very old server that lacks Ed25519 support but still rejects ssh-rsa, an ECDSA key is a reasonable middle ground — more compatible than Ed25519 on legacy systems and not subject to the ssh-rsa SHA-1 deprecation:

bash
ssh-keygen -t ecdsa -b 521 -C "your-email@example.com"

The -b 521 selects the NIST P-521 curve. Copy the public key to the server:

bash
ssh-copy-id -i ~/.ssh/id_ecdsa.pub user@remote-host

Use this only when Ed25519 isn't an option; Ed25519 remains the preferred choice on modern systems.

Advanced notes

Why was ssh-rsa disabled? OpenSSH 8.8 (August 2021) disabled the ssh-rsa signature algorithm by default because it uses SHA-1, which is cryptographically broken. Practical SHA-1 collision attacks make such signatures untrustworthy, so modern OpenSSH chooses security over legacy compatibility.

ssh-rsa vs rsa-sha2: The confusing part is that "ssh-rsa" names a *signature algorithm*, not the key. The same RSA key can be used with the stronger rsa-sha2-256 and rsa-sha2-512 signature algorithms. That is why simply allowing rsa-sha2 on the server fixes the problem without regenerating keys — you keep the existing RSA key but sign with a safe hash.

Verify negotiation with -vvv: Run ssh -vvv user@host and look for lines such as "send_pubkey_test" and the offered/accepted signature algorithms. This confirms whether the failure is a signature-algorithm mismatch (this error) rather than a host-key or key-exchange mismatch, which produce different messages like "no matching host key type found" or "no matching key exchange method".

Key rotation: When migrating, keep the old key in authorized_keys temporarily until every system accepts the new key, then remove it.

Containers and CI/CD: In Docker, Kubernetes, Ansible, or Terraform, this usually stems from a base image with an old or hardened OpenSSH. Update the base image or install a newer openssh package, and prefer Ed25519 keys for CI identities.

Security timeline: If you re-enable ssh-rsa as a stopgap, scope it per-host and set a firm deadline (e.g. 30 days) to migrate to Ed25519/ECDSA or enable rsa-sha2 on the server, then remove the ssh-rsa override so you don't silently depend on weak cryptography.

Frequently asked questions

What does "sign_and_send_pubkey: no mutual signature supported" mean?
When you authenticate using public key cryptography, the SSH client and server must agree on which signature algorithm to use for proving ownership of the key. 8 and newer deprecated the "ssh-rsa" signature algorithm (which relies on the weak SHA-1 hash) for security reasons. This error appears when: the client offers only ssh-rsa (deprecated), the server accepts only ssh-rsa but the client has disabled it, or neither party advertises a common algorithm for the offered key.
How do I fix "sign_and_send_pubkey: no mutual signature supported"?
SSH public-key auth fails because client and server cannot agree on a signature algorithm, usually after OpenSSH 8.8+ disabled the SHA-1-based ssh-rsa algorithm for RSA keys.
What causes "sign_and_send_pubkey: no mutual signature supported"?
Client running OpenSSH 8.8+ which disabled the ssh-rsa (SHA-1) signature algorithm by default, while the server only accepts ssh-rsa Server running OpenSSH 8.8+ which disabled ssh-rsa, while the client offers only ssh-rsa (e.g. an old or unusual RSA key) Legacy SSH server or custom SSH implementation that supports only ssh-rsa with SHA-1 and not the newer rsa-sha2-256 / rsa-sha2-512 algorithms
Is the "sign_and_send_pubkey: no mutual signature supported" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading