git_ssh_no_matching_host_key_type_found

Solventar problemas con compatibilidad entre versiones actuales de clientes SSH y servidores SSH antiguos

Errores SSH / GIT

Error SSH.

Unable to negotiate with X.X.X.X port X: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Error Git (basado en ssh).

Permission denied (publickey).

fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists

Motivos

Se recomienda leer las notas de lanzamiento oficiales de openssh: https://www.openssh.com/releasenotes.html.

A partir de la versión SSH >= 7.X las llaves DSA no son soportadas.

The new openssh version (7.0+) deprecated DSA keys and is not using DSA keys by default (not on server or client). The keys are not preferred to be used anymore, so if you can, I would recommend to use RSA keys where possible.

A partir de la versión SSH >= 8.8 las llaves RSA SHA1 no son soportadas.

This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K [1]

For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.

Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol

En lo que respecta a llaves RSA, el formato de la clave no ha cambiado. Lo único que cambia es el formato de firma que se envía durante cada handshake de autenticación. En los casos de incompatibilidad, es ahí donde SHA1 entra en juego. Antiguamente en SSHv2, el tipo de llave y el tipo de firma solían definirse en combinación. (Por ejemplo, el mismo identificador “ssh-rsa” se definía para llaves RSA y firmas RSA/SHA-1). Sin embargo, actualmente se han desarrollado extensiones del protocolo para evitar esto, y los clientes SSH modernos negociarán automáticamente los tipos de firma (evitando por defecto actualmente sha1) siempre que haya claves RSA involucradas.

En el handshake SSH se usa un bucle de verificación de firma. Este bucle de firma/verificación del hash de intercambio (el cual se usa como secreto compartido) y la firma permite al cliente verificar que el servidor tiene la propiedad de la clave privada del anfitrión y, por tanto, que el cliente está conectado al servidor correcto (siempre que el cliente pueda confiar en la clave pública correspondiente, más adelante en el proceso de negociación). Por lo tanto si ahí se está operando con un algoritmo definido como “roto”, no se debería confiar en dicha negociación.

Depurar el problema

Como averiguar si nuestro cliente SSH soporta rsa/sha1.

ssh -G servidor 2>&1  | grep -i --color ssh-rsa
# Si se muestra "ssh-rsa", es que está todavía soportado.

Como averiguar si el servidor muestra algún problema de incompatibilidad.

ssh -v servidor
...
debug1: kex: host key algorithm: (no match)
Unable to negotiate with 10.0.200.124 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Para casos concretos de servidores git/ssh también se puede obtener el siguiente registro.

ssh -v git@servidor 2>&1
...
send_pubkey_test: no mutual signature algorithm

Soluciones

Actualizar el servicio SSH o soportar de nuevo por parte del cliente este tipo de llaves SSH que usan SHA1 (o cualquier otra considerada deprecated).

Configuración SSH: fichero $HOME/.ssh/config

Host *.dominio.com                 # Configuración para todos los subdominios "*.dominio.com".
   HostKeyAlgorithms +ssh-rsa      # SSH
   PubkeyAcceptedKeyTypes +ssh-rsa # GIT

Solución para Git en forma de variable GIT_SSH_COMMAND.

export GIT_SSH_COMMAND="ssh  -o 'PubkeyAcceptedKeyTypes +ssh-rsa'"

Parámetros del comando ssh.

ssh  -o 'PubkeyAcceptedKeyTypes +ssh-rsa' -o 'HostKeyAlgorithms +ssh-rsa' XYZ@dominio.com

Políticas de seguridad.

Dependiendo de la distribución puede que exista un fichero que defina las políticas criptográficas: /etc/crypto-policies/back-ends/openssh.config ( Opción “PubkeyAcceptedKeyTypes”).

git_ssh_no_matching_host_key_type_found.txt · Last modified: 2021/11/09 22:22 by busindre