Para poder ejecutar túneles SSH, debe tener una cuenta en la máquina "perimetral". Es difícil permitir un túnel sin dar un acceso completo al shell en esa máquina. Eso es un shell como usuario genérico. Teóricamente, los sistemas similares a Unix aplican reglas de seguridad estrictas con respecto a los usuarios locales, por lo que no es un problema dar un acceso de shell a un usuario. En la práctica, si sus usuarios son posibles atacantes, esto aumenta la superficie de ataque: debe preocuparse por lo que dichos atacantes pueden hacer a la máquina de borde desde un shell que se ejecuta en esa máquina, en lugar de acceder a la máquina "desde la red".
Además, si las personas de la LAN interna pueden conectarse mediante SSH a la máquina de borde, están obligados a intentarlo también desde el exterior (es decir, desde su máquina doméstica). Puede o no desear permitir eso.
El tema común aquí es que SSH tiene un tipo de modelo de seguridad de todo o nada: le da acceso o no, pero no es fácil imponer un acceso restringido ("puede conéctese mediante SSH en esta máquina, pero solo para realizar esta o aquella tarea "). Para hacer un acceso restringido, debe configurar el shell de usuario (a nivel de Unix) en un ejecutable específico que realice el trabajo de filtrado, como rssh , pero no encuentro que esta sea una solución realmente sólida.