MkWikiEnSysOp: 3 revisions imported

2018-06-28T17:19:35Z

3 revisions imported

New page

'''General hint:''' Shells like bash record every command you enter. testsaslauthd requires the password to be supplied via a command line argument which is a severe security issue (see [https://bugzilla.redhat.com/show_bug.cgi?id=469589 Bug 469589 in Red Hat Bugzilla] for example). In bash this can be circumvented by putting a space in front of the command (this prevents bash from saving the command in the history).

I've setup a mail system (Debian Wheezy, postfix, courier, authentication data stored in a mysql database; postfix should use SASL to authenticate) and my main problem was that SASL didn't work. After searching around in the WWW, I found there's a command "testsaslauthd" which can be used to test if SASL works at all (if it doesn't, Postfix will fail as well). If I issued

testsaslauthd -u user@domain -p password -f /var/spool/postfix/var/run/saslauthd/mux -s smtp

I just got a

0: NO "authentication failed"

which wasn't very helpful. Then I tried if authentication against PAM would work which can be tested by ommiting the "-s" parameter and specifying "-u" accordingly (without the "@domain"):

testsaslauthd -u user -p password -f /var/spool/postfix/var/run/saslauthd/mux

That worked like a charm and gave me back

0: OK "Success."

The file "/var/spool/postfix/var/run/saslauthd/mux" is in use by /usr/sbin/saslauthd. Occasionally, <code>service saslauthd restart</code> (System V) or <code>systemctl restart saslauthd</code> (SystemD) might help in case of problems.

The log files syslog and mail.log didn't contain any information what was going wrong. After some hours of searching around I found out that the cause was a very little one. I watched the messages in /var/log/auth.log and found

Sep 29 19:36:39 v22014092384920520 saslauthd[13364]: PAM unable to dlopen(pam_mysql.so): /lib/security/pam_mysql.so: cannot open shared object file: No such file or directory
Sep 29 19:36:39 v22014092384920520 saslauthd[13364]: PAM adding faulty module: pam_mysql.so
Sep 29 19:36:39 v22014092384920520 saslauthd[13364]: DEBUG: auth_pam: pam_authenticate failed: Module is unknown
Sep 29 19:36:39 v22014092384920520 saslauthd[13364]: do_auth : auth failure: [user=user@domain] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

The module that should be used is specified in /etc/pam.d/smtp. I then connected to a system where all this magic works and issued

dpkg -S /lib/security/pam_mysql.so

which printed

libpam-mysql: /lib/security/pam_mysql.so

By simply typing

apt-get install libpam-mysql

the problem was solved and testsaslauthd returned OK.

The second problem was that postfix denied any attempts to login via SMTP. First it's interesting how the login works: The username and password are being encoded in BASE64 and transmitted to the server. This encoding can be done using bash:

echo -ne '\000user@domain\000p@$$w0rd' | openssl base64

which prints a string like "AHVzZXJAZG9tYWluAHBAJCR3MHJk".

The method to check if the server accepts your credentials is by talking SMTP to the server:

openssl s_client -connect localhost:25 -starttls smtp

First say "helo hostname", then login with

auth plain (BASE64 encoding of username/password)

If it says

235 2.7.0 Authentication successful

you're lucky and you could try to send mail with

mail from: <user@domain>
rcpt to: <user@domain>
data
Subject: Some subject
(empty line)
Some text
(empty line)
.

If something goes wrong, postfix replies:

535 5.7.8 Error: authentication failed: authentication failure

or with some other error like "generic failure" or "no mechanism available".

[[Category:Linux]]

Postfix with SASL authentication against MySQL - Revision history

MkWikiEnSysOp: 3 revisions imported