Cuando ejecutas:
ssh -A -t [email protected]
estás estableciendo una sesión entre desktop y bar.com . A partir de ahora, todo lo que escriba en esta sesión se interpretará y ejecutará en bar.com .
Luego, establece una sesión de bar.com a server ( sls no es un comando estándar, pero supongo que es un contenedor para otra conexión SSH).
Tienes una segunda sesión cifrada entre bar.com y server . Esta sesión se autentica con su clave privada que se almacena en la máquina desktop .
En el primer comando tienes el argumento -A que habilita reenvío de agente . Este mecanismo permite encriptar la sesión entre bar.com y el servidor, usando la máquina desktop (y la clave privada almacenada allí) para la autenticación.
No significa que la segunda conexión esté cifrada de extremo a extremo entre desktop y server , solo significa que desktop autorizó una sesión entre bar.com y server .
La situación no se puede comparar con un ataque, porque elige deliberadamente utilizar la función para su propia conveniencia y seguridad (su clave privada no sale de su máquina, no almacena otra clave con acceso a server en bar.com , no tiene que escribir la contraseña).
La funcionalidad que aparentemente esperabas se llama tunelización o reenvío de puertos (aunque debe configurarse por separado) . Con esto, establece dos sesiones SSH desde desktop primero a bar.com y luego otra a un puerto diferente de bar.com que estaría "vinculado" al puerto 22 de server . En este escenario, bar.com no tendría la capacidad de ver "dentro" de la sesión SSH entre desktop y server .