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, “ssh-agent y ssh-add”.
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).
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-agentcsh
%
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
:
-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.
%
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.
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
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>.