OpenSSH

1. Usos de OpenSSH

Al principio, las sesiones interactivas en sistemas Unix se realizaban con terminales pasivos, que se limitaban a
gestionar la entrada/salida, conectados a una unidad central a través del puerto serie. Las pulsaciones del teclado se
enviaban sin procesar a la unidad central y la unidad central enviaba como respuesta órdenes de impresión por
pantalla. Los ordenadores eran muy caros entonces, el coste relativamente modesto de los terminales pasivos
permitía compartir el uso de un ordenador.
Con la generalización de las redes IP y la proliferación de los ordenadores personales, la administración remota de
sistemas Unix pasó a realizarse con el protocolo telnet. Se basa exactamente en el mismo principio que los terminales
pasivos, excepto en que las pulsaciones de teclado y las órdenes de impresión por pantalla se envían en paquetes
transportados por IP. El problema es que la gestión de la seguridad con el protocolo telnet es absolutamente
insuficiente: la autentificación se realiza sin encriptar y no hay ningún método de confidencialidad que se aplique a los
intercambios entre el cliente y el servidor.

El protocolo SSH está destinado a proporcionar servicios de autentificación y de confidencialidad a los intercambios
entre cliente y servidor para el transporte seguro de datos. En la mayoría de los casos simples se utiliza como un
"telnet seguro", pero también es capaz de proporcionar un transporte seguro para otros protocolos. La
implementación open source del protocolo SSH es "OpenSSH", creada y mantenida por los miembros del proyecto
OpenBSD.

2. Gestión de autentificaciones

a. Autentificación por contraseña

El uso más sencillo del cliente SSH, que consiste en abrir una sesión de shell remota de forma segura en redes IP,
usa un modo de autentificación simple, que es utilizar una cuenta local del servidor y solicitar al cliente que se
autentifique con el nombre y la contraseña de esta cuenta existente en el servidor. La contraseña se verifica a
continuación y la autentificación se valida. Sin embargo, esta fase de autentificación por contraseña sirve únicamente
para comprobar la validez del cliente. El cliente a su vez puede tener dudas acerca de la identidad del servidor. Dicho
de otro modo: ¿se está a punto de hablar con el servidor deseado o con un servidor falso que se aprovechará de los
comandos tecleados para obtener información acerca de los sistemas? Para evitar cualquier tipo de riesgo de
falsificación de servidor, el cliente realiza una comprobación de la identidad del servidor en la primera conexión. De
hecho, se crea una huella digital del servidor y, después de que el cliente valide esta huella, se guarda en un archivo
llamado known_hosts, alojado en el directorio oculto .ssh en el directorio personal del usuario.

Ejemplo de archivo known_hosts

El archivo known_hosts presenta una línea (muy larga) por cada servidor conocido.

beta:~# cat .ssh/known_hosts

|1|LPx02U8nHnkSb0czyqVrdXPcW04=|jS0/QdS0HydzPZj8QXxHXC4j6EM= ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAv+kXth0/RSAroNfqeV+IkEMetdWRWYBvbNOqUDDSL/fLylBip9le40xfTe1j
FXuYqAWR+mQMo8Pg37/PUWeetlBCvG4F486UbqUn2Ol5B/1GZqzG7nvbOLcp7CDr6vmqgrk2QZvUZcohWc4L9S6z
zvk3EmQ1AMa+BKo4m+FCG9E1mK4bFtvchVqL1amzGg1jd2QuTzMGNibTdrEi9gSr2TrJ5Se9AhNQkIzZPvrqvVAD
itiggcYNetxaNkPKfW8DdClq+qOVVAQuWnZiO63Mp/0+b+JEutFgNsX8mkt9nx34Yws7s3BnIuT7oU+shxnuy/vj
5But4uUry5tFaTxXCw==
beta:~#

b. Autentificación por claves

Sin lugar a dudas, un método más fiable para autentificar conexiones SSH consiste en utilizar claves de
autentificación almacenadas localmente en el disco del usuario. La autentificación por claves no exime de la
obligación de utilizar una contraseña, pero garantiza al usuario que la máquina remota es con la que se quiere
trabajar y no una falsificación.

Creación del par de claves en el cliente

Para que el servidor pueda identificarse formalmente, tiene que tener la clave pública del cliente. Esta clave le
permitirá encriptar datos que sólo el cliente propietario de la clave privada asociada podrá descifrar. Por tanto,
conviene que se genere en primer lugar esta clave pública en el cliente. Como se trata de criptografía asimétrica, la

© ENI Editions - All rights reserved - Mario Junior Inga Cahuana - 1-

 generación de la clave pública es necesariamente simultánea a la de la clave privada asociada. El comando ssh­
keygen permite crear estas claves (la pública y la privada).

Generación del par de claves

ssh-keygen -t algoritmo

Donde algoritmo representa el algoritmo usado para la generación de las claves del cliente. Puede tratarse de RSA
(versión 1 o 2 de SSH). RSA y DSA son dos algoritmos de encriptación asimétricos que se usan a menudo para
autentificar. Si no se especifica un algoritmo, se usa el valor por defecto: RSA.

Generación de un par de claves con los valores por defecto

En este ejemplo se generan un par de claves con el algoritmo por defecto (RSA) para el usuario tata. La representación
gráfica (randomart) de la clave no es automática y su impresión por pantalla depende de la versión del comando.

tata@estacion:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tata/.ssh/id_rsa):
Created directory ’/home/tata/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tata/.ssh/id_rsa.
Your public key has been saved in /home/tata/.ssh/id_rsa.pub.
The key fingerprint is:
[Link] tata@stotion
The key’s randomart image is:
+--[ RSA 2048]----+
| o+=++o |
| . ..+..o|
| o E. |
| o X + |
| S = o |
| + . |
| o |
| |
| |
+-----------------+
tata@estacion:~$

El comando ssh­keygen provoca la creación de dos archivos, creados por defecto en el directorio .ssh ubicado
directamente en el directorio personal del usuario. Estos dos archivos son por defecto id_rsa para la clave privada e
id_rsa.pub para la clave pública asociada. Aunque no sea obligatorio, se recomienda encarecidamente proteger la
clave privada con una contraseña que se solicitará en su creación.

Contenido de los archivos de claves privadas y públicas

A continuación se muestra el contenido de los archivos de claves privadas y públicas. Cabe destacar que los permisos por
defecto están limitados en el archivo de clave privado y abiertos en el archivo de clave pública.

tata@estacion:~/.ssh$ ls -l
total 8
-rw------- 1 tata tata 1743 2011-08-09 09:38 id_rsa
-rw-r--r-- 1 tata tata 394 2011-08-09 09:38 id_rsa.pub
tata@station:~/.ssh$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs0jrYKKQKiS4f/cCQMhOcc2WTMmGrbXXv3oyz67KUwkm4JumEU1
YkOaNi+WM4nVbkzC7rkUnlXQMxu/EpZLoraNySMHZjUgYiWiRuM4pI0z/atPfjVlwPtGzfUKlqSsP4NCark/9G0
WlMgEXlgpEdeJDmMBRuj98PJjOI/cRGRTgR6JEoevFWMPTDRpoBix3YizVY+dA+unJQPaNKWhoDnCZg7xWi+ZRg
T2Q1PcbqYKt4xLio+Eei0dvlgu5r5hSvymOdWbXwykywoloIxnzIPiUe7CAxm+KCBA23LQw73pREd1cglS6Gd23
b5Byv/oI6etqs4WOmcJa40Ymvtfbjw== tata@station
tata@stotion:~/.ssh$ cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,B08C4C3C4B021A76

TzO6ofHOv8sVRDoPj+o7dXfPuXDJaOmQSGhDkWUTC9iGHYnGdHgsig5EKWEez0Zj
YucF9doTpLCv9UsRac6WHRjlQb7AUjk9phEjrKYW4gAfoXNcFY5IiC7fca9i8NQk

- 2- © ENI Editions - All rights reserved - Mario Junior Inga Cahuana

YCj4mtzmbJAFc0W9Ax8g0UzZ8bwElIacI28pAdSvVqVHQ6omnVBoWhXhgWTUZaKp
2XbY5gJ7miKW3Y9IPZ3JLukB3j4rTZ0bu8j/UedyXuogpZgYF2vW0GfvtBbfP31F
(...)
RZfBnf+3+KxTvnAtJsMSZc4Glg+9Gch9V+mjU2SfW+T+bUnYLB/6Mpo1aq/akj3r
0G6w12SgjqiOuuXnsCdU8Ox1olCqiHFrk0DyPmwoxcSQygpm2r7FIwL4MPxbELJO
zfk+0wJOmsUANJzeBKd4LXmZykYsAOmf3zZNlS+iU/ZhCBqFmn3/5w==
-----END RSA PRIVATE KEY-----
tata@estacion:~/.ssh$

En cada conexión, el servidor mira en el directorio local del usuario que se intenta conectar para ver si existe el
directorio .ssh/authorized_keys y si contiene la clave pública del cliente. Si éste es el caso, la autentificación del
servidor la puede realizar el cliente. Por tanto, el cliente deberá copiar su archivo de clave pública en el directorio
~/.ssh.authorized_keys del servidor usando algún método de su elección (memoria usb, copia por red).

c. El agente SSH

Para los administradores que necesiten acceder frecuentemente a varias máquinas por SSH, existe un "agente SSH",
iniciado con el comando ssh­agent, que permite conservar en memoria las claves privadas utilizadas en las
autentificaciones. Las claves privadas se transmiten sólo una vez al agente con el comando ssh­add. Si se requiere
una contraseña de protección de la clave, se solicitará en esta ocasión. A continuación, las claves quedan disponibles
sin intervención directa del usuario para cualquier autentificación.
El comando ssh­add consulta el directorio .ssh en el directorio personal del usuario y busca posibles claves privadas
en los archivos id_rsa, id_dsa e identity. Se pueden consultar las claves almacenadas por el agente SSH mediante
el comando ssh­add ­l.

Carga del agente con el comando ssh­agent

El agente nutre variables durante su funcionamiento que permiten gestionarlo más fácilmente.

tata@estacion:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-sRuvox4519/agent.4519; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4520; export SSH_AGENT_PID;
echo Agent pid 4520;
tata@estacion:~$

ssh­agent: variables comunes

SSH_AGENT_PID El pid del agente que se encuentra en ejecución.

SSH_AUTH_SOCK El socket creado por el proceso.

Carga de claves por el agente SSH

El comando ssh­add sin argumentos permite que el agente SSH, que debe haberse iniciado previamente, cargue las claves.

tata@estacion:~$ ssh-add
Enter passphrase for /home/tata/.ssh/id_rsa:
Identity added: /home/tata/.ssh/id_rsa (/home/tata/.ssh/id_rsa)
tata@estacion:~$

Visualización de las claves privadas que el ssh­agent tiene almacenadas

El comando ssh­add ­l permite comprobar que el agente ha cargado las claves correctamente.

tata@estacion:~$ ssh-add -l
2048 [Link] tata@stotion (RSA)
2048 [Link] /home/tata/.ssh/id_rsa (RSA)
tata@estacion:~$

El agente SSH es ante todo una solución de gestión de claves y no tiene como finalidad la creación de claves
SSH. El agente SSH sólo puede trabajar con claves ya creadas con el comando ssh­keygen.

© ENI Editions - All rights reserved - Mario Junior Inga Cahuana - 3-

 3. Confidencialidad en las comunicaciones

a. Sesión interactiva con SSH

La sesión interactiva se abre desde un cliente a un servidor con una cuenta de usuario existente en el servidor.

Apertura de sesión interactiva con SSH

ssh usuario@dirección_servidor

Sesión interactiva con SSH: opción y parámetros

usuario La cuenta de usuario existente en el servidor con la que se realiza la conexión.

dirección_servidor La dirección IP del servidor con el que se realiza la conexión.

Ejemplo de apertura de sesión interactiva con SSH

alfa:~# hostname ; whoami

alfa
root
alfa:~# ssh toto@[Link]
toto@[Link]’s password:

toto@beta:~$ hostname ; whoami

beta
toto
toto@beta:~$

b. Copia de archivos con SSH

El comando scp requiere el daemon SSH y permite copiar archivos de forma segura utilizando los servicios de
autentificación y de confidencialidad proporcionados por SSH. La copia puede realizarse del cliente al servidos o
viceversa.

Copia de archivos del cliente al servidor con scp

scp archivo_local usuario@dirección_servidor:archivo_remoto

Copia de archivos del servidor al cliente con scp

scp usuario@dirección_servidor:archivo_remoto archivo_local

Copia de archivos con scp: opciones y parámetros

archivo_local Ruta relativa o absoluta del archivo local que debe copiarse.

archivo_remoto Ruta absoluta del archivo remoto que debe copiarse.

usuario Cuenta de usuario existente en el servidor utilizada para realizar la copia.

dirección_servidor Dirección IP del servidor que alberga el servicio SSH.

c. Utilización de aplicaciones en túneles SSH

- 4- © ENI Editions - All rights reserved - Mario Junior Inga Cahuana

 La creación de un túnel SSH permite asegurar las comunicaciones cliente/servidor para protocolos a priori poco
seguros. Se establece un túnel desde el cliente al servidor y todo el tráfico entre estas dos máquinas es seguro. El
servidor genera entonces otra comunicación no segura con la máquina objetivo del tráfico. Las conexiones de los
clientes que deseen utilizar el túnel se crean a través del cliente SSH.

Creación de un túnel SSH

ssh -L puerto:destino_tráfico:puerto_destino usuario@servidor

Túnel SSH: opciones y parámetros

­L Reenvía un puerto local a un servidor SSH (establecimiento del túnel).

puerto El puerto local que se reenviará.

destino_tráfico Dirección IP o nombre de la máquina destino del tráfico.

puerto_destino Puerto al que se reenviará el tráfico en la máquina destino.

usuario Cuenta de usuario en el servidor usada para desplegar el túnel.

servidor Dirección IP o nombre del servidor que será el extremo del túnel.

Con esta instrucción, se crea un túnel entre un cliente y un servidor. En el cliente, el tráfico con destino el puerto
local se reenvía a través del túnel SSH a la máquina destino en el puerto destino.

d. Reenvío de sesiones X11 con SSH

El servidor X no tiene de forma nativa una fuerte seguridad para sus comunicaciones cliente/servidor. Un uso
habitual de SSH consiste en transmitir a través de un túnel SSH aplicaciones gráficas. Para ello, hay que autorizar
que el servidor SSH reenvíe este tipo de tráfico y utilizar un cliente compatible con este modo de funcionamiento.
La autorización del reenvío de sesiones X a través de SSH se consigue modificando el archivo de configuración del
servidor SSH /etc/ssh/sshd_config.

Autorización del reenvío de conexiones X en sshd_config.conf

X11Forwarding yes

Conexión desde un cliente SSH

© ENI Editions - All rights reserved - Mario Junior Inga Cahuana - 5-

 ssh -X usuario@servidor

Donde usuario representa la cuenta de usuario utilizada para la conexión y servidor la dirección IP o el nombre del
servidor al que se conecta. Las aplicaciones gráficas podrán entonces ejecutarse desde la sesión SSH cliente.

- 6- © ENI Editions - All rights reserved - Mario Junior Inga Cahuana