Shell seguro

El protocolo Secure Shell ( SSH ) es un protocolo de red criptográfico para operar servicios de red de forma segura a través de una red no segura. ^[1] Sus aplicaciones más notables son el inicio de sesión remoto y la ejecución de línea de comandos .

SSH fue diseñado para sistemas operativos tipo Unix como reemplazo de Telnet y de protocolos de shell Unix remotos no seguros , como Berkeley Remote Shell (rsh) y los protocolos relacionados rlogin y rexec , que utilizan métodos de autenticación de texto simple e inseguros , como contraseñas .

Dado que mecanismos como Telnet y Remote Shell están diseñados para acceder y operar computadoras remotas, enviar tokens de autenticación (por ejemplo, nombre de usuario y contraseña ) para este acceso a estas computadoras a través de una red pública de manera no segura, plantea un gran riesgo de que terceros obtengan la contraseña y logren el mismo nivel de acceso al sistema remoto que el usuario de Telnet. Secure Shell mitiga este riesgo mediante el uso de mecanismos de cifrado que tienen como objetivo ocultar el contenido de la transmisión a un observador, incluso si el observador tiene acceso a todo el flujo de datos. ^[2]

SSH fue diseñado por primera vez en 1995 por el informático finlandés Tatu Ylönen (para reemplazar el protocolo de red Telnet). El desarrollo posterior del conjunto de protocolos se llevó a cabo en varios grupos de desarrolladores, lo que produjo varias variantes de implementación. La especificación del protocolo distingue dos versiones principales, denominadas SSH-1 y SSH-2. La pila de software implementada con mayor frecuencia es OpenSSH , publicada en 1999 como software de código abierto por los desarrolladores de OpenBSD . Las implementaciones se distribuyen para todos los tipos de sistemas operativos de uso común, incluidos los sistemas integrados.

Las aplicaciones SSH se basan en una arquitectura cliente-servidor , que conecta una instancia de cliente SSH con un servidor SSH . ^[3] SSH funciona como un conjunto de protocolos en capas que comprende tres componentes jerárquicos principales: la capa de transporte proporciona autenticación, confidencialidad e integridad del servidor; el protocolo de autenticación de usuario valida al usuario en el servidor; y el protocolo de conexión multiplexa el túnel cifrado en múltiples canales de comunicación lógicos. ^[1]

SSH utiliza criptografía de clave pública para autenticar la computadora remota y permitirle autenticar al usuario, si es necesario. ^[3]

SSH se puede utilizar en varias metodologías. De la forma más sencilla, ambos extremos de un canal de comunicación utilizan pares de claves públicas y privadas generadas automáticamente para cifrar una conexión de red y, a continuación, utilizan una contraseña para autenticar al usuario.

Cuando el usuario genera manualmente el par de claves pública y privada, la autenticación se realiza básicamente cuando se crea el par de claves y, a continuación, se puede abrir una sesión automáticamente sin que se solicite la contraseña. En este escenario, la clave pública se coloca en todos los equipos que deben permitir el acceso al propietario de la clave privada correspondiente, que el propietario mantiene en privado. Si bien la autenticación se basa en la clave privada, la clave nunca se transfiere a través de la red durante la autenticación. SSH solo verifica que la misma persona que ofrece la clave pública también posee la clave privada correspondiente.

En todas las versiones de SSH es importante verificar las claves públicas desconocidas , es decir, asociarlas con identidades , antes de aceptarlas como válidas. Aceptar la clave pública de un atacante sin validación autorizará a un atacante no autorizado como usuario válido.

En sistemas tipo Unix , la lista de claves públicas autorizadas se almacena normalmente en el directorio de inicio del usuario que tiene permiso para iniciar sesión de forma remota, en el archivo ~/.ssh/authorized_keys. ^[4] SSH respeta este archivo solo si no puede escribirlo nadie más que el propietario y el usuario root. Cuando la clave pública está presente en el extremo remoto y la clave privada correspondiente está presente en el extremo local, ya no es necesario escribir la contraseña. Sin embargo, para mayor seguridad, la clave privada en sí se puede bloquear con una frase de contraseña.

La clave privada también se puede buscar en lugares estándar y su ruta completa se puede especificar como una opción de línea de comandos (la opción -ipara ssh). La utilidad ssh-keygen genera las claves pública y privada, siempre en pares.

SSH se utiliza normalmente para iniciar sesión en el shell o la interfaz de línea de comandos (CLI) de una computadora remota y para ejecutar comandos en un servidor remoto. También admite mecanismos de tunelización , reenvío de puertos TCP y conexiones X11 y se puede utilizar para transferir archivos mediante el Protocolo de transferencia de archivos SSH (SFTP) o el Protocolo de copia segura (SCP) asociados. ^[3]

SSH utiliza el modelo cliente-servidor . Un programa cliente SSH se utiliza normalmente para establecer conexiones a un demonio SSH , como sshd, que acepta conexiones remotas. Ambos están presentes habitualmente en la mayoría de los sistemas operativos modernos , incluidos macOS , la mayoría de las distribuciones de Linux , OpenBSD , FreeBSD , NetBSD , Solaris y OpenVMS . En particular, las versiones de Windows anteriores a Windows 10 versión 1709 no incluyen SSH de forma predeterminada, pero sí existían y existen versiones propietarias , freeware y de código abierto de varios niveles de complejidad y completitud (consulte Comparación de clientes SSH ). En 2018, Microsoft comenzó a portar el código fuente de OpenSSH a Windows ^[5] y en Windows 10 versión 1709 , ahora está disponible un puerto Win32 oficial de OpenSSH.

Los administradores de archivos para sistemas tipo UNIX (por ejemplo, Konqueror ) pueden usar el protocolo FISH para proporcionar una interfaz gráfica de usuario de panel dividido con función de arrastrar y soltar. El programa de código abierto WinSCP ^[6] para Windows proporciona una capacidad de administración de archivos similar (sincronización, copia, eliminación remota) utilizando PuTTY como back-end. Tanto WinSCP ^[7] como PuTTY ^[8] están disponibles empaquetados para ejecutarse directamente desde una unidad USB, sin necesidad de instalación en la máquina cliente. Crostini en ChromeOS viene con OpenSSH de forma predeterminada. La configuración de un servidor SSH en Windows generalmente implica habilitar una función en la aplicación Configuración.

SSH es importante en la computación en la nube para resolver problemas de conectividad, evitando los problemas de seguridad que supone exponer una máquina virtual basada en la nube directamente a Internet. Un túnel SSH puede proporcionar una ruta segura a través de Internet, a través de un cortafuegos, hasta una máquina virtual. ^[9]

La IANA ha asignado el puerto TCP 22, el puerto UDP 22 y el puerto SCTP 22 para este protocolo. ^[10] La IANA había incluido el puerto TCP 22 estándar para servidores SSH como uno de los puertos más conocidos ya en 2001. ^[11] SSH también se puede ejecutar utilizando SCTP en lugar de TCP como protocolo de capa de transporte orientado a la conexión. ^[12]

En 1995, Tatu Ylönen , un investigador de la Universidad Tecnológica de Helsinki en Finlandia, diseñó la primera versión del protocolo (ahora llamado SSH-1 ) a raíz de un ataque de rastreo de contraseñas en la red de su universidad . ^[13] El objetivo de SSH era reemplazar los protocolos anteriores rlogin , TELNET , FTP ^[14] y rsh , que no proporcionaban una autenticación sólida ni garantizaban la confidencialidad. Eligió el puerto número 22 porque está entre telnet(puerto 23) y ftp(puerto 21). ^[15]

Ylönen lanzó su implementación como software gratuito en julio de 1995 y la herramienta ganó popularidad rápidamente. Hacia fines de 1995, la base de usuarios de SSH había crecido hasta 20 000 usuarios en cincuenta países. ^{[ cita requerida ]}

En diciembre de 1995, Ylönen fundó SSH Communications Security para comercializar y desarrollar SSH. La versión original del software SSH utilizaba varios programas gratuitos , como GNU libgmp , pero las versiones posteriores publicadas por SSH Communications Security evolucionaron hacia un software cada vez más propietario .

Se estimó que para el año 2000 el número de usuarios había aumentado a 2 millones. ^[16]

En 2006, después de ser discutido en un grupo de trabajo llamado "secsh", ^[17] una versión revisada del protocolo SSH, SSH-2 fue adoptado como estándar. ^[18] Esta versión ofrece seguridad mejorada y nuevas características, pero no es compatible con SSH-1. Por ejemplo, introduce nuevos mecanismos de intercambio de claves como el intercambio de claves Diffie-Hellman , comprobación mejorada de la integridad de los datos a través de códigos de autenticación de mensajes como MD5 o SHA-1 , que pueden negociarse entre cliente y servidor. SSH-2 también agrega métodos de cifrado más fuertes como AES que eventualmente reemplazó a cifrados más débiles y comprometidos del estándar anterior como 3-des . ^{[19] [20] [18]} Las nuevas características de SSH-2 incluyen la capacidad de ejecutar cualquier número de sesiones de shell sobre una sola conexión SSH. ^[21] Debido a la superioridad y popularidad de SSH-2 sobre SSH-1, algunas implementaciones como libssh (v0.8.0+), ^[22] Lsh ^[23] y Dropbear ^[24] eventualmente solo admitieron el protocolo SSH-2.

En enero de 2006, mucho después de que se estableciera la versión 2.1, el RFC  4253 especificó que un servidor SSH compatible con la versión 2.0 y versiones anteriores debería identificar su versión de protocolo como 1.99. ^[25] Este número de versión no refleja una revisión de software histórica, sino un método para identificar la compatibilidad con versiones anteriores .

En 1999, los desarrolladores, deseosos de disponer de una versión de software libre, reiniciaron el desarrollo de software a partir de la versión 1.2.12 del programa SSH original, que fue el último publicado bajo una licencia de código abierto . ^[26] Esto sirvió como base de código para el software OSSH de Björn Grönvall. ^[27] Poco después, los desarrolladores de OpenBSD bifurcaron el código de Grönvall y crearon OpenSSH , que se envió con la versión 2.6 de OpenBSD. A partir de esta versión, se formó una rama de "portabilidad" para portar OpenSSH a otros sistemas operativos. ^[28]

En 2005 ^[update], OpenSSH era la implementación de SSH más popular y la versión predeterminada en una gran cantidad de distribuciones de sistemas operativos. Mientras tanto, OSSH se ha vuelto obsoleto. ^[29] OpenSSH continúa manteniéndose y es compatible con el protocolo SSH-2, habiendo eliminado el soporte de SSH-1 del código base en la versión OpenSSH 7.6.

SSH es un protocolo que se puede utilizar para muchas aplicaciones en muchas plataformas, incluidas la mayoría de las variantes de Unix ( Linux , los BSD, incluidos macOS de Apple y Solaris ), así como Microsoft Windows . Algunas de las aplicaciones que se indican a continuación pueden requerir funciones que solo están disponibles o son compatibles con clientes o servidores SSH específicos. Por ejemplo, es posible utilizar el protocolo SSH para implementar una VPN , pero actualmente solo con la implementación del servidor y cliente OpenSSH .

• Para iniciar sesión en un shell en un host remoto (reemplazando Telnet y rlogin )
• Para ejecutar un solo comando en un host remoto (reemplazando rsh )
• Para configurar el inicio de sesión automático (sin contraseña) en un servidor remoto (por ejemplo, utilizando OpenSSH ^[30] )
• En combinación con rsync para realizar copias de seguridad, copiar y reflejar archivos de forma eficiente y segura
• Para reenviar un puerto
• Para tunelización (que no debe confundirse con una VPN , que enruta paquetes entre diferentes redes o une dos dominios de difusión en uno).
• Para utilizar como una VPN cifrada completa. Tenga en cuenta que solo el servidor y el cliente OpenSSH admiten esta función.
• Para reenviar X desde un host remoto (posible a través de múltiples hosts intermedios)
• Para navegar por la web a través de una conexión proxy encriptada con clientes SSH que soportan el protocolo SOCKS .
• Para montar de forma segura un directorio en un servidor remoto como un sistema de archivos en una computadora local usando SSHFS .
• Para la monitorización y gestión remota automatizada de servidores a través de uno o más de los mecanismos comentados anteriormente.
• Para desarrollo en un dispositivo móvil o integrado que admita SSH.
• Para proteger los protocolos de transferencia de archivos.

Los protocolos Secure Shell se utilizan en varios mecanismos de transferencia de archivos.

• Copia segura (SCP), que evolucionó a partir del protocolo RCP sobre SSH
• rsync , pensado para ser más eficiente que SCP. Generalmente se ejecuta a través de una conexión SSH.
• Protocolo de transferencia de archivos SSH (SFTP), una alternativa segura a FTP (no debe confundirse con FTP sobre SSH o FTPS )
• Protocolo de transferencia de archivos mediante shell (FISH), publicado en 1998, que evolucionó a partir de comandos de shell de Unix a través de SSH
• El Protocolo rápido y seguro (FASP), también conocido como Aspera , utiliza SSH para el control y puertos UDP para la transferencia de datos.

El protocolo SSH tiene una arquitectura en capas con tres componentes separados:

• La capa de transporte ( RFC  4253) utiliza normalmente el Protocolo de Control de Transmisión (TCP) de TCP/IP , reservando el puerto número 22 como puerto de escucha del servidor. Esta capa gestiona el intercambio inicial de claves, así como la autenticación del servidor, y configura el cifrado, la compresión y la verificación de integridad. Expone a la capa superior una interfaz para enviar y recibir paquetes de texto sin formato con un tamaño de hasta 32.768 bytes cada uno, pero cada implementación puede permitir más. La capa de transporte también organiza el reintercambio de claves, normalmente después de que se haya transferido 1 GB de datos o después de que haya transcurrido una hora, lo que ocurra primero.
• La capa de autenticación de usuario ( RFC  4252) se encarga de la autenticación del cliente y proporciona un conjunto de algoritmos de autenticación. La autenticación está dirigida por el cliente : cuando se le solicita una contraseña, puede ser el cliente SSH el que la solicite, no el servidor. El servidor simplemente responde a las solicitudes de autenticación del cliente. Los métodos de autenticación de usuario ampliamente utilizados incluyen los siguientes:
  • contraseña : método para autenticar contraseñas de forma sencilla, que incluye una función que permite cambiar la contraseña. No todos los programas implementan este método.
  • clave pública : un método de autenticación basado en clave pública , que normalmente admite al menos pares de claves DSA , ECDSA o RSA , y otras implementaciones también admiten certificados X.509 .
  • teclado interactivo ( RFC  4256): un método versátil en el que el servidor envía uno o más mensajes para ingresar información y el cliente los muestra y envía respuestas ingresadas por el usuario. Se utiliza para proporcionar autenticación de contraseña de un solo uso, como S/Key o SecurID . Lo utilizan algunas configuraciones de OpenSSH cuando PAM es el proveedor de autenticación de host subyacente para proporcionar autenticación de contraseña de manera efectiva, lo que a veces genera la incapacidad de iniciar sesión con un cliente que solo admite el método de autenticación de contraseña simple .
  • Métodos de autenticación GSSAPI que proporcionan un esquema extensible para realizar la autenticación SSH mediante mecanismos externos como Kerberos 5 o NTLM , lo que proporciona la capacidad de inicio de sesión único para las sesiones SSH. Estos métodos suelen implementarse en implementaciones SSH comerciales para su uso en organizaciones, aunque OpenSSH tiene una implementación GSSAPI en funcionamiento.
• La capa de conexión ( RFC  4254) define el concepto de canales, solicitudes de canal y solicitudes globales, que definen los servicios SSH proporcionados. Una única conexión SSH se puede multiplexar en varios canales lógicos simultáneamente, cada uno de los cuales transfiere datos de forma bidireccional. Las solicitudes de canal se utilizan para transmitir datos específicos del canal fuera de banda, como el tamaño modificado de una ventana de terminal o el código de salida de un proceso del lado del servidor. Además, cada canal realiza su propio control de flujo utilizando el tamaño de la ventana de recepción. El cliente SSH solicita que se reenvíe un puerto del lado del servidor mediante una solicitud global. Los tipos de canal estándar incluyen:
  • shell para shells de terminal, SFTP y solicitudes de ejecución (incluidas transferencias SCP)
  • direct-tcpip para conexiones reenviadas de cliente a servidor
  • forwarded-tcpip para conexiones reenviadas de servidor a cliente
• El registro DNS SSHFP (RFC 4255) proporciona las huellas digitales de la clave de host pública para ayudar a verificar la autenticidad del host.

Esta arquitectura abierta ofrece una flexibilidad considerable, lo que permite el uso de SSH para diversos fines más allá de un shell seguro. La funcionalidad de la capa de transporte por sí sola es comparable a la de Transport Layer Security (TLS); la capa de autenticación de usuario es altamente extensible con métodos de autenticación personalizados; y la capa de conexión ofrece la capacidad de multiplexar muchas sesiones secundarias en una única conexión SSH, una característica comparable a BEEP y no disponible en TLS.

• EdDSA , ^[31] ECDSA , RSA y DSA para criptografía de clave pública . ^[32]
• ECDH y Diffie–Hellman para intercambio de claves . ^[32]
• HMAC , AEAD y UMAC para MAC . ^[33]
• AES (y los obsoletos RC4 , 3DES , DES ^[34] ) para cifrado simétrico .
• AES-GCM ^[35] y ChaCha20-Poly1305 para cifrado AEAD .
• SHA (y MD5 obsoleto ) para huella digital de clave .

En 1998, se describió una vulnerabilidad en SSH 1.5 que permitía la inserción no autorizada de contenido en un flujo SSH cifrado debido a la insuficiente protección de la integridad de los datos del CRC-32 utilizado en esta versión del protocolo. ^{[36] [37]} Se introdujo una solución conocida como Detector de Ataques de Compensación SSH ^[38] en la mayoría de las implementaciones. Muchas de estas implementaciones actualizadas contenían una nueva vulnerabilidad de desbordamiento de enteros ^[39] que permitía a los atacantes ejecutar código arbitrario con los privilegios del demonio SSH, normalmente root.

En enero de 2001 se descubrió una vulnerabilidad que permite a los atacantes modificar el último bloque de una sesión cifrada con IDEA . ^[40] El mismo mes, se descubrió otra vulnerabilidad que permitía a un servidor malicioso reenviar una autenticación de cliente a otro servidor. ^[41]

Dado que SSH-1 tiene fallas de diseño inherentes que lo hacen vulnerable, ahora se lo considera generalmente obsoleto y se lo debe evitar deshabilitando explícitamente la opción de respaldo a SSH-1. ^[41] La mayoría de los servidores y clientes modernos admiten SSH-2. ^[42]

En noviembre de 2008, se descubrió una vulnerabilidad teórica para todas las versiones de SSH que permitía la recuperación de hasta 32 bits de texto simple de un bloque de texto cifrado que estaba cifrado utilizando lo que entonces era el modo de cifrado predeterminado estándar, CBC . ^[43] La solución más sencilla es utilizar CTR , modo contador, en lugar del modo CBC, ya que esto hace que SSH sea resistente al ataque. ^[43]

El 28 de diciembre de 2014, Der Spiegel publicó información clasificada ^[44] filtrada por el denunciante Edward Snowden que sugiere que la Agencia de Seguridad Nacional podría ser capaz de descifrar parte del tráfico SSH. Los detalles técnicos asociados con dicho proceso no fueron revelados. Un análisis de 2017 de las herramientas de piratería de la CIA BothanSpy y Gyrfalcon sugirió que el protocolo SSH no estaba comprometido. ^[45]

En 2023 se descubrió un nuevo ataque de intermediario contra la mayoría de las implementaciones actuales de ssh. Sus descubridores lo llamaron ataque Terrapin . ^{[46] [47]} Sin embargo, el riesgo se mitiga con el requisito de interceptar una sesión ssh genuina y de que el ataque está restringido en su alcance, lo que fortuitamente da como resultado principalmente conexiones fallidas. ^{[48] [49]} Los desarrolladores de ssh han declarado que el principal impacto del ataque es degradar las características de ofuscación de tiempo de pulsación de teclas de ssh. ^[49] La vulnerabilidad se corrigió en OpenSSH 9.6, pero requiere que tanto el cliente como el servidor se actualicen para que la solución sea completamente efectiva.

Las siguientes publicaciones RFC del grupo de trabajo "secsh" de IETF documentan SSH-2 como un estándar de Internet propuesto .

• RFC  4250 – Números asignados al protocolo Secure Shell (SSH)
• RFC  4251 – La arquitectura del protocolo Secure Shell (SSH)
• RFC  4252 – Protocolo de autenticación Secure Shell (SSH)
• RFC  4253 – Protocolo de capa de transporte Secure Shell (SSH)
• RFC  4254 – Protocolo de conexión Secure Shell (SSH)
• RFC  4255 – Uso de DNS para publicar de forma segura huellas de claves de Secure Shell (SSH)
• RFC  4256 – Autenticación genérica de intercambio de mensajes para el protocolo Secure Shell (SSH)
• RFC  4335 – Extensión de interrupción del canal de sesión de Secure Shell (SSH)
• RFC  4344 – Modos de cifrado de la capa de transporte de Secure Shell (SSH)
• RFC  4345 – Modos Arcfour mejorados para el protocolo de capa de transporte Secure Shell (SSH)

Las especificaciones del protocolo fueron actualizadas posteriormente por las siguientes publicaciones:

• RFC  4419 – Intercambio de grupos Diffie-Hellman para el protocolo de capa de transporte Secure Shell (SSH) (marzo de 2006)
• RFC  4432 – Intercambio de claves RSA para el protocolo de capa de transporte Secure Shell (SSH) (marzo de 2006)
• RFC  4462 – Interfaz de programación de aplicaciones de servicios de seguridad genéricos (GSS-API) para autenticación e intercambio de claves para el protocolo Secure Shell (SSH) (mayo de 2006)
• RFC  4716 – Formato de archivo de clave pública de Secure Shell (SSH) (noviembre de 2006)
• RFC  4819 – Subsistema de clave pública de Secure Shell (marzo de 2007)
• RFC  5647 – Modo de contador Galois AES para el protocolo de capa de transporte de Secure Shell (agosto de 2009)
• RFC  5656 – Integración del algoritmo de curva elíptica en la capa de transporte de Secure Shell (diciembre de 2009)
• RFC  6187 – Certificados X.509v3 para autenticación Secure Shell (marzo de 2011)
• RFC  6239 – Suite B de suites criptográficas para Secure Shell (SSH) (mayo de 2011)
• RFC  6594 – Uso del algoritmo SHA-256 con RSA, algoritmo de firma digital (DSA) y DSA de curva elíptica (ECDSA) en registros de recursos SSHFP (abril de 2012)
• RFC  6668 – Verificación de integridad de datos SHA-2 para el protocolo de capa de transporte Secure Shell (SSH) (julio de 2012)
• RFC  7479 – Ed25519 Registros de recursos SSHFP (marzo de 2015)
• RFC  5592 – Modelo de transporte de Secure Shell para el Protocolo simple de administración de red (SNMP) (junio de 2009)
• RFC  6242 – Uso del protocolo NETCONF sobre Secure Shell (SSH) (junio de 2011)
• RFC  8332 – Uso de claves RSA con SHA-256 y SHA-512 en el protocolo Secure Shell (SSH) (marzo de 2018)
• draft-gerhards-syslog-transport-ssh-00 – Mapeo de transporte SSH para SYSLOG (julio de 2006)
• draft-ietf-secsh-filexfer-13 – Protocolo de transferencia de archivos SSH (julio de 2006)

Además, el proyecto OpenSSH incluye varias especificaciones/extensiones de protocolos de proveedores:

• Descripción general del PROTOCOLO OpenSSH
• Descripción general del certificado/clave OpenSSH
• draft-miller-ssh-agent-04 - Protocolo de agente SSH (diciembre de 2019)

• Ataque de fuerza bruta
• Comparación de clientes SSH
• Comparación de servidores SSH
• Sacacorchos
• Ident
• OpenSSH
• Túnel de Secure Shell
• SSH basado en web

• Barrett, Daniel J .; Silverman, Richard E.; Byrnes, Robert G. (2005). SSH: The Secure Shell (La guía definitiva) (2.ª ed.). O'Reilly. ISBN 0-596-00895-3.
• Stahnke, Michael (2005). Pro OpenSSH . Presione. ISBN 1-59059-476-2.
• Tatu Ylönen (12 de julio de 1995). "Anuncio: Programa de inicio de sesión remoto Ssh (Secure Shell)". comp.security.unix.Anuncio original de Ssh
• Dwivedi, Himanshu (2003). Implementación de SSH . Wiley. ISBN 978-0-471-45880-7.

• Protocolos SSH
• M. Joseph; J. Susoy (noviembre de 2013). Subsistema de clave pública de Secure Shell de P6R. doi : 10.17487/RFC7076 . RFC 7076.
• Archivo tar de código fuente SSH original