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

Me gustaría permitir que un usuario configure un túnel SSH a 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 par de claves públicas / privadas).

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

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

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

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

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

En el "somehost" remoto, esto es lo que utilicé para las claves_autorizadas:

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 del servidor de redis que quería reenviar.

El comando = "/ bin / echo no-enviar-comandos" repite "no-enviar-comandos" si alguien o algo logra enviar comandos al host a través de ssh -T o de otra manera.

Desde un Ubuntu reciente man sshd, Authorized_keys / command se describe de la siguiente manera:

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

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

Creo que la sugerencia de shell restringido, hecha en algunas respuestas anteriores, también es una buena idea. Además, estaría de acuerdo en que todo lo que se detalla aquí podría determinarse leyendo "man sshd" y buscando en él "claves_autorizadas".

Probablemente desee configurar el shell del usuario en el shell restringido . Desactive la variable PATH en el ~ / .bashrc o ~ / .bash_profile del usuario, y no podrán ejecutar ningún comando. Más adelante, si decide que desea permitir que los usuarios ejecuten un conjunto limitado de comandos, como lesso tailpor ejemplo, puede copiar los comandos permitidos en un directorio separado (como /home/restricted-commands) y actualizar la RUTA para que apunte a ese directorio.

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

Para obtener detalles sobre el formato de archivo AUTHORIZED_KEYS, consulte man sshd.

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

Simplemente cree el archivo ejecutable / usr / bin / tunnel_shell con un bucle 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/

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ía una línea en su archivo autorizado_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 

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

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 (restringido-bash) para restringir lo que el usuario puede hacer: el usuario no puede hacer cd (cambiar de directorio) y no puede establecer ninguna variable de entorno.

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

PATH=""

Finalmente, no permitimos al usuario editar ningún archivo estableciendo los siguientes permisos:

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

Hice un programa en C que se parece a esto:

#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);
}

Configuré el shell del usuario restringido para este programa.

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

Vea esta publicación sobre la autenticación de claves públicas .

Las dos cosas principales que debe recordar son:

1. Asegúrese chmod 700 ~/.ssh
2. Anexar el bloque de clave pública a las claves autorizadas

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

El contenido del archivo de clave pública generado se colocará en el archivo autorizado_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.