¿Qué es SSH y cómo funciona?

Secure Shell (SSH) es un protocolo de seguridad comúnmente implementado con una variedad de usos diferentes. Su aplicación más reconocida permite a los usuarios acceder de forma segura a computadoras y servidores remotos, pero también se puede usar para túneles, reenvío de puertos, transferencias de archivos seguras y más.

En esta guía, cubriremos qué es SSH, para qué se utiliza, la historia del protocolo, sus detalles técnicos, así como el temas de seguridad que hay que tener en cuenta.

SSH se compone de tres protocolos separados: la capa de transporte, la capa de autenticación y la capa de conexión. Juntos, sirven para autenticar a la otra parte en la conexión, proporcionar confidencialidad a través del cifrado y verificar la integridad de los datos. SSH ahora se implementa más comúnmente como el SSH-2 patentado o como la iteración de código abierto, OpenSSH.

Los usos de SSH

SSH es un protocolo versátil. Su estructura y características de seguridad le permiten usarse de varias maneras, como para acceso remoto, reenvío de puertos, tunelización y transferencias de archivos seguras.

Acceso remoto

El acceso remoto brinda a los usuarios una forma de iniciar sesión en otra computadora o servidor desde su propia máquina. Se utiliza para acceder a los archivos locales de la máquina de destino o realizar servicios en él, todo sin tener que estar físicamente allí..

Programas como Telnet y rlogin también tienen esta funcionalidad, pero carecen de las características de seguridad de SSH. Las medidas de encriptación y autenticación involucradas en SSH permiten a los usuarios conectarse a otro servidor o computadora de manera protegida, incluso a través de una red intermedia potencialmente peligrosa.

El acceso remoto con SSH se implementa comúnmente para que los empleados puedan trabajar de forma remota o para permitir que el departamento de TI realice tareas sin tener que ir físicamente a la máquina. Se puede usar para administración remota, administración de infraestructura de red, para configurar la automatización, crear copias de seguridad y más.

Reenvío de puertos

El reenvío de puertos se utiliza para transferir solicitudes de una dirección y número de puerto a otro conjunto. Aplica la traducción de direcciones de red (NAT) para redirigir los puertos entre una red local y una computadora remota, lo que le permite acceder a un dispositivo desde fuera de la red.

El reenvío de puertos se puede hacer de tres maneras diferentes:

• Local reenvío de puertos – El reenvío de puerto local le permite conectar su cliente local y una red externa. Puede ser efectivo para hacer cosas como acceder a sitios web que están bloqueados localmente o para conectarse a una base de datos que está detrás de un firewall.
• Reenvío de puerto remoto – Este tipo de reenvío permite que las aplicaciones del lado del servidor accedan a los servicios del lado del cliente. El reenvío de puerto remoto de SSH permite a los usuarios conectarse de forma segura a servidores remotos a través de su PC local al redirigir un puerto local a un servidor SSH remoto.
• Dinámica reenvío de puertos – Esto permite a los usuarios enviar sus datos a través de un puerto particular a una computadora o servidor remoto mediante el uso de varios servidores SSH que actúan como servidores proxy.

Tunelización

Los protocolos de túnel utilizan la encapsulación para mover datos entre redes. Los túneles se pueden implementar para permitir que los protocolos no nativos se ejecuten a través de redes que normalmente no los admitirían. Otro uso común es para Proporcionar seguridad a través de una red insegura.

Los protocolos de túnel envuelven paquetes críticos dentro de la carga útil de otro paquete. El túnel SSH permite a los usuarios evadir la seguridad de la red, vincular dispositivos utilizando un protocolo de red no nativo y proteger los datos que se transmiten. Con frecuencia se usan para conectar a usuarios remotos a los recursos en línea de su organización de manera segura.

SFTP

El Protocolo de transferencia de archivos SSH (FTP), a veces conocido como Protocolo seguro de transferencia de archivos, proporciona una forma segura de acceder, transferir y administrar archivos. Es una alternativa segura a FTP y aprovecha el protocolo SSH para enviar, recibir y administrar archivos de manera segura.

SCP

El Protocolo de copia segura (SCP) es similar al SFTP, pero más limitado en su alcance. Solo permite transferencias de archivos seguras, en lugar del conjunto completo de características que permiten que SFTP actúe como un protocolo de sistema de archivos remoto.

Plataformas & aplicaciones que usan SSH

Los SSH o OpenSSH patentados se pueden usar en todos los sistemas operativos principales. Está disponible en plataformas basadas en Unix como OpenBSD, macOS, Linux y Solaris, mientras que los usuarios de Windows pueden usar SSH a través de PowerShell.

La historia de SSH

SSH fue desarrollado en la Universidad Tecnológica de Helsinki en 1995 por Tatu Ylönen en respuesta a un ataque de detección de contraseñas en la red de la universidad. Su objetivo era proporcionar una alternativa a protocolos como FTP, TELNET, rsh y rlogin, que no garantizaba la confidencialidad ni autenticaba a los usuarios de manera segura.

SSH fue lanzado de forma gratuita al público en 1995 y fue bien recibido. En medio de su rápida adopción, Ylönen fundó SSH Communications Security a fines del mismo año para continuar el desarrollo y comercializar SSH.

En 1995, Ylönen también publicó un Borrador de Internet del Internet Engineering Task Force (IETF) que documentado el protocolo SSH-1. Pronto se encontraron limitaciones en el protocolo y no se pudieron abordar sin afectar la compatibilidad con versiones anteriores. La solución fue una nueva versión del protocolo, y la compañía de Ylönen lanzó SSH-2 en 1996.

SSH-2 presentó nuevos algoritmos, lo que llevó al IETF a fundar un grupo de trabajo que tenía como objetivo estandarizar el protocolo. El grupo fue apodado SECSH, por Segundoure Shell, y publicó su primer Borrador de Internet para SSH-2 en 1997.

El software para SSH-2 se lanzó en 1998, pero no se adoptó inmediatamente de manera generalizada debido a su licencia más restrictiva. En 2006, el IETF convirtió en estándar una versión alterada del protocolo.. Esto fue más seguro, utilizando códigos de autenticación de mensajes para verificar la integridad y el intercambio de claves Diffie-Hellman para la autenticación.

En 1999, el proyecto OpenBSD lanzó OpenSSH. OpenSSH es una versión gratuita del protocolo eso se basa en las modificaciones que Björn Grönvall realizó a SSH 1.1.12. Los desarrolladores volvieron a esta versión anterior y la alteraron mucho, porque era la última versión de SSH que era completamente de código abierto. OpenSSH es ahora la opción más utilizada y desde entonces se ha implementado en una variedad de sistemas operativos, como Windows, macOS, Linux, Solaris y otros..

SSH-1 vs SSH-2 vs OpenSSH

Como se señaló anteriormente, SSH-1 es la primera versión del protocolo, que se lanzó originalmente bajo un licencia de código abierto. Se considera inseguro y no debe implementarse. Esto deja la versión propietaria, SSH-2, y la versión de libre acceso, OpenSSH, como alternativas viables..

SSH-2 y OpenSSH son esencialmente lo mismo cuando se trata de su arquitectura y cómo funcionan. La principal diferencia es que la versión patentada viene con una gama de opciones de soporte, mientras que las que usan OpenSSH deben confiar en los recursos creados libremente por la comunidad.

SSH: los detalles técnicos

SSH-1 funcionó como un protocolo único, pero no entraremos aquí porque es obsoleto. En cambio, nos centraremos en SSH-2 y OpenSSH, que están formados por tres protocolos separados:

• El protocolo de transporte – Esto establece la conexión y proporciona la seguridad subyacente.
• El protocolo de autenticación – Esta capa se usa para autenticar al cliente.
• El protocolo de conexión – Este protocolo maneja los canales a través de los cuales se transmiten los datos..

Cada uno de estos protocolos cumple una función única que funciona para establecer y asegurar una conexión, autenticar a la otra parte y transferir datos. El puerto de conexión TCP predeterminado es 22, y las conexiones se configuran entre un cliente SSH y un servidor SSH a lo largo del modelo cliente-servidor.

El proceso de inicio de sesión remoto de SSH continúa de acuerdo con la siguiente estructura básica (con variaciones dependiendo de la configuración), que cubriremos con más detalle más adelante:

• El cliente contacta al servidor SSH para comenzar la conexión.
• El servidor luego envía su clave pública al cliente para autenticar su identidad.
• Las dos partes negocian los parámetros para la conexión, luego establecen un canal seguro a lo largo de esas líneas.
• Luego, el usuario inicia sesión en el sistema operativo del servidor host y ahora puede administrar sus tareas de forma remota.

Protocolo de transporte

La capa de transporte es un protocolo de bajo nivel que se encarga de las siguientes tareas..

• Autenticación de host del servidor
• Intercambio de llaves
• Cifrado para la confidencialidad de los datos.
• Verificaciones de integridad para verificar que los datos no hayan sido alterados
• Establecer una ID de sesión que se pueda usar en los otros protocolos

los el protocolo de transporte solo autentica el servidor y no el cliente (la autenticación del cliente se realiza en el protocolo de autenticación si es necesario).

En la capa de transporte, el cliente inicia la conexión y las dos partes negocian cómo se intercambiarán las claves, qué algoritmo de clave pública se utilizará, qué cifrado de clave simétrica cifrará los datos, qué algoritmo de autenticación de mensaje se utilizará para verificar los datos y qué método de compresión (si corresponde) se implementará.

Una vez que comienza la conexión, tanto el servidor como el cliente deben enviar a través de una cadena de identificación, que incluye la versión del protocolo (2.0).

Negociación de algoritmos

Para configurar los parámetros de la conexión, ambas partes envían un paquete que contiene una lista con las siguientes opciones:

byte SSH_MSG_KEXINIT

byte [16] cookie (bytes aleatorios)
nombre-lista kex_algorithms
lista de nombres server_host_key_algorithms
name-list encryption_algorithms_client_to_server
nombre-lista encryption_algorithms_server_to_client
nombre-lista mac_algorithms_client_to_server
nombre-lista mac_algorithms_server_to_client
nombre-lista compresión_algoritmos_cliente_servidor_
nombre-lista compresión_algoritmos_servidor_a_cliente
lista de nombres languages_client_to_server
nombre-lista languages_server_to_client
booleanos first_kex_packet_follows
uint32 0 (reservado para futuras extensiones)

Cada lado enumera los parámetros que están dispuestos a aceptar en la conexión, separados por comas. El algoritmo preferido debe aparecer primero.

por intercambio de llaves (kex_algorithms), el primer algoritmo que admitan ambas partes se elegirá para la conexión (también puede haber otros factores que deben cumplirse, según el algoritmo que se haya elegido). Si las dos partes no pueden encontrar un algoritmo mutuamente compatible que satisfaga estos requisitos, entonces la conexión falla.

Algoritmos de clave de host del servidor son los algoritmos admitidos para la clave de host del servidor. El servidor presenta los algoritmos para los que tiene claves de host, mientras que el cliente especifica los algoritmos que está preparado para aceptar. La selección dependerá de si el método de intercambio de claves que se resolvió requiere una clave de host con capacidad de cifrado o una firma digital

Ambas partes enumeran el algoritmos de clave simétrica que están dispuestos a aceptar, con los métodos preferidos en la parte superior. Se debe utilizar la primera opción que aparece en la lista del cliente que también está en la lista del servidor. Si no se puede llegar a un acuerdo, la conexión falla.

Ambos Algoritmo MAC y el algoritmo de compresión se negocian de la misma manera.

Intercambio de llaves

El intercambio de claves es responsable de autenticación del servidor, y eso configura las claves que se usarán para asegurar la conexión en los siguientes pasos Generalmente comienza con las partes enviando sus listas de algoritmos compatibles entre sí. Alternativamente, cada lado puede adivinar el algoritmo preferido del otro lado y enviar un paquete que se ajuste a los parámetros de ese algoritmo al comienzo.

Si la suposición de una de las partes es correcta, ese paquete se usa como el primer paquete de intercambio de claves. Si ninguna de las conjeturas es correcta, cada lado debe dar un paso atrás y enviar sus listas de algoritmos preferidos. Si el mensaje de intercambio de claves incluye la firma digital del servidor como prueba de la legitimidad del servidor, se considera autenticación explícita del servidor. Si utiliza el secreto compartido en su lugar, se le conoce como autenticación implícita del servidor.

El intercambio de claves también es responsable de establecer un secreto compartido y un hash. El valor hash del intercambio de claves inicial se convierte en el identificador único de la sesión y también se usa como parte de las firmas digitales que prueban que la parte es el verdadero propietario de su clave privada.

La función hash que se use dependerá del método de intercambio de claves que se decida en la negociación. Cuando se complete el intercambio de claves, todas las comunicaciones futuras utilizarán el nuevo conjunto de claves y algoritmos.

Según un borrador de Internet del Grupo de trabajo de ingeniería de Internet (IETF), los siguientes métodos de intercambio de claves se consideran seguros:

• curva25519-sha256
• curva448-sha512
• diffie-hellman-group-exchange-sha256
• diffie-hellman-group14-sha256
• diffie-hellman-group15-sha512
• diffie-hellman-group16-sha512
• diffie-hellman-group17-sha512
• diffie-hellman-group18-sha512
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• gss-group14-sha256
• gss-group15-sha512
• gss-group16-sha512
• gss-group17-sha512
• gss-group18-sha512
• gss-nistp256-sha256
• gss-nistp384-sha384
• gss-nistp521-sha512
• gss-curve25519-sha256
• gss-curve448-sha512
• rsa2048-sha256

Algoritmo de clave de host del servidor

Estos algoritmos de clave pública se utilizan para autenticación del servidor, así como para establecer de forma segura la ID de sesión compartida. También se pueden usar opcionalmente para autenticar el host. SSH está diseñado para funcionar con una variedad de algoritmos de clave pública, tipos de codificación y formatos:

• Utiliza algoritmos de clave pública para cifrado y / o firmas digitales..
• Se puede implementar una variedad de métodos de codificación, lo que permite la configuración con diferentes formatos de datos, relleno y orden de bytes.
• Varios formatos de clave permiten codificar las claves de diferentes maneras, así como una variedad de representaciones de certificados.

Los algoritmos predeterminados incluyen lo siguiente, sin embargo, hay algunas otras variaciones que también se pueden implementar:

• ssh-rsa
• ssh-rsa-sha256
• ssh-dss
• ssh-dss-sha256
• x509v3-sign-dss
• x509v3-sign-dss-sha256
• x509v3-sign-rsa
• x509v3-sign-rsa-sha256

Algoritmos de cifrado

Los algoritmos de clave simétrica se utilizan para cifrar los datos y proporcionar confidencialidad. Los parámetros y la clave compartida que se utilizan en el proceso de cifrado se establecen en las fases anteriores de la conexión. El algoritmo elegido cifra la carga útil, la longitud del paquete, la longitud del relleno y los campos de relleno..

Se acepta una variedad de algoritmos de cifrado diferentes en SSH, pero por razones de seguridad, es mejor seguir con AES. Las claves deben tener un mínimo de 128 bits, pero se prefieren claves más grandes.

Algoritmos MAC

El protocolo de transporte verifica la integridad de los datos agregando un código de autenticación de mensaje (MAC) al paquete. Este MAC se basa en el secreto compartido (que se establece en el intercambio de claves), el número de secuencia del paquete y el contenido del paquete. Se calcula antes de que se realice el cifrado..

Las implementaciones deben ofrecer un algoritmo independiente para ejecutarse en cada dirección, aunque es ideal si se usa el mismo en ambos lados. Se puede implementar una amplia variedad de algoritmos de autenticación de mensajes, sin embargo, SHA-256 y superior se deben usar en la mayoría de las situaciones para garantizar un alto nivel de seguridad.

Compresión

La compresión no es obligatoria en el protocolo SSH, y sus implementaciones deben permitir que las conexiones continúen sin compresión. La compresión solo se puede implementar como una opción, utilizando esquemas como zlib. Si se usa compresión, solo afecta la carga útil. El MAC y el campo de longitud del paquete se calculan en función de la carga útil comprimida.

Paquete de protocolo de transporte

El paquete del protocolo de transporte está formateado para incluir la siguiente información (así como algunos detalles menos pertinentes que se han omitido):

• La longitud del paquete
• La longitud de relleno
• La carga útil
• Relleno
• Un código de autenticación de mensaje (MAC)

Protocolo de autenticación

Este protocolo es utilizado por el servidor para autenticar al cliente. Puede hacer esto con una variedad de mecanismos diferentes, muchos de los cuales dependen de la ID de sesión establecida en el protocolo de transporte. Algunos usan las comprobaciones de cifrado e integridad del protocolo de transporte junto con la ID de sesión, mientras que otros usan estos algoritmos por sí mismos.

El servidor utiliza su política local para decidir qué métodos de autenticación acepta de un usuario individual. Dado que el servidor ya ha sido autenticado en el protocolo de transporte, no hay necesidad de autenticar el servidor una vez más.

La seguridad del protocolo de autenticación depende del protocolo de transporte sobre el que se ejecuta. Si el protocolo de transporte no puede garantizar la confidencialidad o verificar la integridad de los datos, esto limita la forma en que el protocolo de autenticación se puede usar de manera segura.

Como ejemplo, si el protocolo de transporte no está aplicando la protección de integridad, entonces no se deberían permitir solicitudes como cambios de contraseña, ya que esto permitiría a los atacantes alterar los datos sin ser notados.

El protocolo de autenticación utiliza la autenticación de clave pública bajo el supuesto de que ni la clave privada del host del servidor ni la clave del host del cliente han sido comprometidas. Si el servidor se ha visto comprometido, esto puede llevar al nombre de usuario y contraseña del cliente a ser lanzado al atacante..

Para que la autenticación basada en host sea segura, el cliente no debe verse comprometido. Si esto es una posibilidad, entonces se deben agregar otros métodos de autenticación. Es importante tener en cuenta que el proceso de autenticación es tan fuerte como el método de intercambio más débil que acepta un servidor.

El proceso del protocolo de autenticación

El protocolo de autenticación comienza cuando el servidor envía al cliente una lista de sus métodos de autenticación aceptados. El cliente puede elegir entre estos métodos en cualquier orden. Este proceso le da control al servidor, pero también permite suficiente flexibilidad para que el cliente pueda organizar el uso del método más conveniente.

Los métodos de autenticación de clientes más comunes incluyen:

• Llave pública – Este método utiliza algoritmos como RSA, DSA y ECDSA para autenticar al cliente mediante criptografía de clave pública. Algunas implementaciones también usan certificados x.509. El servidor verifica la firma digital del cliente con su clave pública para verificar la identidad del cliente..
• Contraseña – Las contraseñas también se pueden usar para autenticar al cliente. El cliente envía a través de su contraseña (que debe estar encriptada por el protocolo de transporte). Si la contraseña coincide con el valor almacenado del servidor, se acepta y la autenticación avanza.
• GSSAPI – Bajo este método, los esquemas externos como Kerberos se pueden usar para el inicio de sesión único.
• Teclado interactivo – Esta técnica proporciona autenticación de contraseña única al hacer que el servidor solicite información al cliente.

Protocolo de conexión

El protocolo de conexión establece cómo se combinarán múltiples canales de datos sobre la capa de transporte segura. También se ocupa de los parámetros que se utilizan para acceder a subsistemas seguros en el host del servidor, así como el envío de proxy y el acceso a shells.

El protocolo de conexión se encuentra en la parte superior de la capa de transporte y los protocolos de autenticación. Permite la ejecución remota de comandos, así como las conexiones X11 y TCP / IP reenviadas. Si el servidor o el cliente se han visto comprometidos, entonces el protocolo de conexión no es seguro.

Canales

Los canales son las vías de comunicación básicas, y cualquiera de las partes puede abrirlos. Los canales pueden incluir sesiones de terminal, conexiones reenviadas y otras formas de comunicación. Cuando hay múltiples canales, se multiplexan en una conexión.

Abriendo canales

Cada canal está numerado en ambos extremos, aunque los números pueden ser potencialmente diferentes en cada lado. Cuando un lado solicita abrir un canal, envía su número de canal como parte del mensaje, así como información sobre el tamaño de ventana inicial y el tamaño máximo de paquete.

El tamaño de la ventana inicial indica cuántos datos puede recibir la parte que abre el canal. Si es necesario enviar más datos, primero se debe ajustar la ventana. Del mismo modo, el tamaño máximo del paquete especifica qué tan grande de un paquete se puede recibir.

Cuando un lado solicita que se abra un canal, el otro lado abrirá el canal si puede acomodarlo. Si no, enviará un mensaje de error. Los canales pueden no abrirse por los siguientes motivos:

• Prohibido por la administración
• Conexión fallida
• Tipo de canal desconocido
• Escasez de recursos

Si cualquiera de los lados de la conexión desea enviar más datos de los que la ventana permite actualmente, pueden enviar un mensaje solicitando agregar más bytes.

Canales de cierre

Una vez que un lado de una conexión ha completado su transmisión de datos, debe enviar un mensaje indicando que ha terminado de usar el canal. A pesar de esto, el canal se mantiene abierto y la otra parte aún puede enviar los datos. Si una parte desea finalizar por completo el canal, lo hace con un mensaje de finalización por separado.

Seguridad SSH

Las diversas versiones de SSH han tenido sus propios problemas de seguridad, aunque las configuraciones actuales de SSH-2 y OpenSSH se consideran mucho más seguros que SSH-1.

SSH-1

SSH-1 generalmente se considera defectuoso, con una gama de vulnerabilidades diferentes. Estos incluyen un error en SSH 1.5 que permitió a usuarios no autorizados insertar contenido en el flujo de datos SSH. Este ataque aprovechó la protección mínima de integridad de datos del algoritmo CRC-32.

Este ataque se mitigó con el Detector de ataque de compensación SSH, que se integró en la mayoría de las implementaciones más nuevas. Esta solución vino con una nueva vulnerabilidad, que tenía el poder de ejecutar código arbitrario con privilegios de root.

También hay una vulnerabilidad que permite a los adversarios cambiar el último bloque en una sesión que usa encriptación IDEA, así como una que permite que un servidor comprometido reenvíe el proceso de autenticación del cliente a un servidor diferente.

Debido a estos problemas de seguridad, se debe usar SSH-2 en su lugar. Para mantener su implementación segura, también debe deshabilitar la renegociación a SSH-1, porque los ataques pueden aprovechar esto para acceder a sus datos a través del nivel de protección más débil de SSH-1.

SSH-2

SSH-2 es vulnerable a un ataque teórico contra su modo predeterminado de cifrado, CBC. Permite al atacante recuperar hasta 32 bits del texto sin formato de un bloque cifrado. Esto puede mitigarse mediante el uso del modo Contador (CTR) y, en su lugar, convirtiendo el cifrado de bloque en un cifrado de flujo.

A finales de 2014, Der Spiegel publicó documentos de la NSA que implicaban que la NSA a veces podría romper SSH. Este PowerPoint de la NSA filtrado afirma que la NSA puede “Potencialmente recuperar nombres de usuario y contraseñas“, Aunque no se dan más detalles. No se sabe qué métodos utilizó la agencia para hacer esto, pero parece poco probable que mienta sobre sus capacidades en su propia documentación interna.

En la fuga de la Bóveda 7 de 2023, se reveló que la CIA tenía dos herramientas que podían usarse para interceptar y robar inicios de sesión y contraseñas SSH. BothanSpy apuntó a clientes de Windows Xshell, mientras que Gyrfalcon se usó contra el cliente OpenSSH en varias distribuciones de Linux diferentes.

Estas herramientas son capaces de robar credenciales y luego transmitirlas de vuelta a un servidor CIA. Ninguno de estos ataques puede romper el protocolo en sí; solo usan otros ataques de canal lateral que pueden evitarlo en ciertas implementaciones.

A pesar de estos ataques, SSH-2 se considera seguro en la mayoría de las situaciones, siempre que se implemente adecuadamente. Los objetivos de alto valor o aquellos que usan implementaciones desactualizadas o deficientes deben considerar otras opciones.

OpenSSH

En OpenSSH versión 2, se descubrió un ataque que aprovechó una debilidad en el paquete binario SSH. El ataque permitió a los investigadores de la Universidad de Londres recuperar 14 bits del texto sin formato de un bloque cifrado. Esto se mitigó en la versión 5.2 al hacer que el protocolo lea la totalidad de una longitud de paquete no válida o un código de autenticación de mensaje, en lugar de finalizar la conexión.

En las versiones 6.8 y 6.9, Linux podría usarse para ejecutar comandos arbitrarios en los terminales de otros usuarios. Esto se logró a través de una vulnerabilidad de escalada de privilegios que permitió a los atacantes inyectar caracteres con el control de entrada / salida TIOCSTI.

¿SSH es seguro??

Si bien puede parecer que SSH tiene muchos problemas de seguridad, es relativoEs normal que se encuentren una serie de vulnerabilidades en las diversas implementaciones de un protocolo. Esto no significa que el protocolo SSH no sea seguro. En cambio, solo significa que necesita ser implementado correctamente.

Mientras esté usando cualquiera SSH-2 u OpenSSH y está configurado de manera apropiada para su uso, debe sentirse seguro de la protección que SSH proporciona a su conexión. Es por eso que sigue siendo un protocolo de uso tan frecuente, especialmente para fines de acceso remoto y tunelización..

Consulte también: Tipos de cifrado comunes explicados

Fondo de tecnología de red cibernética por TheDigitalArtist con licencia bajo CC0