Vorrei consentire a un utente di impostare un tunnel SSH per una particolare macchina su una particolare porta (diciamo 5000), ma voglio limitare questo utente il più possibile. (L'autenticazione avverrà con una coppia di chiavi pubblica / privata).
So di dover modificare il file ~ / .ssh / authorized_keys pertinente, ma non sono sicuro di quale contenuto inserire (oltre alla chiave pubblica).
Risposte:
Su Ubuntu 11.10, ho scoperto che potevo bloccare i comandi ssh, inviati con e senza -T, e bloccare la copia di scp, consentendo il passaggio del port forwarding.
In particolare, ho un server redis su "somehost" associato a localhost: 6379 che desidero condividere in modo sicuro tramite tunnel ssh con altri host che hanno un file di chiavi e ssh con:
$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost
Questo farà sì che il redis-server, la porta "localhost" 6379 su "somehost" appaia localmente sull'host che esegue il comando ssh, rimappato sulla porta "localhost" 16379.
Sul telecomando "somehost" Ecco cosa ho usato per 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
Il no-pty fa scattare la maggior parte dei tentativi ssh che vogliono aprire un terminale.
Il permesso di apertura spiega quali porte possono essere inoltrate, in questo caso la porta 6379 è la porta del server redis che volevo inoltrare.
Il comando = "/ bin / echo do-non-inviare-comandi" fa eco a "do-non-inviare-comandi" se qualcuno o qualcosa riesce a inviare comandi all'host tramite ssh -T o altro.
Da un Ubuntu recente man sshd, authorized_keys / command è descritto come segue:
comando = "comando" Specifica che il comando viene eseguito ogni volta che questa chiave viene utilizzata per l'autenticazione. Il comando fornito dall'utente (se presente) viene ignorato.
Anche i tentativi di usare la copia sicura dei file scp falliranno con l'eco di "do-not-send-commands" Ho scoperto che sftp fallisce anche con questa configurazione.
Penso che anche il suggerimento di shell limitato, fornito in alcune risposte precedenti, sia una buona idea. Inoltre, sarei d'accordo sul fatto che tutto ciò che è dettagliato qui potrebbe essere determinato dalla lettura di "man sshd" e dalla ricerca di "authorized_keys"
~user/.ssh/authorized_keyssarebbe di proprietà di usere usergestirà le chiavi autorizzate utilizzate per accedere all'account. SSH è pignolo riguardo alle autorizzazioni e può imporre aspettative ~/.ssh/e ai suoi contenuti. Ho fatto un sudo chown root: .ssh/authorized_keyse sembra che mi abbia impedito di accedere, ma so per esperienza passata che l'utente non deve possedere quel file - rootpuò gestirlo se preferisci.
Probabilmente si vorrà impostare la shell dell'utente per la shell ristretta . Annulla l'impostazione della variabile PATH nel ~ / .bashrc o ~ / .bash_profile dell'utente e non sarà in grado di eseguire alcun comando. In seguito, se decidi di consentire agli utenti di eseguire un insieme limitato di comandi, come lesso tailper esempio, puoi copiare i comandi consentiti in una directory separata (come /home/restricted-commands) e aggiornare il PERCORSO in modo che punti a quella directory.
ssh use@host "/bin/bash", vero?
user@hostabbia rbash come shell. Vedi The Restricted Shell
/bin/bashfallisce perché contiene barre.
lessè probabilmente una cattiva idea, perché da lì puoi fuggire a una shell senza restrizioni con !/bin/bash. Vedi pen-testing.sans.org/blog/2012/06/06/… per altri esempi. Quindi consentire i singoli comandi dovrebbe essere fatto con molta, molta attenzione, se non del tutto.
Oltre all'opzione authorized_keys come no-X11-forwarding, in realtà ce n'è esattamente quella che stai chiedendo: allowopen = "host: port". Utilizzando questa opzione, l'utente può solo impostare un tunnel per l'host e la porta specificati.
Per i dettagli sul formato del file AUTHORIZED_KEYS fare riferimento a man sshd.
no-ptynon limita nemmeno l'accesso alla shell, arriverai comunque alla shell, semplicemente non ti mostrerà il prompt; Puoi ancora dare comandi e vedere l'output senza problemi. È necessaria l' command="..."opzione se si desidera limitare l'accesso alla shell da .ssh/authorized_keys.
La mia soluzione è fornire all'utente che può eseguire il tunneling, senza una shell interattiva , di impostare quella shell in / etc / passwd su / usr / bin / tunnel_shell .
Basta creare il file eseguibile / 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 spiegato qui: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/
tunnel_shell, lo farai shell -> /bin/bash tunnel_shellquindi puoi ovviamente tornare alla shell, ma se hai impostato tunnel_shell come shell dell'utente, dovrai solo /bin/bash tunnel_shellcorrere, senza shell a cui fuggire , per quanto posso vedere. L'ho provato e non sono riuscito a scappare con ctrl-z. Se fatto provare e potrebbe sfuggire, potrebbe inviare il setup? Allo stesso modo, se sei a conoscenza di documentazione che dice che dovrebbe funzionare così, potresti pubblicarla?
Sono in grado di impostare il file authorized_keys con la chiave pubblica per accedere. Quello di cui non sono sicuro sono le informazioni aggiuntive di cui ho bisogno per limitare ciò che quell'account è autorizzato a fare. Ad esempio, so di poter inserire comandi come:
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding
Vorresti una riga nel tuo file authorized_keys simile a questa.
permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache
Se vuoi consentire l'accesso solo per un comando specifico, come svn, puoi anche specificare quel comando nel file delle chiavi autorizzate:
command="svnserve -t",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding [KEY TYPE] [KEY] [KEY COMMENT]
Da http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks
Ecco un bel post che ho trovato utile: http://www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/
L'idea è: (con il nuovo nome utente limitato come "sshtunnel")
useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash
passwd sshtunnel
Notare che usiamo rbash (limited-bash) per limitare ciò che l'utente può fare: l'utente non può cd (cambiare directory) e non può impostare alcuna variabile d'ambiente.
Quindi modifichiamo la variabile env PATH dell'utente in /home/sshtunnel/.profilenulla - un trucco che farà in modo che bash non trovi alcun comando da eseguire:
PATH=""
Infine impediamo all'utente di modificare qualsiasi file impostando le seguenti autorizzazioni:
chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile
Ho creato un programma in C che assomiglia a questo:
#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);
}
Ho impostato la shell dell'utente con restrizioni su questo programma.
Non penso che l'utente con restrizioni possa eseguire nulla, anche se lo fa ssh server command, perché i comandi vengono eseguiti utilizzando la shell e questa shell non esegue nulla.
Vedi questo post sull'autenticazione delle chiavi pubbliche .
Le due cose principali che devi ricordare sono:
chmod 700 ~/.sshGenererai una chiave sulla macchina degli utenti tramite qualsiasi client ssh che stanno utilizzando. PUTTY per esempio ha un'utilità per fare esattamente questa cosa. Genererà sia una chiave privata che una pubblica.
Il contenuto del file di chiave pubblica generato verrà inserito nel file authorized_keys.
Successivamente è necessario assicurarsi che il client ssh sia configurato per utilizzare la chiave privata che ha generato la chiave pubblica. È abbastanza semplice, ma leggermente diverso a seconda del client utilizzato.
no-ptynon consenta di aprire la visualizzazione interattiva, non fa nulla per impedire l'esecuzione del comando, quindi l'utente può modificare ilauthorized_keysfile se ha accesso con qualcosa di similessh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'.