14.11. OpenSSH
Anterior | Capítulo 14. Seguridad | Siguiente

## 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)

Anterior | Subir | Siguiente
14.10. VPN sobre IPsec | Inicio | 14.12. Listas de control de acceso a sistemas de ficheros

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>.