¿Hay alguna razón para preocuparse por la ejecución de tmux / wemux en un host bastion? Me parece que abriría vectores para que sus sesiones de terminal sean secuestradas por alguna cuenta explotada localmente en el host bastion, algo a lo que el host bastion estaría menos expuesto si solo reenvía sesiones ssh.
¿O es demasiado paranoico?
Dado que tanto tmux como wemux usan su propio proceso de servidor y procedimientos de unión / autenticación, incrementan inherentemente la llamada "superficie de ataque": eso es más código que puede tener errores, y los errores pueden convertirse fácilmente vulnerabilidades.
Sin embargo, al menos tmux tiene buena reputación, con, hasta esta página dice, solo se vio afectada por una vulnerabilidad conocida, que fue relativamente menor (no fue un secuestro de sesión, sino una escalada de derechos en el grupo utmp ). Wemux es más reciente, lo que puede justificar una precaución adicional.
Un asunto más urgente es que si los usuarios pueden ejecutar tmux en el host, probablemente puedan ejecutar comandos arbitrarios, lo que podría ser un problema si estos usuarios son hostiles (entre ellos o con el sistema en general). , aunque solo sea a través de DoS simples (por ejemplo, una fork fork ). Con solo reenvío, SSH se puede "bloquear" de una manera que evita que los usuarios malvados sean una molestia para sus compañeros. Por lo tanto, no debe tener en cuenta tmux , sino el alcance de los servicios que desea ofrecer a sus usuarios: una cuenta shell completa, que es una oferta big .
He ejecutado la pantalla en los hosts bastion en el pasado, pero he estado tratando de alejarme de él solo por la razón que mencionas. Si el host del bastión está invadido, puede obtener acceso a todas sus sesiones abiertas. Por lo tanto, NO se recomienda ejecutar screen / tmux en un host bastion.