info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Userauthentifizierung von Exim via Courier funktioniert nicht mehr nach Update
3 views
Skip to first unread message
Sebastian Suchanek
Apr 20, 2021, 6:06:40 AM4/20/21
to
Hallo NG!
[Disclaimer: Dieses Problem habe ich auch auf der deutschen
Debian-User-Mailingliste geschildert. Wenn sich eine Lösung findet,
werde ich eine Zusammenfassung auch an der jeweils anderen Stelle posten.]
Ausgangspunkt ist ein Server, der unter Debian Stretch läuft. Darauf
läuft u.a. Exim als MTA und Courier-IMAP, wobei bei beiden die
Userauthentifizierung über Courier-Authdaemon läuft. Dieses System lief
über Jahre problemlos bis zum jüngsten Update. (Wohlgemerkt
Sicherheitsupdate, kein Dist-Upgrade!) Im dringenden Verdacht habe ich
dabei das Paket courier-authdaemon bzw. die dazugehörigen Pakete - doch
der Reihe nach:
Nach dem Update, das neben courier-authdaemon auch die Pakete
courier-authlib-userdb, courier-authlib sowie diverse ClamAV-und
Phython-2.7-Pakete umfasste,hatte ich zunächst Fehlereinträge der
folgenden Art im Exim Logfile:
| 2021-04-20 06:42:39 plain authenticator failed for xxx ([yyy]) [zzz]:
435 Unable to authenticate at present (set_id=sebastian): failed to
connect to socket /var/run/courier/authdaemon/socket: Permission denied
("xxx", "yyy" und "zzz" sind jeweils anonymisierte Hostnamen und
IP-Adressen.)
Tatsächlich - der Socket hat zwar noch "globale" Zugriffsrechte...
| # ls -la /var/run/courier/authdaemon/socket
| srwxrwxrwx 1 root root 0 Apr 20 06:42 /var/run/courier/authdaemon/socket
| #
...das Verzeichnis obendrüber jedoch nicht (mehr):
| # ls -la /var/run/courier/
| total 8
| drwxrwxr-x 3 root courier 140 Apr 20 06:42 .
| drwxr-xr-x 41 root root 1480 Apr 20 06:36 ..
| drwxr-x--- 2 courier courier 100 Apr 20 06:42 authdaemon
| -rw-r--r-- 1 root root 6 Apr 20 06:42 imapd.pid
| -rw------- 1 root root 0 Mar 15 2020 imapd.pid.lock
| -rw-r--r-- 1 root root 6 Apr 20 06:42 imapd-ssl.pid
| -rw------- 1 root root 0 Mar 15 2020 imapd-ssl.pid.lock
| #
Das habe ich zunächst einmal hemdsärmelig so gelöst, dass ich den
Debian-User mit in die courier-Gruppe gepackt habe:
| # adduser Debian-exim courier
(Falls es dafür bessere Lösungen geben sollte: gerne her damit.)
Mitglied der "daemon"-Gruppe, wie man in älteren WWW-Fundstücken als
Lösungsvorschlag zu diesen Fehlermeldungen findet, war Debian-exim schon
vorher.
Das hat das Exim-Problem jedoch nur verlagert, nicht gelöst. Die
Fehlermeldungen im Exim-Logfile lauten jetzt:
| 2021-04-20 06:57:41 plain authenticator failed for xxx ([yyy]) [zzz]:
535 Incorrect authentication data (set_id=sebastian)
| 2021-04-20 06:57:44 login authenticator failed for xxx ([yyy]) [zzz]:
535 Incorrect authentication data (set_id=sebastian)
authtest sagt jedoch, dass alles in bester Ordnung wäre und auch das
Abrufen von Mail via courier-imap-ssal vom selben Server, der sich
natürlich auch gegen denselben courier-authdaemon authentifiziert,
klappt problemlos:
| # authtest sebastian $PASSWORT
| Authentication succeeded.
|
| Authenticated: sebastian (system username: sebastian)
| Home Directory: /home/sebastian
| Maildir: (none)
| Quota: (none)
| Encrypted Password: $HASH
| Cleartext Password: $PASSWORT
| Options: (none)
| #
(Statt "$PASSWORT" und "$HASH" stehen im Original natürlich das richtige
Passwort und ein echter Hash.)
In /var/log/auth.log steht dazu auch nur:
| Apr 20 06:57:39 tigersclaw authdaemond: pam_unix(exim:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
user=sebastian
| Apr 20 06:57:41 tigersclaw authdaemond: pam_unix(exim:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
user=sebastian
Und hier noch der Auszug der Authenticators aus meiner Exim-Config:
| [...]
| plain:
| driver = plaintext
| public_name = PLAIN
| client_send =
"^${extract{2}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}\
|
^${extract{3}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}"
| server_condition = \
| ${if eq {${readsocket{/var/run/courier/authdaemon/socket}\
| {AUTH
${strlen:exim\nlogin\n$2\n$3\n}\nexim\nlogin\n$2\n$3\n}}}{FAIL\n}{no}{yes}}
| server_set_id = $2
|
| login:
| driver = plaintext
| public_name = LOGIN
| client_send = ":
${extract{2}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}
\
| :
${extract{3}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}"
| server_prompts = Username:: : Password::
| server_condition = ${if eq
{${readsocket{/var/run/courier/authdaemon/socket} \
| {AUTH
${strlen:exim\nlogin\n$1\n$2\n}\nexim\nlogin\n$1\n$2\n}}}{FAIL\n}{no}{yes}}
| server_set_id = $1
| server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
| [...]
Wie gesagt: bis vor dem Update der courier-authdaemon-Pakete hat das
Setup einwandfrei funktioniert, aber jetzt gehen mir gerade die Ideen
aus, wo man noch suchen bzw. schrauben könnte. Exim und
courier-authdaemon habe ich inzwischen auch schon jeweils mehrfach neu
gestartet.
Lange Rede, kurzer Sinn: wie kriege ich Exim wieder dazu, gegen
courier-authdaemon zu authentifiziern?
Tschüs,
Sebastian
[Disclaimer: Dieses Problem habe ich auch auf der deutschen
Debian-User-Mailingliste geschildert. Wenn sich eine Lösung findet,
werde ich eine Zusammenfassung auch an der jeweils anderen Stelle posten.]
Ausgangspunkt ist ein Server, der unter Debian Stretch läuft. Darauf
läuft u.a. Exim als MTA und Courier-IMAP, wobei bei beiden die
Userauthentifizierung über Courier-Authdaemon läuft. Dieses System lief
über Jahre problemlos bis zum jüngsten Update. (Wohlgemerkt
Sicherheitsupdate, kein Dist-Upgrade!) Im dringenden Verdacht habe ich
dabei das Paket courier-authdaemon bzw. die dazugehörigen Pakete - doch
der Reihe nach:
Nach dem Update, das neben courier-authdaemon auch die Pakete
courier-authlib-userdb, courier-authlib sowie diverse ClamAV-und
Phython-2.7-Pakete umfasste,hatte ich zunächst Fehlereinträge der
folgenden Art im Exim Logfile:
| 2021-04-20 06:42:39 plain authenticator failed for xxx ([yyy]) [zzz]:
435 Unable to authenticate at present (set_id=sebastian): failed to
connect to socket /var/run/courier/authdaemon/socket: Permission denied
("xxx", "yyy" und "zzz" sind jeweils anonymisierte Hostnamen und
IP-Adressen.)
Tatsächlich - der Socket hat zwar noch "globale" Zugriffsrechte...
| # ls -la /var/run/courier/authdaemon/socket
| srwxrwxrwx 1 root root 0 Apr 20 06:42 /var/run/courier/authdaemon/socket
| #
...das Verzeichnis obendrüber jedoch nicht (mehr):
| # ls -la /var/run/courier/
| total 8
| drwxrwxr-x 3 root courier 140 Apr 20 06:42 .
| drwxr-xr-x 41 root root 1480 Apr 20 06:36 ..
| drwxr-x--- 2 courier courier 100 Apr 20 06:42 authdaemon
| -rw-r--r-- 1 root root 6 Apr 20 06:42 imapd.pid
| -rw------- 1 root root 0 Mar 15 2020 imapd.pid.lock
| -rw-r--r-- 1 root root 6 Apr 20 06:42 imapd-ssl.pid
| -rw------- 1 root root 0 Mar 15 2020 imapd-ssl.pid.lock
| #
Das habe ich zunächst einmal hemdsärmelig so gelöst, dass ich den
Debian-User mit in die courier-Gruppe gepackt habe:
| # adduser Debian-exim courier
(Falls es dafür bessere Lösungen geben sollte: gerne her damit.)
Mitglied der "daemon"-Gruppe, wie man in älteren WWW-Fundstücken als
Lösungsvorschlag zu diesen Fehlermeldungen findet, war Debian-exim schon
vorher.
Das hat das Exim-Problem jedoch nur verlagert, nicht gelöst. Die
Fehlermeldungen im Exim-Logfile lauten jetzt:
| 2021-04-20 06:57:41 plain authenticator failed for xxx ([yyy]) [zzz]:
535 Incorrect authentication data (set_id=sebastian)
| 2021-04-20 06:57:44 login authenticator failed for xxx ([yyy]) [zzz]:
535 Incorrect authentication data (set_id=sebastian)
authtest sagt jedoch, dass alles in bester Ordnung wäre und auch das
Abrufen von Mail via courier-imap-ssal vom selben Server, der sich
natürlich auch gegen denselben courier-authdaemon authentifiziert,
klappt problemlos:
| # authtest sebastian $PASSWORT
| Authentication succeeded.
|
| Authenticated: sebastian (system username: sebastian)
| Home Directory: /home/sebastian
| Maildir: (none)
| Quota: (none)
| Encrypted Password: $HASH
| Cleartext Password: $PASSWORT
| Options: (none)
| #
(Statt "$PASSWORT" und "$HASH" stehen im Original natürlich das richtige
Passwort und ein echter Hash.)
In /var/log/auth.log steht dazu auch nur:
| Apr 20 06:57:39 tigersclaw authdaemond: pam_unix(exim:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
user=sebastian
| Apr 20 06:57:41 tigersclaw authdaemond: pam_unix(exim:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
user=sebastian
Und hier noch der Auszug der Authenticators aus meiner Exim-Config:
| [...]
| plain:
| driver = plaintext
| public_name = PLAIN
| client_send =
"^${extract{2}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}\
|
^${extract{3}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}"
| server_condition = \
| ${if eq {${readsocket{/var/run/courier/authdaemon/socket}\
| {AUTH
${strlen:exim\nlogin\n$2\n$3\n}\nexim\nlogin\n$2\n$3\n}}}{FAIL\n}{no}{yes}}
| server_set_id = $2
|
| login:
| driver = plaintext
| public_name = LOGIN
| client_send = ":
${extract{2}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}
\
| :
${extract{3}{::}{${lookup{$sender_address}lsearch*{CONFDIR/sender.smarthost.passwd}{$value}fail}}}"
| server_prompts = Username:: : Password::
| server_condition = ${if eq
{${readsocket{/var/run/courier/authdaemon/socket} \
| {AUTH
${strlen:exim\nlogin\n$1\n$2\n}\nexim\nlogin\n$1\n$2\n}}}{FAIL\n}{no}{yes}}
| server_set_id = $1
| server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
| [...]
Wie gesagt: bis vor dem Update der courier-authdaemon-Pakete hat das
Setup einwandfrei funktioniert, aber jetzt gehen mir gerade die Ideen
aus, wo man noch suchen bzw. schrauben könnte. Exim und
courier-authdaemon habe ich inzwischen auch schon jeweils mehrfach neu
gestartet.
Lange Rede, kurzer Sinn: wie kriege ich Exim wieder dazu, gegen
courier-authdaemon zu authentifiziern?
Tschüs,
Sebastian
Sebastian Suchanek
Apr 20, 2021, 8:36:40 AM4/20/21
to
Am 20.04.2021 um 12:38 schrieb Thomas Noll:
> Am Tue, 20 Apr 2021 12:05:02 +0200 schrieb Sebastian Suchanek:
Hallo Heiko!
>> Wie gesagt: bis vor dem Update der courier-authdaemon-Pakete hat das
>> Setup einwandfrei funktioniert, aber jetzt gehen mir gerade die Ideen
>> aus, wo man noch suchen bzw. schrauben könnte.
>
> Nun, der Exim macht das gleiche wie vorher. Bei pam_unix ist das Kind
> schon im Brunnen. Also liegt das Problem dazwischen. Prinzipiell scheint
> es aber nicht ganz kaputt zu sein, denn der user wird ja immerhin
> korrekt übertragen.
>
> Probier mal ein Passwort mit auschließlich ASCII-Zeichen.
> [...]
Das ist bereits so. (Großbuchstaben, Kleinbuchstaben, Ziffern,
Minuszeichen...)
Aber jetzt, wo Du's sagst, habe ich das ganze nochmal ausprobiert. (Der
Thunderbird, von dem ich gerade schreibe, ist so konfiguriert, dass er
sich E-Mail-Passwörter nicht merkt.) Und, was soll ich sagen - es
funktioniert.
Sollte ich heute Morgen bei der Fehlersuche es tatsächlich geschafft
haben, mein Passwort fünf oder noch mehr Male falsch einzugeben? (Und
ja, auf Dinge wie Caps-Lock habe ich heute Morgen auch schon geachtet...)
Sollte es bei "funktioniert" bleiben - sorry for the noise. Ansonsten
melde ich mich noch 'mal.
Tschüs,
Sebastian
> Am Tue, 20 Apr 2021 12:05:02 +0200 schrieb Sebastian Suchanek:
Hallo Heiko!
>> Wie gesagt: bis vor dem Update der courier-authdaemon-Pakete hat das
>> Setup einwandfrei funktioniert, aber jetzt gehen mir gerade die Ideen
>> aus, wo man noch suchen bzw. schrauben könnte.
>
> schon im Brunnen. Also liegt das Problem dazwischen. Prinzipiell scheint
> es aber nicht ganz kaputt zu sein, denn der user wird ja immerhin
> korrekt übertragen.
>
> Probier mal ein Passwort mit auschließlich ASCII-Zeichen.
> [...]
Das ist bereits so. (Großbuchstaben, Kleinbuchstaben, Ziffern,
Minuszeichen...)
Aber jetzt, wo Du's sagst, habe ich das ganze nochmal ausprobiert. (Der
Thunderbird, von dem ich gerade schreibe, ist so konfiguriert, dass er
sich E-Mail-Passwörter nicht merkt.) Und, was soll ich sagen - es
funktioniert.
Sollte ich heute Morgen bei der Fehlersuche es tatsächlich geschafft
haben, mein Passwort fünf oder noch mehr Male falsch einzugeben? (Und
ja, auf Dinge wie Caps-Lock habe ich heute Morgen auch schon geachtet...)
Sollte es bei "funktioniert" bleiben - sorry for the noise. Ansonsten
melde ich mich noch 'mal.
Tschüs,
Sebastian
0 new messages