¿Puede la raíz de un sistema acceder a datos no cifrados cuando se utiliza un túnel doble?

Antes de intentar cambiar el rendimiento por seguridad, sugiero que en realidad se midan el rendimiento. La sobrecarga para el cifrado SSH es leve; aumenta el tamaño de los datos en menos del 1%, y el uso de la CPU es bajo, a menos que tenga una CPU bastante débil o una red bastante rápida (una CPU Core2 puede mantenerse con 10 MBytes / s SSH usando menos del 15% de un solo núcleo ). Entonces, lo más probable es que el método seguro, con el doble túnel, no sea tan caro.

Además, en su segunda sugerencia, tiene menos gastos generales de tamaño y también menos gastos generales de CPU en su sistema de escritorio (A), pero más gastos generales de CPU en la puerta de enlace (B), ya que esa puerta de enlace tendría que descifrar los datos de A y para volver a cifrarlos y enviarlos a C. Dado que una pasarela tiende a ser un recurso compartido, es probable que la CPU libre sea más escasa en B que en A. Por lo tanto, si el rendimiento es importante (no lo creo, y debería medirse de todos modos), entonces el método seguro es también el mejor método para rendimiento.

Como lo señala @Iszi, su segundo método también es inseguro, ya que permitiría que la pasarela haga un Ataque MitM . Me gustaría señalar que también hace que el uso de scp sea más difícil. Por lo tanto, debe utilizar el método de túnel en túnel: es más seguro, más flexible e incluso podría ser más rápido.

Si alguien tiene acceso a B en el escenario dado, podría configurar un proxy para realizar un ataque de intermediario en la conexión de A a C. Esto les permitiría descifrar cualquier tráfico entre A y C, si no está cifrado de otro modo en un nivel superior.

El atacante configuraría B para presentarse a A como C mientras usa el par de claves del atacante. Luego, de manera similar, se haría pasar por A a C, de modo que la información se puede pasar a través de B como si no pasara nada inusual, excepto que el atacante ahora puede detectar el tráfico en B.

La única manera de detectar esto sería que A y / o C tengan copias verificadas preexistentes de las claves públicas de cada uno. Luego, cuando el atacante salta al medio con sus claves, la entidad que no es de confianza puede ser reconocida y la conexión rechazada.

Sí, es posible que el usuario root en B pueda detectar su tráfico, aunque no diga exactamente qué sistema operativo es. En Linux, eso podría incluir el programa ttysnoop o usar un depurador contra sshd.

He usado mucho túnel en un túnel (así como SSH sobre PPP sobre SSH, que es otra capa), y no necesariamente tiene una carga seria de rendimiento o latencia. Por supuesto, hay una sobrecarga de algunos , pero no más que la variabilidad habitual de una conexión.

Considere el peor de los casos para un solo personaje. En Telnet, se enviaría como una trama Ethernet con una carga útil de 46 bytes (encabezado IP de 20 bytes, encabezado TCP de 20 bytes, datos de 1 byte, pero el estándar Ethernet requiere una carga útil mínima de 46 bytes, 42 en un entorno VLAN). En SSH sería una carga útil de 68 bytes ("El tamaño mínimo de un paquete es 16 (o el tamaño del bloque de cifrado, el que sea más grande) bytes (más 'mac').", RFC 4253 ); Veo 92 bytes viendo una conexión real con Wireshark. En SSH-over-SSH está la sobrecarga del encuadre de SSH; Veo una carga útil de 140 bytes.

Al enviar una gran cantidad de datos, SSH usa marcos (sobre TCP, por lo tanto, no está limitado por el tamaño del paquete) de hasta 32k bytes, por lo que la sobrecarga de doble túnel es insignificante. Me toma 20 años transferir un archivo 2M a una máquina virtual a la que puedo acceder a través de un túnel SSH o directamente a través de SSH. Si I dd es un archivo de texto de 36k, se necesitan aproximadamente 84 paquetes de casi 1380 bytes para enviar desde una sesión ssh "simple".

Por último, el comando exacto que dio,

ssh user@B ssh user@C

probablemente no hará lo que esperas; este segundo "ssh" probablemente mostrará el mensaje "El pseudo-terminal no se asignará porque stdin no es un terminal", y obtendrá un shell que no le solicita la entrada o la edición de la línea de comandos. En su lugar, intente

ssh user@B -t ssh user@C

También tenga en cuenta que esto podría resultar en más paquetes pequeños (= sobrecarga de encabezado TCP y retraso real) si el host B no puede mantenerse al día con los datos que ingresan.