Skip to content

È possibile impostare `sudo` senza password su un server cloud?

I nostri migliori programmatori hanno esaurito le loro riserve di caffè, cercando giorno e notte la risposta, finché Sergio non ha trovato il risultato in Gogs, quindi ora lo condividiamo con noi.

Soluzione:

Soluzione 1:

Mi piace l'idea di accedere ai server tramite le chiavi, in modo da non dover digitare la mia password ogni volta che
digitare la mia password ogni volta che faccio ssh in una casella, ho anche bloccato la password del mio utente (non root) (passwd -l username) in modo che non sia possibile accedere al server.
(non root) (passwd -l username) in modo che sia impossibile accedere senza una chiave...
senza una chiave... Consiglieresti/sconsiglieresti di fare questo per un
utente su un server?

Si sta procedendo alla disabilitazione dei login basati su password nel modo sbagliato. Invece di bloccare l'account di un utente, impostare PasswordAuthentication no nel proprio account /etc/ssh/sshd_config.

Con questa impostazione, l'autenticazione tramite password è disabilitata per ssh, ma si può ancora usare una password per sudo.

Il solo volta che consiglio di impostare NOPASSWD in sudo è per gli account di servizio, dove i processi devono essere in grado di eseguire comandi tramite sudo in modo programmatico. In queste circostanze, assicurarsi di inserire esplicitamente nella whitelist solo l'account specifici che l'account deve eseguire. Per gli account interattivi, si dovrebbe sempre lasciare le password abilitate.

Risposte alle vostre domande di follow-up:

Ma credo che se disabilito l'autenticazione con password in
/etc/ssh/sshd_config in modo da avere una chiave per accedere, posso usare una password più semplice solo per sudo che sia più facile da digitare?
posso usare una password più semplice solo per sudo, più facile da digitare? È
una strategia valida?

Sì, è corretto. Raccomando comunque di usare password relativamente forti per gli account locali, ma non ridicolmente forti. ~8 caratteri, generati in modo casuale, 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.
accesso al mio computer e ruba le mie chiavi (sono comunque protette dalla password del portachiavi del
password del portachiavi del sistema operativo!), potrebbe anche accedere direttamente all'account di
all'account di root, aggirando il percorso sudo.

L'accesso root via ssh dovrebbe essere disabilitato. Punto. Set PermitRootLogin no nel vostro sshd_config.

Quale dovrebbe essere la politica di accesso all'account root?

Dovreste sempre avere un mezzo per ottenere un accesso fuori banda alla console del vostro server. Molti fornitori di VPS lo forniscono, così come i fornitori di hardware dedicato. Se il vostro fornitore non concede un vero accesso alla console (ad esempio, EC2), potete comunque ripristinare l'accesso utilizzando un processo come quello descritto in questa risposta.

Soluzione 2:

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

Consentire NOPASSWORD per i comandi generici, permette a chiunque abbia accesso al vostro userid di eseguire qualsiasi comando. Ciò potrebbe derivare da una compromissione delle vostre credenziali, ma potrebbe anche essere semplice come qualcuno che si siede alla vostra scrivania quando vi allontanate per un secondo.

Trovo che non sia necessario inserire la password molto spesso. Una volta immessa la password, è possibile eseguire diversi comandi se non si attende troppo tempo tra l'uno e l'altro. Il timeout è configurabile.


Soluzione 3:

È possibile avere il meglio dei due mondi: l'autenticazione SSH sia per il login che per sudo. Se si integra il modulo pam_ssh_agent_auth si possono usare le chiavi SSH per autenticarsi senza fornire una password quando si fa sudo.

Lo uso in produzione da più di cinque anni.

Per configurarlo, installare il modulo PAM e aggiungere una riga a /etc/pam.d/sudo o l'equivalente del vostro sistema:

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

In questo caso, assicurarsi di proteggere le chiavi sul computer con una passphrase. In questo modo, qualcuno dovrebbe introdursi nel vostro computer e rubare le chiavi per entrare. Potrebbe farlo estraendole dalla memoria mentre sono sbloccate se ha accesso al vostro account, crackando la vostra passphrase, o rubando la vostra passphrase attraverso un keylogger o navigando a vista mentre la digitate (guardatevi alle spalle!).

Si può usare la stessa chiave SSH che si usa per il login, oppure si può impostare una chiave separata da aggiungere al proprio agente solo quando si fa sudo. Se si vuole essere molto prudenti, si può mantenere un file authorized_keys separato con una chiave SSH separata, da aggiungere all'agente solo quando si deve fare sudo:

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

Soluzione 4:

La userei solo in due circostanze:

  • Quando è assolutamente richiesto per uno script automatizzato che viene eseguito come utente specifico
  • Per compiti di amministrazione specifici (solo compiti di amministrazione, non quelli che agiscono per alterare il sistema) e solo per utenti specifici, naturalmente.

Per impostazione predefinita la maggior parte sudo non vi chiederanno più nulla per un po' di tempo nella stessa sessione (se aprite una nuova shell, questo non ha alcun effetto). È possibile controllare questo comportamento in una certa misura con l'opzione timestamp_timeout .

Senza password sudo non è così pericolosa come la password-less ssh Se un attaccante remoto ha bisogno delle vostre credenziali per entrare, ma se è entrato in qualche modo compromettendo la vostra chiave privata (o se è fisicamente vicino a voi e vi siete lasciati loggati e sbloccati mentre eravate lontani dalla macchina), la richiesta di password è una preziosa difesa aggiuntiva tra loro e l'accesso privilegiato.

Per quanto riguarda il seguito 2:

Se ho anche una chiave per accedere come root tramite ssh

Anche questo è meglio evitarlo, esattamente per il motivo che hai descritto. Se una connessione remota deve avere un accesso privilegiato, fatela accedere tramite un account di servizio e dategli il controllo sufficiente per fare il suo lavoro tramite sudo. Questo è ovviamente più complicato da configurare, quindi molti non se ne preoccupano (il che gioca a vostro favore, dato che gli aggressori possono dedicare il loro tempo a molti frutti più piccoli di voi), quindi si tratta del vecchio compromesso tra sicurezza e convenienza (consiglio: scegliete la sicurezza!).


Soluzione 5:

Visto che l'avete chiesto, ecco il mio consiglio generale su come affrontare il problema del sudo problema.

Sudo non è stato progettato per fornire maggiore sicurezza (anche se in parte può farlo)... ma piuttosto per fornire una buona traccia di controllo di chi sta facendo cosa sul vostro sistema con quali privilegi.

Un Sudo correttamente configurato non userà l'opzione ALL=(ALL) ALL ma piuttosto qualcosa di più limitato a ciò che serve specificamente all'utente. Ad esempio, se un utente deve essere in grado di accedere e riavviare un servizio bloccato, probabilmente non ha bisogno della capacità di installare un nuovo software o di spegnere il server, modificare le regole del firewall, ecc.

A volte è comune che le persone usino sudo per elevarsi all'account di root, ad esempio. sudo su -. Una volta fatto questo, si smette di vedere chi sta facendo cosa dall'account root (root può essere loggato più volte contemporaneamente). Quindi a volte si vuole disabilitare l'account sudo su - anche il comando sudo su - . Tuttavia, per motivi pratici, se si ha bisogno di un account con privilegi di root per l'amministrazione, è necessario almeno che qualcuno invii il comando sudo su -registrerebbe chi si è elevato a root e quando.

Come proteggo le mie scatole:

Cambiare la porta SSH con qualcosa di diverso da quella predefinita. Questo per evitare i bot stupidi che cercano i numeri di porta e poi si accaniscono finché non riescono a entrare (o meno).

Disconoscere l'accesso di root su SSH usando la porta AllowRootLogin no nella configurazione di sshd_config. Questo impedisce a qualcuno di forzare brutalmente l'account di root. In generale è buona norma non permettere mai a nessuno di accedere direttamente all'account di root/amministratore per motivi di verifica e di sicurezza. Se si consente l'accesso diretto a root, non si sa chi è entrato, da chi ha ottenuto la password, ecc. Ma se qualcuno accede all'account di Jimmy e poi eleva i suoi permessi a root, si ha un'idea più precisa di dove iniziare la ricerca di audit (e di chi sia l'account da resettare).

Consentire l'accesso a SSH solo agli utenti che lo richiedono Usare il AllowUsers e specificare esplicitamente quali account devono accedere a SSH. Per impostazione predefinita, tutti gli altri account saranno bloccati da SSH.

Modificare i Sudoer tramite visudo e consentire solo i comandi necessari all'utente. Ci sono molte guide approfondite su come fare, quindi non le descriverò qui. Ecco un antipasto: http://ubuntuforums.org/showthread.php?t=1132821

Se l'account di Sally viene violato e Sally può usare sudo solo per riavviare il server web, l'aggressore potrà divertirsi a riavviare il server web in loop, ma almeno non potrà farlo. rm -rf /your/webserver/directory o aprire tutte le porte del firewall, ecc.

Impostate delle buone regole del firewall che permettano solo le porte necessarie al funzionamento del vostro sistema. Generalmente si vuole eliminare tutto e consentire esplicitamente solo ciò di cui si ha bisogno. Ci sono un sacco di iptables e altri firewall decenti online, eccone uno che uso io (è una base di partenza):

# 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 forte è fondamentale. Anche se si usano le chiavi SSH per l'accesso remoto, si dovrebbe 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 chiavi ssh, gli sarebbe comunque impedito di fare qualcosa di significativo sulla vostra macchina se dovesse forzare la password del vostro account per usare sudo. Le password non dovrebbero essere una parola, ma piuttosto una frase di passaggio. Pensate a una frase e usatela. In genere, in questo modo si ottiene qualcosa di più di 8 caratteri, che fornisce un'ampia entropia, ma è anche più facile da ricordare rispetto a una password casuale. Naturalmente, le buone pratiche in materia di password prevedono l'uso di una password casuale generata dalla macchina per ingannare gli strumenti di cracking come John the Ripper, che sono in grado di superare la maggior parte delle passphrase e delle password. No, cambiare E con 3 non funziona, John ottiene anche queste permutazioni.

valutazioni e recensioni



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.