OpenSSH (también conocido como OpenBSD Secure Shell [a] ) es un conjunto de utilidades de red segura basadas en el protocolo Secure Shell (SSH), que proporciona un canal seguro a través de una red no segura en una arquitectura cliente-servidor . [4] [5]
OpenSSH comenzó como una bifurcación del programa gratuito SSH desarrollado por Tatu Ylönen; versiones posteriores del SSH de Ylönen fueron software propietario ofrecido por SSH Communications Security . [6] OpenSSH se lanzó por primera vez en 1999 y actualmente se desarrolla como parte del sistema operativo OpenBSD .
OpenSSH no es un único programa informático, sino un conjunto de programas que sirven como alternativas a protocolos no cifrados como Telnet y FTP . OpenSSH está integrado en varios sistemas operativos, a saber, Microsoft Windows , macOS y la mayoría de los sistemas operativos Linux , [7] [8] mientras que la versión portátil está disponible como paquete en otros sistemas. [9] [10] [11]
OpenBSD Secure Shell fue creado por los desarrolladores de OpenBSD como una alternativa al software SSH original de Tatu Ylönen, que ahora es software propietario . [12] Aunque el código fuente está disponible para el SSH original, se imponen varias restricciones a su uso y distribución. OpenSSH fue creado como una bifurcación de OSSH de Björn Grönvall que a su vez era una bifurcación de la versión libre original SSH 1.2.12 de Tatu Ylönen, [13] que fue la última que tuvo una licencia adecuada para bifurcarse. [14] [15] Los desarrolladores de OpenSSH afirman que su aplicación es más segura que la original, debido a su política de producir código limpio y auditado y porque se publica bajo la licencia BSD , la licencia de código abierto a la que se refiere la palabra abierta en el nombre.
OpenSSH apareció por primera vez en OpenBSD 2.6. La primera versión portable se realizó en octubre de 1999. [16] Los desarrollos desde entonces han incluido la adición de cifrados (por ejemplo, ChaCha20-Poly1305 en 6.5 de enero de 2014 [17] ), la eliminación de la dependencia de OpenSSL (6.7, octubre de 2014 [18] ) y una extensión para facilitar el descubrimiento y la rotación de claves públicas para hosts confiables (para la transición de DSA a claves de host públicas Ed25519 , versión 6.8 de marzo de 2015 [19] ).
El 19 de octubre de 2015, Microsoft anunció que OpenSSH será compatible de forma nativa con Microsoft Windows y será accesible a través de PowerShell , lanzando una implementación temprana y poniendo el código a disposición del público. [20] Los programas cliente y servidor basados en OpenSSH se han incluido en Windows 10 desde la versión 1803. El cliente SSH y el agente de claves están habilitados y disponibles de forma predeterminada, y el servidor SSH es una característica opcional a pedido. [21]
En octubre de 2019, se agregó protección para claves privadas en reposo en RAM contra especulación y ataques de canal lateral de memoria en OpenSSH 8.1. [22]
OpenSSH se desarrolla como parte del sistema operativo OpenBSD . En lugar de incluir cambios para otros sistemas operativos directamente en OpenSSH, el equipo de portabilidad de OpenSSH mantiene una infraestructura de portabilidad independiente y se realizan "versiones portátiles" periódicamente. Esta infraestructura es sustancial, en parte porque OpenSSH es necesario para realizar la autenticación , una capacidad que tiene muchas implementaciones diferentes. Este modelo también se utiliza para otros proyectos OpenBSD como OpenNTPD .
La suite OpenSSH incluye las siguientes utilidades y demonios de línea de comandos :
El servidor OpenSSH puede autenticar usuarios utilizando los métodos estándar soportados por el protocolo SSH : con una contraseña; autenticación de clave pública , utilizando claves por usuario; autenticación basada en host, que es una versión segura de las relaciones de confianza de host de rlogin utilizando claves públicas; teclado interactivo, un mecanismo genérico de desafío-respuesta , que se utiliza a menudo para la autenticación de contraseña simple, pero que también puede hacer uso de autenticadores más fuertes como tokens ; y Kerberos / GSSAPI . El servidor hace uso de métodos de autenticación nativos del sistema operativo host; esto puede incluir el uso del sistema de autenticación BSD o módulos de autenticación conectables (PAM) para habilitar la autenticación adicional a través de métodos como contraseñas de un solo uso . Sin embargo, esto ocasionalmente tiene efectos secundarios: cuando se usa PAM con OpenSSH, debe ejecutarse como root , ya que los privilegios de root generalmente se requieren para operar PAM. Las versiones de OpenSSH posteriores a la 3.7 (16 de septiembre de 2003) permiten deshabilitar PAM en tiempo de ejecución, por lo que los usuarios regulares pueden ejecutar instancias de sshd.
En OpenBSD, OpenSSH utiliza un usuario sshd dedicado de forma predeterminada para eliminar privilegios y realizar la separación de privilegios de acuerdo con el principio del mínimo privilegio , aplicado en todo el sistema operativo , incluido el servidor Xenocara X.
OpenSSH incluye la capacidad de configurar un canal seguro a través del cual los datos enviados a los sockets de dominio Unix locales del lado del cliente o a los puertos TCP locales del lado del cliente pueden ser " reenviados " (enviados a través del canal seguro) para su enrutamiento en el lado del servidor; cuando se configura este reenvío, se le indica al servidor que envíe esos datos reenviados a algún socket o host/puerto TCP (el host podría ser el propio servidor, "localhost"; o bien, el host puede ser algún otro ordenador, de modo que parezca al otro ordenador que el servidor es el originador de los datos). El reenvío de datos es bidireccional, lo que significa que cualquier comunicación de retorno se reenvía de nuevo al lado del cliente de la misma manera; esto se conoce como " túnel SSH ", [23] y se puede utilizar para multiplexar conexiones TCP adicionales sobre una única conexión SSH desde 2004, [24] para ocultar conexiones, para cifrar protocolos que de otro modo no serían seguros y para eludir los cortafuegos enviando/recibiendo todo tipo de datos a través de un puerto permitido por el cortafuegos. Por ejemplo, se puede crear un túnel del sistema X Window automáticamente al usar OpenSSH para conectarse a un host remoto, y otros protocolos, como HTTP y VNC , se pueden reenviar fácilmente. [25]
La tunelización de una carga útil que encapsula TCP (como PPP ) sobre una conexión basada en TCP (como el reenvío de puertos de SSH ) se conoce como "TCP sobre TCP", y hacerlo puede inducir una pérdida drástica en el rendimiento de la transmisión debido al problema de la fusión de TCP , [26] [27] que es la razón por la que el software de red privada virtual puede utilizar en su lugar para la conexión del túnel un protocolo más simple que TCP. Sin embargo, esto no suele ser un problema cuando se utiliza el reenvío de puertos de OpenSSH, porque muchos casos de uso no implican la tunelización TCP sobre TCP; la fusión se evita porque el cliente OpenSSH procesa la conexión TCP local del lado del cliente para llegar a la carga útil real que se está enviando, y luego envía esa carga útil directamente a través de la propia conexión TCP del túnel al lado del servidor, donde el servidor OpenSSH "desenvuelve" de manera similar la carga útil para "envolverla" nuevamente para enrutarla a su destino final. [28]
Además, algunos programas de terceros incluyen compatibilidad con la tunelización a través de SSH. Entre ellos se incluyen DistCC , CVS , rsync y Fetchmail . En algunos sistemas operativos, los sistemas de archivos remotos se pueden montar a través de SSH utilizando herramientas como sshfs (utilizando FUSE ).
Se puede crear un servidor proxy SOCKS ad hoc utilizando OpenSSH. Esto permite un uso más flexible del proxy que el que se puede realizar con el reenvío de puertos normal.
A partir de la versión 4.3, OpenSSH implementa una VPN basada en tun de capa 2/3 de OSI . Esta es la capacidad de tunelización más flexible de OpenSSH, que permite a las aplicaciones acceder de forma transparente a recursos de red remotos sin modificaciones para utilizar SOCKS. [29]
OpenSSH admite los siguientes tipos de claves públicas: [30] [31]
Antes de la versión 5.2 de OpenSSH, un atacante podía recuperar hasta 14 bits de texto sin formato con una probabilidad de éxito de 2 −14 . [39] La vulnerabilidad estaba relacionada con el modo de cifrado CBC. El modo AES CTR y los cifrados arcfour no son vulnerables a este ataque.
Existía una vulnerabilidad de escalada de privilegios locales en OpenSSH 6.8 a 6.9 ( CVE - 2015-6565) debido a dispositivos TTY con permisos de escritura global (622) , que se creía que era una vulnerabilidad de denegación de servicio . [40] Con el uso de ioctl TIOCSTI , era posible que los usuarios autenticados inyectaran caracteres en las terminales de otros usuarios y ejecutaran comandos arbitrarios en Linux. [41]
Los servidores OpenSSH maliciosos o comprometidos podrían leer información confidencial del cliente, como claves de inicio de sesión privadas para otros sistemas, utilizando una vulnerabilidad que se basa en la función de reanudación de conexión no documentada del cliente OpenSSH, que se denomina roaming, habilitada de forma predeterminada en el cliente, pero no compatible con el servidor OpenSSH. Esto se aplica a las versiones 5.4 (publicadas el 8 de marzo de 2010 [42] ) a 7.1 del cliente OpenSSH, y se corrigió en OpenSSH 7.1p2, publicado el 14 de enero de 2016. Los números CVE asociados a esta vulnerabilidad son CVE - 2016-0777 (fuga de información) y CVE - 2016-0778 (desbordamiento de búfer). [43] [44]
El 29 de marzo de 2024, se informó de un grave ataque a la cadena de suministro de XZ Utils , que tenía como objetivo indirecto el servidor OpenSSH (sshd) que se ejecuta en Linux. El código OpenSSH no está directamente afectado, la puerta trasera es causada por las dependencias de liblzma a través de libsystemd aplicadas por un tercer parche, aplicado por varias distribuciones de Linux. [ cita requerida ]
El 1 de julio de 2024, se reveló la vulnerabilidad de seguridad RegreSSHion , que podría permitir que un atacante remoto hiciera que OpenSSH ejecutara código arbitrario y obtuviera acceso completo a la raíz. Se introdujo inadvertidamente en la versión anterior de OpenSSH 8.5p1 en octubre de 2020 y se corrigió después de la versión 9.8/9.8p1. [45] [46]
En febrero de 2001, Tatu Ylönen, presidente y director de tecnología de SSH Communications Security informó a la lista de correo de desarrollo de OpenSSH que la compañía tenía la intención de afirmar su propiedad de las marcas comerciales "SSH" y "Secure Shell" , [47] y buscaba cambiar las referencias al protocolo a "SecSH" o "secsh", para mantener el control del nombre "SSH". Propuso que OpenSSH cambiara su nombre para evitar una demanda, una sugerencia a la que los desarrolladores se resistieron. El desarrollador de OpenSSH Damien Miller respondió instando a Ylönen a reconsiderar, argumentando que "SSH" había sido desde hacía mucho una marca comercial genérica . [48]
En ese momento, "SSH", "Secure Shell" y "ssh" habían aparecido en documentos que proponían el protocolo como un estándar abierto. Sin marcar estos términos dentro de la propuesta como marcas registradas, Ylönen corrió el riesgo de renunciar a todos los derechos exclusivos sobre el nombre como un medio para describir el protocolo. El uso indebido de una marca registrada, o permitir que otros la usen incorrectamente, da como resultado que la marca se convierta en un término genérico, como Kleenex o Aspirin , lo que abre la marca al uso por parte de otros. [49] Después de estudiar la base de datos de marcas registradas de la USPTO , muchos expertos en línea opinaron que el término "ssh" no era una marca registrada, solo el logotipo que usa las letras minúsculas "ssh". Además, los seis años entre la creación de la empresa y el momento en que comenzó a defender su marca registrada, y que solo OpenSSH estaba recibiendo amenazas de repercusiones legales, pesaron en contra de la validez de la marca registrada. [50]
Tanto los desarrolladores de OpenSSH como el propio Ylönen eran miembros del grupo de trabajo de la IETF que estaba desarrollando el nuevo estándar; después de varias reuniones, este grupo rechazó la petición de Ylönen de cambiar el nombre del protocolo, alegando preocupaciones de que sentaría un mal precedente para otras demandas de marca registrada contra la IETF. Los participantes argumentaron que tanto "Secure Shell" como "SSH" eran términos genéricos y no podían ser marcas registradas. [6]
Este es el puerto del excelente OpenSSH de OpenBSD para Linux y otros sistemas Unix.
El código de reenvío TCP también es bastante rápido. Solo para responder una pregunta de antemano, ssh desencapsula y vuelve a encapsular TCP, por lo que no tienes problemas clásicos de TCP sobre TCP.