Solución 1:
Sí, solo usa /bin/false como shell e indique al usuario que inicie el proceso de tunelización SSH sin ejecutar ningún comando remoto (es decir, el -N marca para OpenSSH):
ssh -N -L 1234:target-host:5678 ssh-host
Solución 2:
En el archivo .ssh/authorized_keys del usuario, coloque algo como lo siguiente:
permitopen="192.168.1.10:3306",permitopen="10.0.0.16:80",no-pty ssh-rsa AAAAB3N...
Entonces, básicamente, los controles estarían frente a la clave pública ssh del usuario separados por un espacio. En el ejemplo, las conexiones que usan la clave pública específica podrán realizar el reenvío de puertos SSH solo al servidor MySQL de 192.168.1.10 y al servidor web de 10.0.0.16, y no se les asignará un shell (sin pty). Está preguntando específicamente sobre la opción "no-pty", pero las otras también pueden ser útiles si se supone que el usuario solo debe hacer un túnel a servidores específicos.
Mire la página de manual de sshd para obtener más opciones para el archivo authorized_keys.
Tenga en cuenta que la experiencia del usuario puede parecer un poco extraña:cuando ingresan, parecerá que la sesión se cuelga (ya que no reciben un pty). Está bien. Si el usuario ha especificado el reenvío de puertos con, por ejemplo, "-L3306:192.168.1.10:3306", el reenvío de puertos seguirá estando en vigor.
En cualquier caso, pruébalo.
Solución 3:
Proporcione al usuario un shell que solo le permita cerrar sesión, como /bin/press_to_exit.sh
#!/bin/bash read -n 1 -p "Press any key to exit" key
De esta manera, puede permanecer conectado todo el tiempo que quiera, con los túneles activos, pero sin ejecutar ningún comando. Ctrl-c cierra la conexión.
Solución 4:
Asigne un shell que no permita que el usuario inicie sesión.
por ejemplo
#!/bin/sh
echo "No interactive login available."
sleep 60
exit 0
evitaría que reciban un indicador de shell y les daría un tiempo de espera de 60 segundos:si no hay una conexión activa durante 60 segundos, se cerrará y, por lo tanto, los desconectará por completo (aumente el número según los requisitos).
Tampoco pueden ejecutar un comando remoto porque ese shell no se lo permite.