El archivo known_hosts permite al cliente autenticar el servidor, para comprobar que no se está conectando a un imitador. El archivo authorized_keys permite el servidor autentica al usuario.

Autenticación del servidor

Una de las primeras cosas que sucede cuando se establece la conexión SSH es que el servidor envía su clave pública al cliente, y prueba (gracias a criptografía de clave pública ) al cliente que conoce la clave privada asociada. Esto autentica al servidor: si esta parte del protocolo es exitosa, el el cliente sabe que el servidor es quien dice ser.

El cliente puede comprobar que el servidor es conocido y no un servidor deshonesto tratando de hacerse pasar por el correcto. SSH proporciona solo un mecanismo simple para verificar la legitimidad del servidor: recuerda los servidores a los que ya se ha conectado, en el archivo ~/.ssh/known_hosts en la máquina cliente (también hay un sistema -wide file /etc/ssh/known_hosts). La primera vez que te conectes a un servidor, debes verificar por algún otro medio que la clave pública presentada por el servidor es realmente la clave pública del servidor al que deseaba conectarse. Si tiene la clave pública del servidor al que está a punto de conectarse, puede agregarla a ~/.ssh/known_hosts en el cliente manualmente.

Por cierto, known_hosts puede contener cualquier tipo de clave pública compatible con la implementación SSH, no solo DSA (también RSA y ECDSA).

Autenticar el servidor debe ser hecho antes de enviarle datos confidenciales. En particular, si la autenticación de usuario implica una contraseña, la contraseña no debe enviarse a un servidor no autenticado.

Autenticación de usuario

El servidor solo permite que un usuario remoto inicie sesión si ese usuario puede demostrar que tiene derecho a acceder a esa cuenta. Dependiendo de la configuración del servidor y la elección del usuario, el usuario puede presentar una de varias formas de credenciales (la lista a continuación no es exhaustiva).

• El usuario puede presentar la contraseña para la cuenta en la que está intentando iniciar sesión; el servidor luego verifica que la contraseña sea correcta.
• El usuario puede presentar una clave pública y demostrar que posee la clave privada asociada con esa clave pública. Este es exactamente el mismo método que se usa para autenticar el servidor, pero ahora el usuario está tratando de probar su identidad y el servidor la está verificando. El intento de inicio de sesión se acepta si el usuario demuestra que conoce la clave privada y la clave pública está en la lista de autorización de la cuenta (~/.ssh/authorized_keys en el servidor).
• Otro tipo de método consiste en delegar parte del trabajo de autenticación del usuario en la máquina cliente. Esto ocurre en entornos controlados como empresas, cuando muchas máquinas comparten las mismas cuentas. El servidor autentica la máquina cliente mediante el mismo mecanismo que utilizado al revés, luego depende del cliente para autenticar al usuario.

Comentarios

• gracias, esto es muy útil. es correcto decir que el archivo known_hosts se mantiene en el cliente mientras que el archivo autorizado_key se mantiene en el servidor
• @Ankit Sí, ese es el caso.
• Tengo ambos archivos en el servidor y ssh para probarlo. Pero los 2 archivos tienen contenido diferente. ¿Entonces las claves son diferentes en estos archivos?
• @Timo Las claves son completamente unr exaltado. Una es la clave de una máquina, la otra es la clave de un usuario.
• @Gilles Entonces, una vez que se agrega la entrada para la clave pública de un servidor ‘ al archivo known_hosts en la máquina del cliente ‘ s, cualquier sesión ssh posterior entre los dos no ‘ t ¿Requiere que el servidor demuestre que tiene la clave privada correcta?

Estos dos archivos son usados por SSH pero para propósitos completamente diferentes, lo que podría explicar fácilmente su confusión.

Claves autorizadas

Por defecto, SSH usa cuentas de usuario y contraseñas que son administradas por el sistema operativo host. (Bueno, en realidad administrado por PAM , pero esa distinción probablemente no sea demasiado útil aquí). Lo que esto significa es que cuando intentas conectarte a SSH con el nombre de usuario «bob» y alguna contraseña, el programa del servidor SSH le preguntará al sistema operativo » Tengo a este tipo llamado «bob» que me dice que su contraseña es «wonka». ¿Puedo dejarlo entrar? » Si la respuesta es sí, SSH te permite autenticarte y seguir tu camino feliz.

Además de las contraseñas SSH también le permitirá utilizar lo que se denomina criptografía de clave pública para identificarlo. El algoritmo de cifrado específico puede variar, pero suele ser RSA o DSA , o más recientemente ECDSA . En cualquier caso, cuando configure sus claves, utilice el ssh-keygen , creas dos archivos. Uno que es tu clave privada y otro que es tu clave pública. Los nombres son bastante propios -explicativo. Por diseño, la clave pública puede esparcirse como semillas de diente de león en el viento sin comprometerlo. La clave privada siempre debe mantenerse en la más estricta confidencialidad.

Entonces, lo que debe hacer es colocar su clave pública en el archivo authorized_keys. Luego, cuando intente conectarse a SSH con el nombre de usuario «bob» y su clave privada le preguntará al sistema operativo » Tengo este nombre de tipo «bob», ¿puede estar aquí? » Si la respuesta es sí, entonces SSH inspeccionará su clave privada y verificará si la clave pública en el archivo authorized_keys es su par. Si ambas respuestas son sí, entonces puede ingresar.

Hosts conocidos

Muy parecido a cómo se usa el archivo authorized_keys para autenticar usuarios el archivo known_hosts se usa para autenticar servidores. Siempre que SSH se configura en un nuevo servidor, siempre genera una clave pública y privada para el servidor, tal como lo hizo para su usuario. Cada vez que te conectas a un servidor SSH te muestra su clave pública, junto con una prueba de que posee la clave privada correspondiente. Si no tiene su clave pública, su computadora la solicitará y la agregará al archivo known_hosts. Si tiene la clave y coincide, se conecta de inmediato. Si las claves no coinciden, recibirá una gran advertencia desagradable. Aquí es donde las cosas se ponen interesantes. Las 3 situaciones en las que suele ocurrir una falta de coincidencia de claves son:

1. La clave cambió en el servidor. Esto podría deberse a la reinstalación del SO o en algunos SO, la clave se vuelve a crear al actualizar SSH.
2. El nombre de host o la dirección IP que está conectando solía pertenecer a un servidor diferente. Esto podría ser una reasignación de dirección, DHCP o algo similar.
3. man- está ocurriendo un ataque intermedio . Esto es lo más importante de lo que la verificación de claves intenta protegerlo.

En ambos casos, known_hosts y authorized_keys, el programa SSH utiliza criptografía de clave pública para identificar al cliente o al servidor.

Comentarios

• » Cada vez que te conectas a un servidor SSH, este presenta su clave privada para probar su identidad. » ¡Ciertamente espero que no! Supongo que te refieres a su clave pública . Si un servidor me presentara a mí, el cliente, su clave privada, (A) no ‘ no me funcionaría para autenticarlo y (B) es una indicación de que el servidor es tan mal configurado que debería dejar de hacer negocios con él de inmediato. Las claves privadas solo deben ser accesibles en la máquina de origen por los usuarios designados. Ese ‘ es un poco el punto. 😉
• Esta respuesta me ayudó más que la aceptada (:
• Si hago ssh a un servidor local (IP local), y luego desde la misma computadora pero ahora de forma remota conectarse al mismo servidor (IP pública) ¿activará claves que no coinciden? ¿Cómo puede mitigar esto?

Acerca de los archivos seguros que contienen claves públicas

Para ayudarlo a comprender en qué se diferencian «hosts_conocidos» y «claves_autorizadas», aquí hay un contexto que explica cómo esos archivos encajan en «ssh». Esta es una simplificación ; hay muchas más capacidades y complicaciones para «ssh» de las que se mencionan aquí.

Las asociaciones están en fuentes confiables

Si bien se ha dicho que los valores de clave pública «se pueden esparcir de manera segura como semillas en el viento», tenga en cuenta que es el Gardner, no la vaina de semillas, quien decide qué semillas se establecen en el jardín. Aunque una clave pública no es secreta, se requiere una protección feroz para preservar la asociación confiable de la clave con lo que la clave está autenticando. encargados de hacer esta asociación incluyen «hosts_conocidos», «claves_autorizadas» y listas de «Autoridad certificadora».

Las fuentes de confianza utilizadas por «ssh»

Para que una clave pública sea relevante para «ssh», la clave debe registrarse con anticipación y almacenarse en el archivo seguro apropiado (esta verdad general tiene una excepción importante, que se discutirá más adelante). El servidor y el cliente tienen sus propios archivos almacenados lista de claves públicas; un inicio de sesión tendrá éxito solo si cada lado está registrado con el otro.

• «hosts_conocidos» reside en el clie nt
• «claves_autorizadas» reside en el servidor

El archivo seguro del cliente se llama «hosts_conocidos», y el archivo seguro del servidor se llama «claves_autorizadas» . Estos archivos son similares en que cada uno tiene texto con una clave pública por línea, pero tienen diferencias sutiles en el formato y el uso.

Los pares de claves se utilizan para la autenticación

Un público -par de claves privadas se utilizan para realizar «criptografía asimétrica». El programa «ssh» puede usar criptografía asimétrica para la autenticación, donde una entidad tiene que responder a un desafío para demostrar su identidad. El desafío se crea codificando con una tecla y se responde decodificando con la otra tecla. (Tenga en cuenta que la criptografía asimétrica se usa solo durante la fase de inicio de sesión; luego «ssh» (TSL / SSL) cambia a otra forma de cifrado para manejar el flujo de datos).

Un par de claves para el servidor, otro para Cliente

En «ssh», ambos lados (cliente y servidor) sospechan del otro; esta es una mejora con respecto al predecesor de «ssh», que era «telnet». Con «telnet», el cliente debía proporcionar una contraseña, pero el servidor no fue examinado. La falta de investigación permitió que ocurrieran ataques «man-in-the-middle», con consecuencias catastróficas para la seguridad. Por el contrario, en el proceso «ssh», el cliente no entrega información hasta que el servidor responde primero a un desafío.

Los pasos en la autenticación «ssh»

Antes de compartir cualquier información de inicio de sesión, el cliente «ssh» primero elimina la oportunidad de un ataque man-in-the-middle al desafiar al servidor a demostrar «¿Eres realmente quien creo que eres?» Para hacer este desafío, el cliente necesita conocer la clave pública asociada con el servidor de destino. El cliente debe encontrar el nombre del servidor en el archivo «known_hosts»; la clave pública asociada está en la misma línea, después del nombre del servidor. La asociación entre el nombre del servidor y la clave pública debe mantenerse inviolada; por lo tanto, los permisos en el archivo «known_hosts» debe ser 600 – nadie más puede escribir (ni leer).

Una vez que el servidor se ha autenticado, tiene la oportunidad de desafiar al cliente. La autenticación involucrará a uno de los públicos- claves que se encuentran en las «claves_autorizadas». (Cuando ninguna de esas claves funciona, el proceso «sshd» recurre a la autenticación de estilo de contraseña).

Los formatos de archivo

Así que para » ssh «, como con cualquier proceso de inicio de sesión, hay listas de» amigos «, y solo los que están en la lista pueden intentar aprobar un desafío. Para el cliente, el archivo» known_hosts «es una lista de amigos que pueden actuar como servidores (hosts); estos se enumeran por nombre. Para el servidor, la lista equivalente de amigos es el archivo «claves_autorizadas»; pero no hay nombres en ese archivo, ya que el Las mismas claves c actúan como identificadores. (Al servidor no le importa de dónde viene el inicio de sesión, sino sólo a dónde va. El cliente está intentando acceder a una cuenta en particular, el nombre de la cuenta se especificó como parámetro cuando se invocó «ssh». Recuerde que el El archivo «claves_autorizadas» es específico de esa cuenta, ya que el archivo se encuentra en el directorio de inicio de esa cuenta.)

Aunque hay muchas capacidades que se pueden expresar en una entrada de configuración, el uso básico y más común tiene los siguientes parámetros. Tenga en cuenta que los parámetros están separados por caracteres de espacio.

Para «hosts_conocidos»:

{server-id} ssh-rsa {public-key-string} {comment} 

Para «claves_autorizadas»:

ssh-rsa {public-key-string} {comment} 

Tenga en cuenta que el token ssh-rsa indica que el algoritmo utilizado para la codificación es «rsa». Otros algoritmos válidos incluir «dsa» y «ecdsa». Por lo tanto, un token diferente podría reemplazar el ssh-rsa que se muestra aquí.

Deje que «ssh» configure automáticamente el Entrada «known_hosts»

En ambos casos, si th La clave pública no se encuentra dentro de un archivo seguro, entonces el cifrado asimétrico no ocurre. Como se mencionó anteriormente, existe una excepción a esta regla.Un usuario puede elegir conscientemente arriesgarse a la posibilidad de un ataque man-in-the-middle al iniciar sesión en un servidor que no está listado en el archivo «known_hosts» del usuario. El programa «ssh» advierte al usuario, pero si el usuario elige seguir adelante, el cliente «ssh» lo permite «solo esta vez». Para asegurarse de que suceda solo una vez, el proceso «ssh» configura automáticamente el archivo «known_hosts» con la información requerida solicitando al servidor public-key, y luego escribir eso en el archivo «known_hosts». Esta excepción subvierte totalmente la seguridad al permitir que el adversario proporcione la asociación de un nombre de servidor con una clave pública. Este riesgo de seguridad está permitido porque hace las cosas mucho más fácil para muchas personas. Por supuesto, el método correcto y seguro habría sido que el usuario insertara manualmente una línea con el nombre del servidor y la clave pública en el archivo «known_hosts» antes de intentar iniciar sesión en el servidor. (Pero para situaciones de bajo riesgo, el trabajo adicional puede no tener sentido).

Las relaciones uno a varios

Una entrada en el archivo «hosts_conocidos» del cliente tiene el nombre de un servidor y una clave pública que es aplicable a la máquina del servidor. El servidor tiene una única clave privada que se usa para responder a todos los desafíos, y la entrada «known_hosts» del cliente debe tener la clave pública correspondiente. Por lo tanto, todos los clientes que accedan a un servidor en particular tendrán la clave pública idéntica. entrada en su archivo «hosts_conocidos». La relación 1: N es que la clave pública de un servidor puede aparecer en muchos archivos «hosts_conocidos» de clientes.

Una entrada en el archivo «claves_autorizadas» identifica que un cliente amigable puede acceder a la cuenta. El amigo puede usar el mismo par de claves pública y privada para acceder a varios servidores diferentes. Esto permite que un solo par de claves se autentique en todos los servidores con los que se haya contactado. Cada una de las cuentas de servidor de destino tendría la entrada de clave pública idéntica en sus archivos «claves_autorizadas». La relación 1: N es que la clave pública de un cliente puede aparecer en los archivos «claves_autorizadas» para varias cuentas en varios servidores.

A veces, los usuarios que trabajan desde varios equipos cliente replicarán el mismo par de claves; por lo general, esto se hace cuando un usuario trabaja en una computadora de escritorio y una computadora portátil. Debido a que las máquinas cliente se autentican con claves idénticas, coincidirán con la misma entrada en las «claves_autorizadas» del servidor.

Ubicación de las claves privadas

Para el lado del servidor, un proceso del sistema , o demonio, maneja todas las solicitudes de inicio de sesión «ssh» entrantes. El demonio se llama «sshd». La ubicación de la clave privada depende de la instalación de SSL, por ejemplo, Apple la coloca en /System/Library/OpenSSL, pero después de instalar su propia versión de OpenSSL, la ubicación será /opt/local/etc/openssl.

Para el lado del cliente, invoca «ssh» (o «scp» ) cuando lo necesite. Su línea de comando incluirá varios parámetros, uno de los cuales puede especificar opcionalmente qué clave privada usar. De manera predeterminada, el par de claves del lado del cliente a menudo se llama $HOME/.ssh/id_rsa y $HOME/.ssh/id_rsa.pub.

Resumen

La conclusión es que tanto los «hosts_conocidos» como las «claves_autorizadas» contienen claves públicas, pero …

• hosts_conocidos: el cliente verifica si el host es genuino
• claves_autorizadas: el host comprueba si se permite el inicio de sesión del cliente

Comentarios

• Los clientes SSH generalmente no ‘ no tiene claves. Las claves públicas que se enumeran en authorized_keys identifican a los usuarios, no a las máquinas.
• Gracias. Esta es una explicación muy clara y fácilmente comprensible de las relaciones entre los archivos y las claves.

No es cierto en absoluto.

El archivo known_hosts contiene la huella digital del host. No es la clave pública o privada del host remoto.

Se genera a partir de su clave, pero enfáticamente NO es la clave en sí.

Si envía SFTP a una dirección que podría resolverse en varios hosts (variables) (carga equilibrada, etc.) debe agregar las huellas digitales de todos los puntos finales posibles, o funcionará inicialmente y luego fallará cuando se enrute al segundo (o posterior) host.

Comentarios

• erm mire su archivo known_hosts y compárelo con una huella digital de host cuando se conecte … Eso debería aclararlo un poco. Además, su ejemplo sería exactamente el mismo, independientemente de si son huellas digitales o claves públicas en el archivo known_hosts.