Hemos ensalzado las virtudes de SSH en numerosas ocasiones, tanto para la seguridad como para el acceso remoto. Echemos un vistazo al servidor en sí, algunos aspectos importantes de "mantenimiento" y algunas peculiaridades que pueden agregar turbulencias a un viaje de otra manera suave.
Si bien escribimos esta guía pensando en Linux, esto también se puede aplicar a OpenSSH en Mac OS X y Windows 7 a través de Cygwin .
Por qué es seguro
Hemos mencionado muchas veces que SSH es una excelente manera de conectar y canalizar datos de forma segura de un punto a otro. Echemos un vistazo breve a cómo funcionan las cosas para que tenga una mejor idea de por qué las cosas pueden salir raras a veces.
Cuando decidimos iniciar una conexión a otra computadora, a menudo usamos protocolos con los que es fácil trabajar. Me vienen a la mente Telnet y FTP. Enviamos información a un servidor remoto y luego recibimos una confirmación sobre nuestra conexión. Para establecer algún tipo de seguridad, estos protocolos suelen utilizar combinaciones de nombre de usuario y contraseña. Eso significa que son totalmente seguros, ¿verdad? ¡Incorrecto!
Si pensamos en nuestro proceso de conexión como correo, entonces usar FTP y Telnet y similares no es como usar sobres de correo estándar. Es más como usar postales. Si alguien se interpone en el medio, puede ver toda la información, incluidas las direcciones de ambos corresponsales y el nombre de usuario y la contraseña enviados. Luego pueden cambiar el mensaje, manteniendo la misma información y suplantando a un corresponsal u otro. Esto se conoce como un ataque "man-in-the-middle" y no solo compromete su cuenta, sino que pone en duda todos y cada uno de los mensajes enviados y archivos recibidos. No puede estar seguro de si está hablando con el remitente o no, e incluso si lo está, no puede estar seguro de que nadie esté mirando todo desde el medio.
Ahora, veamos el cifrado SSL, el tipo que hace que HTTP sea más seguro. Aquí, tenemos una oficina de correos que maneja la correspondencia, que verifica si su destinatario es quien dice ser, y tiene leyes que protegen su correo para que no sea revisado. Es más seguro en general, y la autoridad central (Verisign es una, para nuestro ejemplo de HTTPS) se asegura de que la persona a la que está enviando el correo se compruebe. Lo hacen al no permitir tarjetas postales (credenciales sin cifrar); en su lugar, exigen sobres reales.
Finalmente, veamos SSH. Aquí, la configuración es un poco diferente. No tenemos un autenticador central aquí, pero las cosas aún están seguras. Eso se debe a que le envía cartas a alguien cuya dirección ya conoce (por ejemplo, al conversar con ellos por teléfono) y está utilizando algunas matemáticas muy sofisticadas para firmar el sobre. Se lo entrega a su hermano, novia, papá o hija para que lo lleve a la dirección, y solo si las coincidencias matemáticas elegantes del destinatario asumen que la dirección es la que debería ser. Luego, recibes una carta de vuelta, también protegida de miradas indiscretas por esta increíble matemática. Por último, envía sus credenciales en otro sobre secreto encantado algorítmicamente al destino. Si las matemáticas no coinciden, podemos suponer que el destinatario original se mudó y necesitamos confirmar su dirección nuevamente.
Con la explicación tan larga como sea, creemos que lo cortaremos ahí. Si tiene más información, no dude en chatear en los comentarios, por supuesto. Por ahora, sin embargo, veamos la característica más relevante de SSH, la autenticación de host.
Llaves de host
La autenticación de host es esencialmente la parte en la que alguien de su confianza toma el sobre (sellado con matemáticas mágicas) y confirma la dirección de su destinatario. Es una descripción bastante detallada de la dirección y se basa en algunas matemáticas complicadas que simplemente pasaremos por alto. Sin embargo, hay un par de cosas importantes que se pueden extraer de esto:
- Dado que no existe una autoridad central, la seguridad real radica en la clave del host, las claves públicas y las claves privadas. (Estas dos últimas claves se configuran cuando se le da acceso al sistema).
- Por lo general, cuando se conecta a otra computadora a través de SSH, se almacena la clave de host. Esto hace que las acciones futuras sean más rápidas (o menos detalladas).
- Si cambia la clave de host, lo más probable es que reciba una alerta y ¡debe tener cuidado!
Dado que la clave de host se usa antes de la autenticación para establecer la identidad del servidor SSH, debe asegurarse de verificar la clave antes de conectarse. Verá un cuadro de diálogo de confirmación como el siguiente.
¡Sin embargo, no debería preocuparse! A menudo, cuando la seguridad es un problema, habrá un lugar especial donde se puede confirmar la clave de host (huella digital ECDSA arriba). En empresas completamente en línea, a menudo será en un sitio seguro de solo inicio de sesión. Es posible que deba (¡o elija!) Llamar a su departamento de TI para confirmar esta clave por teléfono. Incluso he oído hablar de algunos lugares donde la llave está en su placa de trabajo o en la lista especial de "Números de emergencia". Y, si tiene acceso físico a la máquina de destino, ¡también puede comprobarlo usted mismo!
Comprobación de la clave de host de su sistema
Hay 4 tipos de algoritmos de cifrado que se utilizan para crear claves, pero el valor predeterminado para OpenSSH a principios de este año es ECDSA ( con buenas razones ). Nos centraremos en eso hoy. Este es el comando que puede ejecutar en el servidor SSH al que tiene acceso:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Su salida debería devolver algo como esto:
256 ца: 62: еа: щц: еч: яй: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
El primer número es la longitud de bits de la clave, luego es la clave en sí, y finalmente tiene el archivo en el que está almacenado. Compare esa parte del medio con lo que ve cuando se le pide que inicie sesión de forma remota. Debe coincidir y ya está todo listo. Si no es así, entonces podría estar sucediendo algo más.
Puede ver todos los hosts a los que se ha conectado a través de SSH mirando su archivo known_hosts. Suele estar ubicado en:
~ / .ssh / hosts_conocidos
Puede abrir eso en cualquier editor de texto. Si miras, intenta prestar atención a cómo se almacenan las claves. Se almacenan con el nombre de la computadora host (o dirección web) y su dirección IP.
Cambio de claves de host y problemas
Hay algunas razones por las que las claves de host cambian o no coinciden con lo que está registrado en su archivo known_hosts.
- El sistema fue reinstalado / reconfigurado.
- Las claves de host se cambiaron manualmente debido a los protocolos de seguridad.
- El servidor OpenSSH se actualizó y utiliza diferentes estándares debido a problemas de seguridad.
- La concesión de IP o DNS cambió. A menudo, esto significa que está intentando acceder a una computadora diferente.
- El sistema se vio comprometido de alguna manera, por lo que la clave del host cambió.
Lo más probable es que el problema sea uno de los tres primeros y puede ignorar el cambio. Si la concesión de IP / DNS cambió, es posible que haya un problema con el servidor y es posible que se le envíe a una máquina diferente. Si no está seguro de cuál es el motivo del cambio, probablemente debería asumir que es el último de la lista.
Cómo OpenSSH maneja hosts desconocidos
OpenSSH tiene una configuración para cómo maneja hosts desconocidos, reflejada en la variable "StrictHostKeyChecking" (sin comillas).
Dependiendo de su configuración, las conexiones SSH con hosts desconocidos (cuyas claves aún no están en su archivo known_hosts) pueden ser de tres maneras.
- StrictHostKeyChecking se establece en no; OpenSSH se conectará automáticamente a cualquier servidor SSH independientemente del estado de la clave del host. Esto es inseguro y no se recomienda, excepto si está agregando un montón de hosts después de una reinstalación de su sistema operativo, después de lo cual lo volverá a cambiar.
- StrictHostKeyChecking está configurado para preguntar; OpenSSH le mostrará nuevas claves de host y le pedirá confirmación antes de agregarlas. Evitará que las conexiones vayan a claves de host modificadas. Este es el predeterminado.
- StrictHostKeyChecking se establece en yes; Lo contrario de "no", esto evitará que se conecte a cualquier host que no esté ya presente en su archivo known_hosts.
Puede cambiar esta variable fácilmente en la línea de comandos utilizando el siguiente paradigma:
ssh -o 'StrictHostKeyChecking [option]' usuario @ host
Reemplace [option] con "no", "preguntar" o "sí". Tenga en cuenta que hay comillas simples rectas alrededor de esta variable y su configuración. También reemplace usuario @ host con el nombre de usuario y el nombre de host del servidor al que se está conectando. Por ejemplo:
ssh -o 'StrictHostKeyChecking ask' [email protected]
Hosts bloqueados debido a cambios de claves
Si tiene un servidor al que está intentando acceder que ya tenía su clave cambiada, la configuración predeterminada de OpenSSH le impedirá acceder a él. Podrías cambiar el valor de StrictHostKeyChecking para ese host, pero eso no sería total, exhaustivo y paranoico seguro, ¿verdad? En su lugar, podemos simplemente eliminar el valor ofensivo de nuestro archivo known_hosts.
Definitivamente es algo desagradable tenerlo en la pantalla. Afortunadamente, nuestra razón de esto fue un sistema operativo reinstalado. Entonces, acerquemos la línea que necesitamos.
Aquí vamos. ¿Ves cómo cita el archivo que necesitamos editar? ¡Incluso nos da el número de línea! Entonces, abramos ese archivo en Nano:
Aquí está nuestra tecla ofensiva, en la línea 1. Todo lo que tenemos que hacer es presionar Ctrl + K para cortar toda la línea.
¡Eso está mucho mejor! Entonces, ahora presionamos Ctrl + O para escribir (guardar) el archivo, luego Ctrl + X para salir.
Ahora, en su lugar, obtenemos un mensaje agradable, al que simplemente podemos responder con un "sí".
Creación de nuevas claves de host
Para que conste, realmente no hay muchas razones para que cambie la clave de host, pero si alguna vez encuentra la necesidad, puede hacerlo fácilmente.
Primero, cambie al directorio del sistema apropiado:
cd / etc / ssh /
Aquí es generalmente donde están las claves de host globales, aunque algunas distribuciones las colocan en otro lugar. ¡En caso de duda, consulte su documentación!
A continuación, borraremos todas las claves antiguas.
sudo rm / etc / ssh / ssh_host_ *
Alternativamente, es posible que desee moverlos a un directorio de respaldo seguro. ¡Solo un pensamiento!
Luego, podemos decirle al servidor OpenSSH que se reconfigure:
sudo dpkg-reconfigure openssh-server
Verás un mensaje mientras tu computadora crea sus nuevas claves. ¡Ta-da!
Ahora que sabe cómo funciona SSH un poco mejor, debería poder salir de situaciones difíciles. La advertencia / error "La identificación del host remoto ha cambiado" es algo que desconcierta a muchos usuarios, incluso a aquellos que están familiarizados con la línea de comandos.
Para obtener puntos de bonificación, puede consultar Cómo copiar archivos de forma remota a través de SSH sin ingresar su contraseña . Allí, aprenderá un poco más sobre los otros tipos de algoritmos de cifrado y cómo usar archivos clave para mayor seguridad.
