Soluzione 1:
Adoro l'idea di accedere ai server tramite chiavi, in modo da non dover digitare la mia password ogni volta che ssh in una casella, blocco persino la password del mio utente (non root) (passwd -l username) quindi è impossibile accedere insenza una chiave... Consiglieresti/non raccomanderesti di farlo per un account utente su un server?
Stai disabilitando gli accessi basati su password nel modo sbagliato. Invece di bloccare l'account di un utente, imposta PasswordAuthentication no nel tuo /etc/ssh/sshd_config .
Con questo set, l'autenticazione della password è disabilitata per ssh, ma puoi comunque usare una password per sudo.
L'unico volta che consiglio di impostare NOPASSWD in sudo è per gli account di servizio, in cui i processi devono essere in grado di eseguire comandi tramite sudo a livello di programmazione. In tali circostanze, assicurati di autorizzare esplicitamente solo il specifico comandi che l'account deve eseguire. Per gli account interattivi, dovresti sempre lasciare abilitate le password.
Risposte alle tue domande successive:
Ma immagino che se disabilito l'autenticazione della password in/etc/ssh/sshd_config in modo da avere ancora una chiave per accedere, posso usare una password più semplice solo per sudo che è più facile da digitare? È una strategia valida?
Sì, è corretto. Consiglio comunque di utilizzare password di account locali relativamente forti, ma non ridicolmente forti. ~8 caratteri, generati casualmente sono sufficienti.
Se ho anche una chiave per accedere come root tramite ssh, se qualcuno ottiene l'accesso al mio computer e ruba le mie chiavi (sono comunque protette dalla password del keyring del sistema operativo!), potrebbero anche ottenere un accesso diretto all'account root, bypassando il percorso sudo.
L'accesso root tramite ssh dovrebbe essere disabilitato. Periodo. Imposta PermitRootLogin no nel tuo sshd_config .
Quale dovrebbe essere allora la politica per l'accesso all'account root?
Dovresti sempre avere un mezzo per ottenere l'accesso fuori banda alla console del tuo server. Diversi fornitori di VPS lo forniscono, così come i fornitori di hardware dedicato. Se il tuo provider non concede l'accesso alla console reale (ad esempio, EC2 ad esempio), in genere puoi comunque ripristinare l'accesso utilizzando un processo come quello che descrivo in questa risposta.
Soluzione 2:
Generalmente limito l'uso di NOPASSWORD ai comandi eseguiti da un processo automatizzato. È preferibile disporre di un account di servizio per questi comandi e limitare l'uso di sudo ai comandi richiesti.
Consentire NOPASSWORD per i comandi generali, consente a chiunque abbia accesso al tuo ID utente di eseguire qualsiasi comando. Ciò potrebbe derivare da una compromissione delle tue credenziali, ma potrebbe essere semplice come qualcuno seduto alla tua scrivania quando ti allontani per un secondo.
Trovo che non devo inserire la mia password così spesso. Una volta inserita la password, puoi eseguire diversi comandi se non aspetti troppo a lungo tra di loro. Il timeout è configurabile.
Soluzione 3:
Puoi avere il meglio di entrambi i mondi:autenticazione SSH sia per login che per sudo. Se integri il modulo pam_ssh_agent_auth puoi utilizzare le chiavi SSH per autenticarti senza fornire una password quando sudo.
Lo uso in produzione da più di cinque anni.
Per configurarlo, installa il modulo PAM, quindi aggiungi una riga a /etc/pam.d/sudo o l'equivalente del tuo sistema:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Se lo fai, assicurati di proteggere le tue chiavi sul tuo computer con una passphrase. In questo modo, qualcuno dovrebbe entrare nel tuo computer e rubare le chiavi per entrare. Potrebbero farlo estraendole dalla memoria mentre sono sbloccate se hanno accesso al tuo account, decifrando la tua passphrase o rubando la tua passphrase attraverso un keylogger o una spalla che naviga mentre lo digiti (guarda dietro di te!).
Puoi utilizzare la stessa chiave SSH che usi per accedere oppure puoi impostare una chiave separata che aggiungi al tuo agente solo quando esegui sudo. Quindi, se vuoi stare molto attento, puoi mantenere un file authorized_keys separato che ha una chiave SSH separata che aggiungi al tuo agente solo quando devi sudo:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo
Soluzione 4:
Lo userei solo in due circostanze:
- Quando è assolutamente richiesto per uno script automatizzato in esecuzione come utente specifico
- Per attività di amministrazione specifiche (attività di amministrazione di sola lettura, non quelle che intervengono per alterare il sistema) e ovviamente solo per utenti specifici
Per impostazione predefinita, la maggior parte sudo le configurazioni non ti chiederanno di nuovo per un po' nella stessa sessione (se apri una nuova shell che non ha alcun effetto). Puoi controllare questo comportamento in una certa misura con il timestamp_timeout impostazione.
sudo senza password non è così pericoloso come ssh senza passphrase chiavi, poiché un utente malintenzionato remoto ha bisogno delle tue credenziali per entrare in primo luogo, ma se sono entrati compromettendo in qualche modo la tua chiave privata (o se sono fisicamente locali per te e ti sei lasciato connesso e sbloccato mentre sei via dalla macchina) allora la richiesta della password è una preziosa difesa aggiuntiva tra loro e l'accesso privilegiato.
Per quanto riguarda il follow-up 2:
Se ho anche una chiave per accedere come root tramite ssh
Anche questo è meglio evitare, esattamente per il motivo che descrivi. Se una connessione remota deve avere accesso privilegiato, falla accedere tramite un account di servizio e fornisci quel controllo sufficiente per svolgere il suo lavoro tramite sudo. Questo è più faf da configurare, ovviamente, quindi molti non si preoccupano (il che funziona a tuo favore se lo fai, poiché ci sono molti frutti più bassi di te su cui gli attaccanti possono passare il tempo!), quindi si riduce al antico compromesso tra sicurezza e convenienza (suggerimento:scegli la sicurezza!).
Soluzione 5:
Visto che me lo hai chiesto, ecco i miei consigli generali su come affrontare il sudo problema.
Sudo non è stato progettato per fornire maggiore sicurezza (sebbene in qualche modo possa farlo) ... ma piuttosto fornire una buona traccia di controllo di chi sta facendo cosa sul tuo sistema con quali privilegi.
Un Sudo configurato correttamente non utilizzerà il ALL=(ALL) ALL impostazione, ma piuttosto qualcosa di più limitato a ciò di cui l'utente ha specificamente bisogno. Ad esempio, se hai bisogno che un utente sia in grado di accedere e riavviare un servizio bloccato, probabilmente non ha bisogno della possibilità di installare nuovo software o spegnere il tuo server, modificare le regole del firewall, ecc.
A volte è comune che le persone utilizzino sudo per elevarsi all'account root, ad es. sudo su - . Una volta che lo fanno, smetti di vedere chi sta facendo cosa dall'account root (root può essere connesso più volte contemporaneamente). Quindi a volte le persone vogliono disabilitare il sudo su - comandare pure. Ma, per motivi pratici, se hai bisogno di un account con privilegi di root completo per l'amministrazione, chiedi almeno a qualcuno di emettere il sudo su - il comando registrerebbe chi è stato elevato a root e quando.
Come metto al sicuro le mie scatole:
Cambia la porta SSH in un'altra rispetto a quella predefinita. Questo per evitare gli stupidi robot che cercano i numeri di porta e poi si muovono finché non entrano (o meno).
Non consentire l'accesso root su SSH utilizzando AllowRootLogin no impostazione nel tuo sshd_config. Ciò impedisce a qualcuno di forzare brutamente nel tuo account root. È generalmente buona norma non consentire mai a qualcuno di accedere direttamente all'account root/amministratore per motivi di controllo e sicurezza. Se consenti l'accesso root direttamente, non sai chi ha effettuato l'accesso, da chi ha ottenuto la password, ecc. Ma, se qualcuno accede all'account di Jimmy, quindi eleva le proprie autorizzazioni a root, hai un'idea migliore da dove iniziare ricerca di controllo (e chi è l'account da reimpostare).
Consenti l'accesso tramite SSH solo agli utenti che lo richiedono Usa il AllowUsers impostazione e specificare esplicitamente quali account necessitano dell'accesso SSH. Questo, per impostazione predefinita, bloccherà tutti gli altri account da SSH.
Modifica Sudoer tramite visudo e consenti solo i comandi di cui l'utente ha bisogno. Ci sono molte guide approfondite su come farlo, quindi non descriverò i dettagli qui. Ecco un antipasto:http://ubuntuforums.org/showthread.php?t=1132821
L'essenza di questo è impedire a un account compromesso di mettere a repentaglio la tua macchina. cioè. se l'account di Sally viene violato e Sally può usare solo sudo per riavviare il server web, beh, l'attaccante potrebbe divertirsi a riavviare il tuo server web in loop, ma almeno non può rm -rf /your/webserver/directory oppure apri tutte le porte del tuo firewall, ecc.
Imposta buone regole del firewall che consentano solo le porte necessarie per il funzionamento della tua casella. Generalmente vuoi abbandonare tutto e consentire esplicitamente solo ciò di cui hai bisogno. Ci sono un sacco di iptable decenti e altri avviamenti di firewall online, eccone uno che uso (è un antipasto di base):
# Generated by iptables-save v1.4.7 on Mon Mar 3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar 3 17:55:02 2014
Anche una password complessa è fondamentale. Anche se usi le chiavi SSH per l'accesso remoto, dovresti comunque richiedere una password per l'uso di Sudo. Questo è un caso in cui sudo potrebbe fornire una maggiore sicurezza. Se qualcuno dovesse rubare le tue chiavi ssh, gli verrebbe comunque impedito di fare qualcosa di significativo sulla tua casella se dovesse ancora forzare la password del tuo account per usare sudo. Le password non dovrebbero essere una parola, ma piuttosto una passphrase. Pensa a una frase e usala. Questo generalmente ti porterà qualcosa di più lungo di 8 caratteri, fornendo molta entropia, ma è anche più facile da ricordare rispetto a una password casuale. Naturalmente, le buone pratiche di password dicono di utilizzare una password casuale generata dalla macchina per ingannare strumenti di cracking come John the Ripper, che strapperà la maggior parte delle passphrase e delle password. No, cambiare E con 3 non funziona, anche John ottiene quelle permutazioni.