El known_hosts El archivo permite que el cliente autentique el servidor para verificar que no se esté conectando a un suplantador. El authorized_keys El archivo permite que el servidor autentique 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 la criptografía de clave pública) al cliente que conoce la clave privada asociada. Esto autentica al servidor:si esta parte del protocolo tiene éxito, el cliente sabe que el servidor es quien dice ser.
El cliente puede verificar que el servidor sea conocido y no un servidor falso que intenta 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 ~/.ssh/known_hosts archivo en la máquina cliente (también hay un archivo para todo el sistema /etc/ssh/known_hosts ). La primera vez que se conecta a un servidor, debe 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 desea 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 admitida por la implementación de SSH, no solo DSA (también RSA y ECDSA).
La autenticación del servidor debe realizarse antes de enviarle datos confidenciales. En particular, si la autenticación del usuario involucra 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. Según 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 de la cuenta en la que intenta iniciar sesión; el servidor luego verifica que la contraseña sea correcta.
- El usuario puede presentar una clave pública y probar 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 lo 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_keysen el servidor). - Otro tipo de método consiste en delegar parte del trabajo de autenticación del usuario a la máquina cliente. Esto sucede en entornos controlados como las empresas, cuando muchas máquinas comparten las mismas cuentas. El servidor autentica la máquina del cliente mediante el mismo mecanismo que se usa al revés, luego confía en el cliente para autenticar al usuario.
Esos dos archivos son utilizados por SSH pero para propósitos completamente diferentes, lo que podría explicar fácilmente su confusión.
Claves autorizadas
De manera predeterminada, 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 muy útil aquí). Lo que esto significa es que cuando intenta conectarse a SSH con el nombre de usuario 'bob' y alguna contraseña, el programa del servidor SSH le preguntará al sistema operativo "I tengo a este tipo llamado 'bob' que me dice que su contraseña es 'wonka'. ¿Puedo dejarlo entrar?" Si la respuesta es sí, entonces SSH le permite autenticarse y seguir su camino feliz.
Además de las contraseñas, SSH también le permitirá usar lo que se llama 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 programa, se crean dos archivos. Uno que es su clave privada y otro que es su clave pública. Los nombres son bastante autoexplicativos. Por diseño, la clave pública se puede esparcir 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 haces es colocar tu clave pública en el authorized_keys expediente. Luego, cuando intente conectarse a SSH con el nombre de usuario 'bob' y su clave privada, le preguntará al sistema operativo "Tengo a este tipo llamado 'bob', ¿puede estar aquí?" Si la respuesta es sí, SSH inspeccionará su clave privada y verificará si la clave pública está en el authorized_keys archivo es su par. Si ambas respuestas son afirmativas, entonces puede ingresar.
Hosts conocidos
Al igual que el authorized_keys El archivo se utiliza para autenticar a los usuarios el known_hosts El archivo se utiliza para autenticar servidores. Cada vez que se configura SSH 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 known_hosts expediente. Si tiene la clave y coincide, entonces 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 clave son:
- La clave cambió en el servidor. Esto podría deberse a la reinstalación del sistema operativo o, en algunos sistemas operativos, la clave se vuelve a crear al actualizar SSH.
- El nombre de host o la dirección IP a la que se está conectando solía pertenecer a un servidor diferente. Esto podría ser reasignación de direcciones, DHCP o algo similar.
- Se está produciendo un ataque malicioso de intermediario. 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.
Acerca de los archivos seguros que contienen claves públicas
Para ayudarlo a comprender en qué se diferencian "known_hosts" y "authorized_keys", aquí hay un contexto que explica cómo esos archivos encajan en "ssh". Esta es una simplificación excesiva; hay muchas más capacidades y complicaciones para "ssh" que las que se mencionan aquí.
Las asociaciones están en fuentes confiables
Si bien se ha dicho que los valores de clave pública "pueden esparcirse de manera segura como semillas en el viento", tenga en cuenta que es el jardinero, no la vaina de semillas, quien decide qué semillas se establecen en el jardín. Si bien 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. Los lugares encargados de realizar esta asociación incluyen listados de "hosts_conocidos", "claves_autorizadas" y "Autoridad de certificación".
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 cada uno su propia lista de claves públicas almacenada de forma segura; un inicio de sesión tendrá éxito solo si cada lado está registrado con el otro.
- "known_hosts" reside en el cliente
- "authorized_keys" reside en el servidor
El archivo seguro del cliente se llama "known_hosts" y el archivo seguro del servidor se llama "authorized_keys". Estos archivos son similares en el sentido de que cada uno tiene texto con una clave pública por línea, pero tienen sutiles diferencias en formato y uso.
Los pares de claves se utilizan para la autenticación
Se utiliza un par de claves públicas y privadas para realizar "criptografía asimétrica". El programa "ssh" puede usar criptografía asimétrica para la autenticación, donde una entidad debe responder a un desafío para probar su identidad. El desafío se crea codificando con una clave y se responde descodificando con la otra clave. (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 encriptación para manejar el flujo de datos).
Un par de claves para el servidor, otro para el 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", se requería que el cliente proporcionara una contraseña, pero el servidor no fue investigado. La falta de investigación permitió que ocurrieran ataques de "hombre en el medio", 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 de 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 de intermediario al desafiar al servidor a demostrar "¿Eres realmente quien creo que eres?" Para realizar 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 intacta; por lo tanto, los permisos en el archivo "known_hosts" deben 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 implicará una de las claves públicas que se encuentran en "authorized_keys". (Cuando ninguna de esas claves funciona, el proceso "sshd" recurre a la autenticación de estilo de contraseña).
Los formatos de archivo
Entonces, para "ssh", como con cualquier proceso de inicio de sesión, hay listas de "amigos", y solo aquellos en la lista pueden intentar pasar 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 "authorized_keys"; pero no hay nombres en ese archivo, ya que las propias claves públicas actúan como identificadores. (Al servidor no le importa de dónde proviene el inicio de sesión, sino solo a dónde va. El cliente está intentando acceder a una cuenta en particular, el nombre de la cuenta se especificó como un parámetro cuando se invocó "ssh". Recuerde que las "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 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 incluyen "dsa" y "ecdsa". Por lo tanto, un token diferente podría ocupar el lugar del ssh-rsa se muestra aquí.
Deje que "ssh" configure automáticamente la entrada "known_hosts"
En ambos casos, si la clave pública no se encuentra dentro de un archivo seguro, no se produce el cifrado asimétrico. Como se mencionó anteriormente, hay una excepción a esta regla. Un usuario puede optar a sabiendas por arriesgarse a la posibilidad de un ataque man-in-the-middle al iniciar sesión en un servidor que no figura 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 por 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 al pedirle al servidor la clave pública y luego escribirla 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 facilita mucho las cosas 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 podría no tener sentido).
Las relaciones de uno a muchos
Una entrada en el archivo "known_hosts" del cliente tiene el nombre de un servidor y una clave pública que se aplica 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 alguna vez a un servidor en particular tendrán la misma entrada de clave pública en su archivo "known_hosts". La relación 1:N es que la clave pública de un servidor puede aparecer en los archivos "known_hosts" de muchos clientes.
Una entrada en el archivo "authorized_keys" identifica que un cliente amigable puede acceder a la cuenta. El amigo puede usar el mismo par de claves públicas y privadas para acceder a varios servidores diferentes. Esto permite que un solo par de claves se autentique en todos los servidores contactados alguna vez. Cada una de las cuentas de servidor de destino tendría la misma entrada de clave pública en sus archivos "authorized_keys". La relación 1:N es que la clave pública de un cliente puede aparecer en los archivos "authorized_keys" para múltiples cuentas en múltiples servidores.
A veces, los usuarios que trabajan desde varias máquinas 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 claves privadas
Para el lado del servidor, un proceso del sistema, o daemon, 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, invoque "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 forma predeterminada, el par de claves del lado del cliente suele llamarse $HOME/.ssh/id_rsa y $HOME/.ssh/id_rsa.pub .
Resumen
La conclusión es que tanto "known_hosts" como "authorized_keys" contienen claves públicas, pero...
- known_hosts -- el cliente verifica si el host es genuino
- authorized_keys -- el host comprueba si se permite el inicio de sesión del cliente