ssh sustituye a rsh

El demonio sshd

El demonio sshd es el programa que espera conexiones de red de los clientes ssh, controla la autenticación y ejecuta el comando requerido. El puerto por defecto en el que escucha es el 22 y su fichero de configuración es /etc/ssh/sshd_config.

Otras opciones a destacar son:

• X11Forwarding yes|no : habilitar o deshabilitar la redirección X

• PasswordAuthentication yes|no : especifica si deseamos utilizar la autenticación básica

En esta configuración se indica también la ruta en la que encontrar las claves que identifican nuestro servidor. Estas son la base de la autenticación mediante clave publica y los valores por defecto son:

• HostKey /etc/ssh/ssh_host_key

• HostKey /etc/ssh/ssh_host_rsa_key

• HostKey /etc/ssh/ssh_host_dsa_key

Estas claves generales al sistema, junto con su correspondiente clave pública, se crean al instalar el servidor mediante el comando ssh-keygen.

Los clientes ssh

Los programas que permiten al usuario utilizar el protocolo SSH son scp,sftp y ssh.

Se pueden configurar opciones generales al sistema en el fichero /etc/ssh/ssh_config como por ejemplo:

• ForwardX11 yes|no : habilitar o deshabilitar la redirección X

• PasswordAuthentication yes|no : especifica si deseamos utilizar la autenticación básica en nuestros clientes.

• IdentityFile ~/.ssh/identity

• IdentityFile ~/.ssh/id_rsa

• IdentityFile ~/.ssh/id_dsa

ssh

El comando ssh ofrece comunicación encriptada y segura entre dos sistemas sobre una red no segura. Este comando reemplaza al telnet, rlogin, rsh.

Para iniciar una sesión en otra máquina usando ssh:

[usuario1@localhost usuario1]$ ssh usuario1@servidor.dominio.es
The authenticity of host 'servidor.dominio.es (192.168.0.2)' can't be established.
RSA key fingerprint is 97:4f:66:f5:96:ba:6d:b2:ef:65:35:45:18:0d:cc:29.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'servidor.dominio.es' (RSA) to the list of known hosts.
usuario1@servidor.dominio.es's password:
[usuario1@servidor.dominio.es usuario1]$
    

La primera vez que realizas la conexión debes aceptar la firma del otro host. De esta manera se establece una relación de confianza que se traduce en archivar la clave pública de este servidor en el fichero $HOME/.ssh/known_hosts.

La sintaxis básica del comando ssh es:

ssh user@hostname [command]
    

Por ejemplo podríamos hacer un ls en la máquina remota y observar su salida:

ssh usuario1@servidor.dominio.es ls
    

ssh usuario1@servidor.dominio.es "tar cf - /home/usuario1" |\
                                  tar xvf -
    

Una de las funcionalidades que le da mayor potencia al ssh es la redirección de las X. Si observas la variable de entorno DISPLAY observarás que tiene la forma localhost:n.n, esta permite que al abrir cualquier aplicación gráfica su salida se redirija al display del cliente.

[usuario1@localhost usuario1]$ ssh usuario1@servidor.dominio.es
[usuario1@servidor usuario1]$ echo $DISPLAY
localhost:11.0
[usuario1@servidor usuario1]$ xeyes&
[usuario1@servidor usuario1]$
    

scp

El comando scp permite copiar ficheros entre dos máquinas. Utiliza ssh para la transmisión de la información, por lo que ofrece la misma seguridad que el ssh. De la misma manera utiliza los métodos de autenticación de ssh. Este comando reemplaza al rcp, ftp.

Este es un ejemplo de uso del scp para copiar desde la máquina local a una remota:

[usuario1@localhost]scp /tmp/file usuario1@servidor.dominio.es:/tmp
    

[usuario1@localhost]scp usuario1@anotherhost:/tmp/file \
                        usuario1@servidor.dominio.es:/tmp
    

La sintaxis del comando es:

scp [-pqrvBC46] [-F ssh_config] [-S program] [-P port] [-c cipher]
         [-i identity_file] [-o ssh_option] [[user@]host1:]file1 [...]
         [[user@]host2:]file2
    

• -p: conserva las propiedades del archivo. Permisos del archivo, fecha de última de modificación.

• -r: copia recursiva de directorios

La sintaxis para especificar el origen o destino de los archivos tiene la forma [[user@]host:]file donde:

• user: es el usuario de la máquina. Si no se especifica es el actual.

• host: es la máquina origen o destino del archivo. Si no se informa es la máquina local.

• file: fichero o directorio a copiar. Por defecto es el directorio HOME del usuario. En caso de ser un directorio deberás especificar la opción -r.

sftp

El comando sftp transfiere archivos entre máquinas de forma interactiva.

Los comandos interactivos son similares al clásico ftp:

[usuario1@localhost usuario1]$ sftp servidor.dominio.es
Connecting to servidor.dominio.es...
usuario1@servidor's password:
sftp> help
Available commands:
cd path                       Change remote directory to 'path'
lcd path                      Change local directory to 'path'
chgrp grp path                Change group of file 'path' to 'grp'
chmod mode path               Change permissions of file 'path' to 'mode'
chown own path                Change owner of file 'path' to 'own'
help                          Display this help text
get remote-path [local-path]  Download file
lls [ls-options [path]]       Display local directory listing
ln oldpath newpath            Symlink remote file
lmkdir path                   Create local directory
lpwd                          Print local working directory
ls [path]                     Display remote directory listing
lumask umask                  Set local umask to 'umask'
mkdir path                    Create remote directory
put local-path [remote-path]  Upload file
pwd                           Display remote working directory
exit                          Quit sftp
quit                          Quit sftp
rename oldpath newpath        Rename remote file
rmdir path                    Remove remote directory
rm path                       Delete remote file
symlink oldpath newpath       Symlink remote file
version                       Show SFTP version
!command                      Execute 'command' in local shell
!                             Escape to local shell
?                             Synonym for help
sftp>
      

Un ejemplo de uso:

[usuario1@localhost]sftp usuario1@servidor.dominio.es
sftp> get fichero
      

Autenticación mediante usuario/contraseña

Es la autenticación básica. Se puede habilitar o deshabilitar en /etc/ssh/sshd_config y /etc/ssh/ssh_config.

Autenticación basada en host/usuario

Como en los comandos "r" se puede configurar el acceso a ssh mediante ficheros que especifican desde que usuario y máquina se permite.

Estos ficheros son:

• /etc/ssh/shosts.equiv: con el mismo funcionamiento que /etc/hosts.equiv

• $HOME/.shosts: a nivel de usuario, como el fichero $HOME/.rhost

Autenticación mediante claves

Para obtener el máximo partido a SSH podemos utilizar su capacidad de autenticación mediante clave pública y privada.

Para ello el cliente debe generar sus claves privada y pública, compartiendo esta última con el servidor para poder identificarse. Una vez hecho esto las conexiones se podrán establecer sin necesidad de utilizar el esquema clásico de usuario y contraseña.

Un mensaje encriptado con la pública sólo puede desencriptarse con la correspondiente clave privada. OpenSSH utiliza estas propiedades de los algoritmos de clave pública y privada para realizar la autenticación sin intercambio de contraseñas.

Estos son los pasos a seguir para poder utilizar esta autenticación.

1. Generar la clave en el cliente.

   [usuario1@localhost usuario1]$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/usuario1/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/usuario1/.ssh/id_dsa. Your public key has been saved in /home/usuario1/.ssh/id_dsa.pub. The key fingerprint is: 1c:bb:8c:da:c5:a4:db:9f:bb:4d:64:86:a8:29:85:05 usuario1@localhost.localdomain [usuario1@localhost usuario1]$

   La passphrase si se rellena tiene un comportamiento similar a la contraseña, será solicitada al utilizar esta clave. Deberá ser una frase, en la que se pueden incluir espacios en blanco y signos de puntuación.

   En nuestro caso hemos decidido dejarla vacía para así poder utilizar este método de autenticación en procesos no interactivos. Puedes utilizar una frase de paso si no confías en la seguridad de tu máquina.

   La passphrase se puede cambiar con el comando ssh-keygen -p.

   El tipo de la clave se especifica mediante el parámetro -t, y puede ser:

   • rsa1 para ssh v1

   • rsa, dsa para ssh v2

   En el ejemplo se ha utilizado el tipo dsa, y se ha guardado en los archivos por defecto. Estos son $HOME/.ssh/id_dsa para la clave privada y $HOME/.ssh/id_dsa.pub para la clave pública.

   La clave privada es la que nos identifica, por lo que debe ser accesible únicamente por el usuario propietario.

2. Compartir la clave pública

   La clave pública debe ser incluida en el fichero $HOME/.ssh/authorized_keys2 de cada máquina en la que deseemos utilizar la autenticación por clave pública.

   Para realizar este intercambio podemos utilizar directamente el ssh desde la máquina en que hemos generado nuestra clave.

   [usuario1@localhost usuario1]$ ssh usuario@servidor.dominio.es \ 'cat >> .ssh/authorized_keys2' < .ssh/id_dsa.pub

Ahora ya podemos utilizar los comandos de ssh sin utilizar el usuario y contraseña, confiando únicamente en las claves publica y privada.

En el caso de utilizar una passphrase no vacia se solicitaría al realizar la autenticación:

[usuario1@localhost usuario1]$ ssh usuario1@servidor.dominio.es
Enter passphrase for key '/home/usuario1/.ssh/id_dsa':
[usuario1@servidor usuario1]$
      

ssh-agent

Lanzamos el agente, este se queda en background pero informa de las variables de entorno que nos serán útiles.

[usuario1@localhost usuario1]$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XXln2tGm/agent.3216; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3217; export SSH_AGENT_PID;
echo Agent pid 3217;
[usuario1@localhost usuario1]$
       

[usuario1@localhost usuario1]$ eval $(ssh-agent)
Agent pid 3229
       

puedes añadir estas lineas a tu .bash_profile para que se ejecuten al inicio de la sesión.

[usuario1@localhost usuario1]$ set |grep SSH
SSH_AGENT_PID=3229
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SSH_AUTH_SOCK=/tmp/ssh-XX5cnIut/agent.3228                (1)
[usuario1@localhost usuario1]$
        

ssh-add

Una vez tenemos el agente de autenticación en marcha, deberemos añadir las claves que deseamos usar. En nuestro caso la que hemos generado en id_dsa.

[usuario1@localhost usuario1]$ ssh-add .ssh/id_dsa
Enter passphrase for .ssh/id_dsa:
Identity added: .ssh/id_dsa (.ssh/id_dsa)
[usuario1@localhost usuario1]$
       

keychain

El agente tiene el inconveniente de que sólo se puede usar en las sesiones en las que estén definidas las variables de entorno que hemos comentado. Si se añade el comando ssh-agent en el inicio de la sesión el efecto será que tendremos un agente por cada sesión.

Para solucionar este comportamiento puedes utilizar el script keychain que se puede obtener de http://www.gentoo.org/projects/keychain/. Este script se incluye en el inicio de la sesión y lanza el ssh-agent una sola vez en el sistema.

Redirección puertos locales

El uso típico de esta redirección es la de tener acceso a servicios que sólo están disponibles desde la máquina remota.

Podemos realizar una conexión ssh a la máquina remota y redirigir este servicio para utilizarlo de manera local.

La sintaxis es:

ssh [-L port:host:hostport] hostname | user@hostname
    

• port: será el puerto local que queremos utilizar para acceder al servicio

• host: máquina que ofrece el servicio

• hostport: puerto en que host ofrece el servicio

• hostname: máquina a la que nos conectamos, puede ser la misma que host

Se entenderá mejor con un ejemplo.

Voy a utilizar el servicio de proxy que se sirve en el puerto 81 de la máquina proxy.dominio.es y que sólo está disponible desde servidor.dominio.es, mediante el puerto local 8080.

[usuario1@localhost usuario1]$ ssh -L 8080:proxy.dominio.es:81 \
                                    usuario1@servidor.dominio.es
[usuario1@servidor usuario1]$
   

[usuario1@localhost usuario1]$ ssh -fN -L 8080:proxy.dominio.es:81 \
                                        usuario1@servidor.dominio.es
[usuario1@localhost usuario1]$ netstat -lnp|grep 8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      6417/ssh
[usuario1@localhost usuario1]$ ps -fp 6417
UID        PID  PPID  C STIME TTY          TIME CMD
usuario1     6417     1  0 19:24 ?        00:00:00 ssh -fN -L 8080:proxy.dominio.es:81 usuario1@servidor.dominio.es
[usuario1@localhost usuario1]$
   

En el ejemplo el servicio redirigido sólo puede usarse localmente. Si quieres que tu máquina acepte conexiones remotas en este puerto deberás añadir al comando la opción -g.

Redirección puertos remotos

Esta redirección se realiza en sentido inverso a la anterior y se utiliza para hacer accesible remotamente un puerto local o accesible localmente.

La sintaxis es:

 ssh [-R port:host:hostport] hostname | user@hostname
    

• port: puerto remoto donde se ofrecerá el servicio

• host: máquina que ofrece el servicio, la local o una a la que tengamos acceso

• hostport: puerto en que host ofrece el servicio

• hostname: máquina a la que nos conectamos, puede ser la misma que host

Por ejemplo, este comando conseguirá que en la máquina remota se sirva en el puerto 8001, el servidor de streaming que se está sirviendo en la máquina local en el puerto 8000.

ssh -fN -R 8000:localhost:8001 usuario1@servidor.dominio.es
    

pop+ssh

Las sesiones de correo POP suelen ser inseguras. Al establecer la sesión el usuario y contraseña viajan en texto claro, así como el contenido del correo.

Si utilizamos ssh para establecer estas conexiones, la información viajará encriptada y lo mas importante, la autenticación también.

Para conseguirlo utilizaremos la redirección local de puertos para redirigir el puerto local 11110 al puerto 110 de nuestro servidor de pop.

[user1@localhost user1]$ssh -fN -L 11110:popserver:110 popserver
     

[user1@localhost user1]$telnet localhost 11110
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
+OK Qpopper (version 4.0.3) at popserver starting.
     

ppp+ssh

Mediante PPP y SSH es posible crear una red privada virtual (VPN) para crear un tunel entre dos hosts.

Los pasos pueden ser:

• Crear un usuario "vpn" en la máquina que hará de servidor de tuneles.

• Preparar la autenticación mediante claves entre el usuario del servidor y el del cliente, mediante el intercambio de clave pública.

• Configurar el sudo en la máquina servidor para que el usuario "vpn" pueda ejecutar el demonio pppd.

  [root@localhost root]# tail -2 /etc/sudoers ALL ALL= (root) NOPASSWD:/usr/local/bin/driftnet vpn ALL= (root) NOPASSWD: /usr/sbin/pppd

• Instalar en el cliente el script ppp-over-ssh que realizará la conexión con el usuario "vpn" en el servidor.

  #!/bin/sh REMOTE_ACCOUNT=vpn@servidor.dominio.es REMOTE_PPPD="sudo /usr/sbin/pppd ipcp-accept-local ipcp-accept-remote noauth" LOCAL_PPPD="pppd silent 10.0.2.1:10.0.2.2" $LOCAL_PPPD pty "ssh -t $REMOTE_ACCOUNT $REMOTE_PPPD"

• En la máquina local ejecutamos el script. Este ejecuta un ssh contra la máquina remota para ejecutar el pppd que establecerá la conexión.

De esta manera se establece un canal seguro entre las dos máquinas utilizando una interfaz ppp. Esto permite utilizar los servicios de la máquina remota para todos los usuarios de la máquina local y también en el sentido inverso.

rsync+ssh

Otro de los programas que puede hacer uso del ssh es rysnc. Rsync permite mantener dos directorios de maquinas diferentes sincronizados. Su protocolo hace que se envíe únicamente las diferencias entre los archivos.

Para especificar que usamos ssh para conectar entre las dos máquinas usamos el parámetro -e:

rsync -e ssh -avpz directorio_local usuario@servidor.dominio.es:directorio_destino