SSH: Shell seguro

SSH significa Secure Shell. También se le conoce como Secure Socket Shell. Se utiliza un protocolo de red criptográfico llamado Secure Shell (SSH) para operar de forma segura servicios de red en redes inseguras. La arquitectura del servidor cliente es la base de las aplicaciones SSH, que vinculan una instancia de cliente SSH con un servidor SSH.

Como sucesor de Telnet y protocolos de shell remotos inseguros de Unix como Berkeley Remote Shell (rsh) y sus protocolos rlogin y rexec asociados, SSH se creó para sistemas operativos similares a Unix que emplean comunicación de token de autenticación de texto plano no segura.

Definición

Podemos aplicar SSH de varias maneras diferentes. La implementación más simple cifra los datos utilizando pares de claves públicas y privadas generadas automáticamente en ambos extremos de un canal de comunicación y una conexión de red. Después de eso, autentica al usuario mediante una contraseña. Cuando un usuario genera manualmente un par de claves pública-privada, la autenticación prácticamente se completa cuando se establece el par de claves, lo que permite iniciar una sesión instantáneamente sin solicitar una contraseña.

arquitectura de la colmena

En este caso, el propietario mantiene en secreto la clave privada correspondiente y la clave pública se instala en todas las máquinas que deben otorgar acceso al propietario. Aunque la clave privada sirve como base para la autenticación, la clave nunca se envía a través de la red al realizar la autenticación. SSH confirma que el proveedor de la clave pública también posee la clave privada correspondiente.

Conectar la clave pública desconocida con una clave privada conocida en todas las versiones de SSH es crucial antes de aceptarlas como claves públicas legítimas con ID. Aceptar una clave pública de un atacante sin validarla aceptará a un atacante que no es de confianza como usuario legítimo.

Creación

Tatu Ylönen, un informático finlandés, creó SSH por primera vez en 1995. El desarrollo posterior del conjunto de protocolos tuvo lugar en muchos grupos de desarrolladores, lo que dio lugar a varias iteraciones de implementación. Hay implementaciones disponibles para todos los sistemas operativos populares, incluidos los sistemas integrados. OpenSSH, que los creadores de OpenBSD pusieron a disposición como software de código abierto en 1999, es el paquete de software más utilizado.

Gestión de claves OpenSSH para autenticación

La lista de claves públicas aprobadas se mantiene comúnmente en sistemas tipo Unix en el archivo ~/.ssh/authorized key en el directorio de inicio del usuario, que tiene privilegios de inicio de sesión remoto. SSH sólo respeta este archivo si nadie más que el propietario y el root no puede modificarlo. La contraseña ya no es necesaria cuando están presentes tanto la clave pública del extremo remoto como la clave privada coincidente del extremo local. Pero podemos usar una frase de contraseña para bloquear la clave privada y obtener mucha más protección. También podemos buscar el código secreto en ubicaciones comunes y podemos usar una opción de línea de comando para proporcionar su ruta completa (opción -i para ssh).

SSH además proporciona autenticación basada en contraseña cifrada y generación automatizada de claves. En este escenario, el atacante puede hacerse pasar por el servidor confiable, solicitar la contraseña y obtenerla (ataque de intermediario). Del lado del servidor, podemos desactivar la autenticación de contraseña.

Usar

SSH utiliza el paradigma cliente-servidor. Normalmente, SSH se utiliza para iniciar sesión. También puede hacer túneles en puertos TCP, reenviar conexiones X11 y ejecutar comandos en un sistema remoto. Normalmente, las conexiones a un demonio SSH que permiten conexiones remotas se realizan mediante una aplicación cliente SSH. Ambos se encuentran a menudo en la mayoría de los sistemas operativos contemporáneos, como macOS, distribuciones de Linux, OpenBSD, FreeBSD, NetBSD, Solaris y OpenVMS. Algunas versiones son propietarias, gratuitas y de código abierto con distintos grados de complejidad y amplitud (como PuTTY y la versión de OpenSSH incluida con Cygwin y OpenSSH). En particular, SSH no se incluye de forma predeterminada en las versiones de Windows hasta la versión 1709 de Windows 10.

La aplicación de Windows gratuita y de código abierto WinSCP, que utiliza PuTTY como back-end, ofrece una funcionalidad similar de administración de archivos (sincronización, copia y eliminación remota). Sin necesidad de instalarlos en la computadora cliente, WinSCP y PuTTY están disponibles empaquetados para funcionar directamente desde una unidad USB. A menudo es necesario habilitar una función en la aplicación de configuración para configurar un servidor SSH en Windows.

Para manejar los problemas de conexión y prevenir los riesgos de seguridad de exponer directamente una máquina virtual basada en la nube a Internet, SSH es crucial en la computación en la nube. Se puede hacer posible una conexión segura a Internet a través de una computadora virtual con túnel SSH a través de un firewall. Para este protocolo, la IANA ha designado el puerto TCP 22, el puerto UDP 22 y el puerto SCTP 22.

Ya en 2001, la IANA clasificó el puerto TCP 22 predeterminado para servidores SSH como uno de los puertos más conocidos. El protocolo de capa de transporte orientado a conexión SCTP se puede utilizar para ejecutar SSH en lugar de TCP.

Progresión histórica

Iteración 1

Un ataque de rastreo de contraseñas en la red de su institución inspiró a Tatu Ylönen, un investigador de la Universidad Tecnológica de Helsinki en Finlandia, a crear la iteración inicial del protocolo (hoy conocido como SSH-1) en 1995.

SSH fue diseñado para asumir el papel de protocolos anteriores, incluidos rlogin, TELNET, FTP y rsh, que carecían de garantías sólidas de autenticación y secreto. Ylönen puso su aplicación a disposición del público como software gratuito. En julio de 1995, el dispositivo rápidamente se hizo popular. A finales de 1995, había 20.000 usuarios de SSH repartidos en 50 países diferentes.

archivo .tif

Para promover y hacer avanzar SSH, Ylönen estableció SSH Communications Security en diciembre de 1995. En la primera versión del programa SSH se utilizaron varios componentes de software libre, incluido GNU libgmp, pero las iteraciones posteriores proporcionadas por SSH Communications Security se convirtieron en software cada vez más propietario. Según estimaciones, en el año 2000 había 2 millones de usuarios.

Iteración 2

El Internet Engineering Task Force (IETF) designó al grupo de trabajo encargado de crear la versión 2 del protocolo SSH como 'Secsh' en su documentación oficial.

SSH-2, una iteración de protocolo mejorada, se convirtió en estándar en 2006. SSH-1 no es compatible con esta versión. SSH-2 ofrece actualizaciones de funcionalidad y seguridad sobre SSH-1. Por ejemplo, el intercambio de claves Diffie-Hellman y la sólida verificación de integridad mediante códigos de autenticación de mensajes brindan mayor seguridad. La capacidad de operar un número ilimitado de sesiones de shell a través de una única conexión SSH es una de las nuevas capacidades de SSH-2. Debido a que SSH-2 es más avanzado y se usa más ampliamente que SSH-1, ciertas implementaciones, como libssh (v0.8.0+), Lsh y Dropbear, solo admiten SSH-2.

Iteración 1.99

RFC 4253 requería que un servidor SSH compatible con 2.0, así como con versiones anteriores, indicara su versión de protocolo como 1.99 en enero de 2006, mucho después de que se desarrollara la versión 2.1. Este número de versión se utiliza para indicar compatibilidad con versiones anteriores en lugar de representar una revisión de software anterior.

OSSH y OpenSSH

Desde que la última versión del programa SSH original, la versión 1.2.12, se distribuyó bajo una licencia de código abierto en 1999, los desarrolladores han estado trabajando en una versión de software gratuita. Esto sirvió de base para el programa OSSH de Björn Grönvall. Poco después, el equipo de OpenBSD clonó el trabajo de Grönvall para producir OpenSSH, que se incluyó en la versión 2.6 de OpenBSD. Crearon una rama de 'portabilidad' a partir de esta versión para transferir OpenSSH a diferentes sistemas operativos.

La implementación SSH más utilizada en 2005 fue OpenSSH, la versión predeterminada en muchas distribuciones de sistemas operativos. Después de eliminar la compatibilidad con SSH-1 del código base en la versión OpenSSH 7.6, OpenSSH aún se está actualizando y es compatible con el protocolo SSH-2. Mientras tanto, OSSH ya no es relevante.

Usos

El usuario 'josh' 'SSHed' desde la computadora local 'foofighter' a la máquina distante 'tengwar' para ejecutar xeyes como ejemplo de túnel de un programa X11 a través de SSH. La gente utiliza el cliente SSH de Windows PuTTY para acceder a OpenWrt.

SSH es un protocolo que funciona con muchos sistemas, incluido Microsoft Windows y la mayoría de las variaciones de Unix (Linux, BSD, incluido macOS de Apple y Solaris). Las siguientes aplicaciones pueden necesitar capacidades exclusivas o compatibles con clientes o servidores SSH específicos. Por ejemplo, actualmente sólo es factible utilizar la implementación del cliente y del servidor OpenSSH del protocolo SSH para construir una VPN.

• Para acceder a un shell en un host distante (reemplazando Telnet y rlogin)
• Para ejecutar un comando solitario en un host distante (reemplazando a rsh)
• Para configurar el inicio de sesión automatizado (sin contraseña) de un servidor distante (por ejemplo, usando OpenSSH)
• Como VPN cifrada completamente funcional, tenga en cuenta que solo el cliente y el servidor OpenSSH admiten esta capacidad.
• Para transmitir X desde un host distante (posible a través de múltiples hosts intermedios)
• Para utilizar clientes SSH que admitan el protocolo SOCKS para navegar por Internet a través de una conexión proxy cifrada.
• Para montar de forma segura el directorio de un servidor remoto como un sistema de archivos en una máquina local que emplea SSHFS.
• A través de una o más de las tecnologías mencionadas anteriormente para el monitoreo y administración remota automática de servidores.
• Para el desarrollo de dispositivos integrados o móviles compatibles con SSH.
• Para proteger los mecanismos de transferencia de archivos.

Métodos de transferencia de archivos

Varios sistemas de transferencia de archivos emplean protocolos Secure Shell como

• Sobre SSH, Secure Copy (SCP) se desarrolla a partir del protocolo RCP.
• rsync, que se supone que es más efectivo que SCP, a menudo se opera a través de una conexión SSH.
• Una alternativa segura al FTP es el Protocolo de transferencia de archivos SSH (SFTP) (no debe confundirse con FTP sobre SSH o FTPS).
• FISH, o archivos transferidos a través del protocolo shell, se introdujo en 1998 y se desarrolló a partir de SSH sobre instrucciones shell de Unix.
• Aspera, también conocido como Protocolo rápido y seguro (FASP), emplea SSH para comando y transporte de datos, puertos UDP.

Arquitectura

Tres componentes distintos conforman la arquitectura en capas del protocolo SSH:

¿Qué es correo electrónico?

• El protocolo de control de transmisión (TCP) de TCP/IP es comúnmente utilizado por la capa de transporte (RFC 4253), con el puerto número 22 reservado como puerto de escucha del servidor. Esta capa implementa cifrado, compresión, verificación de integridad, intercambio de claves inicial y autenticación del servidor. Aunque cada implementación puede permitir más, expone a la capa superior una interfaz para transmitir y recibir paquetes de texto sin formato de hasta 32.768 bytes cada uno. Por lo general, después de que se haya transportado 1 GB de datos o después de que haya pasado una hora, lo que ocurra primero, la capa de transporte organiza el reintercambio de claves.
  
• La autenticación del cliente se maneja a través de la capa de autenticación de usuario (RFC 4252), que también ofrece varias técnicas de autenticación. La autenticación impulsada por el cliente significa que el cliente SSH, no el servidor, puede solicitar una contraseña al usuario. Sólo las solicitudes de autenticación del cliente reciben una respuesta del servidor. A menudo se utilizan las siguientes técnicas de autenticación de usuarios:
  Contraseña, una técnica de autenticación de contraseña simple que incluye la capacidad de modificar la contraseña. No todo el software utiliza esta técnica.
• Por lo general, admite al menos pares de claves DSA, ECDSA o RSA, el Llave pública es una técnica para la autenticación basada en clave pública. Otras implementaciones también aceptan certificados X.509.
Teclado interactivo(RFC 4256) es una técnica flexible en la que el servidor proporciona uno o más mensajes para ingresar información, el cliente los muestra y luego envía las respuestas que el cliente ha ingresado. Utilizado por algunas configuraciones de OpenSSH para ofrecer de manera efectiva autenticación de contraseña cuando PAM es el proveedor de autenticación de host subyacente, que ocasionalmente puede impedir el inicio de sesión con un cliente que solo admite la técnica de autenticación de contraseña simple.
• La funcionalidad de inicio de sesión único para sesiones SSH se proporciona a través de GSSAPI técnicas de autenticación, que ofrecen un sistema extensible para manejar la autenticación SSH utilizando mecanismos externos como Kerberos 5 o NTLM. Aunque OpenSSH tiene una implementación GSSAPI funcional, las implementaciones comerciales de SSH suelen integrar estas técnicas para su uso en empresas.
• La idea de canales que definen los servicios SSH ofrecidos está definida por la capa de conexión (RFC 4254). Podemos multiplexar múltiples conexiones SSH desde una sola. Ambos transmiten datos en ambas direcciones. Las solicitudes de canal transmiten datos fuera de banda específicos de un canal determinado, como el código de salida de un proceso del lado del servidor o el cambio de tamaño de una ventana de terminal. Además, utilizando el tamaño de la ventana de recepción, cada canal controla su flujo. El cliente SSH realiza una solicitud global para reenviar un puerto del lado del servidor. Los tipos de canales que son comunes incluyen:
  • Shell para SFTP, exec y shells de terminal (incluidas las transferencias SCP)
  • Direct-TCPIP para conexiones reenviadas desde el cliente al servidor.
  • Conexiones reenviadas de servidor a cliente mediante forwarded-tcpip
  • Para confirmar la legitimidad del host, el registro DNS SSHFP (RFC 4255) ofrece las huellas digitales de la clave pública del host.

Debido a su diseño abierto podremos usar SSH para una amplia gama de tareas además de asegurar shells, dándole una gran versatilidad.

Vulnerabilidades

SSH-1

Debido a la protección inadecuada de la integridad de los datos proporcionada por CRC-32 en esta versión del protocolo, en 1998 se identificó una vulnerabilidad en SSH 1.5 que permitía la inserción no autorizada de material en una secuencia SSH cifrada. En la mayoría de las implementaciones, agregaron un parche conocido como SSH Compensation Attack Detector. Varias de estas implementaciones revisadas incluyeron una nueva falla de desbordamiento de enteros, que permitía a los atacantes ejecutar código arbitrario con la raíz o las capacidades del demonio SSH.

En enero de 2001 se encontró una falla que permite a los atacantes cambiar el último bloque de una sesión cifrada con IDEA. Ese mismo mes se encontró otra falla que permitió a un servidor fraudulento pasar el inicio de sesión de un cliente a otro servidor.

Debido a sus vulnerabilidades inherentes, SSH-1 generalmente se considera obsoleto y debe evitarse eliminando explícitamente el respaldo de SSH-1. La mayoría de los servidores y clientes actuales admiten SSH-2.

Recuperación de texto sin formato para CBC

En noviembre de 2008 se descubrió en todas las versiones de SSH una vulnerabilidad teórica que permitía recuperar hasta 32 bits de texto sin formato de un bloque de texto cifrado cifrado utilizando el método de cifrado estándar de la época, CBC. La solución más sencilla es cambiar a CTR, counter modo, en lugar del modo CBC, que hace que SSH sea inmune al ataque.

La NSA es sospechosa de descifrar

La divulgación de documentos confidenciales por parte de Edward Snowden a Der Spiegel el 28 de diciembre de 2014 implica que la Agencia de Seguridad Nacional podrá decodificar potencialmente ciertas comunicaciones SSH.