9.2. Inicio de sesión remoto

Es esencial para el administrador poder conectarse a un equipo de forma remota. Los servidores, aislados en su propia habitación, rara vez están equipados con monitores y teclados permanentes — pero están conectados a la red.

9.2.1. Inicio seguro de sesión remota: SSH

El protocolo SSH (interprete de órdenes seguro: «Secure SHell») fue diseñado pensando en la seguridad y la confiabilidad. Las conexiones que utilizan SSH son seguras: la otra parte es autenticada y se cifran todos los datos intercambiados.

VOCABULARIO Autenticación, cifrado

Cuando necesita proveerle a un cliente la capacidad de realizar o desencadenar acciones en un servidor, la seguridad es importante. Debe asegurar la identidad del cliente; esto es autenticación. Esta identidad generalmente consisten en una constraseña que debe mantenerse en secreto o cualquier otro cliente podría obtener la contraseña. Este es el propósito del cifrado, que es una forma de codificación que permite a dos sistemas intercambiar información confidencial en un canal público al mismo tiempo que la protege de que otros la puedan leer.

Frecuentemente se nombran a la autenticación y al cifrado en conjunto, tanto porque se los utiliza a ambos como porque generalmente son implementados con conceptos matemáticos similares.

SSH también ofrece dos servicios de transferencia de archivos. scp es una herramienta para la terminal que puede utilizar como cp excepto que cualquier ruta a otro equipo utilizará un prefijo con el nombre de la máquina seguido de dos puntos («:»).

$ scp archivo equipo:/tmp/

sftp es un programa interactivo similar a ftp. En una sola sesión sftp puede transferir varios archivos y es posible manipular archivos remotos con él (eliminar, renombrar, cambiar permisos, etc.).

Debian utiliza OpenSSH, una versión libre de SSH mantenida por el proyecto OpenBSD (un sistema operativo libre basado en el núcleo BSD enfocado en seguridad) que es una bifurcación («fork») del software SSH original desarrollado por la empresa SSH Communications Security Corp de Finlandia. Esta empresa inicialmente desarrolló SSH como software libre pero eventualmente decidió continuar su desarrollo bajo una licencia privativa. El proyecto OpenBSD luego creó OpenSSH para mentener una versión libre de SSH.

VOLVER A LOS CIMIENTOS Bifurcación: «fork»

Una bifurcación («fork»), en el campo de software, significa que comienza un nuevo proyecto como clon de un proyecto existente y que competirá con él. Desde allí, ambos programas generalmente divergirán rápidamente en términos de nuevos desarrollos. Por lo general son un resultado de desacuerdos dentro del equipo de desarrollo.

La opción de bifurcar un proyecto es un resultado directo de la naturaleza misma del software libre; es un evento saludable cuando permite la continuación de un proyecto como software libre (por ejemplo, en el caso de cambios de licencia). Una bifurcación generada por desacuerdos técnicos o personales usualmente es un desperdicio de recursos; se prefiere otra solución. También ocurren fusiones de dos proyectos que anteriormente habían bifurcado.

OpenSSH está dividido en dos paquetes: la parte del cliente se encuentra en el paquete openssh-client y el servidor en el paquete openssh-server. El metapaquete ssh depende de ambas partes y facilita la instalación conjunta (apt install ssh).

9.2.1.1. Autenticación basada en llaves

Cada vez que alguien inicia sesión a través de SSH, el servidor remoto pide una contraseña para autenticar al usuario. Esto puede ser problemático si desea automatizar la conexión o si utiliza una herramienta que necesita conexiones frecuentes sobre SSH. Es por esto que SSH ofrece un sistema de autenticación basada en llaves.

El usuario genera un par de llaves en la máquina cliente con ssh-keygen -t rsa; la llave pública se almacena en ~/.ssh/id_rsa.pub mientras que la llave privada correspondiente estará almacenada en ~/.ssh/id_rsa. Luego, el usuario utiliza ssh-copy-id servidor para agregar su llave pública al archivo ~/.ssh/authorized_keys en el servidor. Si no se protegió la llave privada con una «frase de contraseña» al momento de crearla, todos los inicios de sesión siguientes al servidor funcionarán sin contraseña. De lo contrario, debe descifrar la llave privada cada vez ingresando la frase de contraseña. Afortunadamente, ssh-agent permite mantener llaves privadas en memoria para no tener que ingresar la frase de contraseña regularmente. Para ello, simplemente utilizaría ssh-add (una vez por sesión de trabajo) siempre que la sesión ya esté asociada con una instancia funcional de ssh-agent. De forma predeterminada, Debian activa este comportamiento en sesiones gráficas pero lo puede desactivar cambiando el archivo /etc/X11/Xsession.options. Para una sesión en consola, puede iniciarlo manualmente con eval $(ssh-agent).

SEGURIDAD Protección de la llave privada

Quien posea la llave privada puede iniciar sesión con la cuenta configurada. Es por esto que se protege la llave privada con una «frase de contraseña». Quien obtenga una copia del archivo de la llave privada (por ejemplo, ~/.ssh/id_rsa) todavía tendrá que saber dicha frase para poder intentar utilizarla. Sin embargo, esta protección adicional no es infalible y es mejor deshabilitar la llave en aquellos equipos en las que la instaló (eliminándola de los archivos authorized_keys) y reemplazándola con una nueva llave que haya generado.

CULTURA Falla OpenSSL en Debian Etch

La biblioteca OpenSSL, como fue provista inicialmente en Debian Etch, tenía un serio problema en su generador de números aleatorios (RNG: «Random Number Generator»). El desarrollador Debian había realizado una modificación para que los programas que la utilizan no generaran advertencias mientras eran objetivo de análisis por herramientas de pruebas de memoria como valgrind. Desafortunadamente, este cambio también significaba que el RNG sólo utilizaba una fuente de entropía que correspondía al número de proceso (PID); pero los 32000 valores posibles del mismo no ofrecen suficiente aleatoriedad.

→ http://www.debian.org/security/2008/dsa-1571

Específicamente, cuando utilizaba OpenSSL para generar una llave, siempre producía una llave dentro de un conjunto conocido de cientos de miles de llaves (32000 multiplicado por una pequeña cantidad de longitudes de llaves). Esto afectaba llaves SSH, llaves SSL y certificados X.509 utilizados por numerosas aplicaciones, como OpenVPN. Un «cracker» sólo debía intentar todas estas llaves para obtener un acceso no autorizado. Para reducir el impacto del problema, se modificó el demonio SSH para rechazar las llaves problemáticas incluidas en los paquetes openssh-blacklist y openssh-blacklist-extra. Además, el programa ssh-vulnkey permite identificar posibles llaves comprometidas en el sistema.

Un análisis más detallado de este problema resaltó que era el resultado de múltiples problemas (pequeños) del proyecto OpenSSL y del encargado del paquete Debian. Una biblioteca tan utilizada como OpenSSL no debería — sin modificaciones — generar advertencias cuando es probada con valgrind. Lo que es más, el código (especialmente las partes tan sensibles como el RNG) deberían tener mejores comentarios para evitar estos errores. Por parte de Debian, el encargado quería validar las modificaciones con los desarrolladores de OpenSSL, pero simplemente explicó las modificaciones sin proporcionar el parche correspondiente para su revisión y se olvidó de mencionar su papel en Debian. Por último, las decisiones de mantenimiento no fueron las óptimas: los cambios en el código original no estaban comentados de forma clara; todas las modificaciones fueron almacenadas en un repositorio Subversion, pero terminaron agrupadas en un sólo parche durante la creación del paquete fuente.

It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian sources webservice were developed.

→ http://sources.debian.org

9.2.1.2. Utilización aplicaciones X11 remotas

El protocolo SSH permite redirigir datos gráficos (sesión «X11» por el nombre del sistema gráfico más utilizado en Unix); el servidor luego mantiene un canal dedicado para estos datos. Específicamente, el programa gráfico ejecutado remotamente puede mostrarse en el servidor X.org de la pantalla local y toda la sesión (datos ingresados y lo que sea mostrado) será segura. De forma predeterminada, esta funcionalidad está desactivada porque permite que aplicaciones remotas interfieran con el sistema local. Puede activarla especificando X11Forwarding yes en el archivo de configuración del servidor (/etc/ssh/sshd_config). Finalmente, el usuario también debe solicitarlo agregando la opción -X al ejecutar ssh.

9.2.1.3. Creación de túneles cifrados con redirección de puertos

Las opciones -R y -L le permiten a ssh crear «túneles cifrados» entre dos equipos, redirigiendo de forma segura un puerto TCP local (revise el recuadro VOLVER A LOS CIMIENTOS TCP/UDP) a un equipo remoto o viceversa.

VOCABULARIO Túnel

Internet, y la mayoría de las redes de área local conectadas a ella, funcionan bajo conmutación de paquetes y no bajo conmutación de circuitos, lo que significa que un paquete enviado de un equipo a otro será detenido en varios routers intermedios para encontrar su ruta al destino. Todavía puede simular el modo de conexión en el que el flujo esté encapsulado en paquetes IP normales. Estos paquetes siguen su ruta usual pero se reconstruye el flujo sin cambios en el destino. A esto le llamamos un «túnel», el análogo a un túnel vial en el que los vehículos conducen directamente desde la entrada a la salida sin encontrase con intersección alguna a diferencia de una ruta en la superficie que involucraría intersecciones y cambios de dirección.

Puede utilizar esta oportunidad para agregar cifrado al túnel: así el flujo del mismo no puede ser reconocido desde el exterior, pero al salir del túnel se encuentra descifrado.

ssh -L 8000:servidor:25 intermediario establece una sesión SSH con el equipo intermediario y escucha en el puerto local 8000 (revise la Figura 9.3, “Redirección de un puerto local con SSH”). Para cualquier conexión en este puerto, ssh iniciará una conexión desde el equipo intermediario al puerto 25 de servidor y unirá ambas conexiones.

ssh -R 8000:servidor:25 intermediario también establece una sesión SSH al equipo intermediario, pero es en este equipo que ssh escuchará en el puerto 8000 (revise la Figura 9.4, “Redirección de un puerto remoto con SSH”). Cualquier conexión establecida en este puerto causará que ssh abra una conexión desde el equipo local al puerto 25 de servidor y unirá ambas conexiones.

En ambos casos, se realizan las conexiones en el puerto 25 del equipo servidor, que pasarán a través del túnel SSH establecido entre la máquina local y la máquina intermediario. En el primer caso, la entrada al túnel es el puerto local 8000 y los datos se mueven hacia la máquina intermediario antes de dirigirse a servidor en la red «pública». En el segundo caso, la entrada y la salida del túnel son invertidos; la entrada es en el puerto 8000 de la máquina intermediario, la salida es en el equipo local y los datos son dirigidos a servidor. En la práctica, el servidor generalmente está en la máquina local o el intermediario. De esa forma SSH asegura la conexión un extremo a otro.

Figura 9.3. Redirección de un puerto local con SSH

Figura 9.4. Redirección de un puerto remoto con SSH

9.2.2. Utilización de escritorios gráficos remotos

VNC (computación en redes virtuales: «Virtual Network Computing») permite el acceso remoto a escritorios gráficos.

Esta herramienta se utiliza más que nada para asistencia técnica; el administrador puede ver los errores con los que se enfrenta el usuario y mostrarle el curso de acción correcto sin tener que estar a su lado.

First, the user must authorize sharing their session. The GNOME graphical desktop environment in Jessie includes that option in its configuration panel (contrary to previous versions of Debian, where the user had to install and run vino). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc command (from the Debian package of the same name) serves the same purpose; you can make it available to the user with an explicit icon.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xvnc4viewer in the Debian package of the same name. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

SEGURIDAD VNC sobre SSH

Si desea conectarse con VNC y no desea que se envíen sus datos en texto plano a través de la red, es posible encapsular los datos en un túnel SSH (revise la Sección 9.2.1.3, “Creación de túneles cifrados con redirección de puertos”). Simplemente tiene que saber que, de forma predeterminada, VNC utiliza el puerto 5900 para la primera pantalla (llamada «localhost:0»), 5901 para la segunda (llamada «localhost:1»), etc.

La orden ssh -L localhost:5901:localhost:5900 -N -T equipo crea un túnel entre el puerto local 5901 en la interfaz de «localhost» y el puerto 5900 de equipo. La primera ocurrencia de «localhost» restringe a SSH para que sólo escuche en dicha interfaz en la máquina local. El segundo «localhost» indica que la interfaz en la máquina remota que recibirá el tráfico de red que ingrese en «localhost:5901». Por lo tanto, vncviewer localhost:1 conectará el cliente VNC a la pantalla remota aún cuando indique el nombre de la máquina local.

Cuando cierre la sesión VNC, recuerde también cerrar el túnel saliendo de la sesión SSH correspondiente.

VNC también funciona para usuarios móviles o ejecutivos de empresas que ocasionalmente necesitan iniciar sesión desde sus casas para acceder a un escritorio remoto similar al que utilizan en la oficina. La configuración de tal servicio es más complicada: primero instale el paquete vnc4server, modifique la configuración del gestor de pantalla para aceptar pedidos XDMCP Query (en gdm3 puede hacerlo agregando Enable=true en la sección «xdmcp» del archivo /etc/gdm3/daemon.conf). Finalmente, inicie el servidor VNC con inetd para que se inicie una sesión automáticamente cuando el usuario intente hacerlo. Por ejemplo, puede agregar la siguiente línea al archivo /etc/inetd.conf:

5950  stream  tcp  nowait  nobody.tty  /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none

Redireccionar las conexiones entrantes al gestor de pantallas soluciona el problema de la autenticación ya que sólo los usuarios con cuentas locales pasarán la pantalla de inicio de sesión de gdm3 (o su equivalente kdm, xdm, etc.). Como esta operación permite múltiples sesiones simultáneamente sin problemas (siempre que el servidor sea suficientemente poderoso), incluso puede ser utilizada para proveer escritorios completos para usuarios móviles (o sistemas de escritorios menos potentes configurados como clientes ligeros). Los usuarios simplemente iniciarán sesión en la pantalla del servidor con vncviewer servidor:50 ya que utiliza el puerto 5950.