Attiva il debug PAM su Syslog

Odio la PAM da quando è nata.

Come posso attivare il debug PAM in Debian Squeeze a livello di amministratore?

Ho controllato tutte le risorse che sono riuscito a trovare. Google, pagine man, qualunque cosa. L'unica cosa che non ho ancora provato (semplicemente non oso, ho detto che odio il PAM?) È scavare nella fonte della biblioteca del PAM.

Ho provato a cercare una soluzione su Google, niente. Quello che ho trovato finora:

http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion ( /etc/pam_debug) e http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html ( debugopzione su voci PAM in /etc/pam.d/).

No, non funziona. Nessuna uscita PAM, niente, silenzio assoluto.

Durante la ricerca di una soluzione ho anche seguito i collegamenti a Pam, che sono stazioni di servizio qui in Germania. Beh, sì, forse in tutti quei miliardi di colpi potrebbe nascondere un indizio, ma spararmi sarei morto prima che lo scoprissi.

Il resto è FYI:

Che problema ho avuto?

Dopo l'aggiornamento a Debian Squeeze qualcosa è diventato strano (beh, ehi, una volta era, uh, quello che era giusto sopra l'Etch .. ah, sì, Woody). Quindi probabilmente non è colpa di Debian, solo una configurazione rovinata da lungo tempo. Ho avuto immediatamente l'impressione che dovesse fare qualcosa con PAM, ma non sapevo davvero cosa stesse succedendo. Ero completamente al buio, lasciato solo, indifeso da bambino, YKWIM. Alcuni accessi ssh hanno funzionato, altri no. È stato divertente. Nessun indizio dentro ssh -v, nessun indizio dentro /var/log/*, niente. Solo "auth successed" o "auth fail", a volte lo stesso utente che ha effettuato l'accesso in parallelo è riuscito in parallelo con una sessione e ha fallito con l'altra, contemporaneamente. E niente di cui tu possa davvero afferrare.

Dopo aver scavato carichi di treni di altre opzioni sono stato in grado di scoprirlo. C'è nulloke nullok_secure, uno speciale Debian. Qualcosa è andato storto /etc/securettye in base al tty(che è in qualche modo casuale) un accesso è stato rifiutato o meno. DAVVERO PIACEVOLE, accidenti!

La correzione è stata semplice e ora tutto è di nuovo a posto.

Tuttavia, questo mi ha lasciato la domanda: come eseguire il debug di un tale casino in futuro. Non è la prima volta che PAM mi fa impazzire. Quindi vorrei vedere una soluzione finale. Finale come in "risolto", non finale come in "armageddon". Grazie.

Ah, a proposito, questo ha rafforzato ancora una volta la mia convinzione che sia bello odiare la PAM da quando è nata. Ho già detto che lo faccio?

Un paio di cose da provare:

Hai abilitato la registrazione dei messaggi di debug in syslog?

cp /etc/syslog.conf /etc/syslog.conf.original
vi /etc/syslog.conf

Aggiungi la seguente riga:

*.debug     /var/log/debug.log

Esci con :wq!.

touch /var/log/debug.log
service syslog restart

È possibile abilitare il debug per tutti i moduli in questo modo:

touch /etc/pam_debug

OPPURE puoi abilitare il debug solo per i moduli che ti interessano aggiungendo "debug" alla fine delle righe pertinenti /etc/pam.d/system-autho degli altri /etc/pam.d/*file:

login   auth    required    pam_unix.so debug

Quindi i messaggi di debug dovrebbero iniziare a comparire in /var/log/debug.log. Spero che questo ti aiuti!

Almeno su CentOS 6.4, /etc/pam_debugNON viene utilizzato.

Se il modulo pam_warn.so è installato, è possibile ottenere un output di registrazione in questo modo:

auth required pam_warn.so

success required pam_warn.so

ecc. Questo modulo garantisce che non interferirà in alcun modo con il processo di autenticazione, ma registra cose significative tramite syslog.

Aggiornare

Dopo aver esaminato il codice e aver fatto un po 'di compilazione, ho scoperto che (1) è possibile abilitare questa modalità di debug attraverso il sorgente e (2) una patch RHEL rende la funzione quasi inutilizzabile (almeno il modulo pam_unix) e (3) è probabilmente è meglio patchare il codice comunque.

Per farlo funzionare per RHEL, è possibile ottenere Linux-PAM ... src.rpm (per qualsiasi versione 1.1) e modificare il file delle specifiche come segue:

• Trova la riga che inizia con

  % configure \

e dopo, aggiungi --enable-debug \

• Rimuovi la riga o commenta la riga (sopra la precedente) che inizia con% patch2

Quindi compilare l'rpm e installarlo (con forza, per sovrascrivere i pacchetti esistenti). Ora crea il file /var/run/pam-debug.log:

install -m 622 /dev/null /var/run/pam-debug.log

Se il file non esiste, l'output di debug verrà inviato a stderr.

• Questo invio a stderr è, a mio avviso, stupido, ed è ciò che causa il conflitto di patch. Puoi cambiare quel comportamento andando nel file libpam / include / security / _pam_macros.h e sostituendo le 4 righe di

  logfile = stderr;

con

return;

Al momento della creazione, riceverai avvisi su dichiarazioni non raggiungibili, ma possono essere ignorate. È possibile apportare questa modifica in uno script sed (e inserirlo nella sezione% prep dell'RPM dopo le patch) ...

sed -i 's/logfile = stderr;$/return;/' libpam/include/security/_pam_macros.h

Se esegui questa piccola patch, puoi ripristinare% patch2, poiché dovrebbe funzionare di nuovo correttamente.

Mi è capitato di passare diverse ore a cercare di scoprire come abilitare i log di debug in PAM su CentOS 6.4. Sebbene questa domanda sia per Debian, scriverò comunque come farlo su CentOS nella speranza che altre persone non debbano impegnare il tempo che ho già.

Come si è scoperto, abilitare i log di debug nel pampacchetto CentOS è semplice. La difficoltà deriva dal fatto che comporta la ricompilazione del pacchetto. Quindi, prima trova l'SRPM (ad es. pam-1.1.1-13.el6.src.rpm) Da qui . Le persone che non conoscono la compilazione di pacchetti da SRPM possono fare riferimento ai passaggi per la configurazione di un ambiente di build RPM .

Ecco il passo principale. Apri il file delle specifiche e aggiungi --enable-debugalla %buildsezione configurenell'invocazione. Riconversione! Reinstallare il pacchetto appena creato. Infine, crea il file in cui verranno scritti i log di debug.

$ sudo touch /var/run/pam-debug.log

Se non si crea il file, al terminale passeranno molti registri, il che potrebbe non essere molto utile.

Debian e Ubuntu (e forse altre distro) hanno un file di registro speciale in cui è registrato tutto l'output di pam:

/var/log/auth.log

Ho lottato con un problema di pam per un giorno e mezzo, finalmente ho scoperto questo file di registro e mi sono salvato dalla follia.

Ecco un esempio del contenuto di questo file quando le cose non vanno come previsto.

Jul 10 09:31:14 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user_lookup: could not open database `/etc/vsftpd_users.db': No such file or directory
Jul 10 09:36:20 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log

Ecco come appare quando funziona:

Jul 10 09:47:00 vagrant-ubuntu-trusty-64 sshd[5222]: pam_unix(sshd:session): session closed for user vagrant
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: Accepted publickey for vagrant from 10.0.2.2 port 54652 ssh2: RSA dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: pam_unix(sshd:session): session opened for user vagrant by (uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session closed for user root
Jul 10 09:51:41 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user 'foo' granted access
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)

Nota che nessuna delle altre possibilità per abilitare la registrazione debug di pam ha funzionato per me.

Qualcosa ha rovinato con / etc / securetty e in base al tty (che è in qualche modo casuale) un login è stato rifiutato o meno. DAVVERO PIACEVOLE, accidenti!

Potresti ampliarlo un po '?

Per la manpage di securetty :

the file contains the device names of terminal lines (one per line, without leading /dev/) on which root is allowed to login.

Il comportamento che descrivi suona molto simile a quello di securetty funziona normalmente (supponendo che tu stia effettivamente accedendo come root).

Alcuni accessi SSH hanno funzionato, altri no.

Anche qui, potrebbero esserci restrizioni non PAM, quindi potrebbe aiutare a fornire alcune informazioni su come si /etc/ssh/sshd_configpresenta.

In particolare, dalla tua descrizione:

• se si stava tentando di accedere come root e non ci riuscisse, ciò potrebbe essere dovuto al fatto che questa linea è presente in sshd_config:PermitRootLogin no
• se alcuni utenti / gruppi funzionano e altri no, uno dei motivi potrebbe essere l'uso sshd_configdi AllowGroupso AllowUsers. Una linea di esempio potrebbe apparire come: AllowGroups users admins

Ovviamente è del tutto possibile che PAM faccia parte del problema, ma i tuoi principali "sintomi" mi sembrano come se potessero essere spiegati con altri mezzi.

Asket ... Ho adorato il tuo post :) Ho combattuto con cose del genere nelle ultime 15 ore ... (Avrei potuto fare una pausa di 30 minuti)

In qualche modo ho funzionato facendo tutte le cose che hai fatto, il che significa che ho un / etc / pam_debug e debug su voci pam. MA come nel mio caso con cui stavo lottando pam_mysql, ho dovuto aggiungere un altro verbose=1dopo le debugmie voci di pam:

mailsystem:~# cat /etc/pam.d/smtp

auth required pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=time

account sufficient pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=times

Quel "sqllog" serve solo a scrivere i log nel DB.

Quindi forse questo ti aiuta solo un po '.

Odiamo tutti PAM. In bocca al lupo!