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

Tabla de contenido:

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

Video: Aprenda las entradas y salidas de OpenSSH en su PC con Linux
Video: 🍅 Cómo aportar GRATIS CALCIO a TOMATERAS + consejos para evitar la PODREDUMBRE APICAL || en20metros 2024, Marcha
Aprenda las entradas y salidas de OpenSSH en su PC con Linux
Aprenda las entradas y salidas de OpenSSH en su PC con Linux
Anonim
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.
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

Hemos mencionado muchas veces cómo SSH es una excelente manera de conectar y canalizar datos de un punto a otro de manera segura. 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 la 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!
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 la 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 tarjetas 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 lo que está en el medio.

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.

Image
Image

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 algunos cálculos 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 asumen 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ías tus credenciales en otro sobre secreto encantado de forma algorítmica 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, siempre y cuando sea, creemos que la cortaremos allí. Si tiene más información, siéntase libre de chatear 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 matemáticos complicados que simplemente omitiremos. Hay un par de cosas importantes que quitar de esto, sin embargo:

  1. 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).
  2. 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).
  3. Si la clave del host cambia, lo más probable es que se le avise y debe tener 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 donde se confirmará la clave del host (la huella digital 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 tecla por teléfono. Incluso he oído hablar de algunos lugares donde la clave está en su tarjeta 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!
¡Pero no debes preocuparte! A menudo, cuando la seguridad es un problema, habrá un lugar especial donde se confirmará la clave del host (la huella digital 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 tecla por teléfono. Incluso he oído hablar de algunos lugares donde la clave está en su tarjeta 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

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 del medio con lo que ve cuando se le solicita que inicie sesión de forma remota. Debería coincidir, y ya está todo listo. Si no lo hace, entonces algo más podría estar sucediendo.

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á utilizando diferentes estándares debido a problemas de seguridad.
  • La concesión de IP o DNS cambió. Esto a menudo significa que está 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

Image
Image

OpenSSH tiene una configuración de cómo maneja hosts desconocidos, que se refleja 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 grupo 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 pasen a las claves de host modificadas. Este es el valor predeterminado.
  • StrictHostKeyChecking se establece en sí; Al contrario de "no", esto evitará que se conecte a cualquier host que aún 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 [option]' user@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 tienes un servidor al que intentas acceder y su clave ya ha cambiado, la configuración predeterminada de OpenSSH evitará que accedas a él. Podría cambiar el valor de StrictHostKeyChecking para ese host, pero eso no sería del todo seguro, completamente paranoico, ¿verdad? En su lugar, simplemente podemos eliminar el valor ofensivo de nuestro archivo conocido_hosts.

Eso definitivamente es algo feo para tener en tu pantalla. Afortunadamente, nuestra razón para esto fue un sistema operativo reinstalado. Entonces, ampliemos la línea que necesitamos.
Eso definitivamente es algo feo para tener en tu pantalla. Afortunadamente, nuestra razón para esto fue un sistema operativo reinstalado. Entonces, ampliemos 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í 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:
Image
Image
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.
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.
¡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í".

Image
Image

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 revisa tu 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á un aviso mientras su computadora crea sus nuevas claves. ¡Ta-da!

Image
Image

Ahora que sabe cómo SSH funciona un poco mejor, debería poder salir de los 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.

Para obtener puntos de bonificación, puede consultar Cómo copiar archivos a través de SSH de forma remota sin ingresar su contraseña. Allí, aprenderá un poco más acerca de los otros tipos de algoritmos de cifrado y cómo usar los archivos clave para mayor seguridad.

Recomendado: