Ligue a depuração do PAM para o Syslog

Question

Eu odeio o PAM desde que surgiu.

Como faço para ativar a depuração do PAM no Debian Squeeze no nível do administrador?

Eu verifiquei todos os recursos que consegui encontrar. Google, manpages, o que for. A única coisa que ainda não tentei (simplesmente não ouso dizer, eu odeio o PAM?) É cavar na fonte da biblioteca do PAM.

Eu tentei procurar uma solução no Google, nada. O que eu encontrei até agora:

link ( /etc/pam_debug ) e link ( debug da opção nas entradas do PAM em /etc/pam.d/ ) .

Não, não funciona. Nenhuma saída PAM, nada, silêncio absoluto.

Enquanto procurava por uma solução, eu até segui os links para Pam, que são postos de gasolina aqui na Alemanha. Bem, sim, talvez em todos esses bilhões de acessos possa esconder uma pista, mas atirar em mim eu estaria morto antes de descobrir.

O descanso é FYI:

Qual problema eu tenho?

Após a atualização para o Debian Squeeze, algo ficou estranho (bem, hey, uma vez foi, uh, o que estava certo sobre o Etch .. ah, sim, Woody). Então, provavelmente não é culpa do Debian, apenas uma configuração muito complicada. Eu imediatamente tive a impressão de que tem que fazer algo com o PAM, mas eu realmente não sabia o que estava acontecendo. Eu estava completamente no escuro, sozinho, desamparado como um bebê, YKWIM. Alguns logins ssh funcionaram, outros não. Foi engraçado. Nenhuma pista em ssh -v , nenhuma pista em /var/log/* , nada. Apenas "auth succeeded" ou "auth fail", às vezes o mesmo usuário logando em paralelo conseguiu com uma sessão e falhou com a outra, ao mesmo tempo. E nada que você realmente consiga.

Depois de cavar cargas de trem de outras opções, consegui descobrir. Existe nullok e nullok_secure , um especial do Debian. Algo parafusado com /etc/securetty e dependendo do tty (que é um pouco aleatório) um login foi rejeitado ou não. REALMENTE AGRADÁVEL, ufa!

A correção foi fácil e agora tudo está bem novamente.

No entanto, isso me deixou com a pergunta, como depurar uma bagunça desse tipo no futuro. Não é a primeira vez que o PAM me deixa louca. Então eu gostaria de ver uma solução final. Final como em "resolvido", não final como em "armageddon". Obrigado.

Ah, BTW, isso reforçou minha crença de que é bom odiar o PAM desde que surgiu. Eu mencionei que eu faço?

    

Answer 1

Algumas coisas para você tentar:

Você ativou o registro de mensagens de depuração no syslog?

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

Adicione a seguinte linha:

*.debug     /var/log/debug.log

Saia com :wq! .

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

Você pode ativar a depuração para todos os módulos da seguinte forma:

touch /etc/pam_debug

OU você só pode habilitar a depuração para os módulos nos quais está interessado adicionando "debug" ao final das linhas relevantes em /etc/pam.d/system-auth ou os outros arquivos /etc/pam.d/* :

login   auth    required    pam_unix.so debug

Em seguida, as mensagens de depuração devem começar a aparecer em /var/log/debug.log . Espero que isso ajude você!

    

Answer 2

Pelo menos no CentOS 6.4, /etc/pam_debug NÃO é usado.

Se o módulo pam_warn.so estiver instalado, você pode obter alguma saída de log dessa maneira:

auth required pam_warn.so

success required pam_warn.so

Esse módulo garante que ele não interfira no processo de autenticação em nenhum momento, mas registra coisas significativas por meio do syslog.

Atualizar

Depois de examinar o código e fazer alguma compilação, descobri que (1) é possível habilitar este modo de depuração através da fonte e (2) um patch do RHEL torna o recurso praticamente inutilizável (pelo menos o módulo pam_unix) e ( 3) provavelmente é melhor corrigir o código de qualquer maneira.

Para fazer isso funcionar para o RHEL, você pode obter o Linux-PAM ... src.rpm (para qualquer versão 1.1) e alterar o arquivo de especificação da seguinte forma:

• Encontre a linha que começa com

  % configure \

e depois, adicione        --enable-debug \

• Remova a linha ou comente a linha (acima da anterior) que começa com % patch2

Em seguida, construa o rpm e instale (com força, para sobrescrever os pacotes existentes). Agora crie o arquivo /var/run/pam-debug.log:

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

Se o arquivo não existir, a saída de depuração será enviada para stderr.

• Este envio para stderr é, na minha opinião, estúpido, e é o que causa o conflito de patch. Você pode mudar esse comportamento indo até o arquivo libpam / include / security / _pam_macros.h e substituindo as 4 linhas de

  logfile = stderr;

com

return;

No build, você receberá avisos sobre instruções inacessíveis, mas elas podem ser ignoradas. Você pode fazer essa mudança em um script sed (e colocá-lo na seção% prep do RPM após os patches) ...

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

SE você fizer esse pequeno patch, poderá restaurar o% patch2, pois ele deve funcionar novamente corretamente.

    

Answer 3

Acabei de passar várias horas tentando descobrir como habilitar logs de depuração no PAM no CentOS 6.4. Embora esta questão seja para o Debian, eu ainda vou escrever como fazer isso no CentOS, na esperança de que outras pessoas não tenham que colocar o tempo que eu já tenho.

No final, a ativação dos logs de depuração no pacote pam CentOS é direta. A dificuldade decorre do fato de que envolve a recompilação do pacote. Portanto, primeiro encontre o SRPM (por exemplo, pam-1.1.1-13.el6.src.rpm ) em aqui . Pessoas que não sabem sobre a compilação de pacotes de SRPMs, podem se referir às etapas em configuração de um ambiente de criação de RPM .

Aqui está o passo principal. Abra o arquivo de especificação e adicione --enable-debug à seção %build na invocação configure . Recompilar! Reinstale o pacote recém-criado. Por fim, crie o arquivo em que os logs de depuração serão gravados.

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

Se você não criar o arquivo, muitos logs serão exibidos no terminal, o que pode não ser muito útil.

    

Answer 4

O Debian e o Ubuntu (e talvez outras distros) possuem um arquivo de log especial no qual toda a saída pam é registrada:

/var/log/auth.log

Eu tenho lutado com um problema relacionado a pam por um dia e meio, finalmente descobri sobre esse arquivo de log e me salvei da insanidade.

Aqui está uma amostra do conteúdo deste arquivo quando as coisas não saem como planejado.

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

Veja como fica quando 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)

Note que nenhuma das outras possibilidades para ativar o log de depuração de pam funcionou para mim.

    

Answer 5

Something screwed with /etc/securetty and depending on the tty (which is somewhat random) a login was rejected or not. REALLY NICE, phew!

Você poderia expandir isso um pouco?

Por página de manual do securetty :

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

O comportamento que você descreve parece muito com a segurança estar funcionando normalmente (supondo que você esteja logando como root).

Some ssh logins worked, some not.

Aqui também, pode haver restrições não-PAM, por isso pode ajudar a fornecer algumas dicas sobre como é o seu /etc/ssh/sshd_config .

Notavelmente, da sua descrição:

• se você estivesse tentando fazer login como root e falhando, isso poderia ser devido a essa linha estar presente em sshd_config : PermitRootLogin no
• se alguns usuários / grupos funcionarem e outros não, um motivo poderia ser o uso em sshd_config de AllowGroups ou AllowUsers . Uma linha de amostra pode se parecer com: %código%

É claro que é totalmente possível que o PAM faça parte do problema, mas seus principais "sintomas" soam para mim como se pudessem ser explicados por outros meios.

    

Answer 6

Asket ... Eu realmente amei sua postagem :) Eu estava lutando com coisas assim nas últimas 15 horas ... (Eu poderia ter tido uma pausa de 30 minutos)

De alguma forma eu consegui trabalhar fazendo todas as coisas que você fez, o que significa que eu tenho um / etc / pam_debug e depurar em entradas pam. MAS como no meu caso eu estava lutando com pam_mysql , eu tive que colocar outro verbose=1 após debug em minhas entradas 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

Esse "sqllog" é apenas para gravar logs no banco de dados.

Então, talvez isso ajude você só um pouquinho.

Todos nós odiamos o PAM. Boa sorte!