SASL (bzw. Digest-MD5) und kein Ende der Probleme...
Hallo nochmal, nachdem ich jetzt den Versuch, SASL wirklich richtig zu verstehen, vorerst ein Stück hintenan gestellt habe, läuft auf dem neuen Router die Emailgeschichte erstmal. Allerdings habe ich ein Problem mit mutt, welches ich nicht genau eingrenzen kann. Auf der Box läuft SuSE 8.2, alle Pakete sind Standardpakete, nur die aktuellen Security-Updates eingespielt. Wenn ich mich mit mutt zum IMAP-Server, der lokal auf derselben Maschine läuft, verbinden will, "funktioniert" das nur, wenn ich ein falsches Passwort eingebe, zumindestens hängt sich dann mutt nicht auf. Sobald ich das richtige Passwort verwende, bleibt mutt nach dem Druck auf <Return> hängen und lässt sich nurmehr killen. Im Log steht dann folgendes: Erst der Fehlversuch, nach welchem mutt noch reagiert: Oct 1 21:38:43 asterix master[1650]: about to exec /usr/lib/cyrus/bin/imapd Oct 1 21:38:43 asterix imap[1650]: executed Oct 1 21:38:43 asterix imapd[1650]: accepted connection Oct 1 21:38:44 asterix imapd[1650]: DIGEST-MD5 server step 1 Oct 1 21:38:44 asterix mutt: DIGEST-MD5 client step 2 Oct 1 21:38:46 asterix imapd[1650]: DIGEST-MD5 server step 2 Oct 1 21:38:46 asterix imapd[1650]: client response doesn't match what we generated Oct 1 21:38:46 asterix imapd[1650]: badlogin: asterix.chdintern.de[192.168.100.251] DIGEST-MD5 [SASL(-13): authentication failure: client response doesn't match what we generated] Dann der Versuch mit dem richtigen Passwort: Oct 1 21:39:30 asterix master[1651]: about to exec /usr/lib/cyrus/bin/imapd Oct 1 21:39:30 asterix imap[1651]: executed Oct 1 21:39:30 asterix imapd[1651]: accepted connection Oct 1 21:39:31 asterix imapd[1651]: DIGEST-MD5 server step 1 Oct 1 21:39:31 asterix mutt: DIGEST-MD5 client step 2 Oct 1 21:39:35 asterix imapd[1651]: DIGEST-MD5 server step 2 Oct 1 21:39:35 asterix mutt: DIGEST-MD5 client step 3 Weitere Meldungen gibt es nicht und mutt hängt für mindestens 5 Minuten fest, länger habe ich mir das nicht angesehen und mit kill draufgehaun. Das Komische daran ist, dass ich mit diesem mutt auch nicht auf meinen anderen IMAP-Server (den ich eigentlich ersetzen will) zugreifen kann, da bietet sich dasselbe Verhalten. Das Log sieht ein wenig anders aus, weil der Server TLS beherrscht, aber im Prinzip passiert dasselbe. Also habe ich mutt in der aktuellen Version 1.4.1i hergenommen und selbst kompiliert, aber das hat erwartungsgemäss auch nichts gebracht. Wenn ich mit pine statt mit mutt versuche, auf den lokalen IMAP-Server zuzugreifen, klappt das erstaunlicherweise. Der einzige Unterschied scheint darin zu liegen, dass pine CRAM-MD5 verwenden möchte und mutt Digest-MD5. Wenn ich übrigens mit mutt von einem anderen Client aus auf einen der beiden IMAP-Server zugreife, klappt das ebenfalls einwandfrei. Wo liegt der Hase im Pfeffer? Bei SASL bzw. SASL2? Oder ist an diesem Digest-MD5 was kaputtbar und ich kann da was drehen? In der Hoffnung, wieder mal mit der Nase auf die richtige Fährte gestoßen zu werden, mfg Hannes P.S: sorry wegen der langen Zeile, ich wollte es nicht umbrechen... -- Was den Menschen vom Tier unterscheidet, sind die Geldsorgen. (unbekannter Autor)
Johannes Studt wrote:
Dann der Versuch mit dem richtigen Passwort:
Oct 1 21:39:30 asterix master[1651]: about to exec /usr/lib/cyrus/bin/imapd Oct 1 21:39:30 asterix imap[1651]: executed Oct 1 21:39:30 asterix imapd[1651]: accepted connection Oct 1 21:39:31 asterix imapd[1651]: DIGEST-MD5 server step 1 Oct 1 21:39:31 asterix mutt: DIGEST-MD5 client step 2 Oct 1 21:39:35 asterix imapd[1651]: DIGEST-MD5 server step 2 Oct 1 21:39:35 asterix mutt: DIGEST-MD5 client step 3
Weitere Meldungen gibt es nicht und mutt hängt für mindestens 5 Minuten fest, länger habe ich mir das nicht angesehen und mit kill draufgehaun. Das Komische daran ist, dass ich mit diesem mutt auch nicht auf meinen anderen IMAP-Server (den ich eigentlich ersetzen will) zugreifen kann, da bietet sich dasselbe Verhalten. Das Log sieht ein wenig anders aus, weil der Server TLS beherrscht, aber im Prinzip passiert dasselbe. Also habe ich mutt in der aktuellen Version 1.4.1i hergenommen und selbst kompiliert, aber das hat erwartungsgemäss auch nichts gebracht.
Wenn ich mit pine statt mit mutt versuche, auf den lokalen IMAP-Server zuzugreifen, klappt das erstaunlicherweise. Der einzige Unterschied scheint darin zu liegen, dass pine CRAM-MD5 verwenden möchte und mutt Digest-MD5.
Wenn ich übrigens mit mutt von einem anderen Client aus auf einen der beiden IMAP-Server zugreife, klappt das ebenfalls einwandfrei.
Wo liegt der Hase im Pfeffer? Bei SASL bzw. SASL2? Oder ist an diesem Digest-MD5 was kaputtbar und ich kann da was drehen?
In der Hoffnung, wieder mal mit der Nase auf die richtige Fährte gestoßen zu werden, mfg
Ich benutze mutt nicht, denke aber mal es liegt daran. Blende doch einfach mal digest-md5 aus (sasl_mech_list: cram-md5 plain). Und probier es dann nochmal. -- Andreas
* Andreas Winkelmann
Ich benutze mutt nicht, denke aber mal es liegt daran. Blende doch einfach mal digest-md5 aus (sasl_mech_list: cram-md5 plain). Und probier es dann nochmal.
Also mit dieser Einschränkung funktioniert es (fast erwartungsgemäß): Oct 1 22:36:10 asterix master[1766]: about to exec /usr/lib/cyrus/bin/imapd Oct 1 22:36:10 asterix imap[1766]: executed Oct 1 22:36:10 asterix imapd[1766]: accepted connection Oct 1 22:36:15 asterix imapd[1766]: login: asterix.chdintern.de[192.168.100.251] hannes CRAM-MD5 User logged in Oct 1 22:36:15 asterix imapd[1766]: seen_db: user hannes opened /var/lib/imap/user/h/hannes.seen Oct 1 22:36:15 asterix imapd[1766]: open: user hannes opened INBOX Aber damit hab ich doch das Problem wieder nur umgangen, nicht gelöst, oder? Ausserdem klappt es ja von einem anderen Client aus mit haargenau demselben mutt (mit denselben Patches sogar, allerdings ist es eine SuSE 8.1-Box) auch mit Digest-MD5. Oct 1 22:37:59 asterix master[1793]: about to exec /usr/lib/cyrus/bin/imapd Oct 1 22:37:59 asterix imap[1793]: executed Oct 1 22:37:59 asterix imapd[1793]: accepted connection Oct 1 22:38:00 asterix imapd[1793]: DIGEST-MD5 server step 1 Oct 1 22:38:03 asterix imapd[1793]: DIGEST-MD5 server step 2 Oct 1 22:38:03 asterix imapd[1793]: login: fileserver02.chdintern.de[192.168.100.2] hannes DIGEST-MD5 User logged in Oct 1 22:38:03 asterix imapd[1793]: seen_db: user hannes opened /var/lib/imap/user/h/hannes.seen Oct 1 22:38:03 asterix imapd[1793]: open: user hannes opened INBOX Also kann es doch fast nicht an mutt liegen, oder? Kann man irgendwie ein verschärftes Logging der SASL-Authentifizierung einschalten? Oder das einfach mal mit telnet zu Fuss machen? Das muss sich doch finden lassen :/ Achso, und ein Nachtrag noch: ich habe mal so ein mutt hängen lassen, anstatt es totzuklopfen, und es hat nach einigen Minuten (ich schätze 15-20) wieder reagiert. Im Logfile stand korrespondierend etwas von "imapd[1650]: idle for too long, closing connection". Hilft mir dieses Wissen irgendwie, einen Zusammenhang zu finden? Hannes -- Das Licht am Ende des Tunnels ist ein entgegenkommender Zug. (unbekannter Autor)
Johannes Studt wrote:
Ich benutze mutt nicht, denke aber mal es liegt daran. Blende doch einfach mal digest-md5 aus (sasl_mech_list: cram-md5 plain). Und probier es dann nochmal.
Also mit dieser Einschränkung funktioniert es (fast erwartungsgemäß):
Oct 1 22:36:10 asterix master[1766]: about to exec /usr/lib/cyrus/bin/imapd Oct 1 22:36:10 asterix imap[1766]: executed Oct 1 22:36:10 asterix imapd[1766]: accepted connection Oct 1 22:36:15 asterix imapd[1766]: login: asterix.chdintern.de[192.168.100.251] hannes CRAM-MD5 User logged in Oct 1 22:36:15 asterix imapd[1766]: seen_db: user hannes opened /var/lib/imap/user/h/hannes.seen Oct 1 22:36:15 asterix imapd[1766]: open: user hannes opened INBOX
Aber damit hab ich doch das Problem wieder nur umgangen, nicht gelöst, oder? Ausserdem klappt es ja von einem anderen Client aus mit haargenau demselben mutt (mit denselben Patches sogar, allerdings ist es eine SuSE 8.1-Box) auch mit Digest-MD5.
Oct 1 22:37:59 asterix master[1793]: about to exec /usr/lib/cyrus/bin/imapd Oct 1 22:37:59 asterix imap[1793]: executed Oct 1 22:37:59 asterix imapd[1793]: accepted connection Oct 1 22:38:00 asterix imapd[1793]: DIGEST-MD5 server step 1 Oct 1 22:38:03 asterix imapd[1793]: DIGEST-MD5 server step 2 Oct 1 22:38:03 asterix imapd[1793]: login: fileserver02.chdintern.de[192.168.100.2] hannes DIGEST-MD5 User logged in Oct 1 22:38:03 asterix imapd[1793]: seen_db: user hannes opened /var/lib/imap/user/h/hannes.seen Oct 1 22:38:03 asterix imapd[1793]: open: user hannes opened INBOX
Also kann es doch fast nicht an mutt liegen, oder? Kann man irgendwie ein verschärftes Logging der SASL-Authentifizierung einschalten? Oder das einfach mal mit telnet zu Fuss machen? Das muss sich doch finden lassen :/
Nö, die offiziellen Logging-Tools für imapd bzw. sasl sind strace und gdb. Bzw. in diesem Fall vielleicht mal nen Netzwerksniffer benutzen. Mit telnet bei den Shared-Secret-Mechs kannst Du vergessen. Sowas geht noch bei plain oder login, aber bei z.B. digest-md5 nicht mehr so einfach.
Achso, und ein Nachtrag noch: ich habe mal so ein mutt hängen lassen, anstatt es totzuklopfen, und es hat nach einigen Minuten (ich schätze 15-20) wieder reagiert. Im Logfile stand korrespondierend etwas von "imapd[1650]: idle for too long, closing connection". Hilft mir dieses Wissen irgendwie, einen Zusammenhang zu finden?
Hmm, nicht wirklich. Bei diesen Shared-Secret-Mechanismen findet schon fast eine Unterhaltung statt. Wenn eine Seite wartet, kann der Fehler wohl auch auf der anderen Seite liegen. Kannst Du nicht irgendwie mutt dazu bringen etwas gesprächiger zu werden? -- Andreas
* Andreas Winkelmann
Nö, die offiziellen Logging-Tools für imapd bzw. sasl sind strace und gdb. Bzw. in diesem Fall vielleicht mal nen Netzwerksniffer benutzen.
*gnirks* Mit solcherlei tiefgreifenden Dingen wie strace und gdb habe ich mich noch nicht befasst, das wird mir also kaum weiterhelfen. Einen Sniffer könnte man allerdings wirklich mal drauf loslassen.
Mit telnet bei den Shared-Secret-Mechs kannst Du vergessen. Sowas geht noch bei plain oder login, aber bei z.B. digest-md5 nicht mehr so einfach.
Schade schade.
Hmm, nicht wirklich. Bei diesen Shared-Secret-Mechanismen findet schon fast eine Unterhaltung statt. Wenn eine Seite wartet, kann der Fehler wohl auch auf der anderen Seite liegen. Kannst Du nicht irgendwie mutt dazu bringen etwas gesprächiger zu werden?
Ich versuche gerade, ob es, mit der configure-Option --enable-debug kompiliert, etwas gesprächiger zu machen ist. Sage dann Bescheid. :) Hannes -- Heutzutage ist Resignation schon ein viel zu grosses persönliches Engagement. (unbekannter Autor)
Johannes Studt wrote:
Hmm, nicht wirklich. Bei diesen Shared-Secret-Mechanismen findet schon fast eine Unterhaltung statt. Wenn eine Seite wartet, kann der Fehler wohl auch auf der anderen Seite liegen. Kannst Du nicht irgendwie mutt dazu bringen etwas gesprächiger zu werden?
Ich versuche gerade, ob es, mit der configure-Option --enable-debug kompiliert, etwas gesprächiger zu machen ist. Sage dann Bescheid. :)
Bin mal gepsannt... -- Andreas
* Andreas Winkelmann
Bin mal gepsannt...
War ich auch, aber das Problem hat sich eben anderweitig "gelöst": http://groups.yahoo.com/group/mutt-dev/message/18340 Naja, was solls, werde ich solange eben Digest-MD5 abdrehen, wie Du es weiter oben empfohlen hast. Wenn ich mutt-1.5.4 auf der SuSE-Box mal kompiliert bekommen würde, wäre wahrscheinlich alles gut, aber das geht bei mir irgendwie nicht, er mag nicht durchlaufen. Vielleicht hat dazu ja noch jemand 'ne Idee? Hannes -- The only problem with troubleshooting is, that sometimes the trouble shoots back.
participants (2)
-
Andreas Winkelmann -
Johannes Studt