SSH

El protocolo Secure Shell o SSH (por Secure Shell), castellanizado como intérprete (de órdenes) seguro es un protocolo de red criptográfico para operar servicios de red de forma segura en una red no segura. Sus aplicaciones más notables son el inicio de sesión remoto y la ejecución de línea de comandos.

Las aplicaciones SSH se basan en una arquitectura cliente-servidor, conectando una instancia de cliente SSH con un servidor SSH. 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 ante el servidor; y el protocolo de conexión multiplexa el túnel encriptado en múltiples canales lógicos de comunicación.

SSH se diseñó en sistemas operativos similares a Unix, como un reemplazo para Telnet y para protocolos de shell de Unix remotos no seguros, como Berkeley Remote Shell (rsh) y los protocolos rlogin y rexec relacionados, todos los cuales usan transmisión de tokens de autenticación de texto simple e inseguro..

SSH fue diseñado por primera vez en 1995 por el científico informático finlandés Tatu Ylönen. El desarrollo posterior del conjunto de protocolos procedió en varios grupos de desarrolladores, produciendo 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, lanzada 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.

Definición

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

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

Cuando el usuario genera manualmente el par de claves pública-privada, la autenticación se realiza esencialmente cuando se crea el par de claves, y luego se puede abrir una sesión automáticamente sin que se solicite una contraseña. En este escenario, la clave pública se coloca en todas las computadoras que deben permitir el acceso al propietario de la clave privada coincidente, 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 coincidente.

En todas las versiones de SSH es importante verificar las claves públicas desconocidas, es decir, asociar las claves públicas 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.

Autenticación: administración de claves OpenSSH

En sistemas similares a Unix, la lista de claves públicas autorizadas generalmente se almacena en el directorio de inicio del usuario que puede iniciar sesión de forma remota, en el archivo ~/.ssh/authorized_keys. Este archivo es respetado por SSH solo si no se puede escribir en él, excepto por el propietario y la raíz. Cuando la clave pública está presente en el extremo remoto y la clave privada coincidente 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 configuración de línea de comando (la opción -ipara ssh). La utilidad ssh-keygen produce las claves pública y privada, siempre en pares.

SSH también admite la autenticación basada en contraseña cifrada mediante claves generadas automáticamente. En este caso, el atacante podría imitar el servidor legítimo, pedir la contraseña y obtenerla (ataque man-in-the-middle). Sin embargo, esto es posible solo si los dos lados nunca se han autenticado antes, ya que SSH recuerda la clave que el lado del servidor usó anteriormente. El cliente SSH genera una advertencia antes de aceptar la clave de un nuevo servidor previamente desconocido. La autenticación de contraseña se puede desactivar desde el lado del servidor.

Uso

SSH generalmente se usa para iniciar sesión en una máquina remota y ejecutar comandos, pero también admite túneles, reenvío de puertos TCP y conexiones X11; puede transferir archivos utilizando los protocolos asociados de transferencia de archivos SSH (SFTP) o copia segura (SCP). SSH utiliza el modelo cliente-servidor.

Un programa de cliente SSH se usa normalmente para establecer conexiones con un demonio SSH que acepta conexiones remotas. Ambos están comúnmente presentes 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 la versión 1709 de Windows 10 no incluyen SSH de forma predeterminada. Existen versiones propietarias, gratuitas y de código abierto (p. ej., PuTTY y la versión de OpenSSH que forma parte de Cygwin) de varios niveles de complejidad y exhaustividad. Los administradores de archivos para sistemas similares a UNIX (por ejemplo, Konqueror) pueden usar el protocolo FISH para proporcionar una GUI de panel dividido con arrastrar y soltar. El programa de código abierto de Windows WinSCP proporciona una capacidad similar de gestión de archivos (sincronización, copia, eliminación remota) utilizando PuTTY como back-end. Ambos WinSCPy PuTTY están disponibles empaquetados para ejecutarse directamente desde una unidad USB, sin necesidad de instalación en la máquina cliente. La configuración de un servidor SSH en Windows generalmente implica habilitar una función en la aplicación Configuración. En Windows 10 versión 1709, está disponible un puerto Win32 oficial de OpenSSH.

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

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

Desarrollo historico

Versión 1

En 1995, Tatu Ylönen, investigador de la Universidad Tecnológica de Helsinki, Finlandia, diseñó la primera versión del protocolo (ahora llamado SSH-1) impulsado por un ataque de detección de contraseñas en la red de su universidad. El objetivo de SSH era reemplazar los protocolos anteriores rlogin, TELNET, FTP y rsh, que no proporcionaban una autenticación sólida ni garantizaban la confidencialidad. Ylönen lanzó su implementación como software gratuito en julio de 1995 y la herramienta rápidamente ganó popularidad. Hacia fines de 1995, la base de usuarios de SSH había crecido a 20.000 usuarios en cincuenta países.

En diciembre de 1995, Ylönen fundó SSH Communications Security para comercializar y desarrollar SSH. La versión original del software SSH usaba varias piezas de software gratuito, como GNU libgmp, pero las versiones posteriores lanzadas 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 crecido a 2 millones.

Versión 2

"Secsh" era el nombre oficial del Grupo de Trabajo de Ingeniería de Internet (IETF) para el grupo de trabajo de IETF responsable de la versión 2 del protocolo SSH. En 2006, se adoptó como estándar una versión revisada del protocolo, SSH-2. Esta versión es incompatible con SSH-1. SSH-2 presenta mejoras de seguridad y características sobre SSH-1. La mejor seguridad, por ejemplo, viene a través del intercambio de claves Diffie-Hellman y una fuerte verificación de integridad a través de códigos de autenticación de mensajes. Las nuevas características de SSH-2 incluyen la capacidad de ejecutar cualquier cantidad de sesiones de shell en una única conexión SSH. Debido a la superioridad y popularidad de SSH-2 sobre SSH-1, algunas implementaciones como libssh (v0.8.0+), Lsh y Dropbear solo admiten el protocolo SSH-2.

Versión 1.99

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

OpenSSH y OSSH

En 1999, los desarrolladores, deseosos de disponer de una versión de software libre, reiniciaron el desarrollo de software desde la versión 1.2.12 del programa SSH original, que fue la última lanzada bajo una licencia de código abierto. Esto sirvió como base de código para el software OSSH de Björn Grönvall. 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.

A partir de 2005, OpenSSH fue la implementación de SSH más popular, siendo la versión predeterminada en una gran cantidad de distribuciones de sistemas operativos. Mientras tanto, OSSH se ha vuelto obsoleto. OpenSSH se sigue manteniendo y es compatible con el protocolo SSH-2, ya que se eliminó la compatibilidad con SSH-1 del código base en la versión OpenSSH 7.6.

Usos

SSH es un protocolo que se puede usar para muchas aplicaciones en muchas plataformas, incluida la mayoría de las variantes de Unix (Linux, los BSD, incluido el macOS de Apple y Solaris), así como Microsoft Windows. Algunas de las aplicaciones 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 usar el protocolo SSH para implementar una VPN, pero actualmente solo con la implementación del servidor y el cliente OpenSSH.

• Para iniciar sesión en un shell en un host remoto (en sustitución de 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, usando OpenSSH)
• En combinación con rsync para realizar copias de seguridad, copiar y duplicar archivos de manera 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 transmisión en uno).
• Para usar como una VPN encriptada 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 admitan 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 supervisión y gestión remota automatizada de servidores a través de uno o más de los mecanismos mencionados anteriormente.
• Para el desarrollo en un dispositivo móvil o integrado que admita SSH.
• Para proteger los protocolos de transferencia de archivos.

Protocolos de transferencia de archivos

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

• Copia segura (SCP), que evolucionó del protocolo RCP sobre SSH
• rsync, destinado a 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 (que no debe confundirse con FTP sobre SSH o FTPS)
• Archivos transferidos a través del protocolo de shell (también conocido como FISH), lanzado en 1998, que evolucionó a partir de los comandos de shell de Unix sobre 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.

Arquitectura

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

• La capa de transporte (RFC 4253) generalmente usa el Protocolo de control de transmisión (TCP) de TCP/IP, reservando el puerto número 22 como un puerto de escucha del servidor. Esta capa maneja el intercambio de claves inicial, 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, generalmente después de que se haya transferido 1 GB de datos o después de que haya pasado una hora, lo que ocurra primero.
• La capa de autenticación de usuario (RFC 4252) maneja la autenticación del cliente y proporciona un conjunto de algoritmos de autenticación. La autenticación está dirigida por el cliente: cuando se solicita una contraseña, puede ser el cliente SSH, 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: un método para la autenticación directa de contraseñas, que incluye una función que permite cambiar una contraseña. No todos los programas implementan este método.
  • clave pública: un método para la autenticación basada en clave pública, que generalmente admite al menos pares de claves DSA, ECDSA o RSA, con otras implementaciones que también admiten certificados X.509.
  • teclado interactivo (RFC 4256): un método versátil en el que el servidor envía una o más indicaciones para ingresar información y el cliente las muestra y envía las 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 conduce a la imposibilidad de iniciar sesión con un cliente que admite solo el método de autenticación de contraseña simple.
  • Métodos de autenticación GSSAPI que brindan un esquema extensible para realizar la autenticación SSH utilizando 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 generalmente se implementan mediante implementaciones SSH comerciales para su uso en organizaciones, aunque OpenSSH tiene una implementación GSSAPI que funciona.
• 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 múltiples 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 cambio de tamaño 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 canales estándar incluyen:
  • shell para shells de terminales, SFTP y solicitudes ejecutivas (incluidas las transferencias SCP)
  • direct-tcpip para conexiones reenviadas de cliente a servidor
  • forwarded-tcpip para conexiones reenviadas de servidor a cliente
• El registro SSHFP DNS (RFC 4255) proporciona las huellas dactilares de la clave pública del host para ayudar a verificar la autenticidad del host.

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

Algoritmos

• EdDSA, ECDSA, RSA y DSA para criptografía de clave pública.
• ECDH y Diffie-Hellman para el intercambio de claves.
• HMAC, AEAD y UMAC para MAC.
• AES (y RC4, 3DES, DES en desuso) para el cifrado simétrico.
• AES-GCM y ChaCha20-Poly1305 para cifrado AEAD.
• SHA (y MD5 en desuso) para la huella digital clave.

Vulnerabilidades

SSH-1

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 integridad de datos de CRC-32 utilizada en esta versión del protocolo. Se introdujo una solución conocida como SSH Compensation Attack Detector en la mayoría de las implementaciones. Muchas de estas implementaciones actualizadas contenían una nueva vulnerabilidad de desbordamiento de enteros 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. El mismo mes, se descubrió otra vulnerabilidad que permitía que un servidor malicioso reenviara la autenticación de un cliente a otro servidor.

Dado que SSH-1 tiene fallas de diseño inherentes que lo hacen vulnerable, ahora generalmente se considera obsoleto y debe evitarse deshabilitando explícitamente el respaldo a SSH-1. La mayoría de los servidores y clientes modernos admiten SSH-2.

Recuperación de texto sin formato CBC

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 sin formato de un bloque de texto cifrado que se cifraba utilizando lo que entonces era el modo de cifrado predeterminado estándar, CBC. La solución más sencilla es utilizar CTR, el modo de contador, en lugar del modo CBC, ya que esto hace que SSH sea resistente al ataque.

Sospecha de descifrado por parte de la NSA

El 28 de diciembre de 2014, Der Spiegel publicó información clasificada filtrada por el denunciante Edward Snowden que sugiere que la Agencia de Seguridad Nacional podría 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.

Documentación de normas

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

• RFC 4250: números asignados del protocolo Secure Shell (SSH)
• RFC 4251: la arquitectura del protocolo Secure Shell (SSH)
• RFC 4252: el protocolo de autenticación Secure Shell (SSH)
• RFC 4253: el protocolo de capa de transporte Secure Shell (SSH)
• RFC 4254: el protocolo de conexión Secure Shell (SSH)
• RFC 4255: uso de DNS para publicar de forma segura huellas dactilares de clave Secure Shell (SSH)
• RFC 4256: autenticación de intercambio de mensajes genéricos para el protocolo Secure Shell (SSH)
• RFC 4335: extensión de interrupción de canal de sesión de Secure Shell (SSH)
• RFC 4344: los 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: Diffie-Hellman Group Exchange 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 programa de aplicación de servicio de seguridad genérico (GSS-API) Autenticación e intercambio de claves para el protocolo Secure Shell (SSH) (mayo de 2006)
• RFC 4716: formato de archivo de clave pública Secure Shell (SSH) (noviembre de 2006)
• RFC 4819: subsistema de clave pública de Secure Shell (marzo de 2007)
• RFC 5647: modo de contador AES Galois para el protocolo de capa de transporte de shell seguro (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 la autenticación de shell seguro (marzo de 2011)
• RFC 6239: suites criptográficas Suite B 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: registros de recursos SSHFP Ed25519 (marzo de 2015)
• RFC 5592: modelo de transporte de shell seguro para el protocolo simple de administración de redes (SNMP) (junio de 2009)
• RFC 6242: uso del protocolo NETCONF sobre Secure Shell (SSH) (junio de 2011)
• draft-gerhards-syslog-transport-ssh-00: asignación 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 de OpenSSH
• draft-miller-ssh-agent-04 - Protocolo de agente SSH (diciembre de 2019)