Impostare la password sudo in modo diverso da quella di accesso

Come utente privilegiato sto provando a impostare la sudopassword su un'altra, quindi su quella utilizzata al momento dell'accesso.

Ho fatto qualche ricerca ma non ho trovato una risposta. Fa sudosupporto che tipo di configurazione?

Se perdi la password, perdi tutto. Qualcuno potrebbe accedere e promuoversi rootcon la stessa password.

sudoha un'opzione per chiedere la rootpassword invece della password utente invocata, ( rootpw), ma la condivisione della rootpassword non è sicuramente un'opzione, ecco perché abbiamo impostato sudo.

Ho fatto config 2FAin passato, ha funzionato alla grande, ma ha anche sconfitto lo scopo dell'automazione. Ad esempio, se si desidera eseguire un comando privilegiato su una dozzina di server con uno expectscript, l'aggiunta 2FAnon consente di farlo.

La soluzione più vicina che ho trovato è consentire solo la chiave privata SSH e impostare la passphrase con una chiave diversa dalla sudopassword (login). Tuttavia, non è comodo, perché in una situazione di emergenza non è possibile accedere con un PC in cui non ha quella chiave.

Se vuoi richiedere la password di root, al contrario della password dell'utente, ci sono opzioni che puoi inserire /etc/sudoers. rootpwin particolare lo farà richiedere la password di root. C'è runaspwe targetpwpure; vedere la manpage sudoers (5) per i dettagli.

A parte questo, sudo fa la sua autenticazione (come tutto il resto) tramite PAM. PAM supporta la configurazione per applicazione. La configurazione di Sudo è in (almeno sul mio sistema Debian) /etc/pam.d/sudo, e si presenta così:

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

In altre parole, per impostazione predefinita, si autentica come qualsiasi altra cosa sul sistema. Puoi cambiare quella @include common-authlinea e fare in modo che PAM (e quindi sudo) utilizzi una fonte di password alternativa. Le righe non commentate in common-auth hanno un aspetto simile (per impostazione predefinita, questo sarà diverso se si utilizza ad esempio LDAP):

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

È possibile utilizzare, ad esempio, pam_userdb.soanziché pam_unix.soe archiviare le password alternative in un database Berkeley DB.

esempio

Ho creato la directory /var/local/sudopass, il proprietario / il gruppo root:shadow, la modalità 2750. Al suo interno, sono andato avanti e ho creato un file di database delle password usando db5.1_load(che è la versione di Berkeley DB in uso su Debian Wheezy):

# umask 0027
# db5.1_load -h / var / local / sudopass -t hash -T passwd.db
anthony
WMaEFvCFEFplI
^D

Questo hash è stato generato con mkpasswd -m des, usando la password "password". Molto altamente sicuro! (Sfortunatamente, pam_userdb sembra non supportare niente di meglio dell'antico crypt(3)hashing).

Ora, modifica /etc/pam.d/sudoe rimuovi la @include common-authlinea e mettila invece a posto:

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Si noti che pam_userdb aggiunge .dbun'estensione al database passato, quindi è necessario lasciarlo .dbspento.

Secondo dannysauer in un commento , potrebbe essere necessario apportare anche la stessa modifica /etc/pam.d/sudo-i.

Ora, per sudo, devo usare al passwordposto della mia vera password di accesso:

anthony @ sudotest: ~ $ sudo -K
anthony @ sudotest: ~ $ sudo echo -e '\ nit ha funzionato'
[sudo] password per anthony: passwordRETURN

ha funzionato

Per Redhat / Centos, il requisito può essere raggiunto con i seguenti passaggi:

Crea un utente personalizzato e passa:

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

Modifica il file sudo pam.d in modo che appaia:

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

Sto ancora cercando il modo di configurare, in modo che solo un determinato utente / gruppo debba essere autenticato con questo metodo personalizzato, altri possono ancora essere authen con il normale metodo di autenticazione di sistema. Qualcuno può darmi qualche consiglio?

Non credo che sudo supporti tale configurazione. Lo scopo della richiesta di password sudo è quello di garantire che la persona che ha emesso il comando sudo sia la stessa persona che ha effettuato l'accesso e il modo più semplice per farlo è chiedere all'utente che ha effettuato il login di autenticarsi nuovamente.

In altre parole, lo scopo della richiesta della password sudo non è quello di stabilire l' autorità , ma di stabilire l' identità . In base all'identità stabilita e alla configurazione sudo, è possibile decidere se l'utente in questione dispone dell'autorità necessaria o dei diritti di accesso.

La tua preoccupazione è che la password del tuo account possa essere divulgata. La soluzione è non utilizzare la password di accesso in modo tale che possa essere divulgata. Con ssh, la password è crittografata sul filo, quindi va bene. Le persone disattivano l'autenticazione della password con ssh per impedire attacchi di indovinare la password, non per proteggere la riservatezza della password. Se stai utilizzando la stessa password dell'account per qualsiasi altra cosa, assicurati di utilizzare un canale sicuro e crittografato per fornire la password. Se sei preoccupato per un keylogger o altro, smetti di usare macchine non attendibili per accedere.

Se qualcuno può ottenere la tua password ssh, probabilmente può anche ottenere la password sudo alternativa, quindi è meglio investire tempo nel rendere le tue connessioni più sicure che passare il tempo a rendere le cose più complicate solo per l'illusione di più sicurezza.

Non ho accesso immediato a un sistema in cui posso testarlo ed elaborare i dettagli, ma ho un'idea:

• (Supponiamo che il tuo normale account di accesso sia shau.)
• Creare un secondo account: shau2. (Non sono sicuro se si desidera che abbia lo stesso UID di shau.)
• Configurare shau2per avere i privilegi di sudo con NOPASSWD.
• Imposta un alias o uno script di shell da fare su shau2 -c sudo "$@". Questo dovrebbe richiedere shau2la password. Se inserito correttamente, verrà eseguito sudocome shau2 (che non dovrebbe richiedere una password).
• Rimuovi shaui privilegi di sudo.

Sfortunatamente, dovresti ripetere questo per ogni utente che ha i privilegi di sudo.

Grazie @ Shâu Shắc per la risposta ! Questa soluzione funziona anche con LinuxMint 17.1 Cinnamon 32 bit (ho installato solo un db-utilpacchetto per poterlo eseguire db_load).

Ma sono molto confuso con il passwd.dbfile risultante . Ho fatto lo stesso della tua risposta (ma ho usato David e Jones , sembrano più accattivanti):

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

Ma le credenziali immesse vengono archiviate all'interno del file hash come testo normale:

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

Puoi anche vedere david e jones tramite mcedit :

Sì, è possibile limitare le autorizzazioni di /usr/local/etc/passwd.db. Tuttavia, nome utente e password memorizzati come testo normale sono dannosi.

Anche con una password sudo separata ci sono alcuni potenziali buchi di sicurezza (per impostazione predefinita installazione distro). Pertanto, la password separata non è applicabile per su (quindi è possibile avviare la sessione root utilizzando sue la password di accesso). Inoltre, Policy Kit non rispetta la password separata (è possibile avviare Synaptic usando synaptic-pkexece login password. Quindi eliminare i pacchetti ...). Questi problemi possono essere eliminati ottimizzando ulteriormente i file di configurazione.

In generale sembra che una password sudo separata sicura possa essere ottenuta solo con l'aiuto del modulo PAM personalizzato (forse, tale modulo confronterà password e hash SHA-512 letti da file) o funzionalità SELinux.

PS: scusa, dovrebbe essere un commento. Ma va come risposta a causa del formato del testo. Grazie per la comprensione.