¡Descarga bat para putty y más Apuntes en PDF de Filosofía del Derecho solo en Docsity!
Acceso remoto por SSH
Introducción
Secure SHell es un protocolo que permite crear conexiones seguras entre dos ordenadores. Usando SSH, la máquina del cliente inicia una conexión con la máquina del servidor mediante una sesión cifrada, imposibilitando que alguien pueda obtener una contraseña de texto. El uso de SSH requiere el uso de Secure Socket Layer (SSL), que proporciona librerías criptográficas para establecer las comunicaciones cifradas.
SSH está diseñado para reemplazar tanto los métodos comunes de acceso remoto a un intérprete de comandos de otro ordenador, tales como rlogin ó telnet, como otros programas diseñados para copiar ficheros entre ordenadores como por ejemplo rcp ó ftp, pues estas aplicaciones no cifran las contraseñas entre el cliente y el servidor.
SSH proporciona los siguientes tipos de protección:
- Una vez se ha realizado una primera conexión a un servidor, el cliente puede verificar que se está conectando al mismo servidor durante posteriores sesiones.
- El cliente transmite su información de autenticación al servidor, como el nombre de usuario y la contraseña, en formato cifrado.
- Todos los datos enviados y recibidos durante la conexión se transfieren por medio de encriptación fuerte, lo cual los hacen extremamente difícil de descifrar y leer.
- El cliente tiene la posibilidad de usar X11 desde aplicaciones lanzadas desde el intérprete de comandos. Esta técnica proporciona una interfaz gráfica segura y un medio seguro para usar aplicaciones gráficas sobre una red.
Como el protocolo SSH cifra todo lo que envía y recibe, se puede usar para asegurar protocolos inseguros. 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 POP3, incrementando la seguridad del sistema y la privacidad de los datos.
Actualmente existen dos variedades diferentes de SSH, la versión 1 y la versión 2, siendo recomendable el uso de la versión 2, pues la versión 1 de SSH contiene algunos algoritmos de encriptación patentados5 y un agujero de seguridad que potencialmente permitiría la inserción de datos falsos en el flujo de datos.
Establecimiento de una conexión mediante SSH
El establecimiento de una conexión mediante SSH sucede en tres pasos sucesivos.
- Creación de una capa de transporte segura (TLS) para que el cliente sepa que se está comunicando con el servidor correcto. Luego se cifra la
comunicación entre el cliente y el servidor por medio de un código simétrico.
- Autenticación del cliente ante el servidor, sin preocuparse de que la información de autenticación pueda ponerse en peligro.
- Uso de la conexión establecida por los servicios que requieran una conexión segura, como pueden ser un intérprete de comandos, una aplicación X11 o un túnel TCP/IP.
Creación de la capa de transporte segura
El papel principal de la capa de transporte, que se ejecuta de forma normal sobre TCP/IP, es el de facilitar una comunicación segura entre los dos ordenadores tanto en el momento de la autenticación como con posterioridad.
Para ello, la capa de transporte verifica que el servidor sea la máquina correcta para la autenticación, se ocupa del cifrado y descifrado de la información y proporciona protección a la integridad de los paquetes de datos cuando son enviados y recibidos. Además, la capa de transporte también puede comprimir los datos a enviar, acelerando la transmisión de la información.
Al establecer la comunicación mediante SSH, un cliente negocia con el servidor varios aspectos que permitirán construir la capa de transporte correctamente. Esa negociación se produce en los siguientes pasos:
- Intercambio inicial de claves.
- Selección del algoritmo de clave pública utilizada.
- Selección del algoritmo de encriptación simétrico utilizado.
- Selección del algoritmo de autenticación de mensajes utilizado.
- Selección del algoritmo de hash utilizado.
El servidor se identifica ante el cliente con una clave de ordenador durante el intercambio de claves. Obviamente, si el cliente nunca se había conectado con el servidor, la clave del servidor le resultará desconocida al cliente. SSH evita este problema permitiendo que el cliente acepte la clave de ordenador del servidor la primera vez que se lleva a cabo una conexión SSH. Luego la clave de ordenador servidor se puede verificar con la versión guardada en el cliente en las siguientes conexiones, proporcionando la confianza que el cliente está realmente comunicando con el servidor deseado.
Después del intercambio inicial de claves, y de la selección de los algoritmos a utilizar, se crean dos valores, un valor de hash usado para intercambios y un valor de secreto compartido, y los dos sistemas empiezan inmediatamente a calcular claves y algoritmos nuevos para proteger la autenticación y los datos que se enviarán a través de la conexión en el futuro.
Después que una cierta cantidad de datos ha sido transmitida con un determinado algoritmo y clave (la cantidad exacta depende de la ejecución de SSH), ocurre otro intercambio de claves, el cual genera otro conjunto de valores de hash y otro valor de secreto compartido. De esta manera aunque un agresor lograse determinar los valores de hash y de secreto compartido,
diferente, tal vez para usar un tamaño de paquete máximo diferente o para transferir un determinado tipo de datos. Esto permite que SSH sea flexible en su modo de encargarse de los diferentes tipos de conexiones remotas, como el acceso telefónico en redes públicas o enlaces LAN de alta velocidad, sin tener que cambiar la infraestructura básica del protocolo.
Configuración de un servidor SSH
El servidor de SSH se es el programa /usr/sbin/sshd , siendo arrancado el servicio de SSH mediante el comando /sbin/service sshd start.
La configuración del servidor se realiza en el fichero /etc/ssh/sshd_config , si bien el fichero de configuración a utilizar puede modificarse mediante la opción -f. Un aspecto a destacar es que si el fichero de configuración por defecto no existe, o bien no existe el fichero especificado mediante la opción –f , el servicio de SSH no se ejecuta, mostrando un mensaje de error que indica la falta de un fichero de configuración.
Las opciones principales de configuración del servidor de SSH se encuentran en las siguientes tablas. En ellas, todas las opciones que se encuentran marcadas por el símbolo * indican que solo están disponibles para la versión 2 del protocolo SSH.
Además del fichero anterior, existen una serie de ficheros en el directorio /etc/ssh que son utilizados por el servidor de SSH. Estos ficheros son:
- moduli : Contiene grupos Diffie-Hellman usados para el intercambio de la clave mediante el algoritmo de Diffie-Hellman. Este intercambio de claves es imprescindible para la construcción de una capa de transporte segura. 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 ambas partes a la misma vez. Este valor se usa para proporcionar la autentificación del ordenador.
- ssh_host_key : La clave privada RSA usada por sshd en la versión 1.
- ssh_host_key.pub : La clave pública RSA usada por sshd en la versión 1.
- ssh_host_dsa_key : La clave privada DSA usada por sshd en la versión
- ssh_host_dsa_key.pub : La clave pública DSA usada por sshd en la versión 2.
- ssh_host_rsa_key : La clave privada RSA usada por sshd en la versión 2.
- ssh_host_rsa_key.pub : La clave pública RSA usada por sshd en la versión 2.
Cada vez que un servidor de SSH es instalado, se crea un conjunto nuevo de claves de identificación, con lo que cualquier cliente que ya conozca la clave de identificación del servidor mostrará un mensaje como:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@ @ 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.
Para evitar esto, el servidor debe mantener las claves antiguas del sistema y restaurarlas con posterioridad. Este proceso es tan sencillo como realizar una copia de seguridad de los ficheros /etc/ssh/ssh_hostkey y restaurarlos una vez ha sido reinstalado el servidor de SSH.
Creación de un par de claves pública/privada para acceso remoto
Como hemos podido ver, existe la posibilidad de permitir que un usuario acceda a un servidor de SSH utilizando autenticación basada en un par de claves pública/privada. La creación de este par de claves pública/privada se realiza mediante el comando:
ssh-keygen -t
Donde debe ser rsa1 para RSA de la versión 1 del protocolo y rsa ó dsa para RSA ó DSA de la versión 2 del protocolo.
En todos los casos, se nos solicitará una contraseña de acceso a la clave privada, la cual debe dejarse vacía si no se desea tener que introducirla cada vez.
Los ficheros creados en cada caso se encuentran en la tabla siguiente:
Cuando deseamos acceder a un ordenador remoto mediante este método, además de que el servidor remoto debe tener permitida la opción, debemos añadir al fichero ~/.ssh/authorized_keys en el usuario del servidor remoto la clave pública con la que deseamos acceder.
Configuración de un cliente SSH
El cliente de SSH existente en Linux es /usr/bin/ssh. La configuración por defecto del mismo se realiza mediante el fichero /etc/ssh/ssh_config , siendo sus principales opciones las expuestas en la tabla siguiente:
deseamos ejecutar, obteniendo una shell del sistema si no se especifica el comando. Si no se especifica ningún usuario, el cliente envía al servidor el nombre del usuario que somos en el ordenador cliente.
Por ejemplo, para acceder con el nombre del usuario actual al servidor rumba.integra.es , basta con escribir en el intérprete de comandos:
ssh rumba.integra.es
La primera vez que un usuario ejecuta ssh contra un servidor remoto, aparece un mensaje similar al siguiente:
The authenticity of host 'robotica.uv.es' can't be established. RSA 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)?
Si se escribe yes , se añadirá el servidor a la lista de ordenadores conocidos por el usuario ( ~/.ssh/known_host ), mostrándose el siguiente mensaje:
Warning: Permanently added ' rumba.integra .es' (DSA) to the list of known hosts.
A continuación, aparece un indicador de comandos preguntando la contraseña desde el ordenador remoto. Después de introducir la contraseña, se ejecutará un intérprete de comandos en el ordenador remoto.
Si deseamos especificar un nombre de usuario diferente, por ejemplo root , podemos escribir cualquiera de las dos opciones siguientes:
ssh -l David rumba.integra.es ssh [email protected]
Y si deseamos ejecutar un comando, por ejemplo ls /usr/share/doc en el ordenador rumba.integra.es , como usuario root , la línea de comandos es:
ssh [email protected] ls /usr/share/doc
Una vez que introduzca la contraseña correcta, se ejecutará el comando y se mostrará el contenido de /usr/share/doc , cerrando a continuación la conexión.
Transferencia de archivos mediante SSH
La transferencia de archivos entre dos ordenadores mediante SSH se puede realizar mediante dos programas, scp y sftp. El programa scp es similar a rcp , mientras que sftp es similar a ftp y pueden considerarse las versiones seguras de esos dos programas inseguros de transferencia de ficheros por la red.
El programa /usr/bin/scp se utiliza para transferir ficheros entre ordenadores de forma segura y cifrada. La sintaxis general, para transferir un fichero local a un sistema remoto es la siguiente:
scp fichero_local usuario@ordenador_destino:/fichero_remoto
fichero_local especifica el origen y usuario@ordenador_destino:/fichero_remoto especifica el destino. Por ejemplo, para transferir el fichero local enviar.txt a nuestra cuenta en rumba.integra.es , el comando es:
scp enviar.txt [email protected]:/home/usuario
Esto trasferirá el fichero local enviar.txt a /home/usuario/enviar.txt en el ordenador rumba.integra.es.
De forma similar, la sintaxis general para transferir un fichero remoto a un sistema local es:
scp usuario@ordenador_origen:/fichero_remoto fichero_local
Donde fichero_remoto especifica el origen, y fichero_local especifica el destino. Se pueden transferir varios ficheros diferentes del origen al destino. Por ejemplo, para transferir el contenido del directorio /descargar a un directorio existente llamado /descargados en el ordenador remoto rumba.integra.es , el comando es:
_scp /descargar/ [email protected]:/descargados/_*
Por su parte, el programa /usr/bin/sftp permite abrir una conexión segura e interactiva de FTP, pudiendo ejecutar cualquier comando disponible en FTP a través de esta conexión cifrada y por tanto segura.
sftp usuario@ordenador
Siendo solicitada la contraseña del usuario y, una vez aceptada dicha contraseña, ejecutar cualquier comando de FTP valido.
Reenvío de conexiones mediante SSH
Además de proporcionar una interfaz de línea de comandos segura, SSH permite redirigir conexiones X11 y puertos inseguros por un canal SSH previamente abierto.
Reenvío de X
En primer lugar, para poder realizar un reenvío de X11, el cliente de SSH debe estar ejecutando un servidor de X, pues en caso contrario las ordenes enviadas por la aplicación X que se ejecuta en el ordenador remoto no podrán ejecutarse al no encontrarse el servidor X que las interprete. Además, tanto el cliente como el servidor deben tener habilitada en su configuración la posibilidad de permitir el reenvío de X11.
Cuando un programa X se ejecuta desde un intérprete de comandos seguro, el cliente y el servidor SSH crean un nuevo canal seguro dentro de la conexión
En este ejemplo, se está reenviando la petición POP3 desde el puerto 1100 en el ordenador a través de una conexión SSH en el puerto 22 para tango.integra.es , el cual conecta a su vez con el puerto 110 de rumba.integra.es para permitir que se compruebe el correo. Mediante el uso de esta técnica, sólo es segura la conexión entre el ordenador local y tango.integra.es.
El reenvío del puerto se puede usar para obtener información segura a través de los cortafuegos de red, de forma que si un cortafuegos está configurado para permitir el tráfico SSH a través del puerto estándar (puerto 22), pero bloquea el acceso a través de otros puertos, es posible todavía una conexión entre dos ordenadores usando los puertos bloqueados al redirigir la comunicación sobre una conexión SSH establecida.
Ejercicios
- Configurar un servidor de SSH de forma que permita tan solo el uso de la versión 2 del protocolo y el acceso de los usuarios mediante la introducción de su usuario y contraseña, impidiendo el uso de cualquier otro método alternativo.
- Configurar un servidor de SSH que permita el uso de las versiones 2 y 1 del protocolo en este orden. El servidor deberá permitir el acceso a los usuarios del grupo “administración”, denegando el acceso al resto de usuarios.
- Un ordenador posee dos interfaces de red, uno público de IP 192.168.1.65 y otro privado de IP 192.168.2.15. Deseamos configurar el servidor de SSH de forma que escuche tan solo el interface de red público, debiendo permitir tan solo el uso de la versión 2 del protocolo y permitir el reenvío de conexiones X11.
- Un cliente de SSH desea conectarse a un servidor de forma que pueda reenviar conexiones X11. Indicar las configuraciones necesarias tanto del cliente como del servidor.
- Deseamos configurar un cliente y un servidor de SSH de forma que permitan el reenvío de puertos. Indicar las configuraciones necesarias en los ficheros.
- Deseamos que nuestro cliente de SSH pueda acceder a un servidor de SSH utilizando un par de claves pública/privada. Indicar tanto los ficheros de configuración del cliente y el servidor como los comandos necesarios para crear y manejar las claves.
- Un servidor, de nombre servidor.integra.es , dispone de un servicio no seguro ejecutándose en su puerto 13 TCP. Deseamos crear un canal seguro entre nuestro ordenador y el servidor para acceder a dicho servicio. Indicar el comando necesario si el servidor ejecuta el servicio de SSH y ambos ordenadores se encuentran configurados para permitir el reenvío de puertos.
