Contents

SSH (Secure SHell) [1] es un programa semejante al programa Telnet, pero que a diferencia de ’este, SSH cifra toda la comunicaci’on entre el cliente y el servidor. Para ello se vale de algoritmo de cifrado (o encriptaci’on) y posiblemente, compresi’on. SSH es muy utilizado para el acceso remoto a hosts, permitiendo a los usuarios trabajar como si estuvieran f’isicamente sentados frente el teclado del host remoto.

En esta pr’actica vamos a aprender a usar el conjunto de utilidades que pertenencen al paquete SSH.

La implementaci’on del SSH que vamos a utilizar en este m’odulo se llama OpenSSH (http://www.openssh.com) e incorpora, entre otras, las siguientes utilidades:

ssh:

Un cliente. El sustituto de Telnet.

sshd:

Un servidor.

scp:

(Secure CoPy). Una utilidad semejante a la utilidad rcp que permite copiar ficheros entre hosts remotos de forma segura.

sftp:

(Secure FTP). Una versi’on segura del programa Ftp.

sshfs:

(SSH File System). Una versi’on del NFS sobre SSH.

1 Algoritmos de cifrado

Los algoritmos de cifrado (o criptogr’aficos) se utilizan para esconder la informaci’on a aquel conjunto de personas que no deber’ian tener acceso a ella. La idea es muy simple y consiste en alterar la representaci’on de la informaci’on usando una clave (o key). As’i, s’olo quien conozca la clave es capaz de restaurar la representaci’on original (descrifrada) de la informaci’on.

Existen dos tipos distintos de algoritmo de cifrado, dependiendo del n’umero de claves que se utilizan:

Algoritmos de clave sim’etrica (privada):

Tambi’en se llaman algoritmos de clave secreta y se caracterizan por usar la misma clave para cifrar y descifrar. As’i, si enviamos un e-mail cifrado a alguien tambi’en tenemos que indicarle la clave que usamos para cifrarlo.

Algoritmos de clave asim’etrica (p’ublica):

Los sistemas de clave sim’etrica presuponen que el receptor conoce la clave secreta, pero, c’omo le hacemos llegar dicha clave s’olo a ’el a trav’es de un canal inseguro como puede ser Internet? Usando un algoritmo de clave sim’etrica es imposible.

Para evitar este problema se idearon los algoritmos de clave asim’etrica (o algoritmos de clave p’ublica). En ’estos, cada extremo de la comunicaci’on maneja dos claves, una p’ublica y otra privada (en total, 4 claves).¹ Se cumple que: (1) lo que se cifra utilizando la clave p’ublica que un interlocutor posee s’olo puede descifrarse con la clave privada que ’unicamente el otro interlocutor posee y (2) es imposible derivar una clave privada a partir de la correspondiente clave p’ublica (sin informaci’on adicional que s’olo se ha producido y tal vez olvidado por quien genera la clave p’ublica a partir de su clave privada² ).

As’i, cuando dos personas desean intercambiarse informaci’on primero deben intercambiar sus claves p’ublicas. Habiendo hecho esto, cuando yo (por ejemplo) deseo enviar un mensaje a alguien lo cifro usando la clave p’ublica de mi interlocutor. Dicho mensaje puede ser interceptado por una tercera persona, pero s’olo mi interlocutor va a ser capaz de descifrarlo porque es la ’unica persona que posee la clave privada que puede descifrarlo. De la misma manera, s’olo yo podr’e descifrar lo que mi interlocutor me env’ia porque s’olo yo poseo la clave privada que permite descifrar el mensaje.

2 Caracter’isticas del SSH

Existen dos versiones de SSH: la versi’on 1 y la versi’on 2. La segunda es la m’as evolucionada y utilizada. SSH permite adem’as comprimir el stream de datos al vuelo (on-the-fly). Con esto ganaremos en velocidad efectiva de tranmisi’on y aumentaremos la seguridad.

SSH usa DES (Data Encryption Standard) en su versi’on 1 y adem’as AES (Advanced Encryption Scheme) y Blowfish en su versi’on 2. DES es considerado el menos seguro y AES el m’as seguro. Debe tenerse en cuenta que el consumo de CPU ser’a proporcional al nivel de seguridad.

El SSH utiliza un algoritmo de clave sim’etrica para cifrar los datos que el cliente y el servidor se intercambian. Dicha clave se genera (de forma aleatoria) en el cliente y se env’ia al servidor usando un algoritmo de clave asim’etrica. Otro aspecto importante de SSH radica en que posee un sistema para autentificar a los extremos de la comunicaci’on (evita el spoofing). De esta manera, se asegura que tanto el emisor como el receptor son realmente quien dicen ser. ³ Veamos con un poco m’as de detalle c’omo se produce este proceso.

El SSH utiliza tres mecanismos (tres protocolos) [1]:

Transport Layer Protocol (TLP) [3]:

Autentifica el servidor, cifra la comunicaci’on y conserva la integridad de la informaci’on transmitida. Suele usar el TCP y adicionalmente puede comprimir los datos.

User Authentication Protocol (UAP) [2]:

Utiliza el TLP y autentifica el cliente al servidor.

Connection Protocol (CP) [4]:

Se ejecuta sobre el UAP y permite multiplexar muchos canales l’ogicos sobre un ’unico tunel cifrado.

A continuaci’on se presenta todo el proceso de comunicaci’on (http://es.tldp.org/Tutoriales/doc-ssh-intro/intro-ssh/node9.html) entre un cliente y un servidor (versi’on 2 del protocolo):

1. Fase de conexi’on TCP:
   1. El cliente establece una conexi’on TCP con el servidor.
2. Fase de identificaci’on del protocolo:
   1. Si el servidor acepta la conexi’on TCP env’ia al cliente un mensaje (no cifrado) que indica los par’ametros fundamentales de la conexi’on (como por ejemplo, la versi’on del protocolo SSH).
   2. El cliente env’ia al servidor otro mensaje con su propia informaci’on acerca de los par’ametros que desea utilizar en la comunicaci’on.
3. Fase de autentificaci’on del servidor:
   1. Si el servidor acepta las condiciones del cliente, el servidor env’ia su host key p’ublica, sin cifrar.
   2. El cliente comprobar’a que la host key recibida es igual a la que recibi’o en la ’ultima conexi’on con dicho servidor. Si es la primera vez que se conecta, mostrar’a la host key al usuario para que pueda, por ejemplo, telefonear al administrador del host remoto para preguntarle la host key. Si no es la primera vez y es diferente (el cliente mira en ~/.ssh/known_hosts), tambi’en mostrar’a la host key para evitar el posible spoofing.
   3. Si el cliente continua con la conexi’on, cifrar’a y almacenar’a la host key en ~/.ssh/known_hosts para futuras comprobaciones.
4. Fase de generaci’on de la clave de sesi’on:
   1. El cliente genera una clave de cifrado sim’etrica llamada session key y la cifra utilizando la host key p’ublica del servidor.
   2. El cliente env’ia la session key cifrada al servidor.
   3. El servidor descifra la session key utilizando su host key privada. En este punto ambos extremos conocen la clave de sesi’on que se utiliza para cifrar y descifrar el resto de la comunicaci’on.
5. Fase de identificaci’on y autentificaci’on del usuario (http://www.ssh.fi/support/documentation/online/ssh/adminguide/32/User_Authentication.html). Se intentar’an secuencialmente cada uno de los siguientes m’etodos⁴ :

   Autentificaci’on basada en el host del usuario: El usuario queda autentificado en estos casos:

   1. Si el host de usuario est’a en /etc/hosts.equiv o en /etc/ssh/shosts.equiv, y si el nombre del usuario es el mismo en la m’aquina local y en la m’aquina remota.
   2. Si los ficheros ~/.rhosts o ~/.shosts en el directorio home del usuario en la m’aquina remota contiene una entrada de la forma usuario_maquina_cliente@maquina_cliente.

   En cualquiera de estos casos es necesario que el fichero /etc/ssh/ssh_known_hosts o el fichero ~/.ssh/known_hosts contenga la host key p’ublica del cliente.

   Autentificaci’on de clave p’ublica: Para poder usar esta forma de autentificaci’on, el usuario en alguna sesi’on previa ha debido generar una clave p’ublica y otra privada (generalmente usando RSA). En dicha sesi’on previa, el usuario ha informado al servidor de su clave de usuario p’ublica. Durante esta fase de autentificaci’on el servidor genera un n’umero aleatorio (llamado challenge) que es cifrado usando la clave p’ublica que le envi’o el usuario. El cliente recibe el desaf’io, lo descifra usando su clave privada, y lo vuelve a cifrar usando la host key p’ublica del servidor. Finalmente se lo env’ia al servidor. El servidor lo descifra usando su host key privada y si el n’umero coindice, entonces el usuario queda autentificado.

   Autentificaci’on basada en password: Consiste en enviar un password que s’olo el usuario conoce (generalmente el password usado en la cuenta de la m’aquina remota). Dicho password viaja cifrado con la clave de sesi’on sim’etrica.

6. Fase de acceso al sistema remoto:
   1. El host remoto ejecuta un shell cuya entrada estandar es proporcionada por el servidor SSH y cuya salida es enviada al servidor SSH.
7. Fase de desconexi’on:
   1. Cuando el usuario realiza un logout, el shell en el host remoto muere y la conexi’on TCP se cierra.

3 Instalaci’on de SSH (cliente y servidor)

En Linux tenemos disponibles un servidor y un cliente SSH a trav’es del paquete OpenSSH (http://www.openssh.com). Su instalaci’on es muy sencilla:

Debian Linux:

 

root# apt-get install ssh

El demonio se llama ssh.

Fedora Core Linux:

 

root# yum install openssh

El demonio se llama sshd.

Gentoo Linux:

 

root# emerge openssh

El demonio se llama sshd.

4 Configuraci’on del servidor

El servidor SSH se configura modificando el fichero de configuraci’on (ojo con la d):

Dicho fichero est’a codificado en ASCII y suficientemente autocomentado. A continuaci’on comentaremos las diferentes opciones (m’as informaci’on en man sshd_config):

Port:

Puerto de escucha del servicio. 22 por defecto.

ListenAddress:

Direcciones que ser’an atendidas. Todas por defecto.

Protocol:

Versi’on del protocolo. 2 por defecto.

HostKey:

Especifica los ficheros con las host keys. /etc/ssh/ssh_host_rsa_key y /etc/ssh/ssh_host_dsa_key, por defecto.

UsePrivilegeSeparation:

Especifica si el fichero ~/.ssh/environment y las opciones environment= en el fichero ~/.ssh/authorized_keys son procesadas por sshd. Por defecto, no.

KeyRegenerationInterval:

Periodo de regeneraci’on del server key para la versi’on 1 del protocolo. Por defecto, 1 hora.

ServerKeyBits:

N’umero de bits de la server key para la versi’on 1 del protocolo. Por defecto 768 bits.

SyslogFacility:

Tipo de registro de actividades. Por defecto AUTH.

LogLevel:

Nivel de registro de actividades. Por defecto, INFO.

LoginGraceTime:

Tiempo de espera para la autentificaci’on. 120 segundos, por defecto.

PermitRootLogin:

Se permite acceder al root? Por defecto, s’i.

StrictModes:

Enviar ficheros con todos los permisos a todos los usuarios. S’i, por defecto.

RSAAuthentication:

Queremos usar RSA (versi’on 1)? S’i, por defecto.

PubkeyAuthentication:

Queremos usar clave p’ublica (versi’on 2)?. S’i, por defecto.

AuthorizedKeysFile:

Fichero con las claves para la autentificaci’on. ~/.ssh/authorized_keys, por defecto.

IgnoreRhosts:

Se ignoran los ficheros ~/.rhosts y ~/.shosts? S’i, por defecto.

RhostsRSAAuthentication:

Permitir la autentificaci’on por /etc/rhosts (versi’on 1). Por defecto, no.

HostbasedAuthentication:

Permitir la autentificaci’on por /etc/rhosts (versi’on 2). Por defecto, no.

IgnoreUserKnownHosts:

Poner a yes si no confiamos en el fichero ~/.ssh/known_hosts para la RhostsRSAAuthentication.

PermitEmptyPasswords:

No, por defecto (y no se recomienda poner yes).

ChallengeResponseAuthentication:

Habilita los passwords “challenge-response”. Por defecto, no.

PasswordAuthentication:

Permite deshabilitar los passwords en texto plano cuando se est’a utilizando tunneling. No, por defecto (los passwords est’an cifrados, por defecto).

KerberosAuthentication:

Usar Kerberos para autentificar los usuarios. Por defecto, no.

KerberosOrLocalPasswd:

Opci’on “OrLocalPasswd” cuando utilizamos Kerberos. Por defecto, s’i.

KerberosTicketCleanup:

Opci’on “TicketCleanup” cuando utilizamos Kerberos. Por defecto, s’i.

KerberosGetAFSToken:

Opci’on “GetAFSToken” cuando utilizamos Kerberos. Por defecto, no.

GSSAPIAuthentication:

Usar GSSAPI para autentificar los usuarios. Por defecto, no.

GSSAPICleanupCredentials:

Opci’on “CleanupCredentials” cuando utilizamos Kerberos. Por defecto, s’i.

X11Forwarding:

Redirigir la conexi’on TCP usada por el servidor X-Window. S’i, por defecto. As’i, cuando accedamos al host remoto desde una consola gr’afica (un xterm, por ejemplo) y ejecutemos una aplicaci’on gr’afica, ’esta aparecer’a en nuestro sistema de ventanas.

X11DisplayOffset:

Offset por defecto para la variable de entorno DISPLAY que controla el display gr’afico utilizado por las aplicaciones gr’aficas.⁵ Por defecto, 10.

PrintMotd:

El fichero /etc/motd es un mensaje de bienvenida codificado en ASCII y que es mostrado cuando accedemos a trav’es del terminal remoto. Por defecto, no usar.

PrintLastLog:

Imprimir la salida m’as reciente del comando de lastlog que se utiliza para saber desde d’onde nos conectamos al servidor la ’ultima vez que utilizamos SSH. Por defecto est’a a yes.

TCPKeepAlive:

Enviar peri’odicamente mensajes “TCP keepalive”. De esta manera si la conexi’on falla los extremos son notificados y el terminal no se “cuelga”. Por defecto, s’i.

UseLogin:

Usar la utilidad login para la autentificaci’on? Por defecto, no.

MaxStartups:

Especifica el n’umero m’aximo de conexiones concurrentes sin autentificar que ser’an permitidas. Por defecto, 10.

Banner:

El banner es un mensaje que puede enviarse antes de iniciarse la conexi’on con el servidor (para avisar, por ejemplo, que se est’a accediendo a un sitio muy chungo :-). Esta opci’on indica la localizaci’on del fichero ASCII que contiene dicho mensaje.

AcceptEnv:

Especifica qu’e variables para la configuraci’on local del lenguaje van a ser aceptadas. Por defecto, todas.

Subsystem:

Permite especificar la localizaci’on en el sistema de ficheros de una determinada utilidad a usar con SSH. Normalmente se utiliza para indicar el fichero que contiene la utilidad sftp.

UsePAM:

Autentificar al usuario utilizando el Pluggable Authentication Module. Por defecto, s’i.

Tras modificar el fichero de configuraci’on del servidor SSH es necesario relanzar el servicio (v’ease el Ap’endice ??).

5 Configuraci’on del cliente

El cliente SSH (ssh) utiliza el fichero de configuraci’on:

y dem’as, el fichero:

si es que existe. Los par’ametros especificados en ’el prevalecen sobre el fichero ssh_config. La informaci’on completa sobre este fichero puede obtenerse mediante man ssh_config.

Ve’amos las principales opciones que podemos configurar:

Host:

Especifica el host al que se aplican los par’ametros que aparecen a continuaci’on. Un “*” (que es el valor por defecto) referencia a todos los hosts. N’otese que los sistemas en los que comparte el directorio “/etc” (que t’ipicamente se monta v’ia NFS) esto puede ser muy ’util.

ForwardAgent:

Indica si la conexi’on con el agente de autentificaci’on (si es que existe) ser’a redirigido a la m’aquina remota. Por defecto, no.

ForwardX11:

Se utiliza para hacer que las conexiones X11 sean autom’aticamente redirigidas sobre el canal seguro (utilizando la variable de entorno DISPLAY). Por defecto es que no.

ForwardX11Trusted:

Especifica si el cliente X11 tendr’a acceso sin restricciones al servidor. Por defecto es que s’i tendr’a acceso total.

RhostsRSAAuthentication:

Especifica si usar el fichero rhosts con RSA (ver configuraci’on del servidor). Por defecto, no.

RSAAuthentication:

Especifica si usar RSA authentication (ver configuraci’on del servidor). Por defecto, s’i.

PasswordAuthentication:

Indica si usar autentificaci’on basada en password. Por defecto, s’i.

HostbasedAuthentication:

Especifica si usar la autentificaci’on basada en rhosts con la autentificaci’on de clave p’ublica. Por defecto, no.

BatchMode:

Permite deshabilitar la pregunta sobre el password. Por defecto, no.

CheckHostIP:

Por defecto est’a habilitada. Si se deshabilita el cliente SSH no comprobar’a si el servidor figura en el fichero /etc/ssh/ssh_known_hosts. Esto permite detectar el DNS spoofing (el que alguien inserte en el DNS una IP falsa para un host).

AddressFamily:

Tipos de direcciones IP aceptadas. Por defecto any.

ConnectTimeout:

El TCP utiliza un temporizador para mantener activa la conexi’on enviando un paquete de datos vac’io, aunque no exista actividad. Con esta opci’on hacemos que sea el SSH el que se encarge de este proceso, en lugar del TCP. Un valor a 0 indica que esta opci’on seguir’a siendo controlada por el TCP.

StrictHostKeyChecking:

Si este flag se activa a yes, el cliente SSH no añadir’a el key host al fichero ~/.ssh/known_hosts, y por tanto, recharar’a la conexi’on con aquellos hosts que hallan cambiado su host key (por ejemplo, porque han reinstalado el sistema operativo).

IdentityFile:

Especifica el fichero con el identificador DSA. En la versi’on 1 del protocolo apunta al fichero ~/.ssh/identity. En la versi’on 2 puede apuntar al fichero ~/.ssh/id_rsa o al fichero ~/.ssh/id_dsa, dependiendo del algoritmo de cifrado usado.

Port:

Puerto donde espera encontrar al servidor. 22, por defecto.

Protocol:

Versi’on del protocolo. 2, por defecto.

Cipher:

Especifica el cifrador en la versi’on 1 del protocolo. Por defecto, 3des.

Ciphers:

Cifradores para la versi’on 2, por orden de preferencia. Por defecto, aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc.

EscapeChar:

Por defecto vale el car’acter ~ (<Alt Gr> + <4>) y se utiliza para realizar acciones como terminar la conexi’on (~.), enviar un BREAK al sistema remoto (~B), acceder al interprete de comandos del cliente (~C), mostrar las conexiones redirigidas (~#), etc.

Tunnel:

Esta opci’on por defecto vale no y se utiliza para evitar tener que utilizar la capa de red del TCP/IP. Los otros posibles valores son: yes, point-to-point y ethernet.

TunnelDevice:

Selecciona el interface de red sobre el que realizar el tunneling. Por defecto, any:any.

PermitLocalCommand:

Controla la posibilidad de ejecutar comandos en la m’aquina local (no en la remota) usando la secuencia de escape  C. Por defecto, no.

SendEnv:

Sirve para especificar el contenido de una variable de entorno (generalmente LANG que controla el lenguaje utilizado en el shell).

HashKnownHosts:

Se usa para aplicar un hashing sobre los nombres de host y direcciones que se especifican en ~/.ssh/known_hosts. No, por defecto.

GSSAPIAuthentication:

Permitir autentificaci’on GSSAPI. Por defecto, no.

6 Uso de SSH

SSH es uno de los programas con los que tendremos que lidiar todos los d’ias que estamos trabajando con m’aquinas modernas con Unix o Linux. Ve’amos algunos ejemplos de uso t’ipicos.

6.1 Accediendo a un host remoto

Para acceder al host remoto utilizamos el cliente ssh. En ese momento se producir’a el proceso de autentificaci’on del servidor y el proceso de identificaci’on y autentificaci’on del usuario. Dependiendo del esquema de autentificaci’on de usuario existen distintas alternativas:

Autentificaci’on basada en password:

Suele ser la forma m’as corriente de acceder al host remoto:

alumno$ ssh host_remoto

Con este comando estamos accediendo al host utilizando el usuario alumno. Cuando queramos acceder con otro nombre de usuario utilizaremos:

alumno$ ssh otro_nombre_de_usuario@host_remoto

Autentificaci’on basada en clave p’ublica:

Como indicamos en la Secci’on 2, el usuario se autentifica probando que es capaz de firmar (descifrar y cifrar) el desaf’io que le plantea el servidor. Para poder hacer esto son necesarios los siguientes pasos:

1. Generar las claves de autentificaci’on:
   # Por curiosidad mostramos el contenido del directorio "~/.ssh".  
   alumno$ ls -l $HOME/.ssh/  
   total 4  
   -rw-r--r-- 1 alumno alumno 1866 2007-02-08 15:12 known_hosts  
    
   # Generaci’on de la clave usando RSA.  
   alumno$ ssh-keygen -t rsa  
   # Selecionar el fichero de salida que se especifica por defecto.  
   # La clave deber’ia tener al menos 20 caracteres seleccionados de  
   # forma aleatoria para considerarse segura.  
    
   # Por curiosidad mostramos el contenido del directorio "~/.ssh".  
   alumno$ ls -l $HOME/.ssh/  
   total 12  
   -rw------- 1 alumno alumno 1743 2007-02-08 22:19 id_rsa  
   -rw-r--r-- 1 alumno alumno  405 2007-02-08 22:19 id_rsa.pub  
   -rw-r--r-- 1 alumno alumno 1866 2007-02-08 15:12 known_hosts  
    
   # Comprobamos que la clave p’ublica se ha generado.  
   alumno$ cat ~/.ssh/id_rsa.pub  
   ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5HgtUR6OfvEIUv6m2xXM6QK3MH0Z6\  
   74btlJ20XDTAfh0llRgiDxnqrH492ZwH0r6EjVfkH6KhB9R2Duxvpzp4LeBWZ0ouL\  
   E5MiJBe0aR7CBUcjkq8FzLL3Caf0c7w3Dbtldn4zQdIoHswsD8sFyk2vT4a3QXBV/\  
   U3Q0DvCXyb5kZp7JOfzNAMJbCD6IVEbDrwqfu4JfTOXAWY8ckofq9zFK+JtkB9XJy\  
   a7pVJVtI0dKCnVTw3oU4eufj4OxwSGnAyVrf9rEv6jB+4R7tCQZdtuJO7SPAUbJsc\  
   rD4qjnOz/BDvx2LUQuQXMrbr7GQ+lBNC6gZWcUF33RGc+wIAjvR8Q==\  
    alumno@debian

2. Enviar la clave p’ublica al servidor:
   # A\~nadimos la clave p’ublica a nuestro fichero de claves p’ublicas en el  
   # host remoto.  
   alumno$ ssh <host_remoto> "mkdir .ssh/; \  
   umask 077; cat >> .ssh/authorized_keys" < ~/.ssh/id_rsa.pub

En este punto deber’iamos tener ya acceso al host remoto. Para ello se nos preguntar’a por la frase que usamos cuando generamos las claves de autentificaci’on. Esta forma de autentificaci’on s’olo se establecer’a cuando accedemos desde el host local usando el usuario alumno. Si accedemos desde otro host o con otro nombre de usuario, se utiliza la autentificaci’on mediante password.

Autentificaci’on basada en el host del usuario:

Para habilitar esta forma de autentificaci’on debemos tener acceso al host remoto como administrador. Estos son los pasos:

1. Acceder al host remoto y comprobar que HostbasedAuthentication = yes y que IgnoreRhosts = no en el fichero /etc/ssh/sshd_config.
2. Reiniciar el servidor SSH en el host remoto si se ha tenido que modificar su configuraci’on.
3. Copiar la host key p’ublica del cliente en el servidor. La clave p’ublica en el cliente se almacena en /etc/ssh/ssh_host_rsa_key.pub. Dicha clave debe ser añadida al fichero /etc/ssh/ssh_known_hosts o al fichero ~/.ssh/known_hosts.
4. En el servidor, añadir el nombre del host cliente al fichero ~/.shosts.
5. En el cliente, asegurarse de que HostbasedAuthentication = yes (fichero /etc/ssh/ssh_config o fichero $HOME/.ssh/config).
6. En el cliente, asegurarse de que la host key privada y p’ublica existen. Esta informaci’on deber’ia estar en los ficheros /etc/ssh/ssh_host_rsa_key y /etc/ssh/ssh_host_rsa_key.pub, respectivamente.

Debido a que necesitamos disponer de la clave de root en el host remoto, esta forma de autentificaci’on es poco corriente. Adem’as, como veremos a continuaci’on, la autentificaci’on basada en clave p’ublica es muy c’omoda y segura si utilizamos un agente SSH.

6.2 Usando ssh-agent y ssh-add

Para que la identificaci’on basada en clave p’ublica sea realmente segura la frase que usemos para generar la clave de autentificaci’on debe ser suficientemente larga (20 caracteres o m’as). Esto puede suponer un embrollo cuando accedemos muchas veces al host remoto.

Para solucionar este problema, el SSH incorpora un demonio llamado ssh-agent que se encarga de escribir por nosotros las frases. Este demonio puede ser invocado por el usuario de la siguiente manera:

Una vez que el demonio est’a ejecut’andose, informarle de nuestra clave de autentificaci’on p’ublica es sencillo:

En este punto, accederemos al host remoto sin necesidad de escribir la frase de acceso porque ssh-agent lo ha hecho por nosotros.

Evid’entemente, como podemos tener acceso a distintas m’aquinas con distintas frases de acceso, podemos usar tantas veces ssh-add como deseemos. Para saber qu’e frases son admistradas en un momento dado por ssh-agent:

Las frases puede ser eliminadas del demonio usando:

Usar man ssh-add para ver el resto de opciones.

6.3 Ejecuci’on de comandos en el host remoto

Con SSH es posible ejecutar comandos no interactivos en el host remoto. Un ejemplo:

6.4 Verificaci’on de la host key

Como vimos al comienzo de esta pr’actica, SSH incorpora un mecanismo para autentificar al servidor basado en la comparaci’on de la host key que env’ia el servidor con la que hay almacenada en el fichero ~/.ssh/known_hosts. Si es la primera vez que nos conectamos o por alg’un motivo, la host key ha cambiado, es una buena costumbre que comprobemos que dicha clave coindice con la que el servidor generar’ia utilizando las herramientas del SSH. Para mostrar la host key en el servidor podemos utilizar el siguiente comando:

En el fichero /etc/ssh/ssh_host_rsa_key.pub se almacena la host key p’ublica de forma cifrada usando el algoritmo RSA. En el fichero /etc/ssh/ssh_host_rsa_key se almacenan la host key privada de forma cifrada usando el algoritmo RSA.

6.5 Copiando ficheros

SSH incorpora una utilidad semejante a cp para copiar ficheros entre hosts de una forma muy sencilla. Algunos ejemplos:

6.6 SSH forwarding

El SSH tiene la habilidad de multiplexar varias conexiones sobre un mismo tunnel cifrado. A esta propiedad se le conoce como forwarding (encaminamiento). Ve’amos algunos ejemplos interesantes:

6.6.1 Forwarding del agente de autentificaci’on

Como vimos anteriormente, el agente de autentificaci’on es muy ’util para lidiar con las frases de clave. El problema es que si hemos accedido a un host remoto A y desde ’el queremos acceder a otro B usando de nuevo el agente, deber’iamos ejecutarlo en A y añadirle las frases. Para conseguir esto podemos hacer dos cosas:

1. Configurar nuestro cliente para que redirija el agente:
   # Tambi’en vale el fichero /etc/ssh/ssh_config  
   alumno$ cat ~/.ssh/config  
   :  
   Host host_remoto  
   ForwardAgent yes  
   :

2. Invocar al cliente mediante:
   # Este comando lanzar’a ssh-agent en el host remoto y copiar’a las claves.  
   alumno@host_local$ ssh -A <host_remoto>

Para verificar que el redireccionamiento ha funcionado, comprobaremos que el agente en el host remoto contempla nuestras claves:

6.6.2 Redireccionamiento del X11

Cuando usamos SSH desde una consola gr’afica, podemos ejecutar aplicaciones gr’aficas en el host remoto y presentarlas en el host local. Para conseguir esto debemos:

1. Configurar nuestro cliente para que rediriga el X11:
   # Tambi’en vale el fichero /etc/ssh/ssh_config  
   alumno$ cat ~/.ssh/config  
   :  
   Host host_remoto  
   ForwardX11 yes  
   :

2. Invocar al cliente mediante:
   alumno@host_local$ ssh -X host_remoto

En este punto podr’iamos ejecutar una aplicaci’on gr’afica, un xterm, por ejemplo:

6.6.3 Redireccionamiento de puertos

El redireccionamiento de puertos es una caracter’istica util’isima de SSH. Con esto podemos acceder a servicios que est’an filtrados por un cortafuegos y cifrar transmisiones sobre redes no seguras.

Antes de mostrar c’omo se realiza el redireccionamiento, una aclaraci’on importante. El objetivo del redireccionamiento es codificar la comunicaci’on desde nuestro host a otro distinto, situado fuera de nuestra red “segura”. En este sentido podemos encontrarnos los siguientes contextos:

• Que el host que ejecuta el servicio (llam’emoslo host X) no tiene un servidor SSH instalado o no tenemos cuenta de usuario en ’el. En este caso deber’iamos tener una cuenta en otro host Y situado en la misma red segura que el host X que ejecuta el servicio, y el redireccionamiento se realizar’ia desde nuestro host al host Y usando una transmisi’on segura, y desde el host Y al host X usando una transmisi’on insegura, pero a trav’es de la red que se considera segura. Usaremos el t’ermino redireccionamiento local indirecto para referirmos a esta posibilidad.
• Que tenemos cuenta de usuario en el host que ejecuta el servicio. En este caso s’olo tenemos que redireccionar el puerto desde nuestro host al host remoto. Llamaremos a esta forma de redireccionamiento, redireccionamiento local directo.
• Con SSH es posible utilizar servicios que est’an tras un cortafuegos que no permite las conexiones SSH entrantes (desde Internet hacia la red protegida). Esto puede hacerse con el redireccionamiento remoto. Para ello debemos tener acceso f’isico al host que ejecuta el servicio y redirigir el puerto del servicio a un puerto en el host que est’a fuera de la red protegida.

Bien, una vez hechas estas aclaraciones explicaremos c’omo redireccionar puertos en cada caso. En los ejemplos que se muestran a continuaci’on supondremos que hemos configurado nuestro navegador Web para que utilize un proxy Web situado en nuestro host (local_host) escuchando en el puerto 1234, aunque dicho servidor est’e realmente ejecut’andose en un host remoto que llamaremos squid_host y al que tenemos acceso mediante SSH. Supondremos adem’as que en la red local (y por tanto, segura) de squid_host existe otro host remoto remote_host en el que tambi’en tenemos cuenta.

Redireccionamiento local directo:

 

# La forma est’andar es:  
alumno@local_host$ ssh -L 1234:squid_host:3128 squid_host  
 
# Aunque tambi’en funciona:  
alumno@local_host$ ssh -L 1234:localhost:3128 squid_host

Con este ejemplo, hemos redirigido el puerto 1234 del local_host al puerto 3128 de host squid_host.

Redireccionamiento local indirecto:

 

alumno@local_host$ ssh -L 1234:squid_host:3128 remote_host

En este ejemplo el puerto 1234 del host local se ha redirigido al puerto 3128 del host squid_host a trav’es del host remote_host.

Redireccionamiento remoto:

 

alumno@squid_host$ ssh -R 1234:localhost:3128 local_host

Redireccionamos el puerto 3128 del host squid_host al puerto 1234 del host local_host. Ojo, que local_host no es en realidad local ahora (lo ser’ia desde el punto de vista de haber hecho el redireccionamiento de forma local).

7 Montaje de un sistema de ficheros remoto

Si tenemos una cuenta de usuario en el host remoto, es muy sencillo acceder a un fichero o a un directorio en dicho host:

Debian’s:

 

local_host@root# apt-get install sshfs

Red Hat’s:

 

local_host@root# yum install sshfs

References