Puoi anche limitare le chiavi ai comandi consentiti (nel file authorized_keys).
Cioè. l'utente non effettuerebbe l'accesso tramite ssh e quindi disporrà di un insieme ristretto di comandi, ma piuttosto gli sarà consentito solo di eseguire tali comandi tramite ssh (ad es. "ssh somehost bin/showlogfile")
Quello che stai cercando si chiama Restricted Shell. Bash fornisce una tale modalità in cui gli utenti possono solo eseguire i comandi presenti nelle loro home directory (e non possono spostarsi in altre directory), il che potrebbe essere abbastanza buono per te.
Ho trovato questo thread molto esplicativo, anche se un po' datato.
ssh segue il rsh tradizione utilizzando il programma shell dell'utente dal file delle password per eseguire i comandi.
Ciò significa che possiamo risolverlo senza coinvolgere ssh configurazione in alcun modo.
Se non vuoi che l'utente sia in grado di avere accesso alla shell, sostituisci semplicemente la shell di quell'utente con uno script. Se guardi in /etc/passwd vedrai che c'è un campo che assegna un interprete dei comandi della shell a ciascun utente. Lo script è usato come shell sia per il loro login interattivo ssh [email protected] così come per i comandi ssh [email protected] command arg ... .
Ecco un esempio. Ho creato un utente foo la cui shell è uno script. Lo script stampa il messaggio my arguments are: seguito dai suoi argomenti (ciascuno su una riga separata e tra parentesi angolari) e termina. Nel caso di log, non ci sono argomenti. Ecco cosa succede:
webserver:~# ssh [email protected]
[email protected]'s password:
Linux webserver [ snip ]
[ snip ]
my arguments are:
Connection to localhost closed.
Se l'utente tenta di eseguire un comando, avrà questo aspetto:
webserver:~# ssh [email protected] cat /etc/passwd
[email protected]'s password:
my arguments are:
<-c>
<cat /etc/passwd>
La nostra "shell" riceve un -c style, con l'intero comando come argomento, proprio come /bin/sh lo riceverebbe.
Quindi, come puoi vedere, ciò che possiamo fare ora è sviluppare ulteriormente lo script in modo che riconosca il caso in cui è stato invocato con un -c argomento, quindi analizza la stringa (diciamo per pattern matching). Le stringhe consentite possono essere passate alla shell reale invocando ricorsivamente /bin/bash -c <string> . Il caso di rifiuto può stampare un messaggio di errore e terminare (incluso il caso in cui -c è mancante).
Devi stare attento a come lo scrivi. Consiglio di scrivere solo corrispondenze positive che consentono solo cose molto specifiche e non consentono tutto il resto.
Nota: se hai root , puoi comunque accedere a questo account sovrascrivendo la shell in su comando, come questo su -s /bin/bash foo . (Sostituire shell a scelta.) Non root non può farlo.
Ecco uno script di esempio:limita l'utente a usare solo ssh per git accesso ai repository sotto /git .
#!/bin/sh
if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then
printf "interactive login not permitted\n"
exit 1
fi
set -- $2
if [ $# != 2 ] ; then
printf "wrong number of arguments\n"
exit 1
fi
case "$1" in
( git-upload-pack | git-receive-pack )
;; # continue execution
( * )
printf "command not allowed\n"
exit 1
;;
esac
# Canonicalize the path name: we don't want escape out of
# git via ../ path components.
gitpath=$(readlink -f "$2") # GNU Coreutils specific
case "$gitpath" in
( /git/* )
;; # continue execution
( * )
printf "access denied outside of /git\n"
exit 1
;;
esac
if ! [ -e "$gitpath" ] ; then
printf "that git repo doesn't exist\n"
exit 1
fi
"$1" "$gitpath"
Naturalmente, confidiamo che questi programmi Git git-upload-pack e git-receive-pack non avere buchi o portelli di fuga che consentano agli utenti di accedere al sistema.
Ciò è insito in questo tipo di schema di restrizione. L'utente è autenticato per eseguire il codice in un determinato dominio di sicurezza e stiamo introducendo una restrizione per limitare tale dominio a un sottodominio. Ad esempio, se consenti a un utente di eseguire vim comando su un file specifico per modificarlo, l'utente può semplicemente ottenere una shell con :!sh[Enter] .