Aprenda las entradas y salidas de OpenSSH en su PC con Linux

Hemos ensalzado las virtudes de SSH varias veces, 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 turbulencia a un viaje por lo demás suave.

Si bien hemos escrito esta guía con Linux en mente, esto también puede aplicarse a OpenSSH en Mac OS X y Windows 7 a través de Cygwin.

Por qué es seguro

Muchas veces hemos mencionado cómo SSH es una excelente manera de conectar y canalizar datos de manera segura de un punto a otro. Veamos brevemente cómo funcionan las cosas para tener una mejor idea de por qué las cosas pueden volverse raras a veces..

Cuando decidimos iniciar una conexión a otra computadora, a menudo usamos protocolos con los que es fácil trabajar. Telnet y FTP vienen a la mente. Enviamos información a un servidor remoto y luego recibimos una confirmación de nuestra conexión. Para establecer algún tipo de seguridad, estos protocolos a menudo utilizan combinaciones de nombre de usuario y contraseña. Eso significa que están totalmente seguros, ¿verdad? Incorrecto!

Si consideramos 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 pasa por 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, mantener la información igual y hacerse pasar por un corresponsal u otro. Esto se conoce como un ataque "man-in-the-middle", y no solo compromete su cuenta, sino que pone en tela de juicio todos y cada uno de los mensajes enviados y 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 entre.

Ahora, veamos el cifrado SSL, el tipo que hace que HTTP sea más seguro. Aquí, tenemos una oficina postal 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. En general, es más seguro, y la autoridad central (Verisign es uno de ellos, para nuestro ejemplo de HTTPS) se asegura de que la persona a la que está enviando el correo se retire. Lo hacen al no permitir tarjetas postales (credenciales sin cifrar); en su lugar mandan sobres reales.

Por último, echemos un vistazo a SSH. Aquí, la configuración es un poco diferente. No tenemos un autenticador central aquí, pero las cosas siguen siendo seguras. Esto se debe a que le está enviando cartas a alguien cuya dirección ya conoce, por ejemplo, conversando con ellos por teléfono, y está utilizando algunas matemáticas muy elegantes para firmar su sobre. Se lo entregas a tu hermano, novia, papá o hija para que lo lleven a la dirección, y solo si las suposiciones de matemáticas del destinatario suponen que la dirección es la que debería ser. Entonces, recibes una carta de vuelta, también protegida de miradas indiscretas por esta asombrosa matemática. Finalmente, envía sus credenciales en otro sobre secreto y con algoritmos encantados al destino. Si las cuentas no coinciden, podemos suponer que el destinatario original se movió y debemos confirmar su dirección nuevamente.

Con la explicación mientras sea, creemos que la cortaremos allí. Si tiene más información, no dude en conversar en los comentarios, por supuesto. Por ahora, sin embargo, veamos la característica más relevante de SSH, la autenticación de host.

Teclas de host

La autenticación del host es esencialmente la parte en la que alguien de confianza toma el sobre (sellado con magia matemática) y confirma la dirección de su destinatario. Es una descripción bastante detallada de la dirección, y se basa en algunos cálculos complicados que simplemente omitiremos. Hay un par de cosas importantes que quitar de esto, sin embargo:

Como no existe una autoridad central, la seguridad real reside en la clave del host, las claves públicas y las claves privadas. (Estas dos últimas teclas se configuran cuando se le da acceso al sistema).
Por lo general, cuando se conecta a otra computadora a través de SSH, la clave del host se almacena. Esto hace que las acciones futuras sean más rápidas (o menos detalladas).
Si la clave del host cambia, lo más probable es que se le avise y tenga cuidado.!

Como 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ás un diálogo de confirmación como el de abajo..

¡Pero no debes preocuparte! A menudo, cuando la seguridad es un problema, habrá un lugar especial en el que se puede confirmar la clave del host (la huella digital de ECDSA anterior). En las empresas totalmente en línea, a menudo será en un sitio de inicio de sesión seguro. Es posible que tenga que (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 clave 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 por sí mismo.!

Comprobación de la clave de host de su sistema

Existen 4 tipos de algoritmos de cifrado utilizados para crear claves, pero el valor predeterminado para OpenSSH a principios de este año es ECDSA (con algunas buenas razones). Nos centraremos en eso hoy. Aquí está el comando que puede ejecutar en el servidor SSH al que tiene acceso:

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

Tu salida debería devolver algo como esto:

256 ca: 62: ea: 7c: e4: 9e: 2e: a6: 94: 20: 11: db: 9c: 78: c3: 4c /etc/ssh/ssh_host_ecdsa_key.pub

El primer número es la longitud de bits de la clave, luego es la clave en sí misma y, finalmente, tiene el archivo en el que está almacenado. Compare esa parte intermedia con lo que ve cuando se le solicita 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 conocido_hosts. Por lo general se encuentra en:

~ / .ssh / known_hosts

Puedes abrirlo en cualquier editor de texto. Si miras, trata de prestar atención a cómo se almacenan las claves. Se almacenan con el nombre del equipo host (o dirección web) y su dirección IP.

Cambio de claves de host y problemas

Existen algunas razones por las que las claves del host cambian o no coinciden con lo que se registra en su archivo conocido_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 está usando diferentes estándares debido a problemas de seguridad.
La concesión de IP o DNS cambió. Esto a menudo significa que estás intentando acceder a una computadora diferente.
El sistema fue comprometido de alguna manera tal que la clave de 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ó, entonces puede haber un problema con el servidor y puede ser enrutado a una máquina diferente. Si no está seguro de cuál es el motivo del cambio, entonces probablemente debería asumir que es el último de la lista..

Cómo OpenSSH maneja hosts desconocidos

OpenSSH tiene una configuración de 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 conocido) son 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 las claves de host modificadas. Este es el predeterminado.
StrictHostKeyChecking se establece en sí; Al contrario de "no", esto evitará que se conecte a cualquier host que no esté presente en su archivo conocido_hosts.

Puede cambiar esta variable fácilmente en la línea de comandos usando el siguiente paradigma:

ssh -o 'StrictHostKeyChecking [opción]' usuario @ host

Reemplace [opción] con "no", "preguntar" o "sí". Tenga en cuenta que hay comillas simples y rectas alrededor de esta variable y su configuración. También reemplace user @ 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 llaves modificadas

Si tiene un servidor al que intenta acceder y su clave ya ha cambiado, la configuración predeterminada de OpenSSH le impedirá acceder. Podría cambiar el valor de StrictHostKeyChecking para ese host, pero eso no sería del todo seguro, ni paranoico, ¿verdad? En su lugar, simplemente podemos eliminar el valor ofensivo de nuestro archivo conocido_hosts.

Eso es definitivamente una cosa fea para tener en tu pantalla. Por suerte, nuestra razón para esto fue un sistema operativo reinstalado. Por lo tanto, vamos a ampliar 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, vamos a abrir ese archivo en Nano:

Aquí está nuestra clave ofensiva, en la línea 1. Todo lo que necesitamos 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 tenemos un buen indicador en su lugar, al que simplemente podemos responder con un "sí".

Creación de nuevas claves de host

Para que conste en acta, realmente no hay demasiada razón para que cambie su clave de host, pero si alguna vez encuentra la necesidad, puede hacerlo fácilmente..

Primero, cambie al directorio del sistema apropiado:

cd / etc / ssh /

Por lo general, aquí es donde se encuentran las claves de host globales, aunque algunas distribuciones las colocan en otro lugar. En caso de duda consulte su documentación.!

A continuación, eliminaremos todas las claves antiguas..

sudo rm / etc / ssh / ssh_host_ *

Como alternativa, puede moverlos a un directorio de respaldo seguro. Solo un pensamiento!

Entonces, podemos decirle al servidor OpenSSH que se reconfigure a sí mismo:

sudo dpkg-reconfigure openssh-server

Verás un aviso mientras tu computadora crea sus nuevas claves. Ta-da!

Ahora que sabe cómo SSH funciona un poco mejor, debería poder salir de lugares difíciles. La advertencia / error “La identificación del host remoto ha cambiado” es algo que despierta a muchos usuarios, incluso a aquellos que están familiarizados con la línea de comandos.