Ativar a depuração do PAM no Syslog

34

Eu odeio o PAM desde que surgiu.

Como ativo a depuração do PAM no Debian Squeeze no nível de administrador?

Eu verifiquei todos os recursos que consegui encontrar. Google, páginas de manual, tanto faz. A única coisa que ainda não tentei (simplesmente não me atrevo, mencionei que odeio o PAM?) É procurar na fonte da biblioteca do PAM.

Eu tentei pesquisar no google por uma solução, nada. O que eu encontrei até agora:

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 ( debugopção nas entradas do PAM in /etc/pam.d/).

Não, não funciona. Sem 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 atire em mim, eu estaria morto antes de descobrir.

O resto é FYI:

Que problema eu tive?

Depois de atualizar para o Debian Squeeze, algo ficou estranho (bem, ei, era uma vez o que estava certo sobre o Etch ... ah, sim, Woody). Portanto, provavelmente não é culpa do Debian, apenas uma configuração complicada e duradoura. Imediatamente tive a impressão de que tem a ver com o PAM, mas realmente não sabia o que estava acontecendo. Eu estava completamente no escuro, deixado sozinho, indefeso como um bebê, YKWIM. Alguns logins ssh funcionaram, outros não. Foi meio engraçado. Nenhuma pista ssh -v, nenhuma pista /var/log/*, nada. Apenas "autenticação bem-sucedida" ou "falha na autenticação", às vezes o mesmo usuário que efetuou login paralelamente teve sucesso em uma sessão e falhou na outra, ao mesmo tempo. E nada que você realmente possa se apossar.

Depois de cavar cargas de trem de outras opções, pude descobrir. Existe nulloke nullok_secure, um especial do Debian. Algo estragado /etc/securettye dependendo do tty(que é um tanto aleatório) um login foi rejeitado ou não. REALMENTE AGRADÁVEL, ufa!

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

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

Ah, BTW, isso novamente fortaleceu minha crença de que é bom odiar o PAM desde que surgiu. Eu mencionei isso?

syslog pam debug

— Tino
fonte

Aqui está como criar esse problema você mesmo no Debian: passwd -d usere tente ssh dentro da caixa como esta user. A saída "senha com falha" no syslog não tem nada a ver com a depuração do PAM, portanto o PAM permanece silencioso.

— Tino

Eu esqueci de mencionar que você deve definir PermitEmptyPasswords yesem /etc/ssh/sshd_configclaro, em seguida, PAM saídas algo como pam_unix(sshd:auth): authentication failure, mas ainda nada para o canal de depuração nem qualquer indício qual módulo PAM causou a falha.

— Tino

O debian tem um /var/log/auth.logarquivo? Descobri recentemente que o Ubuntu o possui e registra todas as coisas relacionadas ao pam por lá. Nenhuma das respostas aqui me ajudou, mas procurar /var/log/auth.logme ajudou a resolver meu problema.

— LordOfThePigs

/var/log/auth.logé syslog. O problema não é log, mas depuração. Se, por exemplo, a pilha PAM falhar mais cedo, você não verá nada, porque os módulos para os quais a saída syslognão é chamada. Ou algo falha e algo não, mas ambos registram exatamente as mesmas linhas. É correto que, suponho, 95% de todos os casos possam ser resolvidos examinando os logs usuais, mas 5% não, pois simplesmente não há vestígios do que realmente acontece nos bastidores.

— Tino

4

+1 por odiar o PAM. ;)

— Zayne S Halsall

24

Algumas coisas para você tentar:

Você ativou o log 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, assim:

touch /etc/pam_debug

OU você pode ativar a depuração apenas para os módulos nos quais deseja adicionar "debug" ao final das linhas relevantes /etc/pam.d/system-authou nos outros /etc/pam.d/*arquivos:

login   auth    required    pam_unix.so debug

As mensagens de depuração devem começar a aparecer /var/log/debug.log. Espero que isto te ajude!

— sn3ak3rp1mp
fonte

Boa resposta, mas acho que estava com a depuração do syslog. Vou dar uma olhada.

— Tino

Eu verifiquei, desculpe, sua resposta não é a solução. O PAM ainda permanece em silêncio. Talvez seja um nullokespecial que apenas este módulo esteja sem depuração. Deixe-me dizer com estas palavras: a falta de depuração em um pedaço de código central tão crucial é um pesadelo pior do que ser assombrado por Freddy Kruger.

— Tino

OK, bem, acho que você responde com precisão está correto! Não é culpa da resposta que PAMé muda. Por enquanto, eu a aceito como "solução" até PAMcapitular. Obrigado.

— Tino

Ainda não vejo a saída de depuração, mas, de qualquer forma, no Ubuntu 16.04, para visualizar a depuração do syslog, faça: echo '* .debug /var/log/debug.log'> /etc/rsyslog.d/90-debug. conf; systemctl restart rsyslog.service

— Noam

Observe que você precisa de permissões e propriedade de arquivo adequadas no debug.log - defina-o da mesma forma que o syslog. (É simples e fácil de esquecer.)

— mgarey

10

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

Se o módulo pam_warn.so estiver instalado, você poderá obter alguns resultados de log desta maneira:

auth required pam_warn.so

success required pam_warn.so

etc. Este módulo garante que não irá interferir com o processo de autenticação a qualquer momento, mas registra coisas significativas via syslog.

Atualizar

Após examinar o código e fazer algumas compilações, descobri que (1) é possível ativar esse modo de depuração pela fonte e (2) um patch RHEL torna o recurso quase inutilizável (pelo menos o módulo pam_unix) e (3) é provavelmente é melhor corrigir o código de qualquer maneira.

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

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, crie o rpm e instale (com força, para substituir 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 o stderr.

Esse envio ao stderr é, na minha opinião, estúpido e é o que causa o conflito do patch. Você pode alterar esse comportamento acessando o arquivo libpam / include / security / _pam_macros.h e substituindo as 4 linhas de

arquivo de log = stderr;

com

return;

Na construção, você recebe avisos sobre instruções inacessíveis, mas elas podem ser ignoradas. Você pode fazer essa alteração 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.

— Otheus
fonte

Obrigado. Boa dica. Vou tentar se tiver problemas novamente. Portanto, esperamos que nunca mais ..;)

— Tino

Isso funcionou para mim, mas observe que, se você estiver executando o SELinux, precisará definir os contextos apropriados em /var/run/pam-debug.log (system_u: object_r: var_log_t capturou a maioria das mensagens). Caso contrário, grande parte da saída de depuração será gravada no erro padrão (ou descartada silenciosamente se você corrigir o comportamento de erro padrão do RedHat).

— Jgibson

6

Passei várias horas tentando descobrir como habilitar logs de depuração no PAM no CentOS 6.4. Embora essa pergunta seja para o Debian, ainda vou escrever como fazê-lo no CentOS, na esperança de que outras pessoas não tenham que gastar o tempo que eu já tenho.

Como se viu, a ativação dos logs de depuração no pampacote do CentOS é simples. A dificuldade decorre do fato de envolver recompilação do pacote. Então, primeiro encontre o SRPM (por exemplo pam-1.1.1-13.el6.src.rpm) a partir daqui . Pessoas que não sabem sobre a compilação de pacotes a partir de SRPMs, podem consultar as etapas de configuração de um ambiente de criação de RPM .

Aqui está o passo principal. Abra o arquivo de especificações e adicione --enable-debugà %buildseção na configurechamada. Recompile! 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.

— pdp
fonte

Outros sabores de Unix ou qualquer coisa que se atreve a usar PAM é muito bem-vindo, também;)

— Tino

5

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

/var/log/auth.log

Estou lutando com um problema relacionado ao pam há um dia e meio, finalmente descobri esse arquivo de log e me salvei da loucura.

Aqui está uma amostra do conteúdo desse 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)

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

— LordOfThePigs
fonte

11

Observe que todas as linhas como pam_*realmente são PAM realated. As outras linhas são produzidas pelas ferramentas de qualquer maneira, independentemente de usarem PAM ou não. Isso significa: Se o PAM negar, por qualquer motivo, é realmente difícil encontrar a causa real, se estiver no PAM. As linhas que não são do PAM não são úteis (pois o problema está no PAM) e as linhas do PAM também não são úteis, pois geralmente são silenciosas demais. Com a presença de muitos módulos PAM, é realmente difícil adivinhar qual módulo pode ser o culpado, e muito menos descobrir como habilitar a depuração, pois isso é diferente para cada um.

— Tino

0

Algo estragou o / etc / securetty e, dependendo do tty (que é um tanto aleatório), um login foi rejeitado ou não. REALMENTE AGRADÁVEL, ufa!

Você poderia expandir um pouco isso?

Por página de manual da 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 bastante com o fato de a segurança estar funcionando normalmente (supondo que você esteja realmente fazendo logon como root).

Alguns logins ssh funcionaram, outros não.

Também aqui pode haver restrições que não são do PAM, portanto, pode ajudar a fornecer algumas dicas sobre como é sua /etc/ssh/sshd_configaparência.

Notavelmente, da sua descrição:

se você estava tentando fazer login como root e falhou, isso pode ser devido a esta linha estar presente em sshd_config:PermitRootLogin no
se alguns usuários / grupos funcionarem e outros não, uma razão pode ser o uso sshd_configde AllowGroupsou AllowUsers. Uma linha de amostra pode se parecer com: AllowGroups users admins

É claro que é perfeitamente possível que o PAM faça parte do problema, mas seus principais 'sintomas' parecem-me que poderiam ser explicados por outros meios.

— iwaseatenbyagrue
fonte

-1

Asket ... Eu realmente amei o seu post :) Eu estava lutando com coisas desse tipo nas últimas 15 horas ... (Eu poderia ter feito uma pausa de 30 minutos)

De alguma forma, consegui fazer tudo o que você fez, o que significa que eu tenho um / etc / pam_debug e depuro nas entradas do pam. MAS, como no meu caso, eu estava lutando pam_mysql, tive que colocar outro verbose=1depois debugnas minhas entradas no 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" serve apenas para gravar logs no banco de dados.

Então, talvez isso ajude você um pouco.

Todos nós odiamos o PAM. Boa sorte!

— Alex
fonte

11

Obrigado pela dica, mas infelizmente isso não ajuda:pam_unix(sshd:auth): unrecognized option [verbose=1]

— Tino