È corretto configurare `sudo` senza password su un server cloud?

Adoro l'idea di accedere ai server tramite le chiavi, in modo da non dover digitare la mia password ogni volta che mi trovo sshin una scatola, blocco anche la rootpassword ( non ) dell'utente ( passwd -l username), quindi è impossibile accedere senza una chiave.

Ma tutto ciò si interrompe se mi viene richiesto di inserire la password per i sudocomandi. Quindi sono tentato di impostare senza passwordsudo per rendere le cose in linea con l'accesso senza password.

Tuttavia, continuo ad avere la sensazione che possa ritorcermi contro in qualche modo inaspettato, sembra solo in qualche modo insicuro. Ci sono avvertenze con tale impostazione? Consiglieresti / non consiglieresti di farlo per un account utente su un server?

chiarimenti

1. Sto parlando dell'uso di sudouna sessione utente interattiva qui, non per servizi o script amministrativi
2. Sto parlando di utilizzare un server cloud (quindi non ho accesso fisico locale a una macchina e posso accedere solo da remoto)
3. So che sudoha un timeout durante il quale non devo reinserire la mia password. Ma il mio concerto non riguarda davvero lo spreco di tempo extra per digitare fisicamente una password. La mia idea però era di non dover gestire affatto una password, perché presumo che:
   • Se devo memorizzarlo, è molto probabile che sia troppo corto per essere protetto o riutilizzato
   • Se generi una password lunga e unica per il mio account remoto, dovrò salvarla da qualche parte (un programma di gestione password locale o un servizio cloud) e recuperarla ogni volta che voglio usarla sudo. Speravo di poterlo evitare.

Quindi, con questa domanda, volevo capire meglio i rischi, le avvertenze e gli svantaggi di una possibile configurazione rispetto alle altre.

Follow-up 1

Tutte le risposte affermano che la passwordless sudoè insicura in quanto consente una "facile" escalation dei privilegi se il mio account utente personale viene compromesso. Lo capisco. D'altra parte, se uso una password, incorrere in tutti i rischi classici con password (stringa troppo corta o comune, ripetuta su servizi diversi, ecc.). Ma immagino che se disabilito l'autenticazione della password in /etc/ssh/sshd_configmodo da avere ancora una chiave per accedere, posso usare una password più semplice solo per sudoquesto è più facile da digitare? È una strategia valida?

Follow-up 2

Se ho anche una chiave per accedere come roottramite ssh, se qualcuno accede al mio computer e ruba le mie chiavi (sono comunque protetti dalla password del portachiavi del sistema operativo!), Potrebbe anche ottenere un accesso diretto rootall'account , bypassando il sudopercorso. Quale dovrebbe essere la politica per accedere rootall'account allora?

Adoro l'idea di accedere ai server tramite le chiavi, in modo da non dover digitare la mia password ogni volta che scrivo in una scatola, blocco anche la password del mio utente (non root) (passwd -l username) quindi è impossibile accedi senza chiave ... Consiglieresti / non consiglieresti 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 nonel tuo /etc/ssh/sshd_config.

Con quel set, l'autenticazione della password è disabilitata per ssh, ma puoi comunque usare una password per sudo.

L' unica volta che raccomando di impostare NOPASSWDsu 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 i comandi specifici che l'account deve eseguire. Per gli account interattivi, è necessario lasciare sempre abilitate le password.

Risposte alle tue domande di follow-up:

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 è sufficiente.

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 protetti dalla password del portachiavi del sistema operativo!), Potrebbe anche avere un accesso diretto al account root, ignorando il percorso sudo.

L'accesso root tramite ssh dovrebbe essere disabilitato. Periodo. Impostare PermitRootLogin nonel tuo sshd_config.

Quale dovrebbe essere la politica per accedere all'account root allora?

Dovresti sempre avere un mezzo per ottenere l'accesso fuori banda alla console del tuo server. Diversi fornitori VPS forniscono questo, così come i fornitori di hardware dedicato. Se il tuo provider non concede un vero accesso alla console (ad esempio EC2, ad esempio), puoi in genere ripristinare l'accesso utilizzando un processo come quello che ho delineato in questa risposta .

In genere, limito l'uso dei NOPASSWORDcomandi eseguiti da un processo automatizzato. È preferibile avere un account di servizio per questi comandi e limitare l'uso di sudo ai comandi richiesti.

Consentendo NOPASSWORDcomandi generali, consente a chiunque abbia accesso al tuo userid di eseguire qualsiasi comando. Ciò potrebbe derivare da un compromesso 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. Dopo aver inserito la password, puoi eseguire diversi comandi se non aspetti troppo a lungo tra di loro. Il timeout è configurabile.

Lo userei solo in due circostanze:

• Quando è assolutamente necessario per uno script automatizzato in esecuzione come utente specifico
• Per attività amministrative specifiche (leggi solo le attività amministrative, non quelle che intervengono per modificare il sistema) e ovviamente solo per utenti specifici

Per impostazione predefinita, la maggior parte delle sudoconfigurazioni non ti chiederà più tempo nella stessa sessione (se apri una nuova shell che non ha alcun effetto). È possibile controllare questo comportamento in misura con l' timestamp_timeoutimpostazione.

Senza password sudonon è pericoloso quanto le sshchiavi senza passphrase , in quanto un malintenzionato remoto ha bisogno delle tue credenziali per accedere, ma se sono entrati in qualche modo compromettendo la tua chiave privata (o se sono fisicamente locali per te e ti sei lasciato loggato e sbloccato mentre sei lontano dalla macchina) quindi la richiesta di 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, proprio per il motivo che descrivi. Se una connessione remota deve avere un accesso privilegiato, accedi tramite un account di servizio e dai quel controllo sufficiente per fare il suo lavoro tramite sudo. Questo è più facile da configurare, ovviamente, così tanti non si preoccupano (il che funziona a tuo favore se lo fai, poiché c'è un sacco di frutta in sospensione più bassa di te per gli attaccanti su cui trascorrere del tempo!), Quindi si riduce al compromesso secolare tra sicurezza e convenienza (suggerimento professionale: scegli la sicurezza!).

Puoi avere il meglio di entrambi i mondi: autenticazione SSH sia per il login che per sudo. Se si integra il modulo pam_ssh_agent_auth, è possibile utilizzare le chiavi SSH per l'autenticazione senza fornire una password quando si sudo.

Lo uso in produzione da più di cinque anni.

Per configurarlo, installa il modulo PAM, quindi aggiungi una linea /etc/pam.d/sudoo 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 estraendoli dalla memoria mentre erano sbloccati se avessero accesso al tuo account, rompendo la passphrase o rubando la passphrase attraverso un keylogger o una spalla che lo naviga mentre lo digiti (guarda dietro di te!).

È possibile utilizzare la stessa chiave SSH utilizzata per accedere, oppure è possibile impostare una chiave separata che si aggiunge al proprio agente solo quando si sudo. Pertanto, se si desidera prestare maggiore attenzione, è possibile mantenere un file autorizzato_keys separato che ha una chiave SSH separata che si aggiunge al proprio agente solo quando è necessario eseguire sudo:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

Da quando hai chiesto, ecco il mio consiglio generale su come affrontare il sudoproblema.

Sudo non è stato progettato per fornire maggiore sicurezza (sebbene possa in qualche modo) ... ma piuttosto fornire una buona pista di controllo di chi sta facendo cosa sul proprio sistema con quali privilegi.

Un Sudo configurato correttamente non utilizzerà l' ALL=(ALL) ALLimpostazione, ma piuttosto qualcosa di più limitato a qualunque cosa sia specificamente necessaria all'utente. Ad esempio, se è necessario 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 server, modificare le regole del firewall, ecc.

A volte è comune per le persone usare sudo per elevarsi all'account di root, cioè. sudo su -. Una volta che lo fanno, smetti di vedere chi sta facendo cosa dall'account root (il root può essere loggato più volte contemporaneamente). Quindi a volte le persone vogliono disabilitare anche il sudo su -comando. Ma, per motivi pratici, se hai bisogno di un account con privilegi di root per l'amministrazione, per lo meno avendo qualcuno che emette il sudo su -comando registrerebbe chi è elevato a root e quando.

Come proteggo le mie scatole:

Cambia la porta SSH in qualcosa di diverso da quello predefinito. Questo per evitare i muti robot che cercano i numeri di porta e poi colpiscono fino a quando non entrano (o no).

Non consentire l'accesso root su SSH utilizzando l' AllowRootLogin noimpostazione in sshd_config. Questo impedisce a qualcuno di forzare brutalmente nel tuo account di root. In genere è buona norma non consentire a nessuno 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 autorizzazioni per eseguire il root, hai un'idea migliore da dove iniziare il tuo ricerca di controllo (e chi è l'account da ripristinare).

Consenti solo agli utenti di SSH che lo richiedono Usa l' AllowUsersimpostazione e esplicitamente specifica quali account devono accedere a SSH. Questo, per impostazione predefinita, bloccherà tutti gli altri account da SSH.

Modifica i sudatori tramite visudo e consenti solo i comandi di cui l'utente ha bisogno. Ci sono molte guide approfondite su come farlo, quindi non tratterò in dettaglio 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. vale a dire. se l'account di Sally viene violato e Sally può solo usare sudo per riavviare il server Web, beh, l'attaccante potrebbe divertirsi a riavviare il server Web in un ciclo, ma almeno non possono rm -rf /your/webserver/directoryo aprire tutte le porte del firewall, ecc.

Imposta buone regole del firewall che consentano solo le porte necessarie per il tuo box. Generalmente vuoi eliminare tutto e consentire esplicitamente solo ciò di cui hai bisogno. Ci sono molti iptables decenti e altri firewall iniziano 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 è la chiave.Anche se usi le chiavi SSH per l'accesso remoto, dovresti comunque richiedere una password per l'uso in Sudo. Questo è un caso in cui sudo potrebbe fornire un po 'più di sicurezza. Se qualcuno dovesse rubare le tue chiavi SSH, gli sarebbe comunque impedito di fare qualcosa di significativo sulla tua scatola se dovessero ancora forzare la password del tuo account per usare sudo. Le password non devono essere una parola, ma piuttosto una passphrase. Pensa a una frase e usala. Questo in genere ti porterà a più di 8 caratteri, fornendo molta entropia, ma è anche più facile da ricordare di una password casuale. Naturalmente, le buone pratiche di password dicono di usare una password casuale generata dalla macchina per ingannare strumenti di cracking come John lo Squartatore, che passerà attraverso la maggior parte delle passphrase e delle password. No, cambiare E con 3 non funziona, anche John ottiene quelle permutazioni.

In alcuni casi è necessario farlo. ad esempio alcune API hypervisor necessitano di login senza password e senza password sudo. Ma puoi ancora limitarlo senza rompere.

Per quello che stai cercando di ottenere. Direi, abituarsi a digitare una password. La sicurezza è più conveniente della convenienza qui. Inoltre, se hai davvero bisogno dell'accesso root puoi usare sudoe memorizzerà le credenziali per un po 'di tempo in modo che se esegui più comandi sudo di fila ti chiederà solo la password la prima volta. Quindi non è un grosso inconveniente come pensi.

Inoltre, se stai digitando molti comandi con privilegi di root e non vuoi mettere sudo davanti a loro tutto il tempo che puoi suo sudo -sper ottenere una shell di root. Inserisci la password una volta e poi è tutto.

Sono stato morso da sudo senza password una volta. Era uno script di shell, un programma di installazione che chiamava sudo per mio conto invece di, sai, richiedere solo sudo o errori.

Imaging digitando 'make' e lo script che esegue la parte 'sudo make install' per te, senza impostare o visualizzare il percorso di base, e lo script essendo così braindead in primo luogo che non sei sicuro di conoscere / usr / local e così inizi a controllare / usr per le modifiche ...

Ho promesso di non usare mai più NOPASSWD e ho anche modificato l'impostazione di timeout su 0.

Pur non rispondendo rigorosamente alla tua domanda, un'altra opzione potrebbe essere quella di impostare un valore più lungo, timestamp_timeoutquindi non è necessario digitare la password così spesso. Questo impedirà a chiunque di ottenere i privilegi di amministratore, ma ridurrà il tuo fastidio.

Dalla pagina man sudoers :

timestamp_timeout

Numero di minuti che possono trascorrere prima che sudo richieda nuovamente un passwd. Il timeout può includere una componente frazionaria se la granularità minima è insufficiente, ad esempio 2.5. Il valore predefinito è 5. Impostalo su 0 per richiedere sempre una password. Se impostato su un valore inferiore a 0, il timestamp dell'utente non scadrà mai. Questo può essere usato per consentire agli utenti di creare o eliminare i propri timestamp rispettivamente tramite "sudo -v" e "sudo -k".

Questo post sul blog mostra alcuni esempi che utilizzano visudoper impostare il timeout in minuti, come ad esempio:

Defaults timestamp_timeout=60

Forse questa è una felice via di mezzo tra sicurezza e facilità d'uso?

Le altre risposte qui sono fantastiche e toccano la maggior parte dei punti importanti. Una cosa che non ho visto menzionato è il fatto che qualsiasi tipo di autenticazione che fai quando accedi da solo può essere catturato da un attaccante remoto che ha già stabilito un punto d'appoggio nel tuo account. Possono modificare i file di login della shell o il PERCORSO per installare un keylogger in modo che tutto ciò che digiti, inclusa la tua password sudo, venga inviato a loro. Potrebbero aggiungere un binario sudo hackerato al tuo PERCORSO per raccogliere la tua password. Possono dirottare la connessione dell'agente ssh al tuo computer di connessione per sconfiggere pam_ssh_agent_auth e diventare root stessi non appena ti connetti. Quindi, in termini di sicurezza assoluta, non vedo alcuna differenza tra l'uso di una password per sudo e non. Naturalmente, lo rende un attacco più complicato,

In sintesi, credo che l'unico modo per impedire che un account utente compromesso diventi root se si dispone dell'accesso sudo è rimuovere l'accesso sudo da se stessi o non utilizzarlo mai. Se non sei d'accordo, fammi sapere, perché mi piacerebbe sbagliarmi!