¿Cuál es la diferencia entre SSL y SSH? ¿Cuál es más seguro?

SSL y SSH proporcionan los elementos criptográficos para construir un túnel para el transporte de datos confidenciales con integridad comprobada. Para esa parte, utilizan técnicas similares, y pueden sufrir los mismos tipos de ataques, por lo que deberían proporcionar una seguridad similar (es decir, una buena seguridad) suponiendo que ambas se implementen correctamente. Que ambos existen es una especie de síndrome NIH : los desarrolladores de SSH deberían haber reutilizado SSL para la parte del túnel (el protocolo SSL es lo suficientemente flexible para acomodar muchas variaciones, incluyendo no usar certificados).

Se diferencian en las cosas que están alrededor del túnel. SSL tradicionalmente utiliza certificados X.509 para anunciar claves públicas de servidor y cliente; SSH tiene su propio formato. Además, SSH viene con un conjunto de protocolos para lo que va dentro del túnel (multiplexando varias transferencias, realizando una autenticación basada en contraseña dentro del túnel, administración de terminales ...) mientras que no hay tal cosa en SSL , o, más exactamente, cuando se usan tales cosas en SSL, no se considera que sean parte de SSL (por ejemplo, cuando se realiza una autenticación HTTP basada en contraseña en un túnel SSL, decimos que es parte de "HTTPS", pero realmente funciona de una manera similar a lo que sucede con SSH).

Conceptualmente, podría tomar SSH y reemplazar la parte del túnel con la de SSL. También puede tomar HTTPS y reemplazar lo SSL con SSH-with-data-transport y un gancho para extraer la clave pública del servidor de su certificado. No hay imposibilidad científica y, si se hace correctamente, la seguridad seguirá siendo la misma. Sin embargo, no existe un conjunto generalizado de convenciones o herramientas existentes para eso.

Por lo tanto, no usamos SSL y SSH para las mismas cosas, pero eso se debe a las herramientas que históricamente vinieron con las implementaciones de esos protocolos, no debido a una diferencia relacionada con la seguridad. Y a quienes implementen SSL o SSH se les recomienda que analicen qué tipo de ataques se intentaron en ambos protocolos.

Esto no es una comparación razonable para hacer. SSL es un método general para proteger los datos transportados a través de una red, mientras que SSH es una aplicación de red para iniciar sesión y compartir datos con una computadora remota.

La protección de la capa de transporte en SSH tiene una capacidad similar a la de SSL, por lo que es "más segura" depende de lo que exija su modelo de amenaza específico y de si las implementaciones de cada uno abordan los problemas con los que está tratando de lidiar.

SSH tiene una capa de autenticación de usuario que carece de SSL (porque no la necesita, SSL solo necesita autenticar las dos interfaces de conexión que SSH también puede hacer). En el arte UTF-8:

      SSL              SSH
+-------------+ +-----------------+
| Nothing     | | RFC4254         | Connection multiplexing
+-------------+ +-----------------+
| Nothing     | | RFC4252         | User authentication
+-------------+ +-----------------+
| RFC5246     | | RFC4253         | Encrypted data transport
+-------------+ +-----------------+

En relación con el problema de los cuales hay más ataques potenciales, parece claro que SSH tiene una superficie de ataque más grande. Pero eso es solo porque SSH tiene una aplicación completa incorporada: la superficie de ataque de SSL + cualquier aplicación que necesite proporcionar no se puede comparar porque no tenemos suficiente información.

Desde un punto de vista criptográfico estricto, ambos proporcionan cifrado autenticado, pero de dos maneras diferentes.

SSH utiliza el llamado cifrado y MAC, es decir, el mensaje cifrado está yuxtapuesto a un código de autenticación de mensaje (MAC) del mensaje claro para agregar integridad. No se ha demostrado que esto siempre sea completamente seguro (incluso si en casos prácticos debería ser suficiente).

SSL usa MAC-then-Encrypt: un MAC está yuxtapuesto al texto claro, luego ambos están encriptados. Esto tampoco es lo mejor, ya que con algunos modos de cifrado de bloque, algunas partes del MAC pueden ser adivinables y revelar algo en el cifrado. Esto llevó a vulnerabilidades en TLS 1.0 (ataque BEAST).

Entonces ambos tienen debilidades teóricas potenciales. El método más sólido es Encrypt-then-MAC (agregar un MAC del mensaje cifrado), que se implementa, por ejemplo, en IPsec ESP.

ssh es como una clave (privada) y la cerradura (pública)

ssl es como la puerta y los ladrillos.

ssl proporciona un enlace seguro entre los dos servidores de la computadora. Por ejemplo, el tuyo y el que te estás conectando.

ssh es la forma en que la computadora que se conecta se puede verificar y obtener acceso.

El problema es doble, no es solo la fortaleza y la debilidad del cifrado. Pero es la facilidad y conveniencia de la entrega. Por lo tanto, desde la perspectiva empresarial, SSL / TLS es más conveniente y fácil porque solo requiere un navegador y un certificado público o privado.

Y SSH requiere que la aplicación o el thin client estén instalados para usarlo. Eso es más un problema desde la perspectiva y el soporte de un usuario de Internet.

No todos los usuarios son brillantes, especialmente los desafiados por la tecnología.

mis 2 centavos.

Creo que hay un aspecto de esta comparación que se pasó por alto. El usuario185 se acercó pero no llegó. Estoy de acuerdo en que estas son manzanas y naranjas y siento una mejor comparación de manzanas con manzanas para ser HTTPS y SSH. HTTPS y SSH utilizan diferentes capas del modelo OSI y, por lo tanto, cifran los datos en diferentes momentos de la transmisión. Entonces, las preguntas reales que uno debería plantearse serían las siguientes: cuándo se cifran y descifran estos datos durante la transmisión. Esto revelará sus posibles superficies de ataque. Con HTTPS, una vez que el dispositivo recibe el paquete en la red de destino (servidor web, enrutador de frontera, equilibrador de carga, etc.) no se encripta y pasa el resto de su viaje en texto sin formato. Muchos dirían que esto no es un gran problema ya que el tráfico es interno en este momento, pero si la carga útil contiene datos confidenciales, se almacena sin cifrar en los archivos de registro de cada dispositivo de red que pasa hasta que llega a su destino final. Con SSH, generalmente, el dispositivo de destino se especifica y la transmisión se cifra hasta que llega a este dispositivo. Hay formas de volver a cifrar los datos HTTPS, pero estos son pasos adicionales que la mayoría se olvida de tomar cuando implementa una solución HTTPS en su entorno.

SSL es una capa de protocolo que se abstrae del contenido que se está canalizando. SSH es una versión segura de shell (SH), no fue diseñada para contener una capa abstracta debajo de ella, fue diseñada específicamente para transportar tráfico de shell. Entonces, aunque las operaciones criptográficas se utilizan en ambas, y esas operaciones criptográficas podrían ser las mismas, el propósito y el diseño general son muy diferentes.

Tenga en cuenta que hay diferencias específicas (como se ha citado anteriormente), pero la mayoría, si no todas, están arraigadas en el propósito de los diferentes protocolos.

Si realmente estás buscando SSH vs SSL (TLS), la respuesta es SSH.

Por una razón por la cual SSH gana sobre SSL es la forma en que realiza la autenticación. Por este motivo, cuando se utiliza FTP, utilice el protocolo SSH (SFTP) en lugar de FTPS (FTP sobre SSL).

  

SSH se utiliza en redes corporativas para:

     

• proporcionar acceso seguro para los usuarios y procesos automatizados
  
• transferencias de archivos interactivas y automatizadas
  
• emitir comandos remotos
  

fuente: enlace