useradd non crittografa le password in / etc / shadow

Mi sono imbattuto in questo problema durante il tentativo di creare nuovi utenti FTP per vsftpd. Dopo aver creato un nuovo utente con il seguente comando e tentato l'accesso con FileZilla, avrei ricevuto un errore "password errata".

useradd f -p pass -d /home/f -s /bin/false

Dopo aver fatto ciò, / etc / shadow contiene

f:pass:1111:0:99:2:::

Una volta che eseguo il comando seguente e fornisco lo stesso pass pass

passwd f

/ etc / shadow contiene

f:$1$U1c5vVwg$x5TVDDDmhi0a7RWFer6Jn1:1111:0:99:2:::

Sembra che la crittografia avvenga quando eseguo passwd , ma non su useradd

È importante sottolineare che dopo aver fatto questo, sono in grado di accedere a FTP con le stesse credenziali esatte.

Sto usando CentOS 5.11, vsftpd per FTP e FileZilla per l'accesso FTP

/ var / log / secure contiene:

Dec 17 useradd[644]: new group: name=f, GID=511
Dec 17 useradd[644]: new user: name=f, UID=511, GID=511, home=/home/f, shell=/bin/false

Perché non funziona quando passo -p passa useradd? Cosa devo fare per farlo funzionare?

— Cattivo fino al midollo
fonte

Non vedo una domanda lì? - Tali cose sono gestite tramite PAM e generalmente registrate/var/log/secure

— HBruijn il

@HBruijn Ho aggiornato la mia risposta per mostrare ciò che è scritto in / var / log / secure

— BadToTheBone

Veramente? +12 per una domanda a cui la pagina man pertinente risponde esplicitamente?

— un CVn il

Si noti che in un hash password, $1$ indica che viene utilizzato MD5 . MD5, sebbene non sia assolutamente terribile per le password, al giorno d'oggi è piuttosto debole. È una domanda completamente separata, ma ti esorto assolutamente a considerare la migrazione a una funzione di hash più forte.

— un CVn il

Nota a margine: le password /etc/shadownon sono crittografate ma sono state tratteggiate in hash

— Tobias Kienzler il

Risposte:

Funziona come previsto. Se si desidera impostare una password utilizzando il useraddcomando, è necessario fornire una versione con hash della password useradd.

La stringa passsoddisfa i criteri di formato per il campo password con hash in /etc/shadow, ma nessun hash di password effettivo per quella stringa. Il risultato è che a tutti gli effetti, quell'account si comporterà come una password, ma qualsiasi password che si tenta di utilizzare per accedervi verrà rifiutata come non corretta.

Vedi man useraddo la documentazione di useradd :

-p, --password PASSWORD

La password crittografata, come restituita da crypt (3) . L'impostazione predefinita è disabilitare la password.

Nota: questa opzione non è consigliata poiché la password (o password crittografata) sarà visibile dagli utenti che elencano i processi.

È necessario assicurarsi che la password rispetti la politica delle password del sistema.

— kasperd
fonte

manuseradd :

   -p, --password PASSWORD
       The encrypted password, as returned by crypt(3). The default is to
       disable the password.

Dovresti passarci una password con hash.
Non una password in chiaro.

— impostore
fonte

useraddsi aspetta che tu gli passi l'hash della password, non la password stessa. È possibile utilizzare la seguente variazione sul comando per fornire una password con hash al useraddcomando:

useradd f -p "$(mkpasswd --method=sha-512 'pass')" -d /home/f -s /bin/false

Per scoprire i metodi disponibili, utilizzare:

mkpasswd --method=help

Per evitare di passare la password dalla riga di comando, inserisci la password in un file (usando un editor e non usando echoo simili) e fai questo:

useradd f -p "$(mkpasswd --method=sha-512 --password-fd=0 < filename)" -d /home/f -s /bin/false

Questo passerà la password con hash sulla riga di comando, ma non quella in chiaro.

mkpasswdviene fornito con il expectpacchetto.

— In pausa fino a nuovo avviso.
fonte

Non usare MD5! Usa SHA-2

— Josef il

Si noti che ciò espone temporaneamente la password attraverso le varie interfacce del kernel (a qualsiasi processo è consentito leggere la riga di comando di qualsiasi altro processo) e può comportare il salvataggio in testo normale su disco tramite $ HISTORY o meccanismi simili.

— un CVn il

@ MichaelKjörling: Un molto buon punto. Si prega di vedere la mia risposta modificata.

— In pausa fino a nuovo avviso.

Naturalmente, stai ancora memorizzando la password in chiaro sul disco. Almeno, questo dà al sysadmin una scelta. Forse a questo punto stiamo meglio usando solo una password fittizia all'inizio e correndo immediatamente passwdper cambiarla in qualcos'altro ......

— un CVn

Assolutamente Dennis, è molto meglio, ma la password finisce ancora sul disco in chiaro. In alcune situazioni e in determinati modelli di minaccia, questo può essere un vero problema. Non deve essere.

— un CVn il