Autenticazione chiave SSH, ma ancora bisogno di password per sudo?

Sto provando un approccio diverso che non richiede la creazione e la gestione delle password: ho impostato l'autenticazione basata su chiave con la chiave pubblica dell'utente, l'autenticazione disabilitata basata su password per ssh e impostare gli account utente con un vuoto ma scaduto password ( passwd -de ). In questo modo gli utenti vengono spinti al loro primo accesso e possono scegliere le proprie password.

Mi sento un po 'a disagio per la password vuota ma, per quanto posso dire, va bene finché l'autenticazione della password per ssh è disabilitata e non ci sono altri servizi in esecuzione che richiedono l'autenticazione (IMAP o qualcosa del genere). Qualche opinione su questo?

A mio parere, sudo per gli amministratori del server è un po 'eccessivo. Se le persone effettuano l'accesso e dispongono dell'accesso root (tramite qualche meccanismo), in genere eseguono le attività, dove useranno sudo per > 90% delle volte. Lo scopo di sudo è di fornire agli account che sono registrati una separazione tra le applicazioni non attendibili e le attività simili a quelle degli amministratori e informare gli utenti che stanno cambiando il sistema (e devono stare attenti). Per i desktop, entrambi si applicano. Per i server, tuttavia, la maggior parte delle attività richiede già sudo, quindi entrambi i punti diventano deboli. sudo ha alcuni vantaggi con il suo controllo a grana fine, ma per fare affidamento sulle sue capacità di registrazione, è necessario impostare la registrazione remota, altrimenti le persone con accesso root possono falsificare i registri precedenti.

Is there some security caveat I'm missing why this is not more widely adopted?

pam_ssh_agent_auth richiede l'inoltro di ssh-agent per funzionare su ssh. Tuttavia, è un po 'inutile usarlo, poiché ogni processo (non cgrouped) in esecuzione con l'account dell'utente potrebbe utilizzare l'agente per eseguire comandi come root. Ciò consente a tutti questi processi di eseguire sudo che è esattamente ciò che fa il parametro NOPASSWORD .

Il mio consiglio è di avere NOPASSWORD e di essere soddisfatto. Dà ancora alle persone la sensazione di "ora cambio il sistema", ma non ha fastidiose password.

Se vuoi ancora avere le password, puoi inviarle per e-mail in chiaro, ma richiederle di essere modificate la prima volta che vengono utilizzate. Un utente malintenzionato avrebbe bisogno sia dell'email sia della chiave privata dell'utente per avere successo. Se hanno già accesso alla chiave privata, potrebbero fare alcune cose brutte a .bashrc e ottenere l'accesso la prossima volta che l'utente ottiene sudo con una password che l'utente malintenzionato non ha bisogno di sapere.

Suggerisco di evitare persino l'installazione di sudo sui tuoi sistemi: si tratta di un vettore di attacco aggiuntivo che solitamente non giustifica il fatto di averlo. Ho scritto un articolo sull'uso sudo (errato) se sei interessato a saperne di più sull'argomento: link

Oggetto: la domanda originale - se hai bisogno di un comando privilegiato per essere eseguito da utenti non privilegiati, puoi usare il trucco seguente:

1. genera una chiave SSH passphrase-less
2. antepone la parte pubblica a quanto segue: from="127.0.0.1",command="your_desired_command_here",no-pty,no-port-forwarding,no-agent-forwarding (puoi anche limitare ulteriormente la sessione SSH, vedi "man sshd"). Nota che la chiave deve essere separata da questa intestazione da un carattere di spazio.
3. installa quella chiave pubblica per l'account privilegiato ~ / .ssh / authorized_keys
4. fornire all'utente la chiave privata (o creare uno script che semplicemente SSH in oltre l'interfaccia di loopback sull'account privilegiato utilizzando la chiave privata)

Ad esempio, se l'account privilegiato è r_service (creato con useradd -om -u0 -g0 -d /root/service -s /bin/bash r_service ) la chiamata a quel comando privilegiato da un account non privilegiato sarebbe qualcosa di simile:

$ ssh -i ~/.ssh/privileged_command r_service@0

In questo modo concederai ai tuoi utenti di eseguire quel comando privilegiato senza compromettere il modello di sicurezza.

L'autenticazione SSH e i privilegi di sicurezza sono due cose diverse, quindi non c'è motivo di averlo come caratteristica predefinita. Tuttavia, apre un altro vettore per l'attacco (c'è un CVE ) e dal mio punto di vista rende più facile per gli utenti per abusarne, che è male.

Per quanto riguarda le password, un modo è di inviare una password di breve durata all'utente e chiedergli di cambiarla dopo l'accesso iniziale. Oppure permetti loro di "registrare" il loro account e funzionano solo con l'hash. Ci sono pro e contro in ogni approccio, ma un buon posto per l'ispirazione sono i servizi commerciali e gratuiti di account Shell.