No creo que te estés perdiendo mucho. El único cambio es que si una máquina está comprometida, la idea es minimizar la cantidad de información útil que se le da a un atacante. En el archivo known_hosts , no es necesario incluir más información (calcular unos pocos cientos de HMAC no es un trabajo oneroso), a diferencia de ~/.ssh/config donde se debe incluir en la línea Address si desea conectarse a través de su alias (el hashing no funcionaría) y en su historial de línea de comandos, si elige mantener uno.
Es de suponer que podría tener un host_ conocido muy grande (por ejemplo, si lo sincroniza con otra computadora cuando configura la cuenta), pero diga que no use .ssh/config y no mantenga un historial de línea de comandos o que nunca se haya conectado a la mayoría de las máquinas en el historial de la línea de comandos.
En esas situaciones, el hash de las direcciones IP utilizadas en tus hosts conocidos podría disminuir la exposición en caso de un compromiso.
Además, HashKnownHosts es una opción configurable, y el valor predeterminado es no hash (probablemente por las razones que especificó, no ayuda mucho). Ver man ssh_config :
HashKnownHosts
Indica que ssh (1) debe incluir nombres y direcciones de host cuando se agregan a ~ / .ssh / known_hosts.
Estos nombres de hash pueden ser utilizados normalmente por ssh (1) y sshd (8), pero no revelan información de identificación en caso de que se divulgue el contenido del archivo. El valor predeterminado es "no". Tenga en cuenta que los nombres y las direcciones existentes en los archivos de hosts conocidos no se convertirán automáticamente, sino que se pueden procesar manualmente usando ssh-keygen (1). El uso de esta opción puede romper las facilidades, como la finalización de pestañas, que depende de la capacidad de leer los nombres de host no limpiados desde ~ / .ssh / known_hosts.
Tenga en cuenta el formato de una línea de hash conocido_host (ejemplo tomado de aquí - mi configuración actual no es hash) para una entrada para 192.168.1.61 :
|1|F1E1KeoE/eEWhi10WpGv4OdiO6Y=|3988QV0VE8wmZL7suNrYQLITLCg= ssh-rsa ...
donde la primera parte F1E1KeoE/eEWhi10WpGv4OdiO6Y= es una sal aleatoria, que actúa como una clave para el HMAC-SHA1 al hash 192.168.1.61.
Puede verificar en la línea de comandos con (BSD / Mac OS X):
#### key='echo F1E1KeoE/eEWhi10WpGv4OdiO6Y= | base64 -D | xxd -p'
#### echo -n "192.168.1.61" | openssl sha1 -mac HMAC -macopt hexkey:$key|awk '{print $2}' | xxd -r -p|base64
3988QV0VE8wmZL7suNrYQLITLCg=
o en GNU / linux con:
#### key='echo F1E1KeoE/eEWhi10WpGv4OdiO6Y= | base64 -d | xxd -p'
#### echo -n "192.168.1.61" | openssl sha1 -mac HMAC -macopt hexkey:$key|awk '{print $2}' | xxd -r -p|base64
3988QV0VE8wmZL7suNrYQLITLCg=
donde simplemente descodificamos la sal y la usamos como clave en un HMAC sha1, y luego recodificamos el hash en base64. Simplemente al especificar como otra respuesta, se suponía originalmente que el HMAC podría haber usado la clave privada ssh del usuario para calcular el código de autenticación de mensajes basado en hash, pero este no es el caso.