usar tunel realizar mac inverso crear como comando unix ssh

unix - tunel - Permitir al usuario configurar un túnel SSH, pero nada más



tunel ssh linux terminal (10)

Me gustaría permitir que un usuario configure un túnel SSH para una máquina en particular en un puerto en particular (digamos, 5000), pero quiero restringir a este usuario tanto como sea posible. (La autenticación será con el par de llaves público / privado).

Sé que necesito editar el archivo ~ / .ssh / authorized_keys relevante, pero no estoy seguro de qué contenido colocar allí (que no sea la clave pública).

Puedo configurar el archivo authorized_keys con la clave pública para iniciar sesión. De lo que no estoy seguro es de la información adicional que necesito para restringir lo que esa cuenta puede hacer. Por ejemplo, sé que puedo poner comandos como:

no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Querrá una línea en su archivo authorized_keys que se vea así.

permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache

Además de la opción authorized_keys como no-X11-forwarding, en realidad hay exactamente una que está pidiendo: permitopen = "host: port". Al usar esta opción, el usuario solo puede configurar un túnel para el host y el puerto especificados.

Para los detalles del formato de archivo AUTHORIZED_KEYS, consulte man sshd.

Aquí tienes una buena publicación que encontré útil: http://www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/

La idea es: (con el nuevo nombre de usuario restringido como "sshtunnel")

useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash passwd sshtunnel

Tenga en cuenta que usamos rbash (restricted-bash) para restringir lo que el usuario puede hacer: el usuario no puede cd (cambiar el directorio) y no puede establecer ninguna variable de entorno.

Luego editamos la variable de /home/sshtunnel/.profile PATH del usuario en /home/sshtunnel/.profile en nada, un truco que hará que bash no encuentre ningún comando para ejecutar:

PATH=""

Finalmente, no permitimos que el usuario edite ningún archivo estableciendo los siguientes permisos:

chmod 555 /home/sshtunnel/ cd /home/sshtunnel/ chmod 444 .bash_logout .bashrc .profile

En Ubuntu 11.10, encontré que podía bloquear comandos ssh, enviados con y sin -T, y bloquear la copia de scp, mientras permitía el reenvío de puertos.

Específicamente, tengo un redis-server en "somehost" vinculado a localhost: 6379 que deseo compartir de forma segura a través de túneles ssh con otros hosts que tienen un archivo de claves y se ssh in con:

$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost

Esto hará que el puerto redis-server, "localhost" 6379 en "somehost" aparezca localmente en el host que ejecuta el comando ssh, reasignado al puerto "localhost" 16379.

En el "host remoto" Aquí está lo que utilicé para authorized_keys:

cat .ssh/authorized_keys (portions redacted) no-pty,no-X11-forwarding,permitopen="localhost:6379",command="/bin/echo do-not-send-commands" ssh-rsa rsa-public-key-code-goes-here keyuser@keyhost

El no-pty dispara la mayoría de los intentos de ssh que quieren abrir una terminal.

El permitopen explica qué puertos se pueden reenviar, en este caso el puerto 6379 el puerto redis-server que quería reenviar.

El comando = "/ bin / echo do-not-send-commands" hace eco de "do-not-send-commands" si alguien o algo logra enviar comandos al host a través de ssh -T o de lo contrario.

Desde un man sshd Ubuntu man sshd reciente, el comando authorized_keys / se describe de la siguiente manera:

command = "command" Especifica que el comando se ejecuta siempre que esta clave se utilice para la autenticación. El comando proporcionado por el usuario (si lo hay) se ignora.

Los intentos de usar la copia segura de archivos scp también fallarán con un eco de "do-not-send-commands". He encontrado que sftp también falla con esta configuración.

Creo que la sugerencia de shell restringida, hecha en algunas respuestas anteriores, también es una buena idea. Además, estoy de acuerdo en que todo lo detallado aquí podría determinarse leyendo "man sshd" y buscando "authorized_keys" en el mismo.

Generará una clave en la máquina de los usuarios a través del cliente ssh que estén usando. PUTTY, por ejemplo, tiene una utilidad para hacer esto exactamente. Generará una clave privada y pública.

El contenido del archivo de clave pública generado se colocará en el archivo authorized_keys.

A continuación, debe asegurarse de que el cliente ssh esté configurado para usar la clave privada que generó la clave pública. Es bastante sencillo, pero ligeramente diferente según el cliente que se utilice.

Hice un programa C que se ve así:

#include <stdio.h> #include <unistd.h> #include <signal.h> #include <stdlib.h> void sig_handler(int signo) { if (signo == SIGHUP) exit(0); } int main() { signal(SIGINT, &sig_handler); signal(SIGTSTP, &sig_handler); printf("OK/n"); while(1) sleep(1); exit(0); }

Configuro la shell del usuario restringido para este programa.

No creo que el usuario restringido pueda ejecutar nada, incluso si lo hacen con el ssh server command , porque los comandos se ejecutan usando el shell, y este shell no ejecuta nada.

Mi solución es proporcionar al usuario que solo puede estar haciendo túneles, sin un caparazón interactivo , para configurar ese shell en / etc / passwd a / usr / bin / tunnel_shell .

Simplemente cree el archivo ejecutable / usr / bin / tunnel_shell con un ciclo infinito .

#!/bin/bash trap '''' 2 20 24 clear echo -e "/r/n/033[32mSSH tunnel started, shell disabled by the system administrator/r/n" while [ true ] ; do sleep 1000 done exit 0

Completamente explicado aquí: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/

Probablemente desee establecer el shell del usuario en el shell restringido . Desarma la variable PATH en ~ / .bashrc del usuario o ~ / .bash_profile, y no podrán ejecutar ningún comando. Más adelante, si decides que quieres permitir que los usuarios ejecuten un conjunto limitado de comandos, como less o tail por ejemplo, puedes copiar los comandos permitidos en un directorio separado (como /home/restricted-commands ) y actualice la RUTA para apuntar a ese directorio.

Si desea permitir el acceso solo para un comando específico, como svn, también puede especificar ese comando en el archivo de claves autorizadas:

command="svnserve -t",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding [KEY TYPE] [KEY] [KEY COMMENT]

De http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks