Vulnerabilidades de Secure Shells

El servidor remoto no tiene acceso a su máquina; la sesión SSH es esencialmente un túnel hacia una cuenta de shell en la máquina remota.

La razón por la que SSH es seguro es que usa mecanismos similares a TLS , que hacen cumplir la confidencialidad y la autenticidad. Esencialmente, el servidor SSH tiene una clave pública, que se transmite a usted y se almacena en su máquina. Entonces confías en esa clave para todas las comunicaciones futuras. Siempre que la transmisión original de la clave pública SSH no haya sido alterada, puede mantener la seguridad de las comunicaciones en el futuro.

Cuando se conecta, su cliente usa la clave pública del servidor para cifrar una clave de sesión generada aleatoriamente, y envía esa clave cifrada al servidor, que usa la clave privada (que es secreta, y que solo el servidor conoce) para descifrar el mensaje. En ese momento, solo usted y el servidor conocen la clave de la sesión y pueden usarla para cifrar mensajes utilizando un cifrado simétrico. La clave de sesión también se utiliza para imponer la autenticidad e integridad de los mensajes, a través de un código de autenticación de mensajes , que permite a ambos lados de la conversación para garantizar que ninguna parte de la transmisión haya sido alterada por un tercero.

Una versión simplificada del protocolo de enlace es la siguiente:

1. El servidor genera un par de claves para un cifrado asimétrico, por ejemplo, RSA. La clave privada se mantiene en secreto. Este par de claves se utiliza como la identidad del servidor, y generalmente solo se genera una vez, y luego se actualiza con poca frecuencia.
2. El servidor envía al cliente su clave pública. Esto solo tiene que suceder una vez, por primera vez el cliente se comunica con el servidor, o si el servidor cambia su clave pública. Después de eso, el cliente conserva una copia local de la clave pública.
3. El cliente y el servidor acuerdan un paquete de cifrado para usar, por ejemplo, AES-128 y SHA256. Este proceso es bastante complejo y está algo fuera del alcance de esta respuesta.
4. El cliente genera una clave de sesión aleatoria para el cifrado simétrico elegido (por ejemplo, una clave de 128 bits para AES-128) y la cifra con la clave pública del servidor.
5. El cliente envía el mensaje al servidor.
6. El servidor descifra el mensaje usando la clave privada, y usa la clave de sesión desencriptada como la clave para el cifrado simétrico elegido.
7. Cada mensaje se cifra mediante el cifrado simétrico y se autentica a través de un HMAC en función del algoritmo hash elegido en el acuerdo de conjunto de cifrado. Ambas partes ahora pueden intercambiar mensajes de forma segura.

Obviamente, esto pasa por alto algunos detalles, pero es una representación razonable de lo que sucede.

La respuesta de Polinomio cubre la parte difícil de tu pregunta. Para el resto:

"¿Qué hace que un shell seguro sea tan seguro?"

"Secure Shell" fue la alternativa a lo que existía antes. Telnet, FTP, rcp y rsh.

Todos esos protocolos funcionaron de forma clara y podrían ser interceptados trivialmente por cualquier persona que pudiera detectar el tráfico. También estaban sujetos a ataques de suplantación y ataques en el medio, donde el imitador o MITM podrían recopilar sus credenciales o ver su sesión.

"¿Hay alguna vulnerabilidad o preocupación acerca del uso de este canal con tanta frecuencia?"

No hay nada específicamente incorrecto en usar SSH con frecuencia. Es una práctica común en los círculos técnicos usar SSH para todo. Los riesgos de seguridad para SSH generalmente están vinculados a los usuarios que usan contraseñas débiles en los servidores con acceso a Internet, o los administradores que no pueden mantener la ssh actualizada, no bloquean las cuentas después de demasiados intentos fallidos o utilizan la limitación de velocidad para mitigar el forzoso.

Es mejor deshabilitar la autenticación basada en contraseña y confiar exclusivamente en pares de claves públicas y privadas. Los pares clave no pueden ser forzados brutalmente.

El uso de par de llaves y fideicomisos no centralizados hace que las implementaciones de SSH sean más confiables que SSL. Pero requiere que un usuario más técnico entienda cómo usar SSH correctamente.