Devo eliminare le password degli utenti dopo aver impostato l'autenticazione con chiave pubblica per SSH?

È meglio usare le chiavi pubbliche per SSH. Quindi il mio sshd_configha PasswordAuthentication no.

Alcuni utenti non effettuano mai l'accesso, ad esempio un utente sftp con shell /usr/sbin/nologin. O un account di sistema.

Quindi posso creare un tale utente senza password con adduser gary --shell /usr/sbin/nologin --disabled-password.

È una buona / cattiva idea? Ci sono ramificazioni che non ho preso in considerazione?

— lonix
fonte

Fintanto che questi non sono account di utenti reali o non hanno bisogno della loro password per l' sudoaccesso (in virtù del fatto che non dispongono affatto delle autorizzazioni sudo o che dispongono dell'autorizzazione sudo con NOPASSWD), la risposta selezionata dovrebbe essere adatta. Ho inviato una modifica a quella risposta per includere la preoccupazione sudo, ma ho pensato che l'avrei chiamato qui nel frattempo.

— Doktor J,

Risposte:

Se si dispone dell'accesso root al server e si possono rigenerare le chiavi ssh per gli utenti nel caso in cui le perdano

sei sicuro che un utente (come persona) non disporrà di più account utente e dovrà passare da quelli a una sessione SSH (beh, possono anche aprire più sessioni SSH in caso di necessità)

non avranno mai bisogno dell'accesso "fisico" (tramite tastiera + monitor o console remota per una macchina virtuale) al server

nessun utente ha accesso con password sudo(ovvero non ha affatto accesso sudo o ha accesso sudo con NOPASSWD)

Penso che sarai bravo.

Abbiamo molti server al lavoro configurati in questo modo (solo alcuni account hanno bisogno dell'accesso alla VM tramite console remota vmware, altri si connettono solo tramite SSH con pubkey auth).

— Sig. Shunz
fonte

Aggiungerei anche "sai che gli utenti non dovranno mai accedere al sistema da sistemi remoti privi della loro chiave SSH privata". E "Sei disposto a trattare con utenti che si imbattono in una situazione a cui non hai pensato".

— Andrew Henle,

La prima condizione è l'IMO non necessaria. I tuoi utenti dovrebbero creare le loro chiavi da soli. Autorizzi semplicemente le loro chiavi pubbliche mentre te le danno. Se perdono una chiave, ne genereranno un'altra e sostituirai quella vecchia sul server.

— Christophe Drevet-Droguet,

@AndrewHenle Questo è un buon punto, tuttavia se sshd ha PasswordAuthentication noun problema diverso (l'utente non sarebbe in grado di accedere comunque).

— Lonix,

"Mai" è così tanto tempo. L'amministratore può facilmente aggiungere nuovamente l'autenticazione della password, se necessario.

— hyde,

Bene, la domanda riguarda chiaramente gli account che sicuramente non (e probabilmente non dovrebbero) accedere, come gli account di sistema utilizzati da servizi specifici o utenti solo sftp. La domanda afferma inoltre che gli utenti non hanno shell di login. Per questi tipi di utenti penso sia consigliabile disabilitare esplicitamente l'accesso tramite password.

— Christian Gawron,

Questa domanda originariamente menzionava ciò passwd --delete <username> che non è sicuro : con ciò, il campo della password crittografata /etc/shadowsarà completamente vuoto.

username::...

Se hai configurato il tuo sshdrifiuto dell'autenticazione con password, allora è sicuro con SSH ... Ma se qualsiasi altro servizio sul tuo sistema utilizza l'autenticazione con password e non è configurato per rifiutare password null, questo consente l'accesso senza password! Non vuoi questo.

adduser --disabled-passwdprodurrà una /etc/shadowvoce in cui il campo della password crittografata è solo un asterisco, ad es

username:*:...

Questa è "una password crittografata che non può mai essere inserita con successo", ovvero significa che l'account è valido e consente tecnicamente l'accesso, ma rende impossibile l' autenticazione tramite password . Quindi, se hai altri servizi basati sull'autenticazione con password sul tuo server, questo utente ne viene bloccato.

Solo i metodi di autenticazione che utilizzano qualcosa di diverso dalla password dell'account standard (ad esempio le chiavi SSH) funzioneranno per questo utente, per qualsiasi servizio che utilizza i file delle password di sistema in questo sistema. Quando hai bisogno di un utente che può accedere solo con chiavi SSH, questo è quello che vuoi.

Se è necessario impostare un account esistente su questo stato, è possibile utilizzare questo comando:

echo 'username:*' | chpasswd -e

Esiste un terzo valore speciale per il campo password crittografato:, adduser --disabled-loginquindi il campo conterrà un solo punto esclamativo.

username:!:...

Come l'asterisco, ciò rende impossibile l'autenticazione della password, ma ha anche un significato aggiuntivo: contrassegna la password come "bloccata" per alcuni strumenti di amministrazione. passwd -lha più o meno lo stesso effetto prefissando l'hash della password esistente con un punto esclamativo, il che rende nuovamente impossibile utilizzare l'autenticazione della password.

Ma ecco una trappola per gli incauti: nell'anno 2008, la versione del passwdcomando che deriva dal vecchio shadowpacchetto è stata cambiata per ridefinire passwd -lda "blocco dell'account" a "blocco della password". Il motivo dichiarato è "per compatibilità con altre versioni passwd".

Se (come me) l'hai imparato molto tempo fa, potrebbe essere una brutta sorpresa. Non aiuta neanche cose che adduser(8)apparentemente non sono ancora consapevoli di questa distinzione.

La parte che disattiva il conto per tutti i metodi di autenticazione fissa di fatto un valore di data di scadenza del 1 per l'account: usermod --expiredate 1 <username>. Prima dell'anno 2008, passwd -lquesto proviene dal shadowkit di origine utilizzato per eseguire questa operazione oltre al prefisso della password con un punto esclamativo, ma non lo fa più.

Il log delle modifiche del pacchetto Debian dice:

debian / patches / 494_passwd_lock-no_account_lock: ripristina il comportamento precedente di passwd -l (che è cambiato in # 389183): blocca solo la password dell'utente, non l'account dell'utente. Inoltre documentare esplicitamente le differenze. Ciò ripristina un comportamento comune con le versioni precedenti di passwd e con altre implementazioni. Chiude: # 492307

La cronologia dei bug per il bug Debian 492307 e il bug 389183 può essere utile per comprendere il pensiero dietro questo.

— TELCOM
fonte

Grazie per l'avvertimento ... Sto per modificare la domanda in modo che nessuno commetta questo errore!

— Lonix,

Il tuo avviso si applica anche al caso in cui utilizzo adduser --disabled-passwd, quindi se qualche altro servizio consente l'autenticazione con password, l'utente può accedere senza password?

— Lonix,

No, in adduser --disabled-passwordparticolare rende impossibile l'autenticazione della password per avere successo per quell'account.

— telcoM,

Poiché l'eliminazione della password sembra così innocente ma è così pericolosa, suggerisco di cambiare il paragrafo su di esso con il paragrafo sull'uso, *quindi è la prima cosa che la gente legge.

— Captain Man,

Wow, questa è una brutta sorpresa in attesa di accadere ... e come al solito, sembra che ci sia un problema di compatibilità da incolpare. È apparso nel passwdcodice sorgente nel 2008. Non ti piace quando qualcosa che hai imparato una volta e su cui hai fatto affidamento risulta non essere più così?

— telcoM,