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

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

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 is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

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.

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with 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.

→ https://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.

Bajo tales condiciones es difícil encontrar las medidas correctivas para evitar que ocurran incidentes similar. La lección a aprender aquí es que cada divergencia que Debian introduce al software de origen debe estar justificada, documentad, debe ser enviada al proyecto de origen cuando sea posible y publicitada ampliamente. Es desde esta perspectiva que se desarrollaron el nuevo formato de paquete fuente («3.0 (quilt)») y el servicio web de código fuente de Debian.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Sección 10.2.2, “Infraestructura de llave pública: easy-rsa”) by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Both, public key and certificate authentication, can be used alongside each other.

9.2.1.3. 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.

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

9.2.1.4. 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 includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

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 xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. 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.4, “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.