Diferentes formatos SSH known_hosts

6

Últimamente he tenido problemas con la implementación de mi servidor CI debido a que el cliente (CI) rechazó la clave de host del control remoto (a pesar de estar presente known_hosts). Estaba perplejo hasta hoy, cuando me di cuenta de que SSH estaba guardando claves de host en un formato con el que el complemento de implementación no parece ser compatible. Como referencia, el formato compatible (todavía presente en mi máquina personal) se parece a esto:

11.22.33.44 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCkVf7rhfC7nLxbeIQRj2bWitUC+XLSAeQ0ap8r8rKObDXYfPdB97NZth9JCEt3OrBXuBeg4PaAEuPu2QF7WXoT60hgAP6etr0W4LqcH59yd/X0ogFP7Y7hIf6dz1txDKaW92wgUi5XShwH6vukf0gLvW6/ak1LTBuoy72gaoUvxZge4KZivz9XqvSQHNOG9KYNfh8U6cRM8YTQo5in7YD5d6REV/FUmXpvBzCa9kbVRSlQFGYEc1HidTnPnJDteas3A9y3na385O7WN64aAkg7TO8IFXKdDHSwji9ZyrCVPA5GEuyLKhDFanV8iJ7CNflHMP8TwG5FOT2bSkV0lPyl

Si bien el formato SSH se está guardando actualmente al aceptar nuevas claves de host, se parece a esto:

11.22.33.44 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEJJEs165NgdEcD94Xg3ySFA/qgkfytxNCX1X3pB2SPgU/mHLGXCXM8+VqMBXocM8OMOq2L0fDGr5mI+nGqjhNU=

(Nota: aunque falsifiqué un poco las claves públicas, todavía no se parecen en absoluto en su forma original).

Solo el primer formato es compatible con el complemento de implementación, mientras que el segundo se ignora incondicionalmente. ¿Alguien puede explicar esta discrepancia?

ssh known-hosts caseif
fuente

Respuestas:

11

Estos no son formatos diferentes known_hosts, sino diferentes tipos de clave ( ssh-rsay ecdsa-sha2-nistp256, bien descritos en la página del manual sshd). El servidor generalmente tiene más claves de host de diferentes tipos para proporcionar una compatibilidad más amplia con diferentes clientes.

Si está en el servidor, puede encontrar todas las claves de host e imprimir sus claves públicas utilizando, pero la línea no tiene el mismo formato que:

$ cat /etc/ssh/ssh_host_*.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEJJEs165NgdEcD94Xg3ySFA/qgkfytxNCX1X3pB2SPgU/mHLGXCXM8+VqMBXocM8OMOq2L0fDGr5mI+nGqjhNU= user@host

El formato aceptado por el known_hostsarchivo se puede obtener usando (desde el servidor para lograr la autenticidad de las claves):

$ ssh-keyscan 11.22.33.44
11.22.33.44 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEJJEs165NgdEcD94Xg3ySFA/qgkfytxNCX1X3pB2SPgU/mHLGXCXM8+VqMBXocM8OMOq2L0fDGr5mI+nGqjhNU=
#[...]

Esto imprime el formato que puede almacenar directamente en el cliente known_hosts.

Para toda la imagen (de la página del manual):

Cada línea en estos archivos contiene los siguientes campos: marcadores (opcional), nombres de host, bits, exponente, módulo, comentario. Los campos están separados por espacios.

(aunque no parece coherente con lo que se genera: nombre de host, tipo de clave, datos clave (base64)): lo comprobaré más adelante, ya que no es importante para la pregunta

Jakuje
fuente
El formato al que estoy acostumbrado es: dirección IP, espacio, tipo de clave, espacio, cuatro letras As y algunas otras cosas (que a menudo comienzan de manera similar, pero finalmente contienen los datos de la clave sin procesar y son diferentes). Entonces ambos ejemplos siguen el mismo formato. Con ecdsa-sha2-nistp256 noto otro AAAA y un AAABBB posterior parece común. Su solución: actualice el complemento para admitir el tipo de clave más reciente. (Desea que su complemento se actualice regularmente, de lo contrario, esto puede ser un problema continuo a medida que los nuevos tipos de clave se vuelven comunes.)
TOOGAM
@TOOGAM No, el primero tiene la dirección IP prefijada. Los datos clave deben ser los mismos si desea que funcionen (¿y por qué codificar los mismos datos de dos maneras diferentes?).
Jakuje