errore di authentication saslauthd

Il mio server ha sviluppato un problema previsto in cui non riesco a connettersi da un client di posta.

Ho esaminato i log del server e l'unica cosa che sembra identificare un problema sono events come il seguente:

Nov 23 18:32:43 hig3 wherecot: imap-login: Login: user =, metodo = PLAIN, rip = xxxxxxxx, lip = xxxxxxx, TLS Nov 23 18:32:55 hig3 postfix / smtpd [11653]: connetti da xxxxxxx .sci [xxxxxxx] 23 novembre 18:32:55 hig3 postfix / smtpd [11653]: avviso: errore di authentication SASL: imansible connettersi a server saslauthd: nessun file o directory di questo tipo 23 novembre 18:32:55 hig3 postfix / smtpd [11653]: warning: xxxxxxx.co.uk [xxxxxxxx]: authentication SASL LOGIN non rioutput: guasto generico 23 novembre 18:32:56 hig3 postfix / smtpd [11653]: connessione persa dopo AUTH da xxxxxxx.co.uk [xxxxxxx] Nov 23 18:32:56 hig3 postfix / smtpd [11653]: scolbind da xxxxxxx.it [xxxxxxx]

Il problema è insolito, perché solo mezz'ora prima del mio ufficio, non mi è stato richiesto per un corretto nome utente e password nel mio client di posta. Non ho effettuato modifiche al server, quindi non riesco a capire cosa sarebbe successo per fare questo errore.

Le ricerche dei messaggi di errore forniscono vari risultati, con 'correzioni' che sono incerto (ovviamente non voglio farlo peggiorare o risolvere qualcosa che non sia rotto).

Quando correre

testaslauthd -u xxxxx -p xxxxxx

Ho anche il risultato seguente:

connect (): Nessun file o directory del genere

Ma quando corrono

testsaslauthd -u xxxxx -p xxxxxx -f / var / spool / postfix / var / eseguire / saslauthd / mux -s smtp

Ottengo:

0: OK "Successo".

Ho trovato questi comandi su un altro forum e non sono del tutto sicuro di cosa significano, ma spero che possano dare un'indicazione su where il problema potrebbe trovarsi.

Quando correre

ps -ef | grep saslauthd

Questa è l'output:

radice 1245 1 0 Nov24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / eseguire / saslauthd -r -n 5 root 1250 1245 0 Nov24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / eseguire / saslauthd -r -n 5 root 1252 1245 0 Nov24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / eseguire / saslauthd -r -n 5 root 1254 1245 0 Nov24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / eseguire / saslauthd -r -n 5 root 1255 1245 0 Nov24? 00:00:00 / usr / sbin / saslauthd -a pam -c -m / var / spool / postfix / var / eseguire / saslauthd -r -n 5 root 5902 5885 0 08:51 pp / 0 00:00:00 grep –color = auto saslauthd

Se fa la differenza, sto eseguendo Ubuntu 10.04.1, Postfix 2.7.0 e Webmin / Virtualmin.

  • Muovendo il pulseaudio fuori casa
  • Ubuntu - Identificazione della session di bash di un utente registrato
  • Impostazione umask per utente www-data (eseguito sudo) su Ubuntu 10.04 LTS
  • L'installazione di Postgresql 9.3 non riesce
  • Ubuntu 10.04 crash del server
  • Installazione di alcuni pacchetti su Ubuntu utilizzando apt-get install senza privilegi di root
  • Serve solo le richieste di un dominio specifico?
  • Le richieste di contabilità di Meraki al server RADIUS
  • 4 Solutions collect form web for “errore di authentication saslauthd”

    Postfix può essere eseguito in un chroot (per impostazione predefinita in /var/spool/postfix ) o no. In caso contrario, cercherà di aprire /var/spool/postfix/var/run/saslauthd/mux per l'authentication sasl. In caso contrario, cercherà di aprire /var/run/saslauthd/mux

    Sembra che, per qualche motivo, l'istanza del postfix sia in esecuzione in un chroot, e non è più. È strano, ma questo è quello che suppongo dai dettagli della tua domanda. Se è ciò che è successo, puoi cambiare la configuration di saslauthd per utilizzare /var/run/saslauthd oppure eseguire nuovamente il postfix in un chroot.

    Per sapere se il Postfix è in esecuzione chroot, è ansible controllare /etc/postfix/master.cf : Se ha la linea smtp inet n - y - - smtpd o smtp inet n - - - - smtpd , allora il tuo Postfix è in esecuzione un chroot. Se ha la linea smtp inet n - n - - smtpd allora il tuo Postfix NON è in esecuzione in un chroot. Questo controllo viene da / etc / default / saslauthd (file di configuration Ubuntu sasl).

    Sembra che il postfix guarda sempre nella posizione chroot per saslauthd anche se è configurato per NON utilizzare l'ambiente chroot per i suoi servizi.

    Ho trovato questo post di blog più utile, anche se è dal 2005!

    http://www.jimmy.co.at/weblog/?p=52

    postfix fa un chroot in modo che non possa comunicare con saslauthd. Questa è la parte difficile:

     rm -r /var/run/saslauthd/ mkdir -p /var/spool/postfix/var/run/saslauthd ln -s /var/spool/postfix/var/run/saslauthd /var/run chgrp sasl /var/spool/postfix/var/run/saslauthd adduser postfix sasl 

    È ansible eseguire saslauthd in modalità di debug utilizzando:

    saslauthd -c -d -a pam -m /var/run/saslauthd

    Dal tuo cliente, fai questo:

    openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect mail.mydomain.com:587

    Quando richiesto digitare questo:

     HELO mynotebook.com LOGIN PLAIN <base64code> 

    where viene base64code bit base64code :

     perl -MMIME::Base64 -e 'print encode_base64("\000username\000password");' 

    Ogni volta che ho incontrato un problema simile con saslauthd (e quando tutto il resto è stato duplicato), si tratta di autorizzazioni directory / file. Controllare each passo di questo path /var/spool/postfix/var/run/saslauthd per assicurarsi che saslauthd possa effettivamente arrivare.

    Nessun file o directory di questo tipo quando si tenta di connettersi suggerisce che la socket UNIX che sta cercando SASLAuthd on non esiste.

    Se si esegue ps -ef | grep saslauthd ps -ef | grep saslauthd , riesci a vedere che funziona ancora?

    Se è così, forse vedere se ha la sua posizione di log.

    Se non fosse, potrebbe essere sufficiente un riavvio.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.