PROTOCOLO SSH MARTA BENÍTEZ GONZÁLEZ JOSÉ GUTIÉRREZ BENÍTEZ

PROTOCOLO SSH MARTA BENÍTEZ GONZÁLEZ JOSÉ GUTIÉRREZ BENÍTEZ 1

CONTENIDO Introducción Características Versiones del protocolo SSH Secuencia de eventos de una conexión SSH Archivos de configuración de OpenSSH Más que un SHELL seguro Requerir SSH para conexiones seguras OpenSSH (servidor y cliente) 2

Introducción SSH permite a los usuarios registrarse en sistemas de host remotamente. Encripta la sesión de registro imposibilitando que alguien pueda obtener contraseñas no encriptadas. Está diseñado para reemplazar los métodos más viejos y menos seguros para registrarse remotamente en otro sistema a través de la shell de comando, tales como telnet o rsh. 3

Características (I) SSH es un protocolo para crear conexiones seguras entre dos sistemas usando una arquitectura cliente/servidor. Proporciona los siguientes tipos de protección: El cliente puede verificar que se está conectando al servidor al que se conectó inicialmente. El cliente transmite su información de autenticación al servidor usando una encriptación robusta de 128 bits. Todos los datos enviados y recibidos durante la conexión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremamente difícil de descifrar y leer. El cliente tiene la posibilidad de enviar por X11 las aplicaciones lanzadas desde el intérprete de comandos del shell. Esta técnica proporciona una interfaz gráfica segura (reenvío por X11). 4

Características (II) El servidor SSH puede convertirse en un conducto para convertir en seguros los protocolos inseguros mediante el uso de una técnica llamada reenvío por puerto, como por ejemplo POP, incrementando la seguridad del sistema en general y de los datos. Muchas aplicaciones SSH cliente están disponibles para casi todos los principales sistemas operativos en uso hoy día. 5

Por qué usar SSH? Las amenazas se pueden catalogar del siguiente modo: Intercepción de la comunicación entre dos sistemas La parte interceptora puede interceptar y conservar la información, o puede modificar la información y luego enviarla al receptor al cual estaba destinada. Este ataque se puede montar a través del uso de un paquete sniffer una utilidad de red muy común. Personificación de un determinado host Un sistema interceptor finge ser el receptor a quien está destinado un mensaje. Si funciona la estrategia, el cliente no se da cuenta del engaño y continúa la comunicación con el interceptor como si su mensaje hubiese llegado a su destino satisfactoriamente. Esto se produce con técnicas como el envenenamiento del DNS o spoofing de IP. El cliente SSH y el servidor usan firmas digitales para verificar su identidad. Toda la comunicación entre los sistemas cliente y servidor es encriptada. 6

Versiones del protocolo SSH Existen dos variedades de SSH actualmente: La versión 1 de SSH Hace uso de muchos algoritmos de encriptación patentados y es vulnerable a un hueco de seguridad que potencialmente permite a un intruso insertar datos en la corriente de comunicación. La versión 2 de SSH La suite OpenSSH bajo Red Hat Linux utiliza la versión 2 por defecto. Importante Se recomienda que sólo se utilicen servidores y clientes compatibles con la versión 2 de SSH siempre que sea posible. 7

Secuencia de eventos de una conexión SSH La siguiente serie de eventos ayudan a proteger la integridad de la comunicación: Se lleva a cabo un 'handshake' encriptado para que el cliente pueda verificar que se está comunicando con el servidor correcto. La capa de transporte entre el cliente y la máquina remota es encriptada mediante un código simétrico. El cliente se autentica ante el servidor. El cliente remoto puede interactuar con tranquilidad con la máquina remota. 8

Secuencia de eventos de una conexión SSH EJEMPL0 1 EJEMPL0 2 [root@localhost ksh]# ssh a2554@pracgsi.ulpgc.es a2554@pracgsi.ulpgc.es's password: Last login: Fri May 7 20:39:08 2004 from 39.red-80-37-155.pooles.rima-tde.net [a2554@ftp0 a2554]$ ls Acampada mbox public_html 9

Capa de transporte (I) El papel principal de la capa de transporte es facilitar una comunicación segura entre los dos hosts en el momento y después de la autenticación. Se lleva a cabo manejando la encriptación y decodificación de datos y proporcionando protección de los paquetes de datos. Al contactar un cliente a un servidor, se negocian varios puntos importantes para que ambos sistemas puedan construir la capa de transporte correctamente. Se producen los siguientes pasos: - Intercambio de claves - Se determina el algoritmo de encriptación de la clave pública - Se determina el algoritmo de la encriptación simétrica - Se determina el algoritmo autenticación de mensajes - Se determina el algoritmo de hash que hay que usar 10

Capa de transporte (II) El servidor se identifica ante el cliente con una clave de host única durante el intercambio de claves. OpenSSH permite que el cliente acepte la clave de host del servidor después que el usuario sea notificado y verifique la aceptación de la nueva clave del host. Para las conexiones posteriores, la clave de host del servidor se puede verificar con la versión guardada en el cliente, proporcionando la confianza que el cliente está realmente comunicando con el servidor deseado. SSH fue ideado para funcionar con casi cualquier tipo de algoritmo de clave pública o formato de codificación. Después del intercambio de claves inicial se crea un valor hash usado para el intercambio y un valor compartido secreto. Después que una cierta cantidad de datos haya sido transmitida con un determinado algoritmo y clave, ocurre otro intercambio de claves, el cual genera otro conjunto de valores de hash y un nuevo valor secreto compartido. De esta manera aunque un agresor lograse determinar los valores de hash y de secreto compartido, esta información sólo será válida por un período de tiempo limitado. 11

Autenticación El servidor le dirá al cliente los diferentes métodos de autenticación soportados, tales como el uso de firmas privadas codificadas con claves o la inserción de una contraseña. El cliente intentará autenticarse ante el servidor mediante el uso de cualquiera de los métodos soportados. Luego, el servidor podrá decidir qué métodos de encriptación soportará basado en su pauta de seguridad, y el cliente puede elegir el orden en que intentará utilizar los métodos de autenticación entre las opciones a disposición. 12

Canales Múltiples canales son abiertos a través de la técnica llamada multiplexar. Cada uno de estos canales manejan la conexión para diferentes sesiones de terminal y para sesiones X11. Cada canal es asignado a un número diferente en cada punta de la conexión. Cuando el cliente intenta abrir un nuevo canal, los clientes envían el número del canal junto con la petición. Esto es hecho para que diferentes tipos de sesión no afecten una a la otra y así cuando una sesión termine, su canal pueda ser cerrado sin interrumpir la conexión SSH primaria. Los canales también soportan el control de flujo, el cual les permite enviar y recibir datos ordenadamente. De esta manera, los datos no se envían a través del canal sino hasta que el host haya recibido un mensaje avisando que el canal está abierto y puede recibirlos. El cliente y el servidor negocian las características de cada canal automáticamente. 13

Archivos de configuración de OpenSSH (I) OpenSSH tiene dos conjuntos diferentes de archivos de configuración: uno para los programas cliente (ssh, scp, y sftp) y otro para el demonio del servidor (sshd). La información de configuración SSH para todo el sistema está almacenada en el directorio /etc/ssh/: - Moduli. Contiene grupos Diffie-Hellman usados para el intercambio de la clave Diffie-Hellman. Cuando se intercambian las claves al inicio de una sesión SSH, se crea un valor secreto y compartido que no puede ser determinado por ninguna de las partes individualmente. Este valor se usa para proporcionar la autentificación del host. - ssh_config. Archivo de configuración del sistema cliente SSH por defecto que se sobreescribe si hay alguno ya presente en el directorio principal del usuario (~/.ssh/config). 14

Archivos de configuración de OpenSSH (II) - sshd_config. El archivo de configuración para el demonio sshd. - ssh_host_dsa_key. La clave privada DSA usada por el demonio sshd. - ssh_host_dsa_key.pub. La clave pública DSA usada por el demonio sshd. - ssh_host_key. La clave privada RSA usada por el demonio sshd para la versión 1 del protocolo SSH. - ssh_host_key.pub. La clave pública RSA usada por el demonio sshd para la versión 1 del protocolo SSH. - ssh_host_rsa_key. La clave privada RSA usada por el demonio sshd para la versión 2 del protocolo SSH. - ssh_host_rsa_key.pub. La clave pública RSA usada por el demonio sshd para la versión 2 del protocolo SSH. 15

Archivos de configuración de OpenSSH (III) [a2554@ftp0 a2554]$ cd /etc/ssh [a2554@ftp0 ssh]$ ls moduli ssh_host_dsa_key ssh_host_rsa_key.pub ssh_authorized_keys ssh_host_dsa_key.pub ssh_known_hosts ssh_authorized_keys2 ssh_host_key ssh_known_hosts2 ssh_config ssh_host_key.pub sshd_config ssh_host_rsa_key 16

Archivos de configuración de OpenSSH (IV) La información específica para el usuario está almacenada en el directorio principal ~/.ssh/: - authorized_keys. Este archivo que contiene una lista de claves públicas "autorizadas". - id_dsa. Contiene la clave privada DSA del usuario. - id_dsa.pub. Contiene la clave pública DSA del usuario. - id_rsa. La clave RSA privada usada por ssh para la versión 2. - id_rsa.pub. La clave pública RSA usada por ssh para la versión 2. - identity. La clave privada RSA usada por ssh para la versión 1. - identity.pub. La clave pública RSA usada por ssh para la versión 1. - known_hosts. Este archivo contiene las claves de host DSA de los servidores SSH accesados por el usuario. Este archivo es muy importante para asegurarse de que el cliente SHH está conectado al servidor SSH correcto. 17

Archivos de configuración de OpenSSH (V) [a2554@ftp0 a2554]$ [root@localhost root]# cd.ssh [root@localhost.ssh]# ls known_hosts [root@localhost.ssh]# vi known_hosts 192.168.200.100 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAy3NfQ2Xy7aoTG/bZ0Jt5I5oqUf2ivaXMJpIKQGtmEp+XKc8FbhF BkrNK4dGY/WYoFsf8cjkXlVAy3xvLDVH0j0NQlSmNeEicP4e2ZHb2V0cGjztro4beSH5fJsahKYkb/aHW7n u84amvgocqlhle5yoo8mc8jzyem6nksbdyews=pracgsi.ulpgc.es,193.145.141.36 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA02iPpdqam5aSYKX37KrAOYT/RY+Ze1iRwI/8gYV+5obPgE7KV G3D+criLJcENU0Ywyg7WDuZrMjJLzekwDE37lR33IeaHQwvFwKOfzPXg0vOYJ/nXE9vX7aRIPXYus3pD WFeHr8Xg+gKvb689RtJIhXfOUZOL6BLCNRp0qwWtV0=~ ~ [root@localhost.ssh]# 18

Reenvío por X11 Abrir una sesión X11 a través de una conexión SSH establecida es tan fácil como ejecutar un programa X en una máquina local. Cuando un programa X se ejecuta desde un intérprete de comandos de shell segura, el cliente y el servidor SSH crean un nuevo canal seguro dentro de la conexión SSH actual, y los datos del programa X se envían a través de ese canal a la máquina cliente de forma transparente. El reenvío por X11 es muy útil. Por ejemplo, se puede usar para crear una sesión segura e interactiva con up2date. Para hacer esto, conéctese al servidor usando ssh y escriba: up2date & Se le pedirá proporcionar la contraseña de root para el servidor. Luego aparecerá el Agente de actualización de Red Hat y permitirá al usuario actualizar con seguridad el sistema remoto. 19

Reenvío del puerto Con SSH se puede asegurar los protocolos TCP/IP a través del reenvío de puertos. Cuando se use esta técnica, el servidor SSH se convierte en un conducto encriptado para el cliente SSH. El reenvío de puertos funciona mediante el mapeado de un puerto local en el cliente a un puerto remoto del servidor. Para crearlo, hay que utilizar el siguiente comando: ssh -L local-port:remote-hostname:remote-port username@hostname Ejemplo: Si desea comprobar su correo en el servidor llamado mail.example.com usando POP a través de una conexión encriptada, use el comando siguiente: ssh -L 1100:mail.example.com:110 mail.example.com 20

Requerir SSH para conexiones remotas Para que SSH sea realmente eficaz, el uso de todos los protocolos de conexión inseguros como por ejemplo FTP y Telnet, deberían ser prohibidos. Algunos servicios a deshabilitar incluyen: -telnet -rsh -ftp - rlogin -vsftpd Para desactivar métodos de conexión inseguros al sistema, use el programa de línea de comandos chkconfig, el programa basado en ncurses ntsysv, o la aplicación gráfica Herramienta de configuración de servicios (redhat-config-services). Todas estas herramientas requieren acceso root. 21

OpenSSH OpenSSH es una implementación gratuita y de código libre de los protocolos SSH (Secure SHell). Esto sustituye a telnet, ftp, rlogin, rsh, y rcp con herramientas seguras y de conectividad de la red encriptada. OpenSSH soporta las versiones 1.3, 1.5, y 2 del protocolo SSH. Actualmente, OpenSSH, utiliza la versión 2, por defecto, el cual usa las claves RSA por defecto. 22

Por qué usar OpenSSH? Las utilidades OpenSSH, son más seguras, ya que en todas las comunicaciones, incluyendo contraseñas, son encriptadas. Telnet y ftp utilizan contraseñas de texto plano y envían toda la información sin encriptar. Otra razón por la que se recomienda usar OpenSSH es que automáticamente reenvía la variable DISPLAY a la máquina cliente. Es decir, si está ejecutando el sistema X Window en su máquina local, e ingresa a una máquina remota usando el comando ssh, cuando ejecute un programa en la máquina remota que requiera X, será visualizado en su equipo local. 23

Configurar un servidor OpenSSH El sistema debe tener los paquetes RPM instalados. Se requiere el paquete openssh-server que depende a su vez del paquete openssh. El demonio OpenSSH usa el archivo de configuración /etc/ssh/sshd_config. Por defecto, el archivo de configuración instalado es suficiente para numerosas configuraciones. En la página del manual sshd existe una lista de palabras reservadas para configurar el servidor con nuestra propia configuración. Para iniciar y parar un servicio OpenSSH, se usan los comandos: /sbin/service sshd start. /sbin/service sshd stop. Es posible arrancar el demonio automáticamente en el momento de inicio. 24

Problemas de reinstalación Si se reinstala un sistema Red Hat Linux, y clientes conectados a éste, antes de reinstalar con cualquiera de las herramientas OpenSSH, después de la reinstalación, los usuarios del cliente verán el siguiente mensaje: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. El sistema reinstalado crea un nuevo conjunto de claves de identificación para el sistema; de ahí, el aviso de que la clave del host RSA ha cambiado. Si se desea mantener las claves del host generadas para el sistema, se debe realizar una copia de seguridad de los archivos /etc/ssh/ssh_host*key* y restaurarlos después de reinstalar. Este proceso retiene la identidad del sistema, y cuando los clientes traten de conectarse al sistema después de la instalación, éstos no recibirán el mensaje de aviso. 25

Configuración cliente OpenSSH Uso del comando ssh (I) Se deben tener los paquetes openssh-clients y openssh instalados en la máquina cliente. El comando ssh permite iniciar sesiones y ejecutar comandos en máquinas remotas. Para iniciar una sesión remota a una máquina llamada penguin.example.net, se escribe el comando siguiente: ssh penguin.example.net La primera vez que ejecute ssh a una máquina remota, verá un mensaje similar al siguiente: The authenticity of host 'penguin.example.net' can't be established. DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c. Are you sure you want to continue connecting (yes/no)? 26

Configuración cliente OpenSSH Uso del comando ssh (II) Si se acepta, permite agregar el servidor en su lista de host conocidos. Luego, se verá un indicador de comandos preguntando por la contraseña. Después de introducir la contraseña, nos encontraremos en el indicador de comandos de la máquina remota. Si no se especifica un nombre de usuario, el nombre de usuario con el que se ha validado como la máquina local se validará en la máquina remota. Si se quiere especificar un nombre de usuario se usa el comando siguiente: ssh username@penguin.example.net El comando ssh se puede utilizar para ejecutar un comando en una máquina remota sin acceder al indicador de comandos. La sintaxis es: ssh hostname command. Por ejemplo => ssh penguin.example.net ls /usr/share/doc 27

Configuración cliente OpenSSH Uso del comando scp El comando scp puede ser usado para transferir archivos entre máquinas sobre una conexión encriptada y segura. La sintaxis general para transferir el archivo local a un sistema remoto es: scp localfile username@tohostname:/newfilename localfile especifica la fuente, y username@tohostname:/newfilename especifica el destino. La sintaxis general para transferir un archivo remoto al sistema local es: scp username@tohostname:/remotefile /newlocalfile remotefile especifica la fuente, y newlocalfile especifica el destino. Se puede especificar múltiples archivos como las fuentes. Por ejemplo, para transferir el contenido del directorio /downloads a un directorio existente llamado uploads en la máquina remota penguin.example.net: scp /downloads/* username@penguin.example.net:/uploads/ 28

Configuración cliente OpenSSH Uso del comando sftp La utilidad sftp puede ser usada para abrir una sesión segura interactiva de FTP. Es similar a ftp excepto que ésta utiliza una conexión encriptada segura. La sintaxis general es: Sftp username@hostname.com. Una vez autentificado, podrá utilizar un conjunto de comandos similar al conjunto utilizado por el comando FTP. La utilidad sftp sólo está disponible en las versiones 2.5.0p1 de OpenSSH y superiores. 29

Configuración cliente OpenSSH Generar pares de claves RSA v2 Si no se quiere introducir la contraseña cada vez que se conecte a una máquina remota con ssh, scp, o sftp, se puede generar un par de claves de autorización. Para generar las claves de un usuario, se deben seguir los siguientes pasos para cada usuario: 1. Para generar un par de claves RSA para trabajar con la versión 2 del protocolo: ssh-keygen -t rsa Aceptar la localización por defecto del archivo ~/.ssh/id_rsa. Introducir una palabra de paso diferente de la contraseña de la cuenta y confirmarla introduciéndola nuevamente. La clave pública se escribe en ~/.ssh/id_rsa.pub. La clave privada está escrita en ~/.ssh/ id_rsa, y no debe ser facilitada a nadie. 2. Cambiar los permisos del directorio.ssh usando el comando chmod 755 ~/.ssh. 3. Copiar el contenido de ~/.ssh/id_rsa.pub a ~/.ssh/authorized_keys en la máquina en la que se quiere conectar. Si el archivo ~/.ssh/authorized_keys no existe, se puede copiar el archivo ~/.ssh/id_rsa.pub al archivo ~/.ssh/authorized_keys en la otra máquina. 30

Configuración cliente OpenSSH Generar pares de claves DSA v2 1. Para generar un par de claves DSA, se escribe el siguiente comando: ssh-keygen -t dsa Aceptar la localización por defecto del archivo ~/.ssh/id_dsa. Introducir una palabra de paso diferente a la contraseña de la cuenta y confirmarla introduciéndola de nuevo. La clave pública es escrita en ~/.ssh/id_dsa.pub. La clave privada es escrita a ~/.ssh/ id_dsa. 2. Cambiar los permisos del directorio.ssh usando el comando chmod 755 ~/.ssh. 3. Copiar el contenido de ~/.ssh/id_dsa.pub a ~/.ssh/authorized_keys en la máquina en la cual quiere conectarse. Si el archivo ~/.ssh/authorized_keys no existe, puede copiar el archivo ~/.ssh/id_dsa.pub al archivo ~/.ssh/authorized_keys en la otra máquina. 31

Configuración cliente OpenSSH Pares de claves RSA v1.3 y v1.5 1. Para generar un par de claves RSA se escribe el comando siguiente: ssh-keygen -t rsa1 Aceptar la localización por defecto del archivo (~/.ssh/identity). Introducir una palabra de paso diferente a la contraseña de la cuenta y confirmarla introduciéndola de nuevo. La clave pública está escrita en ~/.ssh/identity.pub. La clave privada está escrita en ~/. ssh/identity. 2. Cambiar los permisos del directorio.ssh y la clave con los comandos chmod 755 ~/.ssh y chmod 644 ~/.ssh/identity.pub. 3. Copiar los contenidos de ~/.ssh/identity.pub al archivo ~/.ssh/authorized_keys en la máquina a la cual se desea conectar. Si el archivo ~/.ssh/authorized_keys no existe, se puede copiarlo desde ~/.ssh/identity.pub al archivo ~/.ssh/authorized_keys en el equipo remoto. 32

33