4.2. SSH: operaciones de red seguras

Dado el creciente número de equipos instalados en entornos de red, a menudo es preciso acceder a los hosts desde una ubicación remota, lo que normalmente conlleva que el usuario envíe cadenas de inicio de sesión y de contraseña con fines de autenticación. Si esas cadenas se transmiten como texto sin formato, pueden ser interceptadas y usadas de forma fraudulenta para acceder a la cuenta de ese usuario sin que el usuario autorizado ni siquiera tenga constancia de ello. Aparte del hecho de que de este modo el atacante tendría libre acceso a todos los archivos del usuario, la cuenta fraudulenta se podría utilizar para obtener acceso de administrador o de usuario Root o para acceder a otros sistemas. En el pasado, las conexiones remotas se establecían a través de telnet, que no ofrece garantías contra el acceso no autorizado mediante el cifrado ni ningún otro mecanismo de seguridad. Existen otros canales de comunicación no protegida, como el protocolo FTP tradicional y algunos programas de copia remotos.

El paquete SSH proporciona la protección necesaria mediante el cifrado de las cadenas de autenticación (por lo general, un nombre de inicio de sesión y una contraseña) y de todos los demás datos que se intercambian entre los hosts. Con SSH, los usuarios externos pueden seguir registrando el flujo de los datos, pero el contenido se cifra y no se puede convertir a texto sin formato a menos que se conozca la clave de cifrado. Por tanto, SSH habilita la comunicación segura en redes no seguras, como Internet. El tipo de SSH que acompaña a SUSE Linux es OpenSSH.

4.2.1. Paquete OpenSSH

Con SUSE Linux se instala el paquete OpenSSH por defecto. Con él, los programas ssh, scp y sftp están disponibles como alternativas de telnet, rlogin, rsh, rcp y ftp. En la configuración por defecto, el acceso al sistema en SUSE Linux sólo es posible mediante las utilidades de OpenSSH y únicamente si el cortafuegos lo permite.

4.2.2. Programa ssh

Gracias al programa ssh, es posible iniciar la sesión en sistemas remotos y trabajar de modo interactivo. Sustituye tanto a telnet como a rlogin. El programa slogin es sólo un enlace simbólico que señala a ssh. Por ejemplo, se puede iniciar la sesión en un host llamado sun con el comando ssh sun. El host solicita entonces la contraseña para el host sun.

Una vez que se autentique correctamente, podrá trabajar en la línea de comandos remota o utilizar aplicaciones interactivas, como YaST. Si el nombre de usuario local es distinto del remoto, puede iniciar la sesión con un nombre de inicio de sesión distinto mediante ssh -l augustine sun o bien ssh augustine@sun.

Además, ssh ofrece la posibilidad de ejecutar comandos en sistemas remotos, igual que con rsh. En el siguiente ejemplo, se ejecuta el comando uptime en el host sun y se crea un directorio denominado tmp. La salida del programa se muestra en el terminal local del host earth.

ssh otherplanet "uptime; mkdir tmp" 
tux@otherplanet's password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Las comillas son precisas para enviar ambas instrucciones con un comando. Sólo así se consigue que el segundo comando se ejecute en el host sun.

4.2.3. scp: copia segura

scp permite copiar archivos a un equipo remoto. Constituye una alternativa segura y cifrada de rcp. Por ejemplo, con scp MiCarta.tex sun: se copia el archivo MiCarta.tex del host earth al host sun. Si el nombre de usuario del host earth es distinto del nombre de usuario del host sun, se debe especificar este último con el formato nombreusuario@host. Este comando no cuenta con la opción -l.

Una vez que se introduce la contraseña correcta, scp inicia la transferencia de datos y muestra una fila de asteriscos que va aumentando para simular una barra de progreso. Además, el programa muestra el tiempo estimado que queda para que se complete esa barra de progreso. Puede suprimir la salida incluyendo la opción -q.

scp proporciona también una función de copia reiterativa apropiada para directorios completos. Con el comando scp -r src/ sun:backup/ se copia todo el contenido del directorio src, incluidos todos los subdirectorios, al directorio backup del host sun. Si este directorio no existe, se crea automáticamente.

La opción -p indica a scp que debe mantener intacta la marca horaria de los archivos. Con la opción -C, se comprime la transferencia de datos. De este modo se reduce al mínimo el volumen de datos que se deben transferir, pero se genera una carga mayor en el procesador.

4.2.4. sftp: transferencia de archivos segura

El programa sftp se puede utilizar en lugar de scp para la transferencia de archivos segura. Durante una sesión de sftp se pueden utilizar muchos de los comandos de ftp conocidos. sftp puede ser más apropiado que scp, especialmente cuando se transfieren datos cuyos nombres de archivo se desconocen.

4.2.5. Daemon SSH (sshd): servidor

Para utilizar los programas de cliente SSH ssh y scp, se debe estar ejecutando en segundo plano un servidor, el daemon SSH, que debe estar a la escucha de las conexiones en el puerto TCP/IP 22. El daemon genera tres pares de claves cuando se inicia por primera vez. Cada par está integrado por una clave privada y una pública, por lo que se habla de este procedimiento como un procedimiento basado en claves públicas. Para garantizar la seguridad de la comunicación a través de SSH, se debe restringir el acceso a los archivos de claves privadas al administrador del sistema. Los permisos de archivo se definen convenientemente en la instalación por defecto. Las claves privadas se necesitan sólo de forma local para el daemon SSH y no se deben proporcionar a ningún otro usuario. Los componentes de claves públicas (reconocibles por la extensión de nombre .pub) se envían al cliente que solicita la conexión y pueden leerlos todos los usuarios.

El cliente SSH inicia una conexión. El daemon SSH a la espera y el cliente SSH solicitante intercambian datos de identificación para comparar las versiones del protocolo y del software y para impedir las conexiones a través de un puerto equivocado. Dado que a la solicitud responde un proceso secundario del daemon SSH original, se pueden establecer varias conexiones SSH al mismo tiempo.

Para la comunicación entre el servidor y el cliente SSH, OpenSSH es compatible con las versiones 1 y 2 del protocolo SSH. En los sistemas SUSE Linux que se hayan instalado recientemente, la versión por defecto es la 2. Para seguir utilizando la versión 1 después de actualizar, siga las instrucciones detalladas en /usr/share/doc/packages/openssh/README.SuSE. En ese documento se describe también la forma de transformar un entorno SSH 1 en un entorno SSH 2 en funcionamiento en unos pocos pasos.

Cuando se utiliza la versión 1 de SSH, el servidor envía su clave de host pública y una clave de servidor, que se genera en el daemon SSH cada hora. Ambas claves permiten que el cliente cifre una clave de sesión que se elige libremente y que se envía al servidor SSH. El cliente SSH indica además al servidor el método de cifrado que se debe utilizar.

La versión 2 del protocolo SSH no requiere una clave de servidor. En ambos extremos se emplea un algoritmo Diffie-Helman para intercambiar las claves.

Las claves de host privada y de servidor son absolutamente necesarias para descifrar la clave de sesión y no se pueden obtener a partir de las partes públicas. Sólo el daemon SSH con el que se contacta puede descifrar la clave de sesión utilizando sus claves privadas (consulte man /usr/share/doc/packages/openssh/RFC.nroff). Esta fase inicial de la conexión se puede vigilar de cerca activando la opción de depuración detallada -v del cliente SSH.

La versión 2 del protocolo SSH se utiliza por defecto. Se puede anular esta configuración y utilizar la versión 1 del protocolo con el conmutador -1. El cliente almacena todas las claves públicas del host en ~/.ssh/known_hosts, después de establecer el primer contacto con un host remoto. De esta forma se evitan los ataques por parte de intrusos: intentos de servidores SSH extraños de utilizar nombres y direcciones IP de suplantación. Este tipo de ataques se detectan mediante una clave de host que no está incluida en ~/.ssh/known_hosts o por la imposibilidad del servidor de descifrar la clave de sesión al no encontrarse la clave privada correspondiente adecuada.

Se recomienda guardar una copia de seguridad de las claves privadas y públicas almacenadas en /etc/ssh/ en una ubicación externa segura, con el fin de detectar modificaciones de las claves y volver a utilizar las anteriores después de realizar una instalación nueva. De este modo, se ahorra a los usuarios las advertencias perturbadoras. Si se comprueba que, a pesar de la advertencia, se trata en realidad del servidor SSH correcto, la entrada existente para el sistema se debe eliminar de ~/.ssh/known_hosts.

4.2.6. Mecanismos de autenticación de SSH

A continuación, tiene lugar la autenticación en sí, la cual, en su forma más básica, consiste en introducir una contraseña como se ha mencionado arriba. SSH obedece a la necesidad de introducir un software seguro que resulte además fácil de utilizar. Dado que está pensado para sustituir a rsh y a rlogin, SSH debe ser capaz también de proporcionar un método de autenticación adecuado para el uso cotidiano, lo que se consigue por medio de otro par de claves que genera el usuario. El paquete SSH proporciona un programa de ayuda para ello: ssh-keygen. Tras introducir ssh-keygen -t rsa o ssh-keygen -t dsa, se genera el par de claves y se pide al usuario que proporcione un nombre de archivo de base en el que almacenar las claves.

Confirme el ajuste por defecto y responda a la solicitud de contraseña codificada. Incluso cuando el software sugiere una contraseña codificada vacía, se recomienda utilizar un texto de una longitud comprendida entre 10 y 30 caracteres para el procedimiento descrito aquí. No utilice palabras o frases cortas y sencillas. Confirme la acción repitiendo la contraseña codificada. A continuación, verá la ubicación donde se almacenan las claves pública y privada. En este ejemplo, en los archivos id_rsa y id_rsa.pub.

Utilice ssh-keygen -p -t rsa o ssh-keygen -p -t dsa para cambiar la contraseña codificada anterior. Copie el componente de clave pública (id_rsa.pub en el ejemplo) en el equipo remoto y guárdelo en ~/.ssh/authorized_keys. Se le pedirá que se autentique con su contraseña codificada cuando vuelva a establecer una conexión. Si no es así, compruebe la ubicación y el contenido de esos archivos.

A la larga, este procedimiento resulta más engorroso que proporcionar la contraseña cada vez. Por eso, el paquete SSH proporciona otra herramienta, ssh-agent, que mantiene las claves privadas mientras dure una sesión X. La sesión X se inicia como un proceso secundario de ssh-agent. La forma más fácil de llevar a cabo este procedimiento consiste en definir la variable usessh al principio del archivo .xsession con el valor yes (sí) e iniciar la sesión mediante un gestor de pantalla, como KDM o XDM. Del mismo modo, también puede introducir ssh-agent startx.

En este momento, puede utilizar ssh o scp como de costumbre. Si ha distribuido su clave pública como se describe arriba, ya no se le solicitará la contraseña. Asegúrese de terminar la sesión X o de bloquearla con una aplicación de protección de contraseña, como xlock.

Todos los cambios pertinentes derivados de la introducción de la versión 2 del protocolo SSH están también documentados en el archivo /usr/share/doc/packages/openssh/README.SuSE.

4.2.7. Mecanismos X, de autenticación y remisión

Más allá de las mejoras relacionadas con la seguridad descritas anteriormente, SSH también simplifica el uso de aplicaciones X remotas. Si ejecuta ssh con la opción -X, la variable DISPLAY se define automáticamente en el equipo remoto y toda la salida de X se exporta al equipo remoto a través de la conexión SSH existente. Al mismo tiempo, las aplicaciones X que se inician de forma remota y se ven localmente con este método no pueden ser interceptadas por usuarios no autorizados.

Si se añade la opción -A, el mecanismo de autenticación de ssh-agent se transfiere a la siguiente máquina. De este modo, puede trabajar desde distintas máquinas sin necesidad de escribir la contraseña, pero sólo si ha distribuido su clave pública a los hosts de destino y la ha almacenado correctamente en ellos.

Ambos mecanismos están desactivados en los ajustes por defecto, pero se pueden activar de forma permanente en cualquier momento en el archivo de configuración del sistema, /etc/ssh/sshd_config, o en el del usuario, ~/.ssh/config.

ssh también se puede utilizar para redirigir conexiones TCP/IP. En los ejemplos siguientes, se le indica a SSH que debe redirigir el puerto SMTP y el puerto POP3, respectivamente:

ssh -L 25:sun:25 earth

Con este comando, cualquier conexión dirigida al puerto 25 (SMTP) del host earth se redirige al puerto SMTP del host sun a través de un canal cifrado. Esto resulta especialmente útil para quienes utilicen servidores SMTP sin las funciones SMTP-AUTH o POP antes de SMTP. Desde cualquier ubicación arbitraria conectada a una red, se puede transferir el correo electrónico al servidor de correo “personal” para su distribución. Del mismo modo, todas las solicitudes POP3 (puerto 110) del host earth se pueden remitir al puerto POP3 del host sun con este comando:

ssh -L 110:sun:110 earth

Ambos comandos se deben ejecutar como usuario Root, debido a que la conexión se establece con puertos locales que requieren privilegios. El correo electrónico se envía y se recupera por parte de los usuarios normales a través de una conexión SSH existente. Los hosts SMTP y POP3 se deben definir como localhost para que esto funcione. Para obtener información adicional, consulte las páginas Man de cada uno de los programas descritos arriba o los archivos incluidos en /usr/share/doc/packages/openssh.