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).
Respuestas:
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".
~user/.ssh/authorized_keyssería propiedad de usery useradministraría las claves autorizadas utilizadas para acceder a la cuenta. SSH es exigente con los permisos y puede imponer expectativas sobre ~/.ssh/su contenido. Hice una sudo chown root: .ssh/authorized_keysy parece haberme impedido iniciar sesión, pero sé por experiencia pasada que el usuario no tiene que ser propietario de ese archivo; rootpuede administrarlo si lo prefiere.
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.
ssh use@host "/bin/bash", ¿verdad?
user@hosttiene rbash como caparazón. Ver The Restricted Shell
/bin/bashfalla porque contiene barras.
lesses probablemente una mala idea, porque desde allí puedes escapar a un shell sin restricciones con !/bin/bash. Consulte pen-testing.sans.org/blog/2012/06/06/… para ver otros ejemplos. Por lo tanto, permitir comandos individuales debe hacerse con mucho, mucho cuidado, si es que lo hace.
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.
no-ptytampoco restringe el acceso al shell, todavía llegará al shell, simplemente no le mostrará el indicador; Todavía puede dar comandos y ver el resultado sin problemas. Necesita la command="..."opción si desea restringir el acceso al shell desde .ssh/authorized_keys.
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/
tunnel_shell, lo tendrás shell -> /bin/bash tunnel_shellpara que, por supuesto, puedas escapar de regreso al caparazón, pero si lo has configurado tunnel_shell como el caparazón del usuario, solo tendrás /bin/bash tunnel_shellejecución, sin un caparazón al que escapar. , por lo que puedo ver. Lo probé y no pude escapar con ctrl-z. Si lo intentaste y pudieras escapar, ¿podrías publicar la configuración? Asimismo, si conoce alguna documentación que diga que debería funcionar así, ¿podría publicarla?
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:
chmod 700 ~/.sshGenerará 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.
no-ptyno permite abrir una vista interactiva, no hace nada para evitar la ejecución del comando, por lo que el usuario puede editar elauthorized_keysarchivo si tiene acceso con algo comossh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'.