Hacks para Unix-like: Configuración de SSH en un sistema Debian 3.1

El protocolo SSH cuenta con dos versiones. La primera de ellas se mantiene por motivos de compatibilidad, pero se recomienda generalmente el uso de la segunda, por su mayor seguridad. OpenSSH es una implementación, usable en sistemas Linux, de cliente y servidor para estos protocolos, la versión disponible para Debian permite usar tanto SSH1 como SSH2.[1]


Tal como se describe en uno de los borradores de la especificación temporal "SSH Protocol Architecture" [2] ssh es un protocolo para iniciar sesiones en máquinas remotas que ofrece autenticación, confidencialidad e integridad. Consta de tres componentes:

  1. Protocolos de transporte y red: Que normalmente opera sobre TCP/IP dando autenticidad, confidencialidad e integridad.
  2. Protocolo de autenticación de usuario: Que autentica al usuario ante el servidor.
  3. Protocolo de conexión: Que multiplexa un canal cifrado en diversos canales lógicos.

Este protocolo requiere que los servidores tengan "llaves", las cuales son usadas por los clientes cada vez que se conectan a un servidor para verificar que no fue suplantado. Una llave es un número codificado y cifrado en un archivo. Para el cifrado de llaves, OpenSSH ofrece los algoritmos RSA y DSA (de los cuales para la versión 2 recomendamos DSA).

Para instalar un servidor OpenSSH, que le permita conectarse a su sistema de forma segura, instale el paquete ssh preferiblemente tomando la versión más reciente del sitio de seguridad de Debian o compile las fuentes más recientes que puede obtener del sitio oficial de OpenSSH. Cuando instale se generarán un par de "llaves" para su computador, una pública y una privada. Una vez instalado podrá afinar la configuración del servidor en el archivo /etc/ssh/sshd_config que puede incluir líneas como las siguientes:

PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
RhostsAuthentication no
hostsRSAAuthentication no
HostbasedAuthentication no
X11Forwarding yes 

La última línea permitirá a los clientes que se conecten ejecutar aplicaciones de X-Window y transmitir la información gráfica sobre la conexión segura.

Un usuario también puede crear un par de llaves que le faciliten su autenticación al emplear ssh o scp. Estos programas por defecto piden clave al usuario que se conecte a un servidor SSH. Si un usuario genera sus llaves pública y privada, puede saltarse esta autenticación pues se hará de forma automática con las llaves. Para lograrlo su llave pública debe estar en el computador al cual se conecta (en ~/.ssh/authorized_keys) y su llave privada en el computador desde el cual se conecta (normalmente en ~/.ssh/id_dsa).

La generación de llaves puede hacerse con:

ssh-keygen -t dsa

que por defecto dejará su llave pública en ~/.ssh/id_dsa.pub y su llave privada en ~/.ssh/id_dsa (que además quedará protegida por una palabra clave que usted especifica). Como el nombre indica, la llave privada no debe compartirla, por el contrario la llave pública puede transmitirla y puede ser vista por cualquiera.

En el computador en el que desee conectarse, agregue en el archivo ~/.ssh/authorized_keys (o ~/.ssh/authorized_keys2 si usa DSA y una versión de OpenSSH anterior a la 3.1), su llave pública. Por ejemplo el usuario mario desde purpura.micolegio.edu.co puede configurar la entrada con autenticación automática a la cuenta pepe en amarillo.micolegio.edu.co con:

purpura> scp ~/.ssh/id_dsa.pub amarillo.micolegio.edu.co:/home/pepe/id_dsa_mario.pub 
purpura> ssh -l pepe amarillo.micolegio.edu.co
...
amarillo> cat id_dsa_mario.pub >> ~/.ssh/authorized_keys

Cuando mario se intente conectar desde purpura, a la cuenta pepe en amarillo ya no tendrá que dar la clave de pepe en ese computador sino la palabra clave con la que protegió su llave privada. Incluso esta palabra clave puede darse una sola vez, aún cuando se realicen diversas conexiones con:

purpura> ssh-agent bash
purpura> ssh-add mario

Tras lo cual mario tecleará una vez la palabra clave de su llave privada, y después en esa sesión de BASH todo ingreso que haga a la cuenta pepe en amarillo, no solicitará clave alguna.

Referencias editar

  1. Administración de una red con GNU/Linux. Capítulo 6
  2. T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. (September 20, 2002 ). SSH Protocol Architecture. The Internet Engineering Task Force. Network Working Group (en inglés)