En el lado del servidor, puede restringir esto configurando su shell de usuario en /bin/true . Esto les permitirá autenticarse, pero en realidad no ejecutar nada, ya que no obtienen un shell para ejecutarlo. Esto significa que estarán limitados a cualquier subconjunto de cosas que SSH pueda ofrecerles. Si ofrece reenvío de puertos, aún podrán hacerlo.
En el lado del cliente, probablemente querrá conectarse con el -N . Esto evita que el cliente PIDA un comando remoto como un shell, solo se detiene después de que se completa la parte de autenticación. Gracias a los comentaristas por señalar esto.
Lo siguiente tiene la ventaja de que los reenvíos de sockets de agentes X11 y SSH tampoco están permitidos, lo que aún podría estar permitido en la forma de Calebs. Otra ventaja es que, si el usuario puede cambiar su shell predeterminado de cualquier otra forma, seguirá restringiendo su acceso SSH solo a reenvíos TCP.
Pon lo siguiente en tu /etc/ssh/sshd_config :
Match User that-restricted-guy
AllowTcpForwarding yes
X11Forwarding no
AllowAgentForwarding no
ForceCommand /bin/false
para permitir al usuario that-restricted-guy para reenviar cualquier conexión TCP a través de su máquina habilitada para SSH (conexión a esta máquina, también a localhost e incluso conexión desde esta máquina a otras máquinas).
Si lo quieres aún más restrictivo (lo cual es una buena idea), también puedes hacer lo siguiente:
Match User even-more-restricted-guy
PermitOpen 127.0.0.1:12345
X11Forwarding no
AllowAgentForwarding no
ForceCommand /bin/false
Esto permitirá al usuario even-more-restricted-guy para reenviar únicamente las conexiones al puerto TCP 127.0.0.1 12345 (como se ve a través de su máquina habilitada para SSH).
Cuando el usuario se conecta normalmente, ahora se desconectará instantáneamente porque el /bin/false se activará el comando que no hace más que salir instantáneamente con un código de 1. Si desea evitar esto y mantener abierta su conexión de reenvío, agregue el -N bandera al ssh dominio. Esto no intentará ejecutar ningún comando, pero aún permite configurar los reenvíos de TCP.
Un ejemplo de un comando de reenvío que debería funcionar en la última configuración:
ssh -L 12345:127.0.0.1:12345 -N [email protected]
Puede controlar lo que las personas pueden hacer en ssh haciendo coincidir grupos, suponiendo que su versión de ssh sea lo suficientemente nueva como para admitirlo (openssh 5.x+).
Básicamente, los tratamos como si fueran usuarios de sftp, pero permitimos el reenvío de tcp y opcionalmente especificar los destinos a los que pueden reenviar. Si les proporciona un directorio de inicio pero no crea ningún directorio debajo de él, no podrán transferir ningún archivo porque no tendrán permiso para hacerlo.
Match Group nicepeople
PubkeyAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no
GatewayPorts no
ChrootDirectory /opt/dummy_location/%u
ForceCommand internal-sftp
AllowTcpForwarding yes
PermitOpen 192.168.0.8:22
PermitOpen 192.168.0.5:8080
# Or leave out the PermitOpen to allow forwarding to anywhere.
HostbasedAuthentication no
RhostsRSAAuthentication no
AllowAgentForwarding no
Banner none
Puede repetir estos grupos de coincidencia Bloques para cada grupo al que desee proporcionar un comportamiento o restricciones diferentes.
Puede controlar aún más a dónde puede ir esta persona en la red usando iptables
/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -j REJECT
/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -m tcp -p tcp -d 192.168.0.0/24 -j ACCEPT
Esto supone que el GID del grupo "buena gente" es 500.
Algunas de las opciones de ssh anteriores están disponibles en las versiones anteriores de openssh, pero no en la sección Match Group. Match Group está muy limitado en OpenSSH 4.x y versiones anteriores.