Un approccio coerente e sicuro agli account senza password con SSH


13

Devo ammettere che in alcuni casi mi piacciono i server senza password. Un server tipico è vulnerabile a chiunque abbia accesso fisico ad esso. Quindi in alcuni casi è pratico bloccarlo fisicamente e da allora fidarsi di qualsiasi accesso fisico.

Concetti basilari

In teoria, quando raggiungo fisicamente un server di questo tipo, dovrei essere in grado di eseguire attività di amministrazione senza password semplicemente digitando rootcome login e non dovrei chiedermi una password. Lo stesso può valere per gli account utente ma non si accede realmente ad essi fisicamente. Pertanto non sono necessarie password di sistema per l'accesso locale (occasionale).

Quando accedo al server in remoto, per l'amministrazione o per l'account utente, mi aspetto di utilizzare sempre una chiave privata SSH. È molto semplice impostare una chiave SSH per un account appena creato e quindi non sono necessarie password di sistema per l'accesso remoto (regolare).

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

La conclusione è che, in teoria, non avremmo neeed eventuali password di sistema per i casi d'uso del genere. Quindi la domanda è: come possiamo configurare il sistema e gli account utente per farlo accadere in modo coerente e sicuro.

Dettagli di accesso locale

Come possiamo garantire che sia possibile accedere all'account root localmente senza password? Non penso che possiamo usarlo passwd -dperché ciò renderebbe l'accesso alla radice troppo permissivo e un utente non privilegiato potrebbe passare a root gratuitamente, il che è sbagliato. Non possiamo utilizzarlo passwd -lperché ci impedisce di accedere.

Si noti che l'accesso locale riguarda esclusivamente l'accesso mediante la tastiera locale. Pertanto, una soluzione valida non deve consentire la commutazione dell'utente (se si utilizza suo sudo).

Dettagli di accesso remoto

Fino a poco tempo fa la soluzione sopra avrebbe funzionato, ma ora SSH ha iniziato a verificare la presenza di account utente bloccati. Probabilmente non possiamo usare passwd -dper gli stessi motivi. Non possiamo usare passwd -uperché si lamenta solo che porterebbe a quello che passwd -dfa.

C'è una soluzione alternativa con password fittizia per questa parte.

user=...

echo -ne "$user:`pwgen 16`\n" | chpasswd

Potrebbe anche essere possibile disattivare completamente il controllo degli account bloccati in SSH, ma sarebbe meglio conservare il supporto degli account bloccati e riuscire a sbloccarli.

Note finali

Ciò che mi interessa è una soluzione che ti consenta di accedere all'account root localmente e a tutti gli account, incluso root da remoto, senza password. D'altra parte, una soluzione non deve influire sulla sicurezza se non in modi esplicitamente descritti, in particolare non consentendo agli utenti remoti di accedere all'account di root o all'account di altri utenti. La soluzione dovrebbe essere sufficientemente solida da non causare indirettamente problemi di sicurezza.

Una risposta accettata e premiata può o meno descrivere una configurazione dettagliata dei singoli strumenti, ma deve contenere i punti chiave per raggiungere gli obiettivi dichiarati. Si noti che questo probabilmente non può essere risolto con l'uso convenzionale di strumenti come passwd, ssh, su, sudoe simili.

Altre idee dopo aver letto le prime risposte

Solo un'idea: l'accesso root locale potrebbe essere ottenuto avviando shell root anziché processi di login. Ma c'è ancora la necessità di bloccare solo l'autenticazione con password, non l'autenticazione con chiave pubblica.


Utilizzare una configurazione PAM personalizzata per l'accesso locale senza password e fare lo stesso per gli accessi sudo e SSH.
0xC0000022L

Risposte:


5

Requisiti per i quali offrirò soluzioni, come punti elenco:

  1. Accesso alla console di root senza password
  2. Accesso remoto root senza password da utenti pre-autorizzati
  3. Accesso remoto senza password per account specificati da utenti pre-autorizzati
  4. Accesso remoto senza password per qualsiasi account da utenti pre-autorizzati

I seguenti esempi sono basati su Debian, poiché è quello che ho qui per i test. Tuttavia, non vedo alcun motivo per cui i principi non possano essere applicati a nessuna distribuzione (o effettivamente a qualsiasi derivato ix basato su PAM).

Accesso alla console di root senza password

Penso che il modo in cui mi approccerei a questo sarebbe di sfruttare PAM e il /etc/securettyfile di configurazione.

Come prerequisito, è necessario impostare una password di root "sufficientemente sicura". Ciò non è necessario per l'accesso alla console ma esiste per rendere irrealistici i tentativi di cracking della forza bruta. L'account è altrimenti un account root perfettamente normale.

In /etc/pam.d/loginho il seguente set standard di linee per l'autenticazione (quelle che iniziano con la parola chiave auth):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

Il common-authfile include di riferimento contiene le seguenti righe pertinenti:

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

Il common-authfile indica a PAM di saltare una regola (il rifiuto) se un "accesso UNIX" ha esito positivo. In genere questo significa una corrispondenza /etc/shadow.

La auth ... pam_securetty.solinea è configurata per impedire accessi root tranne nei dispositivi tty specificati in /etc/securetty. (Questo file include già tutti i dispositivi console.)

Modificando authleggermente questa riga è possibile definire una regola che consenta un login root senza una password da un dispositivo tty specificato in /etc/securetty. Il success=okparametro deve essere modificato in modo che okvenga sostituito dal numero di authrighe da saltare in caso di successo della corrispondenza. Nella situazione mostrata qui, quel numero è 3, che passa alla auth ... pam_permit.soriga:

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

Accesso remoto root senza password da utenti pre-autorizzati

Questa è una semplice inclusione di chiavi ssh per quegli utenti autorizzati che vengono aggiunti al authorized_keysfile root .

Accesso remoto senza password per account specificati da utenti pre-autorizzati

Questa è anche una semplice inclusione delle chiavi ssh per gli utenti autorizzati che vengono aggiunti al .ssh/authorized_keysfile dell'utente appropriato e corrispondente . (L' utente remoto tipico chris desidera accedere senza password allo scenario chris dell'utente locale .)

Si noti che gli account possono rimanere nello stato bloccato predefinito dopo la creazione (ovvero con solo !nel campo password per /etc/shadow) ma consentire l'accesso basato su chiave SSH. Ciò richiede che root inserisca la chiave nel file del nuovo utente .ssh/authorized_keys. Ciò che non è così ovvio è che questo approccio è disponibile solo quando UsePAM Yesè impostato /etc/ssh/sshd_config. PAM differenzia !come "account bloccato per password ma possono essere consentiti altri metodi di accesso" e !..."account bloccato. Periodo". (Se UsePAM Noimpostato, OpenSSH considera l'eventuale presenza di !avviare il campo password per rappresentare un account bloccato.)

Accesso remoto senza password per qualsiasi account da utenti pre-autorizzati

Non mi è stato del tutto chiaro se volevi o meno questa struttura. Vale a dire, alcuni utenti autorizzati sarebbero in grado di accedere senza una password a qualsiasi account locale.

Non posso testare questo scenario, ma credo che ciò possa essere ottenuto con OpenSSH 5.9 o versioni successive, che consente authorized_keysdi definire più file /etc/ssh/sshd_config. Modifica il file di configurazione per includere un secondo file chiamato /etc/ssh/authorized_keys. Aggiungi le chiavi pubbliche degli utenti autorizzati selezionati a questo file, assicurandoti che le autorizzazioni siano tali da essere di proprietà di root e avere accesso in scrittura solo da root (0644).


Dovrò esaminare più attentamente il n. 1 e testarlo. Sembra molto interessante, anche se richiede ancora una password (sicura) configurata. Il n. 3 non è completo poiché al giorno d'oggi un utente appena creato è bloccato per impostazione predefinita anche dall'accesso SSH. Non ho davvero chiesto il punto 4, ma sembra comunque molto interessante e potrei avere un uso per tale metodo, in realtà.
Pavel Šimerda,

La password complessa per root è obbligatoria ma mai utilizzata. Supponevo che sapessi implementare il n. 3; fammi sapere se hai bisogno di maggiori dettagli. Sui sistemi (Debian) è possibile accedere a un nuovo account a cui non è stata ancora definita una password, a condizione che il .ssh/authorized_keysfile contenga la chiave pubblica pertinente. questo aiuta?
roaima,

Penso di aver bisogno di un modo semplice e standard per recuperare il comportamento che si vede su Debian, ovvero che un account appena creato è bloccato solo per l'autenticazione della password e non per quella della chiave pubblica.
Pavel Šimerda,

Per l'account utente di prova che ho creato per confermare l'istruzione ssh nel mio commento precedente, vedo un singolo !nel campo della password in /etc/shadow. Secondo la pagina man, questo indica un account valido per il quale nessuna password può corrispondere.
roaima,

1
È interessante, almeno non è così ovvio , grazie.
Pavel Šimerda,

1

Sembra che tu voglia account utente reali (non root) con chiavi ssh e NOPASSWDaccesso completo tramite sudo(che è disponibile di default nella maggior parte delle distribuzioni Linux in questi giorni ed è anche banale da installare manualmente). Puoi avere password vuote per ogni account utente (che non funzionerà in remoto), quindi l'utente esegue sudo -so l'utente ~/.bash_profilecontiene semplicemente quel comando.

sudo

Aggiungi ogni utente al sudogruppo UNIX (ad esempio usermod -a -G sudo USERNAME, anche se i sistemi più vecchi avranno modi meno intuitivi per farlo; nel peggiore dei casi, modifichi /etc/groupsdirettamente).

In /etc/sudoerso /etc/sudoers.d/local, vuoi una linea come questa:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

Se si desidera l'accesso root automatico, aggiungerlo al profilo dell'utente. Per bashquello sarebbe ~/.bash_profile:

sudo -s

Ciò ti consentirà di vedere chi ha effettuato l'accesso (prova whoo last) e lascerà l'accesso /var/log/auth.log.

Login senza password

Su sistemi molto più vecchi, potresti semplicemente modificare /etc/passwd(o su sistemi leggermente più vecchi /etc/shadow) e rimuovere l'hash, quindi ad esempio bob:$1$salt$hash:12345:0:99999:7:::diventa solo bob::12345:0:99999:7:::. Questo era tutto ciò di cui avevi bisogno. Ai sistemi moderni non piace questo. Ci sono probabilmente altri modi per farlo, ma il modo che ho appena verificato è il seguente (fonte: Leo's Random Stuff ) :

Apri /etc/shadowe osserva un account con informazioni reali. Ciò includerà tre elementi delimitati da simboli di dollaro ( $). Questi rappresentano il meccanismo di hashing, quindi il sale , quindi l'hash. Nota il sale, quindi esegui questo:

openssl passwd -1 -salt SALT

(Questo utilizza MD5 come meccanismo di hashing. È una password vuota, quindi non dovresti preoccuparti.) Quando ti viene richiesta una password, premi invio. Salvare quella stringa, inclusi eventuali punti finali, e incollarla dopo i primi due punti sulla linea dell'utente /etc/shadow(ciò dovrebbe sostituire qualsiasi contenuto preesistente tra il primo e il secondo punto). (Per favore, non usare letteralmente SALTcome sale!)

SSH

La sshconfigurazione del tuo demone vive in /etc/sshd_configo /etc/ssh/sshd_config. Per una corretta sicurezza, ti consiglio di includere queste righe:

PermitRootLogin no
PermitEmptyPasswords no

Vedi il writeup di Secure Secure Shell per ulteriori misure di sicurezza che puoi aggiungere alla tua configurazione ssh per rafforzarla meglio contro sofisticati aggressori.

Ora i tuoi utenti non possono accedere tramite sshpassword vuote (questa è una misura di sicurezza necessaria). Ciò significa che possono accedere solo con i tasti ssh.

Ogni utente, per ciascuno dei propri sistemi client, dovrebbe creare una coppia di chiavi ssh, ad es

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

Questo produce una chiave privata in $HOME/.ssh/id_rsae una chiave pubblica in $HOME/.ssh/id_rsa.pub. Chiedi a quell'utente di inviarti le loro chiavi pubbliche e di aggiungerle a questo server $HOME/.ssh/authorized_keys(nota che ogni utente $HOME/.sshdeve essere in modalità 700, ad es mkdir -p ~user/.ssh && chmod 700 ~user/.ssh.).

Gli utenti che non desiderano chiavi ssh possono essere passati al sistema fisico. Lì, la loro password vuota li accederà, a quel punto potranno digitare passwddalla shell e impostare una password, permettendo così l'accesso remoto.

(In realtà ho usato questa tecnica per consentire alle persone di accedere a una raccolta di sistemi quando gestivo un dipartimento IT. Ha costretto gli utenti a usare chiavi ssh e non ho dovuto fornire loro le password. La loro iniziale ~/.bash_profileaveva due righe in fondo: passwde quindi in mv ~/.bash_profile.real ~/.bash_profilemodo da impostare una nuova password al primo accesso.)

rischi

Ti stai fidando completamente dei tuoi utenti. Non c'è niente che impedisce a un utente di scherzare con il ~/.ssh/authorized_keysfile di un altro utente e quindi alterare la tua capacità di revocare e controllare l'accesso, ma questo è inevitabile se stai dando accesso completo alla radice.

Conclusione

Ogni utente è ora un membro del gruppo sudo e ha accesso completo senza password a una shell di root. Questi utenti non dispongono di password per i loro account e possono accedere in remoto utilizzando le chiavi ssh.

Se perdi uno dei tuoi dipendenti, puoi rimuovere il suo account. Se uno dei laptop dei tuoi dipendenti viene rubato, puoi rimuovere la chiave ssh di quel laptop dal authorized_keysfile dell'utente . In caso di violazione della sicurezza, sono presenti registri che mostrano chi ha effettuato l'accesso.


La parte su sudo manca la domanda poiché riguardava esclusivamente i nuovi accessi, non il cambio di utenti. Modificata la domanda per renderla più chiara. La parte relativa all'accesso senza password presenta lo stesso comportamento errato passwd -ddella domanda, consentendo sudi passare a quell'utente senza password. La sezione dei rischi descrive due cose (pasticciare con i dati di altri utenti e ottenere l'accesso come root) la cui rimozione è il vero punto della domanda. Pertanto, mentre le singole sezioni sono ben scritte, questa non è affatto una risposta alla domanda.
Pavel Šimerda,

Supponevo che avresti aggiunto l'utente e quindi limitato l'utente.
Adam Katz,
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.