WardtermCliente SSH
ES
Descargar

"sign_and_send_pubkey: no mutual signature supported": cómo solucionarlo

Tu cliente SSH y el servidor no comparten ningún algoritmo de firma para esta clave. Casi siempre significa una clave RSA y un servidor antiguo que solo conoce las firmas SHA-1 (ssh-rsa), que los clientes OpenSSH rechazan por defecto desde la 8.8. La clave en sí está bien. Usa una clave Ed25519 en ese servidor si la admite, actualiza el servidor, o permite ssh-rsa solo para ese host con PubkeyAcceptedAlgorithms +ssh-rsa.

Actualizada el . Reproducido con OpenSSH 10.3 en macOS y OpenSSH 10.0 en Debian 13 como clientes contra un servidor OpenSSH 6.6 real en Ubuntu 14.04, con una clave desechable.

Qué ves

sign_and_send_pubkey: no mutual signature supported
user@server: Permission denied (publickey,password).

A menudo lo único visible es la segunda línea. En nuestras pruebas la primera línea apareció con un archivo de clave RSA en formato antiguo sin un archivo .pub al lado. Con un archivo .pub, el mismo fallo era silencioso, y solo ssh -v mostraba el motivo:

debug1: send_pubkey_test: no mutual signature algorithm

Crear el archivo .pub quita la primera línea pero no arregla el inicio de sesión.

Por qué ocurre

El nombre ssh-rsa se refiere a dos cosas: un tipo de clave y una firma con SHA-1. Una clave RSA también puede firmar con SHA-256 o SHA-512, conocidas como rsa-sha2-256 y rsa-sha2-512. OpenSSH las admite desde la 7.2. OpenSSH 8.8 dejó de ofrecer por defecto la firma SHA-1, porque SHA-1 está roto.

Así, un servidor anterior a la 7.2, o un equipo con una biblioteca SSH antigua, solo puede aceptar la firma que tu cliente ya no hace. Un servidor moderno no se ve afectado, y no necesitas sustituir una clave RSA por esto: la misma clave inició sesión sin problema en un servidor moderno en nuestras pruebas.

Confírmalo

ssh -v user@server true 2>&1 | grep -E 'remote software version|mutual|server-sig-algs'

Una coincidencia se ve así. Una versión antigua de servidor y ninguna línea server-sig-algs:

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13
debug1: send_pubkey_test: no mutual signature algorithm

Para confirmarlo, pruébalo en una sola conexión:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa user@server

Si inicia sesión, esa es la causa. Los clientes anteriores a OpenSSH 8.5 llaman a esta opción PubkeyAcceptedKeyTypes.

Solución 1: usa una clave Ed25519

Es la mejor solución si el servidor la admite, es decir, OpenSSH 6.5 o posterior. Funcionó contra el servidor 6.6 de nuestra prueba sin opciones especiales, y no necesita SHA-1.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_oldserver
ssh-copy-id -o PubkeyAcceptedAlgorithms=+ssh-rsa -i ~/.ssh/id_ed25519_oldserver.pub user@server

Mira cómo generar una clave ed25519. ECDSA también sirve donde Ed25519 no esté disponible. Para comparar los dos tipos de clave, mira RSA o Ed25519.

Solución 2: permite ssh-rsa solo para ese host

Úsala para un dispositivo que no puedes cambiar, como equipos de red antiguos. Limítala a ese host en ~/.ssh/config en lugar de ponerla bajo Host *:

Host old-box
  HostName 203.0.113.10
  User user
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes
  PubkeyAcceptedAlgorithms +ssh-rsa

OpenSSH lo describe como un parche provisional hasta que se pueda actualizar el sistema antiguo. Si el dispositivo solo tiene una clave de host RSA, aparece otro error sobre el tipo de clave de host. Añade HostKeyAlgorithms +ssh-rsa al mismo bloque, y mira no matching key exchange para esa familia de errores.

Solución 3: actualiza el servidor

Un servidor con OpenSSH 7.2 o posterior firma con SHA-2 automáticamente y el mensaje desaparece. Un servidor tan antiguo además carece de años de correcciones de seguridad.

Si sigue fallando en sistemas tipo Red Hat

En RHEL 9 y derivados, la política criptográfica del sistema restringe por defecto las firmas SHA-1, además del ajuste de OpenSSH:

update-crypto-policies --show

Si tienes que llegar al servidor antiguo desde esa máquina, vuelve a permitir las firmas SHA-1 con la subpolítica SHA1 y reinicia:

sudo update-crypto-policies --set DEFAULT:SHA1

Afecta a toda la máquina y a cada programa, así que prefiere la solución 1 donde puedas.

El caso inverso

Un cliente antiguo contra un servidor nuevo falla al revés: el cliente ofrece ssh-rsa y el servidor lo rechaza. El cliente solo ve Permission denied (publickey). Actualiza el cliente o usa una clave Ed25519.

Preguntas

¿Tengo que sustituir mi clave RSA?

No. La misma clave RSA firma con rsa-sha2-256 o rsa-sha2-512 en cualquier servidor con OpenSSH 7.2 o posterior. El error viene de servidores antiguos que solo aceptan firmas SHA-1.

¿Es seguro PubkeyAcceptedAlgorithms +ssh-rsa?

Permite firmas SHA-1 solo para ese host. Déjalo en el bloque Host de ese host como solución temporal, y pasa a una clave Ed25519 o a un servidor más reciente.

¿Qué diferencia hay entre ssh-rsa y rsa-sha2-256?

Las dos usan la misma clave RSA. ssh-rsa firma con SHA-1, que OpenSSH dejó de ofrecer por defecto en la 8.8, mientras que rsa-sha2-256 y rsa-sha2-512 firman con SHA-2.

Fuentes

Más en Mensajes de error

Todas las guías