Accendere il debug PAM a Syslog

Odio PAM da quando è venuto fuori.

Come posso triggersre il debug PAM in Debian Squeeze al livello di amministratore?

Ho controllato each risorsa che ho potuto trovare. Google, manpages, qualunque cosa. L'unica cosa che non ho ancora provato (non mi dispiace, ho detto che odio PAM?) Sta scavando nella fonte della biblioteca di PAM.

Ho provato a google per una soluzione, 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 ( debug sull'opzione PAM in /etc/pam.d/ ).

No, non funziona. Nessun output PAM, niente, silenzio assoluto.

Mentre cercavo una soluzione ho seguito anche i collegamenti a Pam, cioè le stazioni di benzina qui in Germania. Beh, sì, forse in tutti quei miliardi di colpi potrebbe hide un indizio, ma spararmi che sarei morto prima di scoprire.

Il rest è FYI:

Che problema avevo?

Dopo l'aggiornamento a Debian Squeeze qualcosa è stato strano (beh, ehi, una volta era, uh, quello che era proprio dietro l'Etch .. ah, sì, Woody). Quindi probabilmente non è colpa di Debian, solo una confusione a lungo avvitata. Ho subito avuto l'impressione che abbia a che fare con PAM, ma non sapevo davvero cosa sta succedendo. Ero completamente al buio, lasciata da solo, impotente come un bambino, YKWIM. Alcuni ssh logins funzionavano, altri no. Era un po 'divertente. Nessun indizio in ssh -v , nessun indizio in /var/log/* , niente. Solo "auth succeeded" o "auth fail", a volte lo stesso utente che si registrava in parallelo è riuscito con una session e non è riuscito con l'altro, allo stesso tempo. E niente che puoi realmente prendere.

Dopo aver scavato treni di altre opzioni ho potuto scoprire. C'è nullok e nullok_secure , uno speciale Debian. Qualcosa avvitato con /etc/securetty e a seconda del tty (che è un po 'random) un login è stato respinto o no. REALMENTE NICE, phew!

La correzione è stata facile e tutto è nuovo bene.

Tuttavia questo mi ha lasciato la domanda, come debug una tale confusione in futuro. Non è la prima volta che PAM mi guida le noci. Quindi vorrei vedere una soluzione definitiva. Finale come in "risolto", non ultimo come in "armageddon". Grazie.

Ah, BTW, questo ha nuovamente rafforzato la mia convinzione che è bello odiare PAM fin da quando è venuto. Ho detto che lo faccio?

6 Solutions collect form web for “Accendere il debug PAM a Syslog”

Un paio di cose da provare:

Avete abilitato la logging dei messaggi di debug in syslog?

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

Aggiungere la seguente row:

 *.debug /var/log/debug.log 

Uscire con :wq! .

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

È ansible abilitare il debug di tutti i moduli come segue:

 touch /etc/pam_debug 

Oppure è ansible abilitare il debug solo per i moduli interessati aggiungendo "debug" alla fine delle righe pertinenti in /etc/pam.d/system-auth o negli altri file /etc/pam.d/* :

 login auth required pam_unix.so debug 

Poi i messaggi di debug debbano iniziare a apparire in /var/log/debug.log . Spero che questo ti aiuta!

Alless su CentOS 6.4, /etc/pam_debug NON è utilizzato.

Se il module pam_warn.so è installato, è ansible get un output di logging in questo modo:

 auth required pam_warn.so success required pam_warn.so 

ecc. Questo module assicura che non interferisca con il process di authentication in qualsiasi momento, ma registra roba significativa tramite syslog.

Aggiornare

Dopo aver esaminato il codice e facendo qualche compilazione, ho scoperto che (1) è ansible abilitare questa modalità di debug attraverso la sorgente e (2) una patch RHEL rende la funzionalità quasi inutilizzabile (alless il module pam_unix) e (3) probabilmente meglio patch il codice comunque.

Per get questo per funzionare per RHEL, è ansible get il Linux-PAM … src.rpm (per qualsiasi versione 1.1) e modificare il file di prova come segue:

  • Trova la row che inizia con

    % configure \

e dopo di esso, aggiungere –enable-debug \

  • Rimuovere la linea o commentare la linea (sopra quella precedente) che inizia con% patch2

Quindi build il rpm e installare (con forza, per sovrascrivere i pacchetti esistenti). Ora creare 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 spedire a stderr è, a mio parere, stupido ed è ciò che provoca il conflitto di patch. È ansible modificare tale comportmento entrando nel file libpam / include / security / _pam_macros.h e sostituendo le 4 righe di

    logfile = stderr;

con

 return; 

In fase di creazione, avrai avvisi di dichiarazioni irraggiungibili, ma possono essere ignorate. È ansible effettuare questa modifica in uno script sed (e inserirlo nella sezione% prep di RPM dopo le patch) …

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

Se si fa questa piccola patch, è ansible ripristinare il% patch2, in quanto dovrebbe funzionare correttamente.

Ho appena trascorso diverse ore cercando di capire come abilitare i registri di debug in PAM su CentOS 6.4. Anche se questa domanda è per Debian, continuerò a scrivere come farlo su CentOS nella speranza che altre persone non debbano mettere nel tempo che ho già.

Come è risultato in ultima analisi, l'abilitazione dei registri di debug nel pacchetto pam CentOS è semplice. La difficoltà deriva dal fatto che comport la ricompilazione del pacchetto. Quindi, per prima cosa trovare il SRPM (es. pam-1.1.1-13.el6.src.rpm ) da qui . Le persone che non conoscono la compilazione dei pacchetti da SRPM possono fare riferimento ai passaggi per l' impostazione di un ambiente di creazione RPM .

Ecco il passo principale. Aprire il file spec e aggiungere --enable-debug alla sezione %build nell'invocazione configure . Ricompilare! Reinstallare il pacchetto appena creato. Infine, crea il file in cui i registri di debug verranno scritti.

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

Se non si crea il file allora un sacco di registri volerà al terminal, che potrebbe non essere molto utile.

Debian e Ubuntu (e forse altre distros) dispongono di un file di registro speciale in cui viene registrata l'output di tutti i tipi di output:

/var/log/auth.log

Sono stato a lottare con un problema relativo a 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) 

Notare che nessuna delle altre possibilità per consentire la logging di debug di pam ha funzionato per me.

Asket … ho apprezzato molto il tuo post 🙂 Ho combattuto con cose come questo per le ultime 15 ore … (forse avrei avuto una pausa di 30 minuti però)

In qualche modo mi ha fatto funzionare 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 stavo lottando con pam_mysql , ho dovuto mettere un altro verbose=1 dopo il debug sulle mie voci:

 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 

Quello "sqllog" è solo per scrivere registri nel DB.

Quindi forse questo ti aiuta solo un po '.

Tutti odioamo PAM. In bocca al lupo!

Qualcosa avvitato con / etc / securetty e a seconda del tty (che è un po 'random) un login è stato respinto o no. REALMENTE NICE, phew!

Potresti espandersi su questo?

Per 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 comportmento che descrivi suona molto come securetty sta funzionando normalmente (supponendo che si sta effettivamente accedendo come root).

Alcuni ssh logins funzionavano, altri no.

Anche in questo caso, potrebbero essere presenti restrizioni non PAM, in modo da contribuire a fornire un'informazione su ciò che sembra il tuo /etc/ssh/sshd_config .

In particolare, dalla tua descrizione:

  • se si stava tentando di accedere come root e non riuscendo, allora ciò potrebbe essere dovuto alla presenza di questa row in sshd_config : PermitRootLogin no
  • se alcuni utenti / gruppi lavorano e altri no, una delle ragioni potrebbe essere l'utilizzo in sshd_config di AllowGroups o AllowUsers . Una row di esempio potrebbe apparire come: AllowGroups users admins

Ovviamente è ansible che PAM faccia parte della questione, ma i tuoi "sintomi" mi suono come potrebbero essere spiegati con altri mezzi.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.