¿Cómo restringir a un usuario SSH para que solo permita el túnel SSH?

¿Cómo puedo restringir a un usuario en el servidor SSH para permitirles solo los privilegios para TUNNELING SSH ? es decir, no pueden ejecutar comandos incluso si inician sesión a través de SSH.

Mis servidores Linux son Ubuntu 11.04 y OpenWrt.

linux ssh account-restrictions

— LanceBaynes
fuente

Respuestas:

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án 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, es probable que desee conectarse con el -N. Esto evita que el cliente PIDA un comando remoto como un shell, simplemente se detiene después de que se realiza la parte de autenticación. _{Gracias a los comentaristas por señalar esto.}

— Caleb
fuente

Voy a probar este: P thx!

— LanceBaynes

Para agregar a la respuesta de Caleb, es posible que también deba decirle al cliente que no ejecute un shell. Con la línea de comando openssh, esto se hace con la bandera -N. Hay una opción similar en PuTTY, pero no recuerdo el nombre exacto.

— Bill B

hmm, eso es básicamente seguridad del lado del cliente, ¿no? Estoy buscando una configuración de seguridad del lado del servidor, ¡pero gracias!

— LanceBaynes

Lo siento, no estaba claro: quise decir en combinación con la configuración del servidor. Según mi experiencia en el pasado, si configuras el shell en algo que no es un shell, no puedes conectarte en absoluto porque intenta abrir un shell pero no puede. Por lo tanto, la seguridad se aplica en el lado del servidor (usando el método de Caleb), pero si tiene problemas para conectarse después de eso, es posible que deba configurar el interruptor del lado del cliente.

— Bill B

Usted crea dicho usuario con useradd sshtunnel -m -d /home/sshtunnel -s /bin/true.

— fracz

Lo siguiente tiene la ventaja de que los reenvíos de socket del agente X11 y SSH también están prohibidos, lo que aún podría permitirse en la forma de Calebs. Otra ventaja es que si el usuario puede cambiar su shell predeterminado de cualquier otra manera, esto todavía restringirá su acceso SSH a solo reenvíos TCP.

Ponga lo siguiente en su /etc/ssh/sshd_config:

Match User that-restricted-guy
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

para permitir al usuario that-restricted-guyreenviar cualquier conexión TCP a través de su máquina habilitada para SSH (conexión a esta máquina, también a localhoste incluso conexión desde esta máquina a otras máquinas).

Si lo desea aún más restrictivo (lo cual es una buena idea) también puede hacer lo siguiente:

Match User even-more-restricted-guy
  PermitOpen 127.0.0.1:12345
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Esto permitirá que el usuario even-more-restricted-guysolo reenvíe las conexiones al puerto TCP 12745.0.0.1 12345 (ya que es visible a través de su máquina habilitada para SSH).

Cuando el usuario normalmente se conecta, ahora se desconectará instantáneamente porque /bin/falsese activará el comando, que no hace nada 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 la -Nbandera al sshcomando. Esto no intentará ejecutar ningún comando, pero aún permite configurar los reenvíos 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 even-more-restricted-guy@insert-your-machine

— aef
fuente

Reformé la respuesta como una solución mejorada sobre la respuesta de Calebs.

— aef

Seguro. Yo también limpié. Es bueno ver resuelto el malentendido. Buenas noches.

— Jakuje

Puede controlar lo que las personas pueden hacer en ssh haciendo coincidir los grupos, suponiendo que su versión de ssh sea lo suficientemente nueva como para admitirla (openssh 5.x +).

Básicamente, los tratamos como si fueran usuarios de sftp, pero permitimos el reenvío de tcp y, opcionalmente, especificamos los destinos a los que pueden reenviar. Si les da un directorio de inicio pero no crea ningún directorio debajo de él, no pueden 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 bloques de Grupo de coincidencias para cada grupo que desee proporcionar diferentes comportamientos o restricciones.

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 "nicepeople" es 500.

Algunas de las opciones ssh anteriores están disponibles en las versiones anteriores de openssh, pero no dentro de la sección Grupo de coincidencias. Match Group es muy limitado en OpenSSH 4.xy versiones anteriores.

— Aaron
fuente