14.11. OpenSSH

Escrito por Chern Lee.

OpenSSH es un conjunto de herramientas de conectividad que se usan para acceder a sistemas remotos de forma segura. Puede usarse como sustituto directo de rlogin, rsh, rcp y telnet. Además cualquier otra conexión TCP/IP puede reenviarse o enviarse a través de un túnel a través de SSH. OpenSSH cifra todo el tráfico para eliminar de forma efectiva el espionaje, el secuestro de conexiones, y otros ataques en la capa de red.

OpenSSH está a cargo del proyecto OpenBSD, y está basado en SSH v1.2.12, con todos los errores recientes corregidos y todas las actualizaciones correspondientes. Es compatible con los protocolos SSH 1 y 2. OpenSSH forma parte del sistema base desde FreeBSD 4.0.

14.11.1. Ventajas de utilizar OpenSSH

Normalmente, al utilizar telnet(1) o rlogin(1) los datos se envían a través de la red en limpio, es decir, sin cifrar. Cualquier sniffer de red entre el cliente y el servidor puede robar la información de usuario/contraseña o los datos transferidos durante su sesión. OpenSSH ofrece diversos métodos de validación y cifrado para evitar que sucedan estas cosas.

14.11.2. Habilitar sshd

El dæmon sshd está habilitado por defecto FreeBSD 4.X y puede elegir habilitarlo o no durante la instalación en FreeBSD 5.X. Si quiere saber si está habilitado revise si la siguiente línea está en rc.conf:

sshd_enable="YES"

Esta línea cargará sshd(8), el programa dæmon de OpenSSH, en el arranque de su sistema. Puede ejecutar el dæmon sshd tecleando sshd en la línea de órdenes.

14.11.3. Cliente SSH

ssh(1) funciona de manera similar a rlogin(1).

# ssh user@example.com
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'ejemplo.com' added to the list of known hosts.
usuario@ejemplo.com's password: *******

El login continuará como lo haría si fuera una sesión de rlogin o telnet. SSH utiliza un sistema de huellas de llaves para verificar la autenticidad del servidor cuando el cliente se conecta. Se le pide al usuario que introduzca yes solamente la primera vez que se conecta. Todos los intentos futuros de login se verifican contra la huella de la llave guardada la primera vez. El cliente SSH le alertará si la huella guardada difiere de la huella recibida en futuros intentos de acceso al sistema. Las huellas se guardan en ~/.ssh/known_hosts, y en ~/.ssh/known_hosts2 las huellas SSH v2.

Por defecto las versiones recientes de los servidores OpenSSH solamente aceptan conexiones SSH v2. El cliente utilizará la versión 2 si es posible y pasará como respaldo a la versión 1. El cliente puede también ser obligado a utilizar una u otra pasándole -1 o -2, respectivamente para la versión 1 y la versión 2. Se mantiene la compatibilidad del cliente con la versión 1 para mantener la compatibilidad con versiones antiguas.

14.11.4. Copia segura

scp(1) funciona de manera muy similar a rcp(1); copia un fichero desde o hacia un sistema remoto, con la diferencia de que lo hace de una forma segura.

#  scp usuario@ejemplo.com:/COPYRIGHT COPYRIGHT
usuario@ejemplo.com's password: *******
COPYRIGHT            100% |*****************************|  4735
00:00
#

Ya que la huella se guardó en este equipo durante el ejemplo anterior se verifica ahora al utilizar scp(1).

Los argumentos de scp(1) son similares a cp(1), con el fichero o ficheros como primer argumento, y el destino como segundo. Ya que el fichero se transfiere a través de la red, a través de SSH, uno o más argumentos tienen la estructura user@host:<ruta_al_fichero_remoto>.

14.11.5. Configuración

Los ficheros de configuración del sistema tanto para el dæmon OpenSSH como para el cliente están en /etc/ssh.

ssh_config contiene las opciones del cliente, mientras que sshd_config configura el dæmon.

Además las opciones sshd_program (/usr/sbin/sshd por defecto), y sshd_flags de rc.conf ofrecer más niveles de configuración.

14.11.6. ssh-keygen

ssh-keygen(1) le permite validar a un usuario sin pedirle la contraseña:

% ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 usuario@host.ejemplo.com

ssh-keygen(1) creará un par de llaves pública y privada para usar en la validación. La llave privada se guarda en ~/.ssh/id_dsa o en ~/.ssh/id_rsa, mientras que la llave pública se guarda en ~/.ssh/id_dsa.pub o en ~/.ssh/id_rsa.pub, respectivamente para llaves DSA y RSA. La llave pública debe guardarse en el ~/.ssh/authorized_keys de la máquina remota para que la configuración funcione. Las llaves RSA versión 1 deben guardarse en ~/.ssh/authorized_keys.

De este modo permitirá conexiones a la máquina remota mediante llaves SSH en lugar de contraseñas.

Si usa una contraseña al ejecutar ssh-keygen(1), se le pedirá al usuario una contraseña cada vez que quiera utilizar la llave privada. ssh-agent(1) puede evitar la molestia de introducir repetidamente frases largas. esto se explica má adelante, en la Sección 14.11.7, “ssh-agent y ssh-add”.

Aviso:

Las opciones y ficheros pueden ser diferentes según la versión de OpenSSH que tenga en su sistema; para evitar problemas consulte la página de manual ssh-keygen(1).

14.11.7. ssh-agent y ssh-add

ssh-agent(1) y ssh-add(1) ofrecen métodos para que las llaves SSH se puedan cargar en memoria, permitiendo eliminar la necesidad de teclear la contraseña cada vez que haga falta.

ssh-agent(1) gestionará la validación utilizando la llave (o llaves) privada que le cargue. ssh-agent(1) se usa para lanzar otras aplicaciones. En el nivel más básico puede generar una shell o a un nivel más avanzado un gestor de ventanas.

Para usar ssh-agent(1) en una shell necesitará primero ser invocado como argumento por una shell. Segundo, añada la identidad ejecutando ssh-add(1) y facilitando la contraseña de la llave privada. Completados estos pasos el usuario puede hacer ssh(1) a cualquier equipo que tenga instalada la llave pública correspondiente. Por ejemplo:

% ssh-agent csh
% ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
%

Para utilizar ssh-agent(1) en X11 tendrá que incluir una llamada a ssh-agent(1) en ~/.xinitrc. De este modo ofrecerá los servicios de ssh-agent(1) a todos los programas lanzados en X11. Veamos un ejemplo de ~/.xinitrc:

exec ssh-agent startxfce4

Esto lanzaría ssh-agent(1), que a su vez lanzaría XFCE cada vez que inicie X11. Hecho esto y una vez reiniciado X11 para aplicar los cambios puede ejecutar ssh-add(1) para cargar todas sus llaves SSH.

14.11.8. Túneles SSH

OpenSSH permite crear un túnel en el que encapsular otro protocolo en una sesión cifrada.

La siguiente orden le dice a ssh(1) que cree un túnel para telnet:

% ssh -2 -N -f -L 5023:localhost:23 usuario@foo.ejemplo.com
%

Veamos las opciones que se le han suministrado a ssh:

-2

Obliga a ssh a utilizar la versión 2 del protocolo. (No la use si está trabajando con servidores SSH antiguos)

-N

Indica que no se ejecutará una orden remota, o solamente túnel. Si se omite, ssh iniciaría una sesión normal.

-f

Obliga a ssh a ejecutarse en segundo plano.

-L

Indica un túnel local según el esquema puerto local:equipo remoto:puerto remoto.

usuario@foo.ejemplo.com

El servidor SSH remoto.

Un túnel SSH crea un socket que escucha en localhost en el puerto especificado. Luego reenvía cualquier conexión recibida en el puerto/equipo local vía la conexión SSH al puerto o equipo remoto especificado.

En el ejemplo el puerto 5023 en localhost se reenvía al puerto 23 del localhost de la máquina remota. Ya que 23 es telnet, esto crearía una sesión telnet segura a través de un túnel SSH.

Puede usar esto para encapsular cualquier otro protocolo TCP inseguro como SMTP, POP3, FTP, etc.

Ejemplo 14.1. Uso de SSH para crear un túnel seguro para SMTP
% ssh -2 -N -f -L 5025:localhost:25 usuario@correo.ejemplo.com
usuario@correo.ejemplo.com's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 correo.ejemplo.com ESMTP

Puede usar esta técnica junto con ssh-keygen(1) y cuentas adicionales de usuario para crear un entorno más transparente, esto es, más cómodo. Puede usar llaves en lugar de teclear contraseñas y puede ejecutar los túneles de varios usuarios.


14.11.8.1. Ejemplos prácticos de túneles SSH

14.11.8.1.1. Acceso seguro a un servidor POP3

En el trabajo hay un servidor SSH que acepta conexiones desde el exterior. En la misma red de la oficina reside un servidor de correo que ejecuta un servidor POP3. La red, o ruta de red entre su casa y oficina puede o no ser completamente de fiar. Debido a esto necesita revisar su correo electrónico de forma segura. La solución es crear una conexión SSH al servidor SSH de su oficina y llegar por un túnel al servidor de correo.

% ssh -2 -N -f -L 2110:correo.ejemplo.com:110 usuario@servidor-ssh.ejemplo.com
usuario@servidor-ssh.ejemplo.com's password: ******

cuando el túnel esté funcionando haga que su cliente de correo envíe peticiones POP3 a localhost en el puerto 2110. La conexión será reenviada de forma totalmente segura a traveés del túnel a correo.ejemplo.com.

14.11.8.1.2. Saltarse un cortafuegos draconiano

Algunos administradores de red imponen reglas de cortafuegos extremadamente draconianas, filtrando no solo las conexiones entrantes, sino también las salientes. Tal vez solo se le otorgue acceso a máquinas remotas a través de los puertos 22 y 80 para ssh y navegar en web.

Tal vez quiera acceder a otros servicios (que tal vez ni siquiera estén relacionados con el trabajo), como un servidor Ogg Vorbis para escuchar música. Si ese servidor Ogg Vorbis transmite en un puerto que no sea el 22 o el 80 no podrá tener acceso a él.

La solución es crear una conexión SSH fuera del cortafuegos de su red y utilizarla para hacer un túnel al servidor Ogg Vorbis.

% ssh -2 -N -f -L 8888:musica.ejemplo.com:8000 usuario@sistema-no-filtrado.ejemplo.org
usuario@sistema-no-filtrado.ejemplo.org's password: *******

Haga que el programa con el que suele escuchar música haga peticiones a localhost puerto 8888, que será reenviado a musica.ejemplo.com puerto 8000, evadiendo con éxito el cortafuegos.

14.11.9. La opción de usuarios AllowUsers

Limitar qué usuarios pueden entrar y desde dónde suele ser razonable. La opción AllowUsers le permite configurarlo, por ejemplo, para permitir entrar solamente al usuario root desde 192.168.1.32. Puede hacerlo con algo parecido a esto en /etc/ssh/sshd_config:

AllowUsers root@192.168.1.32

Para permitir al usuario admin la entrada desde cualquier lugar, solamente introduzca el nombre de usuario:

AllowUsers admin

Puede listar múltiples usuarios en la misma línea:

AllowUsers root@192.168.1.32 admin

Nota:

Es importante que incluya a cada usuario que necesite entrar a esta máquina o no podrán entrar.

Después de hacer los cambios a b /etc/ssh/sshd_config debe decirle a sshd(8) que cargue de nuevo sus ficheros de configuración ejecutando:

# /etc/rc.d/sshd reload

14.11.10. Lecturas complementarias

OpenSSH

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1) ssh_config(5)

sshd(8) sftp-server(8) sshd_config(5)

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.

Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.