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.
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.
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.
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.
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>.
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.
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.
AvisoLas 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).
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.
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:
-2Obliga a ssh a utilizar la versión 2 del protocolo. (No la use si está trabajando con servidores SSH antiguos)
-NIndica que no se ejecutará una orden remota, o solamente túnel. Si se omite, ssh iniciaría una sesión normal.
-fObliga a ssh a ejecutarse en segundo plano.
-LIndica un túnel local según el esquema puerto local:equipo remoto:puerto remoto.
usuario@foo.ejemplo.comEl 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.
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.
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.
AllowUsersLimitar 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
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>.