Dado que mecanismos como Telnet y Remote Shell están diseñados para acceder y operar computadoras remotas, enviar los 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 información. contraseña y lograr 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 destinados a 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. 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 más comúnmente implementada es OpenSSH , lanzada en 1999 como software de código abierto por los desarrolladores de OpenBSD . Las implementaciones se distribuyen para todo tipo 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 opera 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 cifrado en múltiples canales de comunicación lógicos. [1]
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ública-privada generadas 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 solicitar 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 correspondiente, que el propietario mantiene privada. 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, 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: gestión de claves OpenSSH
En sistemas tipo Unix , la lista de claves públicas autorizadas normalmente se almacena en el directorio de inicio del usuario al que se le permite iniciar sesión de forma remota, en el archivo ~/.ssh/authorized_keys. [4] Este archivo es respetado por SSH sólo si nadie más que el propietario y el root pueden escribir en él. 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 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.
Los administradores de archivos para sistemas tipo UNIX (por ejemplo, Konqueror ) pueden usar el protocolo FISH para proporcionar una GUI de panel dividido con función de arrastrar y soltar. El programa de código abierto de Windows WinSCP [6] proporciona una capacidad similar de gestión de archivos (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. La extensión de shell seguro del navegador Chrome también permite conexiones SSH sin necesidad de instalación de software e incluso permite SSH desde una computadora Chromebook . La configuración de un servidor SSH en Windows normalmente 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 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, 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 estándar 22 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]
Desarrollo historico
Versión 1
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 ) impulsado por 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 rápidamente ganó popularidad. Hacia finales de 1995, la base de usuarios de SSH había aumentado hasta alcanzar los 20.000 usuarios en cincuenta países. [ cita necesaria ]
Se estima que en el año 2000 el número de usuarios había aumentado a 2 millones. [dieciséis]
Versión 2
"Secsh" era el nombre oficial del Grupo de Trabajo de Ingeniería de Internet (IETF) para el grupo de trabajo del IETF responsable de la versión 2 del protocolo SSH. [17] 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 funciones con respecto a SSH-1. Una mayor seguridad, por ejemplo, se obtiene mediante el intercambio de claves Diffie-Hellman y una sólida comprobación de la integridad mediante códigos de autenticación de mensajes . Las nuevas características de SSH-2 incluyen la capacidad de ejecutar cualquier número de sesiones de shell a través de una única conexión SSH. [18] Debido a la superioridad y popularidad de SSH-2 sobre SSH-1, algunas implementaciones como libssh (v0.8.0+), [19] Lsh [20] y Dropbear [21] 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 especificaba que un servidor SSH que admitiera 2.0 y versiones anteriores debería identificar su versión de protocolo como 1.99. [22] 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, que deseaban disponer de una versión de software gratuita, reiniciaron el desarrollo de software a partir de la versión 1.2.12 del programa SSH original, que fue el último lanzado bajo una licencia de código abierto . [23] Esto sirvió como base de código para el software OSSH de Björn Grönvall. [24] 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. [25]
En 2005 [actualizar], OpenSSH era la implementación 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. [26] OpenSSH continúa manteniéndose y admite el protocolo SSH-2, habiendo eliminado el soporte SSH-1 del código base en la versión OpenSSH 7.6.
Usos
SSH es un protocolo que se puede utilizar para muchas aplicaciones en muchas plataformas, incluida la mayoría de las variantes de Unix ( Linux , BSD , incluidos macOS de Apple y Solaris ), así como Microsoft Windows . Algunas de las aplicaciones siguientes 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, usando OpenSSH [27] )
En combinación con rsync para realizar copias de seguridad, copiar y reflejar archivos de manera eficiente y segura
El protocolo rápido y seguro (FASP), también conocido como Aspera , utiliza SSH para control y puertos UDP para transferencia de datos.
Arquitectura
El protocolo SSH tiene una arquitectura en capas con tres componentes separados:
La capa de transporte ( RFC 4253) normalmente utiliza 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 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 la 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á impulsada por el cliente : cuando a uno se le solicita una contraseña, puede ser el cliente SSH la que la solicita, no el servidor. El servidor simplemente responde a las solicitudes de autenticación del cliente. Los métodos de autenticación de usuarios ampliamente utilizados incluyen los siguientes:
contraseña : un método para la autenticación de contraseña 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 para la autenticación basada en clave pública , que generalmente 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 devuelve las respuestas ingresadas por el usuario. Se utiliza para proporcionar autenticación de contraseña de un solo uso , como S/Key o SecurID . Utilizado por 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 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 utilizando mecanismos externos como Kerberos 5 o NTLM , proporcionando capacidad de inicio de sesión único para sesiones SSH. Estos métodos generalmente se implementan mediante implementaciones SSH comerciales para su uso en organizaciones, aunque OpenSSH tiene una implementación GSSAPI funcional.
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 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 canales estándar incluyen:
shell para shells de terminales, SFTP y solicitudes ejecutivas (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 pública del host para ayudar a verificar la autenticidad del host.
Esta arquitectura abierta proporciona una flexibilidad considerable, permitiendo 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 usuarios es altamente extensible con métodos de autenticación personalizados; y la capa de conexión proporciona la capacidad de multiplexar muchas sesiones secundarias en una única conexión SSH, una característica comparable a BEEP y no disponible en TLS.
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 una protección insuficiente de la integridad de los datos del CRC-32 utilizado en esta versión del protocolo. [33] [34] Se introdujo una solución conocida como Detector de ataques de compensación SSH [35] en la mayoría de las implementaciones. Muchas de estas implementaciones actualizadas contenían una nueva vulnerabilidad de desbordamiento de enteros [36] 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 . [37] El mismo mes, se descubrió otra vulnerabilidad que permitía a un servidor malicioso reenviar la autenticación de un cliente a otro servidor. [38]
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. [38] La mayoría de los servidores y clientes modernos admiten SSH-2. [39]
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 a partir de un bloque de texto cifrado cifrado utilizando lo que entonces era el modo de cifrado predeterminado estándar, CBC . [40] 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. [40]
Sospecha de descifrado por parte de la NSA
El 28 de diciembre de 2014, Der Spiegel publicó información clasificada [41] 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. [42]
Ataque de tortuga marina
En 2023 se descubrió un nuevo ataque de intermediario contra la mayoría de las implementaciones ssh actuales. Sus descubridores lo denominaron ataque Terrapin . [43] [44] Sin embargo, el riesgo se mitiga por el requisito de interceptar una sesión ssh genuina y porque el alcance del ataque está restringido, lo que fortuitamente resulta principalmente en conexiones fallidas. [45] [46] Los desarrolladores de ssh han declarado que el mayor impacto del ataque es degradar las funciones de ofuscación del tiempo de pulsación de teclas de ssh. [46] La vulnerabilidad se solucionó en OpenSSH 9.6, pero requiere que tanto el cliente como el servidor se actualicen para que la solución sea completamente efectiva.
RFC 4250: Números asignados del protocolo Secure Shell (SSH)
RFC 4251: 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 dactilares 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 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 – Autenticación e intercambio de claves de la interfaz del programa de aplicación de servicios de seguridad genérico (GSS-API) 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 Secure Shell (marzo de 2007)
RFC 5647: Modo contador AES Galois para el protocolo de capa de transporte Secure Shell (agosto de 2009)
RFC 5656: Integración del algoritmo de curva elíptica en la capa de transporte Secure Shell (diciembre de 2009)
RFC 6187 – Certificados X.509v3 para 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 curva elíptica DSA (ECDSA) en registros de recursos SSHFP (abril de 2012)
RFC 6668: Verificación de la integridad de los 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 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)
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 protocolo 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)
^ ab T. Ylonen; C. Lonvick (enero de 2006). La arquitectura del protocolo Secure Shell (SSH). Confianza del IETF. doi : 10.17487/RFC4251 . RFC 4251.
^ "Ciencia y tecnología de la Universidad de Missouri: Telnet seguro".
^ abc T. Ylonen; C. Lonvick (enero de 2006). El protocolo de autenticación Secure Shell (SSH). Confianza del IETF. doi : 10.17487/RFC4252 . RFC 4252.
^ "Cómo configurar claves autorizadas". Archivado desde el original el 10 de mayo de 2011.
^ Win-32 OpenSSH
^ "Página de inicio de WinSCP". Archivado desde el original el 17 de febrero de 2014.
^ "Página WinSCP para PortableApps.com". Archivado desde el original el 16 de febrero de 2014.
^ "Página PuTTY para PortableApps.com". Archivado desde el original el 16 de febrero de 2014.
^ Amies, A; Wu, CF; Wang, GC; Criveti, M (2012). "Redes en la nube". IBM DeveloperWorks . Archivado desde el original el 14 de junio de 2013.
^ "Registro de número de puerto de protocolo de transporte y nombre de servicio".
^ "Registro de número de puerto de protocolo de transporte y nombre de servicio". iana.org . Archivado desde el original el 4 de junio de 2001.
^ Seggelmann, R.; Tuxen, M.; Rathgeb, EP (18 a 20 de julio de 2012). SSH sobre SCTP: optimización de un protocolo multicanal adaptándolo a SCTP . VIII Simposio Internacional sobre Sistemas de Comunicación, Redes y Procesamiento de Señales Digitales (CSNDSP). págs. 1–6. doi :10.1109/CSNDSP.2012.6292659. ISBN978-1-4577-1473-3. S2CID 8415240.
^ Tatu Ylönen. "La nueva llave maestra: cambiar las cerraduras en su entorno de red". Archivado desde el original el 20 de agosto de 2017.
^ Tatu Ylönen. "Puerto SSH". Archivado desde el original el 3 de agosto de 2017.
^ Ylönen, Tatu. "La historia del puerto SSH es 22". www.ssh.com . Consultado el 30 de noviembre de 2023 .
^ Nicolás Rosasco y David Larochelle. "Cómo y por qué tecnologías más seguras tienen éxito en los mercados heredados: lecciones del éxito de SSH" (PDF) . Citando a Barrett y Silverman, SSH, Secure Shell: The Definitive Guide, O'Reilly & Associates (2001) . Departamento de Ciencias de la Computación, Univ. de Virginia. Archivado (PDF) desde el original el 25 de junio de 2006 . Consultado el 19 de mayo de 2006 .
^ "Documentos del protocolo Secsh". VanDyke Software, Inc. Archivado desde el original el 13 de enero de 2010.
^ "Preguntas frecuentes sobre SSH". Archivado desde el original el 10 de octubre de 2004.
^ "libssh".
^ "Una implementación GNU de los protocolos Secure Shell". Archivado desde el original el 4 de febrero de 2012.
^ "Dropbear SSH". Archivado desde el original el 14 de octubre de 2011.
^ Ylonen, T.; Lonvick, C. "Cliente antiguo, servidor nuevo". El protocolo de capa de transporte Secure Shell (SSH). IETF. segundo. 5.1. doi : 10.17487/RFC4253 . RFC 4253.
^ ssh-1.2.13 ahora disponible: política de copia modificada (ahora se requiere permiso para vender ssh comercialmente, el uso aún está permitido para cualquier propósito)
^ Fuentes OSSH
^ "OpenSSH: historial y créditos del proyecto". openssh.com. 2004-12-22. Archivado desde el original el 24 de diciembre de 2013 . Consultado el 27 de abril de 2014 .
^ "Información OSSH para VU#419241". Centro de Coordinación CERT . 2006-02-15. Archivado desde el original el 27 de septiembre de 2007. De cualquier manera ossh es viejo y obsoleto y no recomiendo su uso.
^ Sobell, Mark (2012). Una guía práctica para los comandos, editores y programación de Shell de Linux (3ª ed.). Upper Saddle River, Nueva Jersey: Prentice Hall. págs. 702–704. ISBN978-0133085044.
^ Harris, B.; Velvindron, L. (febrero de 2020). Algoritmos de clave pública Ed25519 y Ed448 para el protocolo Secure Shell (SSH). doi : 10.17487/RFC8709 . RFC 8709.
^ ab Stebila, D.; Verde, J. (diciembre de 2009). Integración del algoritmo de curva elíptica en la capa de transporte Secure Shell. doi : 10.17487/RFC5656 . RFC 5656 . Consultado el 12 de noviembre de 2012 .
^ Molinero, D.; Valchev, P. (3 de septiembre de 2007). El uso de UMAC en el protocolo de capa de transporte SSH. ID borrador-miller-secsh-umac-00.
^ Ylonen, T.; Lonvick, C. El protocolo de capa de transporte Secure Shell (SSH). IETF. doi : 10.17487/RFC4253 . RFC 4253.
^ Igoe, K.; Solinas, J. (agosto de 2009). Modo de contador AES Galois para el protocolo de capa de transporte Secure Shell. doi : 10.17487/RFC5647 . RFC 5647.
^ "Nota de vulnerabilidad VU#13877: CRC débil permite la inyección de paquetes en sesiones SSH cifradas con cifrados en bloque". CERT DE EE. UU . Archivado desde el original el 10 de julio de 2010.
^ "Vulnerabilidad del detector de ataques de compensación SSH CRC-32". Enfoque de seguridad . Archivado desde el original el 25 de julio de 2008.
^ "Nota de vulnerabilidad VU#945216: el código de detección de ataque SSH CRC32 contiene un desbordamiento de enteros remoto". CERT DE EE. UU . Archivado desde el original el 13 de octubre de 2005.
^ "Nota de vulnerabilidad VU#315308: CRC débil permite cambiar el último bloque del paquete SSH cifrado con IDEA sin previo aviso". CERT DE EE. UU . Archivado desde el original el 11 de julio de 2010.
^ ab "Nota de vulnerabilidad VU # 684820: SSH-1 permite que un servidor malicioso reenvíe la autenticación del cliente a otro servidor". CERT DE EE. UU . Archivado desde el original el 1 de septiembre de 2009.
^ "Cómo utilizar claves SSH para la autenticación". Arriba Nube . 17 de septiembre de 2015 . Consultado el 29 de noviembre de 2019 .
^ ab "Nota de vulnerabilidad VU#958563: vulnerabilidad SSH CBC". CERT DE EE. UU . Archivado desde el original el 22 de junio de 2011.
^ "Ojos curiosos: dentro de la guerra de la NSA contra la seguridad en Internet". Spiegel en línea . 28 de diciembre de 2014. Archivado desde el original el 24 de enero de 2015.
^ Ylonen, Tatu (3 de agosto de 2017). "BothanSpy & Gyrfalcon: análisis de las herramientas de piratería de la CIA para SSH". ssh.com . Consultado el 15 de julio de 2018 .
^ "Ataque de tortuga marina". terrapin-attack.com . Consultado el 20 de diciembre de 2023 .
^ Jones, Connor. "SSH sacudido, no afectado por la vulnerabilidad de degradación de Terrapin". www.theregister.com . Consultado el 20 de diciembre de 2023 .
^ Jones, Connor. "SSH sacudido, no afectado por la vulnerabilidad de degradación de Terrapin". www.theregister.com . Consultado el 20 de diciembre de 2023 .
^ ab "Notas de la versión de OpenSSH 9.6". openssh.com . 2023-12-18.
Otras lecturas
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.seguridad.unix.Anuncio original de Ssh
Dwivedi, Himanshu (2003). Implementando SSH . Wiley. ISBN 978-0-471-45880-7.
enlaces externos
Wikimedia Commons tiene medios relacionados con SSH .
Wikibooks tiene un libro sobre el tema: Tecnologías de Internet/SSH
Protocolos SSH
M. José; J. Susoy (noviembre de 2013). Subsistema de clave pública Secure Shell de P6R. doi : 10.17487/RFC7076 . RFC 7076.