6 votos

SSH en Ventura - ¿Cómo lidiar con hosts que ejecutan versiones muy antiguas de OpenSSH?

Ventura [13.0 Beta (22A5352e)] se entrega con OpenSSH_9.0p1.

Según las notas de la versión de OpenSSH:

Esta versión desactiva por defecto las firmas RSA que utilizan el algoritmo hash SHA-1. Este cambio se ha realizado debido a que el algoritmo hash SHA-1 está criptográficamente roto, y es posible crear colisiones hash de prefijo elegido por <USD$50K

El host web al que quiero conectarme tiene OpenSSH_5.3p1 que parece estar configurado para ofrecer sólo RSA y DSA:

no matching host key type found. Their offer: ssh-rsa,ssh-dss

Preferiría utilizar las teclas ed25519. He "arreglado" temporalmente el problema añadiendo lo siguiente a mi /etc/ssh/ssh_config f

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa

Tiene que haber una forma mejor. Por supuesto, no puedo hacer que el proveedor de alojamiento web actualice su OpenSSH, así que tendré que arreglarlo yo.

¿Alguna sugerencia?

6voto

staffan Puntos 3299

Si el servidor no acepta claves ed25519, no puedes usar claves ed25519. Tienes que usar un tipo de clave que el servidor admita, fin de la historia.

Mientras el cliente OpenSSH siga soportando alguna característica en común con el servidor, puedes seguir usándolo. Si está deshabilitado por defecto, puedes habilitarlo para un servidor específico añadiendo una directiva Host al archivo ~/.ssh/config en su directorio personal. Algo como:

Host my-old-server.example.com
PubkeyAcceptedKeyTypes +ssh-rsa

Si no estás seguro de qué ajustes tienes que cambiar, aquí tienes cómo averiguarlo:

  • Puedes listar los ajustes compatibles con ssh -Q sig etc. Utilice la terminación de shell o consulte man ssh_config para lo que puede poner después de -Q .
  • Puede ver la configuración permitida por defecto ejecutando ssh -G localhost . Esto vuelca la configuración que ssh utiliza cuando se conecta a localhost.
  • Puede ver qué ajustes ofrece su cliente y qué ajustes admite el cliente conectándose con el inicio de sesión: ssh -vvv my-old-server.example.com .

Tenga en cuenta que para el uso ordinario de SSH, incluso las firmas basadas en SHA-1 están bien. SHA-1 está roto cuando se trata de colisiones y esto es catastrófico para las infraestructuras de clave pública: un atacante que quiera hacerse pasar por goodserver.example.com puede calcular un nombre "basura" tal que una solicitud de certificado para goodserver.example.com y el nombre basura tienen el mismo hash SHA-1, registre el nombre basura y obtenga un certificado válido para él, y debido a la colisión del hash SHA-1 ese certificado también es válido para goodserver.example.com . Así es como se utiliza normalmente TLS (incluido HTTPS), pero no SSH. Cuando te conectas directamente a un servidor, la propiedad de seguridad que importa para el hash es la segunda resistencia a la preimagen (para que el atacante no pueda suplantar la identidad del servidor directamente), y SHA-1 aún no se ha roto en este aspecto.

En cuanto a RSA, es tan seguro como ECDSA o Ed25519, su único inconveniente es que es un poco más lento.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X