En SUSE Linux, el paquete OpenSSH está incluido en la instalación estándar, por lo que dispondrá de los programas ssh, scp y sftp como alternativa a telnet, rlogin, rsh, rcp y ftp. En la configuración estándar, el acceso a un sistema SUSE Linux únicamente es posible con las herramientas OpenSSH y sólo en el caso de que el cortafuegos permita el acceso.

El programa ssh permite conectarse a un sistema de forma remota y trabajar con él interactivamente. Por este motivo constituye un sustituto tanto de telnet como rlogin. Por razones de parentesco con rlogin, el enlace simbólico adicional de nombre slogin apunta igualmente a ssh. Por ejemplo, con el comando ssh sun podremos registrarnos en el ordenador sun. Después de introducir el comando, se nos preguntará la contraseña en el sistema sun.

Después de haber conseguido una autenticación válida se podrá trabajar tanto desde la línea de comandos, por ejemplo con el comando ls, como de forma interactiva, por ejemplo con YaST. Si quiere diferenciar el nombre de usuario local del usuario en el sistema remoto, hágalo por ejemplo con ssh -l juan sun o bien con ssh juan@sun.

Además, ssh nos ofrece la posibilidad ya conocida en rsh de ejecutar comandos en un sistema remoto. En el siguiente ejemplo se ejecutará el comando uptime en el ordenador sun y se creará un directorio con el nombre tmp. Los resultados del programa se visualizarán en la terminal local del ordenador earth.

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

Las comillas son en este caso necesarias para unir los comandos. Sólo de esta forma se ejecutará también el segundo comando en el ordenador sun.

Con la ayuda de scp se pueden copiar archivos a un ordenador remoto. scp es un sustituto seguro y codificado de rcp. Por ejemplo con el comando: scp  MiCarta.tex sun: se copiará el archivo MiCarta.tex del ordenador earth al ordenador sun. En el caso de que los nombres de usuarios en earth y sun sean diferentes, en scp habrá que recurrir a escribir nombre_usuario@nombre_ordenador. No existe la opción -l.

Después de consultar la contraseña, scp comienza con la transmisión de datos e indica el avance mediante una barra formada por estrellas que crece de izquierda a derecha. Además se muestra en el lado derecho el tiempo restante para completar la transmisión (estimated time of arrival). La opción -q suprime todas las indicaciones en pantalla.

scp ofrece también la posibilidad de transferir de forma recursiva todo un directorio. El comando: scp  -r src/ sun:backup/ copia el contenido completo del directorio src/, incluyendo todos los subdirectorios, en el directorio backup/ en el ordenador sun. If el subdirectorio no existe todavía, se creará automáticamente.

Mediante la opción -p, scp mantiene fecha y hora de los archivos que se copian. Con -C se realiza una transferencia comprimida. Como ventaja el volumen de datos disminuye, pero en cambio el esfuerzo de cálculo es más elevado. Dada la potencia de cálculo de hoy en día, se puede despreciar este efecto negativo.

Otra posibilidad para la transferencia segura de archivos es sftp, que ofrece muchos de los comandos conocidos de ftp una vez que la conexión se ha establecido. En comparación con scp, resulta más adecuado para transferir archivos cuyos nombres no se conocen.

Para que se puedan utilizar los programas cliente ssh y scp, en segundo plano se debe ejecutar un servidor, el daemon SSH, que espera las conexiones en el puerto TCP/IP Port 22. Al iniciarse por primera vez, el daemon genera tres pares de claves que constan de una parte pública y una privada. Por este motivo este mecanismo se considera un proceso basado en “public-key”. Para garantizar la comunicación segura, sólo el administrador de sistema debe tener el derecho de acceder a las claves privadas. Por eso en la configuración predeterminada los derechos sobre los archivos se configuran de forma correspondiente. El daemon de SSH utiliza localmente las claves privadas que no deben ser comunicadas a nadie. En cambio, las partes públicas de las claves (se reconocen por ejemplo por la extensión .pub) se comunican a todos los interlocutores en el proceso de comunicación y son por tanto legibles para todos los usuarios.

El cliente SSH inicia la conexión. El daemon SSH que se encontraba en espera y el cliente que pide una conexión intercambian datos de identificación para utilizar las mismas versiones de protocolo y para evitar la conexión a un puerto equivocado. En realidad, el que responde es un “proceso hijo” del daemon SSH inicial, por lo que es posible mantener al mismo tiempo muchas conexiones SSH.

Para la comunicación entre el cliente y el servidor SSH, OpenSSH soporta las versiones 1 y 2 del protocolo SSH. Al instalar SUSE Linux por primera vez se utiliza automáticamente la versión actual del protocolo, 2. En cambio, si prefiere conservar SSH 1 después de actualizar, siga las instrucciones descritas en /usr/share/doc/packages/openssh/README.SuSE. Allí también se describe cómo transformar en pocos pasos un entorno SSH 1 en un entorno SSH 2 operativo.

Con el protocolo SSH versión 1, el servidor envía su clave pública host key y una server key creada el daemon SSH nuevamente cada hora. El cliente SSH se sirve de estas dos claves para codificar (encrypt) una clave que varía de sesión en sesión (session key) y que se envía al servidor SSH. Además indica al servidor el tipo de cifrado (cipher).

El protocolo SSH versión 2 no incluye la server key. En su lugar utiliza un algoritmo de Diffie-Hellman para intercambiar las claves.

Para descifrar la clave de sesión es imprescindible disponer de las claves privadas de host y server, las cuales no se pueden obtener por medio de las partes públicas. Por este motivo, sólo el daemon SSH contactado es capaz de descifrar la clave de sesión mediante su clave privada (ver man /usr/share/doc/packages/openssh/RFC.nroff). Es posible seguir esta fase de establecimiento de conexión mediante la opción de búsqueda de errores del programa cliente de SSH (opción -v).

Por defecto se utiliza el protocolo SSH versión 2, pero sin embargo se puede forzar el protocolo SSH versión 1 con el parámetro -1. Los ataques del tipo “man-in-the-middle” se evitan porque el cliente guarda en ~/.ssh/known_hosts todas las claves públicas del host después de haber tomado el primer contacto. Los servidores SSH que tratan de camuflarse con el nombre y la IP de otro ordenador se descubren con una alerta. Se delatan ya sea por una clave de host diferente a la que está guardada en ~/.ssh/known_hosts o bien porque no pueden descifrar la clave de sesión por falta de la clave privada correcta.

Se recomienda guardar de forma externa las claves públicas y privadas del directorio /etc/ssh/ y hacer una copia de seguridad de las mismas. Así es posible averiguar modificaciones de las claves y restaurarlas después de una nueva instalación. Esta restauración de las claves evita sobre todo que los usuarios se preocupen por el mensaje de advertencia. Una vez comprobado que se trata del servidor SSH correcto a pesar del aviso, es necesario borrar de ~/.ssh/known_hosts la entrada para el sistema.

Ahora se realiza la verdadera autenticación en su forma más simple mediante la indicación de nombre de usuario y contraseña tal como se ha mencionado en los ejemplos anteriores. El objetivo de SSH era proporcionar un nuevo software seguro pero al mismo tiempo fácil de usar. Debido a que va a sustituir a rsh y rlogin, SSH también ha de ofrecer un método sencillo de autenticación que pueda emplearse fácilmente en el día a día. SSH realiza la autenticación mediante otro juego de claves creado a petición del usuario. Para ello el paquete SSH dispone de la utilidad ssh-keygen. Después de introducir ssh-keygen -t rsa o ssh-keygen -t dsa, transcurre un tiempo hasta que el juego de claves está creado. A continuación el programa consulta el nombre de archivo para guardar las claves.

Después confirmar la ubicación sugerida se pide una contraseña. Aunque el programa admite una contraseña vacía, es mejor introducir un texto de 10 a 30 caracteres. Es preferible no utilizar palabras o frases demasiado sencillas o cortas. Después de introducirlo, el programa pide una confirmación. El programa indica entonces el lugar donde se guardan la clave privada y la pública; estos podrían ser, por ejemplo, los archivos id_rsa y id_rsa.pub.

El comando ssh-keygen -p -t rsa o ssh-keygen -p -t dsa sirve para cambiar la contraseña antigua. La parte pública de la clave (en nuestro ejemplo id_rsa.pub) se ha de copiar al ordenador remoto, guardándola allí como ~/.ssh/authorized_keys. En el siguiente intento de conectar, SSH pregunta por la contraseña. Si esto no funciona, compruebe que la ubicación y el contenido de los archivos anteriormente mencionados son correctos.

A la larga este procedimiento es más complicado que la introducción de una contraseña. Por eso el paquete SSH incorpora otra utilidad llamada ssh-agent que mantiene claves privadas durante una sesión en entorno X. Para realizarlo, todo el entorno X Windows se inicia como un proceso hijo de ssh-agent. Con este fin, el método más sencillo consiste en editar el archivo .xsession, asignando a la variable usessh el valor yes y después entrar al sistema con un gestor como por ejemplo KDM o XDM. Otra posibilidad es la de iniciar el entorno gráfico mediante ssh-agent startx.

Ahora se puede utilizar ssh o scp como es habitual y si ha distribuido su clave pública como antes, no se le pedirá ninguna contraseña. Al salir del ordenador es importante terminar la sesión X o bloquearla mediante un protector de pantalla con contraseña (por ejemplo xlock).

Todas las modificaciones importantes realizadas con la implantación del protocolo SSH versión 2 también se encuentran documentadas en el archivo /usr/share/doc/packages/openssh/README.SuSE.

Aparte de las mejoras en cuanto a la seguridad del sistema, ssh facilita también el trabajo con aplicaciones de X-Windows remotas. Al utilizar ssh con la opción -X, la variable DISPLAY en el ordenador remoto se configura automáticamente y todas las ventanas del X-Windows se mandan a través de la conexión ssh existente al ordenador cliente. Esta sencilla función evita la captura de datos por parte de terceros en caso de aplicaciones-X remotas con visualización local.

La opción -A traspasa el mecanismo de autenticación de ssh-agent al siguiente ordenador. Así se puede acceder de un ordenador a otro sin necesidad de introducir una contraseña. Es algo que sólo funciona si la clave pública se encuentra correctamente en todos los ordenadores destino.

Por razones de seguridad, los dos mecanismos están desactivados en la configuración predeterminada. No obstante, se pueden activar de forma permanente en el archivo de configuración global /etc/ssh/ssh_config o en el personal de cada usuario ~/.ssh/config.

También se puede utilizar ssh para el reenvío de cualquier conexión TCP/IP. Como ejemplo se muestra el reenvío del puerto SMTP y POP3:

ssh -L 25:sun:25 earth

En este caso, cualquier conexión dirigida al puerto 25 (SMTP) de earth se reenvía al puerto SMTP de sun a través del canal codificado. Es un procedimiento especialmente útil para usuarios de servidores SMTP que no disponen de SMTP-AUTH o de prestaciones POP-before-SMTP. Así, el servidor de correo “en casa” puede entregar el correo a cualquier lugar con conexión a Internet. De forma análoga, el siguiente comando reenvía todas las consultas hechas al puerto 110 (POP3) en earth al puerto POP3 de sun:

ssh -L 110:sun:110 earth

Ambos ejemplos exigen la introducción de los comandos como superusuario root, ya que las conexiones se realizan con puertos locales privilegiados. Con la conexión SSH establecida, el correo se envía y se recibe como siempre en modo de usuario normal. En tal caso hay que configurar como Host SMTP y POP3 la máquina local localhost. Puede conseguir información adicional en la páginas de manual de los distintos programas y en los archivos que se encuentran dentro del directorio /usr/share/doc/packages/openssh.