Soluzione 1:
Come altri hanno già detto, disabilitando sftp
non è neanche lontanamente sufficiente:un utente con ssh
illimitato access può visualizzare qualsiasi file per cui il proprio account è autorizzato a visualizzare, può modificare tutto ciò che è autorizzato a modificare e può facilmente scaricare qualsiasi cosa possa leggere sul proprio computer. L'unico modo per impedire loro di farlo è limitare effettivamente il loro accesso. Inoltre, non è l'ideale fare affidamento su .profile
per limitare gli utenti, poiché non è quello che serve (Modifica:come menziona Aleksi nella sua risposta, è infatti banale aggirare .profile
; la cosa su .profile
è che è per comodità, non per sicurezza, quindi non ha lo scopo di limitare l'utente. Usa cose progettate per la sicurezza, come le cose qui sotto, per fornire sicurezza).
Esistono due modi di base per farlo:puoi limitarli tramite i permessi dei file o costringerli a eseguire solo l'app della tua console. Il secondo modo è migliore:assegna gli utenti che dovrebbero essere limitati all'app della console a un gruppo (ad es. customers
); poi, in sshd_config
, aggiungi le seguenti righe:
Match Group customers
ForceCommand /path/to/app
Ciò che fa è fare in modo che tutte le connessioni degli utenti in quel gruppo aprano l'app della console; non possono avviare nient'altro, incluso il sftp
strumento server. Questo impedisce anche loro di fare altro con il sistema e diversamente da .profile
, lo fa utilizzando il server SSH stesso (.profile
li limita alla shell, ForceCommand
impedisce anche di fare altre cose che non comportano l'avvio di una shell). Diversamente anche da .profile
, questo è progettato come una cosa di sicurezza; è specificamente creato per impedire a un utente malintenzionato di eluderlo.
L'alternativa (probabilmente inferiore) comporterebbe la creazione di un nuovo utente per eseguire l'app della console. Dovresti quindi limitare le directory dei dati a quell'utente, impostare l'app della console di proprietà di quell'utente e impostare u+s
sul programma. Questo è il setuid
morso; significa che qualcuno che esegue il programma della console lo fa con i permessi del proprietario del programma. In questo modo, l'utente stesso non ha accesso alle directory, lo ottiene solo attraverso il programma. Tuttavia, dovresti probabilmente usare solo ForceCommand
, in quanto limita tutti accesso a "basta eseguire questo programma".
Soluzione 2:
Modifica:
Nel caso in cui non sia ovvio, la seguente risposta non è intesa come sicuro metodo per impedire che SFTP venga utilizzato da chiunque abbia accesso shell al server. È solo una risposta che spiega come disabilitarlo dalla visibilità esterna. Per una discussione sulla sicurezza a livello di utente, vedere le risposte di @cpast e @Aleksi Torhamo. Se la sicurezza è il tuo obiettivo, questa risposta non è quella giusta. Se la semplice visibilità del servizio è il tuo obiettivo, allora questa è la tua risposta.
Passiamo ora alla risposta originale:
Commenta il supporto sftp in sshd_config (e ovviamente riavvia sshd
):
#Subsystem sftp /usr/lib/openssh/sftp-server
Soluzione 3:
Non tentare di farlo con .profile
perché non fornisce alcuna sicurezza e non limita esattamente nulla!
Non importa cosa metti in .profile
, poiché puoi aggirarlo semplicemente dando un comando da eseguire sulla riga di comando ssh, come questo:ssh [email protected] command
. Puoi comunque ottenere il normale accesso alla shell eseguendo ssh -t [email protected] bash
.
Disabilitare il sottosistema sftp, come menzionato in un'altra risposta, non aiuta affatto. I sottosistemi sono essenzialmente solo alias di comandi, e puoi ancora usare sftp normalmente facendo sftp -s /path/to/sftp-executable [email protected]
.
Come hanno detto cpast e alcuni commentatori, dovresti usare i meccanismi appropriati per limitare l'accesso. Cioè,
- Usa
ForceCommand
insshd_config
- Utilizza login senza password e
command="..."
in.ssh/authorized_keys
- Cambia la shell dell'utente in qualcosa che limiti ciò che l'utente può fare
Note:
command="..."
si applica solo a una chiave, quindi non limita l'accesso ssh per l'utente che utilizza una password o un'altra chiave- Potresti anche voler limitare il port forwarding ecc. (Port forwarding, x11 forwarding, agent forwarding e pty allocation sono quelli di cui ho sentito parlare)
AllowTcpForwarding
ecc. insshd_config
no-port-forwarding
ecc. in.ssh/authorized_keys
- Se hai altri demoni (come FTP) in esecuzione, dovresti verificare che non lascino entrare l'utente (alcuni demoni prendono questa decisione in base alla shell dell'utente, quindi se lo cambi, potresti voler ri- controlla questo)
- Puoi cambiare la shell dell'utente in uno script che fa quello che vuoi; viene eseguito senza argomenti o come
script -c 'command-the-user-wanted-to-run'
- Entrambi
ForceCommand
ecommand="..."
eseguire il comando attraverso la shell dell'utente, quindi non funzionano se la shell dell'utente è impostata su es./bin/false
o/sbin/nologin
Dichiarazione di non responsabilità:non sono assolutamente un esperto in materia, quindi mentre posso dire che il .profile
la cosa non è sicura, non posso promettere che non ci sia qualche "trucco" con gli altri metodi che non conosco. Sono al sicuro per quanto ne so, ma non sarei la prima persona a sbagliare su Internet.