Active la depuración de PAM en Syslog

34

Odio a PAM desde que surgió.

¿Cómo activo la depuración de PAM en Debian Squeeze a nivel de administrador?

He comprobado todos los recursos que pude encontrar. Google, páginas de manual, lo que sea. Lo único que no he probado todavía (simplemente no me atrevo, ¿mencioné que odio a PAM?) Está cavando en la fuente de la biblioteca de PAM.

Intenté buscar una solución en Google, nada. Lo que encontré hasta ahora:

http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion ( /etc/pam_debug) y http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html ( debugopción en entradas PAM en /etc/pam.d/).

No, no funciona. Sin salida PAM, nada, silencio absoluto.

Mientras buscaba una solución, incluso seguí enlaces a Pam, que son estaciones de servicio aquí en Alemania. Bueno, sí, tal vez en todos esos miles de millones de golpes podría ocultar una pista, pero dispararme estaría muerto antes de descubrirlo.

El descanso es para tu información:

¿Qué problema tuve?

Después de actualizar a Debian Squeeze, algo se puso extraño (bueno, oye, una vez fue, eh, lo que estaba justo sobre el Etch ... ah, sí, Woody). Entonces, probablemente no sea culpa de Debian, solo una configuración jodida de larga vida. Inmediatamente tuve la impresión de que tenía que hacer algo con PAM, pero realmente no sabía qué estaba pasando. Estaba completamente en la oscuridad, solo, indefenso como un bebé, YKWIM. Algunos inicios de sesión ssh funcionaron, otros no. Fue algo gracioso. No hay pistas ssh -v, no hay pistas /var/log/*, nada. Simplemente "autenticación exitosa" o "falla de autenticación", a veces el mismo usuario que inició sesión en paralelo tuvo éxito en una sesión y falló con la otra, al mismo tiempo. Y nada que realmente puedas conseguir.

Después de excavar cargas de trenes de otras opciones pude averiguarlo. Hay nulloky nullok_secure, un especial de Debian. Algo falló /etc/securettyy, según tty(algo aleatorio), un inicio de sesión fue rechazado o no. Realmente agradable, ¡uf!

La solución fue fácil y ahora todo vuelve a estar bien.

Sin embargo, esto me dejó con la pregunta de cómo depurar tal desorden en el futuro. No es la primera vez que PAM me vuelve loco. Entonces me gustaría ver una solución final. Final como en "resuelto", no final como en "armageddon". Gracias.

Ah, por cierto, esto nuevamente fortaleció mi creencia de que es bueno odiar a PAM desde que surgió. ¿Mencioné que lo hago?

syslog pam debug

— Tino
fuente

Aquí le mostramos cómo crear este problema usted mismo en Debian: passwd -d usery luego intente ingresar a la caja de esta manera user. La salida "contraseña fallida" en syslog no tiene nada que ver con la depuración de PAM, por lo que PAM permanece en silencio.

— Tino

Olvidé mencionar que debes configurarlo, PermitEmptyPasswords yespor /etc/ssh/sshd_configsupuesto, luego PAM genera algo como pam_unix(sshd:auth): authentication failure, pero aún nada en el canal de depuración ni ninguna pista de qué módulo PAM causó la falla.

— Tino

¿Debian tiene un /var/log/auth.logarchivo? Recientemente descubrí que Ubuntu lo tiene y registra todas las cosas relacionadas con pam allí. Ninguna de las respuestas aquí me ayudó, pero mirar /var/log/auth.logme ayudó a solucionar mi problema.

— LordOfThePigs

/var/log/auth.loges syslog. El problema no es el registro sino la depuración. Si, por ejemplo, la pila PAM falla temprano, no verá nada, porque los módulos que salen syslogno se invocan en absoluto. O algo falla y algo no, pero ambos registran exactamente las mismas líneas. Es correcto que, supongo, el 95% de todos los casos se pueden resolver mirando los registros habituales, pero el 5% no, ya que simplemente no hay rastro de lo que realmente sucede detrás de escena.

— Tino

44

+1 por odiar a PAM. ;)

— Zayne S Halsall

24

Un par de cosas para que pruebes:

¿Habilitó el registro de mensajes de depuración en syslog?

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

Agregue la siguiente línea:

*.debug     /var/log/debug.log

Salir con :wq! .

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

Puede habilitar la depuración para todos los módulos de esta manera:

touch /etc/pam_debug

O bien, puede habilitar la depuración solo para los módulos que le interesan agregando "depuración" al final de las líneas relevantes en /etc/pam.d/system-authu otro/etc/pam.d/* archivos:

login   auth    required    pam_unix.so debug

Entonces los mensajes de depuración deberían comenzar a aparecer /var/log/debug.log. ¡Espero que esto te ayude!

— sn3ak3rp1mp
fuente

Buena respuesta, pero creo que tenía depuración de syslog. Yo lo comprobaré.

— Tino

Lo revisé, lo siento, tu respuesta no es la solución. PAM aún permanece en silencio. Quizás este es un nullokespecial que solo este módulo carece de depuración. Permítanme decirlo con estas palabras: la falta de depuración en un código central tan crucial es una pesadilla peor que simplemente ser perseguido por Freddy Kruger.

— Tino

OK, bueno, ¡creo que tu respuesta es correcta! No es culpa de la respuesta lo que PAMes mudo. Así que por el momento lo acepto como "solución" hasta que PAMcapitule. Gracias.

— Tino

Todavía no veo la salida de depuración, pero de todos modos, en Ubuntu 16.04, para ver la depuración de syslog, haga: echo '* .debug /var/log/debug.log'> /etc/rsyslog.d/90-debug. conf; systemctl restart rsyslog.service

— Noam

Tenga en cuenta que necesita los permisos adecuados y la propiedad del archivo en debug.log: configúrelo igual que syslog. (Es simple y fácil de olvidar.)

— mgarey

10

Al menos en CentOS 6.4, /etc/pam_debugNO se usa.

Si el módulo pam_warn.so está instalado, puede obtener algunos resultados de registro de esta manera:

auth required pam_warn.so

success required pam_warn.so

Este módulo garantiza que no interferirá con el proceso de autenticación en ningún momento, pero registra cosas significativas a través de syslog.

Actualizar

Después de examinar el código y hacer algunas compilaciones, descubrí que (1) es posible habilitar este modo de depuración a través de la fuente, y (2) un parche RHEL hace que la característica sea casi inutilizable (al menos el módulo pam_unix) y (3) es probablemente sea mejor parchear el código de todos modos.

Para que esto funcione para RHEL, puede obtener Linux-PAM ... src.rpm (para cualquier versión 1.1) y cambiar el archivo de especificaciones de la siguiente manera:

Encuentra la línea que comienza con

% configure \

y luego, agregue --enable-debug \

Elimine la línea o comente la línea (arriba de la anterior) que comienza con% patch2

Luego construya las rpm e instálelas (con fuerza, para sobrescribir los paquetes existentes). Ahora cree el archivo /var/run/pam-debug.log:

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

Si el archivo no existe, la salida de depuración se enviará a stderr.

Este envío a stderr es, en mi opinión, estúpido, y es lo que causa el conflicto del parche. Puede cambiar ese comportamiento yendo al archivo libpam / include / security / _pam_macros.h y reemplazando las 4 líneas de

archivo de registro = stderr;

con

return;

En la compilación, recibirá advertencias sobre declaraciones inalcanzables, pero pueden ignorarse. Puede hacer este cambio en un script sed (y ponerlo en la sección% prep del RPM después de los parches) ...

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

Si hace este pequeño parche, puede restaurar el% patch2, ya que debería funcionar de nuevo correctamente.

— Oteo
fuente

Gracias. Buena pista Lo intentaré si alguna vez vuelvo a tener problemas. Así que espero que nunca ...;)

— Tino

Esto funcionó para mí, pero tenga en cuenta que si está ejecutando SELinux, necesitará establecer los contextos apropiados en /var/run/pam-debug.log (system_u: object_r: var_log_t capturó la mayoría de los mensajes). De lo contrario, gran parte de la salida de depuración se escribirá en un error estándar (o se descartará en silencio si se reparó el comportamiento de error estándar de RedHat).

— jgibson

6

Me pasó varias horas tratando de descubrir cómo habilitar los registros de depuración en PAM en CentOS 6.4. Aunque esta pregunta es para Debian, todavía escribiré cómo hacerlo en CentOS con la esperanza de que otras personas no tengan que dedicar el tiempo que ya tengo.

Al final resultó que, habilitar registros de depuración en el pampaquete de CentOS es sencillo. La dificultad deriva del hecho de que implica la recompilación del paquete. Entonces, primero encuentre el SRPM (por ejemplo pam-1.1.1-13.el6.src.rpm) desde aquí . Las personas que no conocen la compilación de paquetes de SRPM pueden consultar los pasos para configurar un entorno de compilación de RPM .

Aquí está el paso principal. Abra el archivo de especificaciones y agréguelo --enable-debuga la %buildsección en la configureinvocación. Recompilar! Vuelva a instalar el paquete recién creado. Finalmente, cree el archivo donde se escribirán los registros de depuración.

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

Si no crea el archivo, volarán muchos registros en la terminal, lo que podría no ser muy útil.

— pdp
fuente

Otros sabores de Unix o cualquier cosa que se atreva a usar PAM también son bienvenidos;)

— Tino

5

Debian y Ubuntu (y tal vez otras distribuciones) tienen un archivo de registro especial en el que se registran todos los resultados de pam:

/var/log/auth.log

He estado luchando con un problema relacionado con pam durante un día y medio, finalmente descubrí este archivo de registro y me salvé de la locura.

Aquí hay una muestra del contenido de este archivo cuando las cosas no salen según lo planeado.

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

Así es como se ve cuando funciona:

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)

Tenga en cuenta que ninguna de las otras posibilidades para habilitar el registro de depuración de pam funcionó para mí.

— LordOfThePigs
fuente

1

Tenga en cuenta que todas las líneas como en pam_*realidad están relacionadas con PAM. Las otras líneas son generadas por las herramientas de todos modos, independientemente de si usan PAM o no. Esto significa: si PAM niega, por alguna razón, es realmente difícil encontrar la causa real, si está en PAM. Las líneas que no son PAM no son útiles (ya que el problema se encuentra en PAM) y las líneas PAM a menudo tampoco son útiles, ya que a menudo son demasiado silenciosas. Con la presencia de muchos módulos PAM, realmente le resulta difícil adivinar qué módulo podría ser el culpable, y mucho menos descubrir cómo habilitar la depuración, ya que esto es diferente para cada uno.

— Tino

0

Algo se atornilló con / etc / securetty y, dependiendo del tty (que es algo aleatorio), se rechazó o no un inicio de sesión. Realmente agradable, ¡uf!

¿Podrías ampliar eso un poco?

Por la página de manual de securetty :

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

El comportamiento que describe suena bastante a que securetty funciona normalmente (suponiendo que realmente esté iniciando sesión como root).

Algunos inicios de sesión ssh funcionaron, otros no.

Aquí también, puede haber restricciones que no sean PAM, por lo que puede ser útil proporcionar una idea de cómo se /etc/ssh/sshd_configve.

Notablemente, de su descripción:

si intentaba iniciar sesión como root y fallaba, eso podría deberse a que esta línea estaba presente en sshd_config:PermitRootLogin no
Si algunos usuarios / grupos funcionan, y otros no, una razón podría ser el uso sshd_configde AllowGroupso AllowUsers. Una línea de muestra podría verse así: AllowGroups users admins

Por supuesto, es totalmente posible que PAM sea parte del problema, pero sus principales "síntomas" me parecen que podrían explicarse por otros medios.

— iwaseatenbyagrue
fuente

-1

Asket ... Realmente me encantó tu publicación :) Estuve peleando con cosas como esta durante las últimas 15 horas ... (aunque podría haber tenido un descanso de 30 minutos)

De alguna manera lo puse a trabajar haciendo todo lo que hiciste, lo que significa que tengo un / etc / pam_debug y depurar en las entradas de pam. PERO como en mi caso con el que estaba luchando pam_mysql, tuve que poner otro verbose=1después debugen mis entradas de 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

Ese "sqllog" es solo para escribir registros en la base de datos.

Entonces, tal vez esto te ayude un poco.

Todos odiamos a PAM. ¡Buena suerte!

— Alex
fuente

1

Gracias por la pista, pero desafortunadamente esto no ayuda:pam_unix(sshd:auth): unrecognized option [verbose=1]

— Tino