Come sbloccare l'account per l'autorizzazione ssh a chiave pubblica, ma non per l'autorizzazione tramite password?


32

SSH non mi consente di accedere, perché l'account è bloccato. Voglio sbloccare l'utente sul mio server per l'autorizzazione della chiave pubblica su ssh, ma non abilitare l'accesso con password.

Ho provato:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

Voci del registro di autenticazione:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

si dovrebbe (secondo me) fare questo per tutti gli utenti ... una semplice configurazione, quando a farlo per tutta la sshd
Skaperen

passwd -uè una cattiva idea. Vedi la risposta di Giles sotto.
Peter Jenkins,

Risposte:


15

Sblocca l'account e fornisci all'utente una password complessa come suggerisce @Skaperen.

Modifica /etc/ssh/sshd_confige assicurati di avere:

PasswordAuthentication no

Verifica che la riga non sia commentata ( #all'inizio) e salva il file. Infine, riavvia il sshdservizio.

Prima di procedere, assicurarsi che l'autenticazione con chiave pubblica funzioni prima.

Se è necessario farlo solo per uno (o un numero limitato) di utenti, lasciare PasswordAuthenticationabilitato e utilizzare invece Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Posizionalo nella parte inferiore del file poiché è valido fino al Matchcomando o EOF successivo.

È inoltre possibile utilizzare Match Group <group name>o una negazioneMatch User !bloggs

Come accennato nei commenti, è anche possibile invertirlo in modo che l'autenticazione password sia disabilitata nella parte principale della configurazione e utilizzare le Matchistruzioni per abilitarlo per alcuni utenti:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

ho avuto l'impressione che Miro volesse disabilitare la password per un solo uso. ma vedi il mio commento precedente
Skaperen del

@Skaperen - potresti avere ragione. Ho leggermente modificato la mia risposta.
garethTheRed,

La Matchsintassi sembra buona, ma la proverò al contrario. Abilita l'accesso con password per utenti (pochi zoppi).
kravemir,

@Miro - È una buona idea, l'ho aggiunto alla mia risposta per riferimento futuro.
garethTheRed,

37

Qualunque cosa tu faccia, non lasciare l'account nello stato lasciato da passwd -u, con un campo password vuoto: ciò consente l'accesso senza inserire una password (tranne su SSH, perché SSH lo rifiuta).

Cambia l'account per non avere password, ma per sbloccarlo. Un account non ha password se l'hash della password nel database delle password non è l'hash di nessuna stringa. Tradizionalmente, una stringa di un carattere come *o !viene utilizzata per questo.

Gli account bloccati usano anche un marcatore speciale nel campo della password che fa sì che la stringa non sia l'hash di nessuna stringa. Il marker dipende dal sistema. Su Linux, il passwdcomando contrassegna le password bloccate inserendo !a all'inizio e OpenSSH considera l'account come bloccato se il campo inizia con !. Altre varianti di Unix tendono a utilizzare meccanismi simili ma non identici, quindi fai attenzione se il database delle password è condiviso tra una rete eterogenea.

Su Linux, è possibile disabilitare l'accesso basato su password a un account consentendo l'accesso SSH (con qualche altro metodo di autenticazione, in genere una coppia di chiavi) con

usermod -p '*' username

L'utente non sarà in grado di ripristinare l'account per avere una password, perché ciò richiede che inserisca una password valida.

Se lo desideri, puoi invece configurare SSH per rifiutare l'autenticazione della password, indipendentemente dal fatto che l'account abbia una password. Dovrai comunque fare in modo che SSH non consideri l'account bloccato, quindi ad esempio su Linux dovrai rimuovere il !campo dalla password (ma non rendere il campo vuoto - impostalo *come spiegato sopra ). Per disabilitare l'autenticazione della password per SSH, aggiungere una PasswordAuthenticationdirettiva /etc/sshd_configo /etc/ssh/sshd_config(qualunque sia sul proprio sistema). Utilizzare un Matchblocco per rendere tale direttiva applicabile solo a un utente specifico; Matchi blocchi devono apparire

…
Match User username
    PasswordAuthentication no

6
Grazie - ha usermod -p '*' usernamefunzionato un incanto!
Homme Zwaagstra,

1
OpenSSHd consente agli utenti bloccati (ad es. Hash di password con !prefisso) di accedere con qualche altro metodo di autenticazione se UsePAM yesimpostato sshd_config. Questo è probabilmente il valore predefinito con la maggior parte delle distribuzioni (ad es. Con Fedora).
maxschlepzig,

1
Ho un sistema incorporato senza PAM, quindi la distinzione '*'vs. '!'è super utile.
jpkotta,

8

Non è necessario abilitare o impostare le password, e in realtà non dovresti, se stai già utilizzando chiavi forti. Blocca nuovamente il tuo account (sudo passwd -l username) da una sessione esistente e correggi la tua configurazione SSH.

Il motivo per cui ciò è accaduto è probabilmente perché hai modificato una delle impostazioni predefinite del demone SSH (in / etc / ssh / sshd_config).

Cambia questo in / etc / ssh / sshd_config e riavvia SSH:

UsePAM yes

In generale, a meno che tu non abbia una buona ragione per disabilitare PAM, ti consiglio di tenerlo abilitato; abilitare PAM in SSH ti consentirà comunque di accedere, anche con una password rimossa. Qualunque cosa tu faccia, non impostare una password vuota o simile ... bloccare il campo password non deve significare bloccare l'intero account.

Suggerimento rapido quando si scherza con SSH: tenere aperta un'altra sessione (in un'altra finestra) ogni volta che si apportano modifiche alla configurazione di SSH, quindi verificare che sia ancora possibile accedere; se si interrompe inavvertitamente l'accesso, utilizzare la sessione corrente per correggerlo.

(Dichiarazione di non responsabilità: lavoro presso Userify, che fornisce software di gestione delle chiavi SSH.)


0

Ho avuto questo problema su CentOS 7. Sono un normale utente Linux basato su Debian, quindi ero un pesce fuor d'acqua. Ho notato che in alcuni dei server ha funzionato e in uno solo non ha funzionato. Audit.log non ha detto nulla di utile e neanche secure.log ha dato nulla. Ho scoperto che l'unica vera differenza erano alcune differenze nel contesto di sicurezza su file e directory tra quelli che funzionavano e quelli che non lo facevano. Ottieni la sicurezza con

sudo ls -laZ <user-home>/.ssh

della directory (presumo molte impostazioni predefinite su sshd_config).

Dovresti vedere alcuni ssh_home_te user_home_tattributi. In caso contrario, utilizzare il chconcomando per aggiungere gli attributi mancanti.

Per esempio

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Nel mio caso, il mio sospetto è che l'utente sia stato creato in modo non standard. La sua casa era una directory in /var/lib.

Maggiori informazioni in: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/


-2

sbloccare l'account e modificare la password in una stringa casuale

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.