Mi piace la seguente configurazione per la gestione dell'accesso SSH, che uso al lavoro per gestire un gruppo di utenti su una piccola flotta di server. Sicurezza e facilità di gestione sono in cima alla lista delle mie priorità.
Le sue caratteristiche principali sono la facile gestione dei diritti SSH attraverso l'appartenenza al gruppo Unix, con autorizzazioni ben definite e la sicurezza di default.
Impostare
Installa software (opzionale ma utile):
yum install members # or apt install members
Aggiungi gruppi:
addgroup --system allowssh
addgroup --system sftponly
In /etc/ssh/sshd_config, assicurarsi che le seguenti impostazioni siano No:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
E alla fine /etc/ssh/sshd_config, aggiungi queste due stanze:
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
(non dimenticare di riavviare SSH dopo aver modificato il file)
Spiegazione
Quindi, cosa fa tutto questo?
- Disattiva sempre gli accessi root, come misura di sicurezza aggiuntiva.
- Disabilita sempre gli accessi basati su password (le password deboli sono un grosso rischio per i server che eseguono sshd).
- Consente l'accesso (pubkey) solo agli utenti del
allowsshgruppo.
- Gli utenti del
sftponlygruppo non possono ottenere una shell su SSH, ma solo SFTP.
La gestione di chi ha accesso viene quindi semplicemente gestita l'appartenenza al gruppo (queste modifiche hanno effetto immediato, non è necessario il riavvio di SSH):
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Nota che i tuoi utenti sftp devono essere membri di entrambi sftponly(per assicurarsi che non ottengano una shell) e di allowssh(per consentire l'accesso in primo luogo).
Ulteriori informazioni
Questa configurazione non consente l'accesso con password ; tutti gli account devono utilizzare l'autenticazione con chiave pubblica. Questa è probabilmente la più grande vincita alla sicurezza che puoi ottenere con SSH, quindi sostengo che valga la pena anche se devi iniziare ora.
Se davvero non lo vuoi, aggiungi anche PasswordAuthentication yesalla Match Group allowsshstanza. Ciò consentirà sia l'autenticazione pubkey che password per gli allowsshutenti.
Questa configurazione limita qualsiasi sftponlyutente alla propria home directory. Se non lo si desidera, rimuovere la ChrootDirectory %hdirettiva.
Se non si desidera che il chrooting al lavoro, è importante che la directory home dell'utente (e qualsiasi directory sopra di esso) è di proprietà root:roote non scrivibile da gruppo / altro. Va bene che le sottodirectory della home directory siano di proprietà dell'utente e / o scrivibili.
Sì, la home directory dell'utente deve essere di proprietà root e non scrivibile per l'utente. Purtroppo, ci sono buone ragioni per questa limitazione. A seconda della situazione, ChrootDirectory /homepotrebbe essere una buona alternativa.
L'impostazione della shell degli sftponlyutenti su /sbin/nologinnon è né necessaria né dannosa per questa soluzione, poiché SSH ForceCommand internal-sftpsostituisce la shell dell'utente.
L'uso /sbin/nologinpuò essere utile per impedire loro di accedere in altri modi (console fisica, samba, ecc.).
Questa configurazione non consente rootaccessi diretti su SSH; questo costituisce un ulteriore livello di sicurezza. Se davvero non ha bisogno login di root diretto, modificare la PermitRootLogindirettiva. Valuta di impostarlo su forced-commands-only, prohibit-passworde (come ultima risorsa) yes.
Per i punti bonus, dai un'occhiata a come limitare chi può sufare il root; aggiungere un gruppo di sistema chiamato wheele aggiungere / abilitare auth required pam_wheel.soin /etc/pam.d/su.