tags: ASO-GISI Sistemas Operativos

SSH


Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →


Introducción a SSH

La orden telnet se utiliza para la comunicación interactiva con otro ordenador utilizando el protocolo TELNET. Sin embargo telnet es poco utilizado en la actualidad dado que por defecto no encripta la información que intercambia (incluidas las contraseñas) y otros problemas de seguridad. En su lugar, se utiliza la orden ssh, que utiliza el protocolo SSH (de Secure Shell) para crear un canal de comunicación seguro (utilizando técnicas criptográficas) entre dos equipos que no depende de la seguridad de la red subyacente. SSH permite realizar login a máquinas remotas de forma segura, ejecución remota de programas, intercambio de ficheros, etc.

Encriptación y cifrado

La encriptación se basa en el cifrado con una clave de un mensaje cuyo contenido se quiere proteger. SSH utiliza tanto el cifrado simétrico como el cifrado asimétrico.

Cifrado simétrico

En el cifrado simétrico se utiliza la misma clave tanto para el cifrado como el descifrado. Esto significa que la clave debe ser secreta (conocida solo por el emisor y el receptor). El mayor problema de este cifrado es cómo puede hacer llegar el emisor al receptor la clave de forma segura.

Cifrado asimétrico

En el cifrado asimétrico se utilizan dos claves relacionadas entre sí: una privada (secreta) y otra pública. Las claves tienen la propiedad de que un mensaje cifrado por una determinada clave pública solo puede ser desencriptado utilizando la correspondiente clave privada (y si es encriptado con la clave privada, solo puede desencriptarse con la pública).

Esto permite que el emisor pueda utilizar la clave pública del receptor para encriptar el mensaje y solo éste pueda desencriptarlo. Por otro lado, si el propietario de la clave privada la utiliza para cifrar un mensaje, el destinatario (si la puede desencriptar con la clave pública del emisor) está identificando y autenticando al remitente.

Aunque el cifrado asimétrico soluciona el intercambio de claves entre los participantes en la comunicación, tiene varios problemas en comparación con el cifrado simétrico, como un mayor tamaño de los mensajes codificados y necesidad de un mayor tiempo de proceso.

Protocolo SSH

El protocolo SSH determina la secuencia de eventos para lograr una comunicación segura entre dos host. Resumidamente esta consiste en:

  • Handsake encriptado (usando cifrado asimétrico) para que el cliente pueda verificar que se está comunicando con el servidor.
  • La capa de transporte de conexión entre el cliente y la máquina remota se encripta mediante un código simétrico que se establece algorítmicamente sin necesidad de ser explícitamente intercambiado, lo cual aumenta la seguridad.
  • El cliente se autentica ante el servidor.
  • El cliente interactúa con la máquina remota sobre la conexión encriptada.

El servidor se identifica ante el cliente con una llave (o clave) de host única. La primera vez que se conecta el cliente la llave no existirá y será necesario que la valide el cliente (este es un paso crítico y debería asegurarse, quizás por otros medios, que la llave es correcta). Esta llave se guarda en el cliente y en sucesivas ocasiones vale para comprobar la identidad del servidor. En ciertos casos (por ejemplo, reinstalación de la máquina servidora o que se sospecha que la clave ha sido comprometida y se ha generado otra) puede variar esta llave y es necesario eliminar la guardada para aceptar la nueva.
Para más información ver, por ejemplo: https://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-ssh-conn.html

Claves del servidor

En el servidor, las claves de host se encuentran en el directorio /etc/ssh y su nombre comienza por ssh_host_. Al instalar los paquetes openssh-server y openssh-client automáticamente se generarán las llaves del host. Ej.:

$ ls -l /etc/ssh/ssh_host_*
-rw------- 1 root root  505 nov 17 23:13 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r-- 1 root root  173 nov 17 23:13 /etc/ssh/ssh_host_ecdsa_key.pub
-rw------- 1 root root  399 nov 17 23:13 /etc/ssh/ssh_host_ed25519_key
-rw-r--r-- 1 root root   93 nov 17 23:13 /etc/ssh/ssh_host_ed25519_key.pub
-rw------- 1 root root 2602 nov 17 23:13 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  565 nov 17 23:13 /etc/ssh/ssh_host_rsa_key.pub

Como se puede comprobar, tras ssh_host_ viene una palabra que indica el algoritmo de cifrado de la llave (ecdsa, ed25519, rsa) y luego _key para indicar que es una llave. Con estas condiciones aparecen dos ficheros, diferenciándose uno de otro porque uno termina en .pub (el que contiene la llave pública) y el otro no (el que contiene la llave privada). Nótese también que los permisos del fichero de la llave privada son más restringidos que los de la pública y es además de más tamaño.

Por ejemplo, los contenidos de los ficheros podrían ser:

$ cat /etc/ssh/ssh_host_ed25519_key
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAA[muchas más "letras"]bnR1AQI=
-----END OPENSSH PRIVATE KEY-----
$ cat /etc/ssh/ssh_host_ed25519_key.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKtFjC0t/wx30kIWyXsoyMVY2wL68k2k29KdelcgKzum root@ubuntu

Si ejecutamos lo siguiente, obtendremos el host fingerprint, que sirve para "validar" que la llave pública que nuestro cliente ssh recibe en la primera conexión es la "real" (también se puede copiar la clave pública del host e instalarla en nuestro cliente, con lo cual nos aseguramos de que es la válida):

$ cat /etc/ssh/ssh_host_ed25519_key.pub |cut -d" " -f2|base64 -d|md5sum
7a7ccf278a5cacfe3402a80907963ce6  -

Conexión por ssh sin contraseña

Es posible conectar por ssh a un host (y usar otras instrucciones basadas en SSH) sin necesitar de introducir una contraseña. Para identificarnos se usa, de nuevo, el sistema de llaves.
El proceso de configuración consiste básicamente en:

  • Generar en el cliente (donde vamos a ejecutar ssh) una llave (se puede hacer en Windows/puTTY con la utilidad puTTYgen.exe y en Linux con ssh-keygen).
  • Configurar el cliente ssh para que utilice la clave privada.
    Con puTTY, en el menú SSH->Auth se especificaría en el campo "Private key file for authentification" el fichero con la clave privada (se puede grabar la configuración de la conexión para que se cargue automáticamente cada vez que necesitamos conectarnos al host).
    Con Linux, desde el usuario desde el que nos conectaríamos ejecutaríamos lo siguiente:
$ mkdir ~/.ssh  #si no existe
$ chmod 700 ~/.shh #si los permisos no fueran correctos
$ vi ~/.ssh/config

y en ~/.ssh/config añadiríamos unas entrada similares a:

Host nombre
Hostname ip
User usuarioHostDestino
IdentityFile ~/.ssh/id_rsa

  • Configurar el host (servidor) para que utilice la clave pública. Para ello se ejecutaría en el host, con el usuario al que nos fuéramos a conectar con ssh, lo siguiente:
$ mkdir ~/.ssh  #si no existe
$ chmod 700 ~/.shh #si los permisos no fueran correctos
$ vi ~/.ssh/authorized_keys #añadir aquí el contenido del fichero de clave pública del cliente
$ chmod 644 ~/.ssh/authorized_keys #si los permisos no fueran correctos

Con esto, nos podríamos conectar de forma segura sin especificar la contraseña mediante ssh.

Seguridad de SSH

Nótese que la seguridad del sistema radica en:
1º Obtener de forma fiable por primera vez la llave pública del host al que nos vamos a conectar.
2º Tener a buen recaudo la llave privada.

Por otro lado, el aumento de la potencia de los ordenadores hace que los ataques de "fuerza bruta" puedan romper las llaves, razón por la cual se van "reforzando" periódicamente (por ejemplo, aumentando el número de bits de las mismas o utilizando nuevos y mejores algoritmos).