Test saslauthd Authentication Safely with testsaslauthd

You will finish with a repeatable check that a saslauthd socket is reachable and that a supplied username and password are accepted by its configured authentication backend. The examples use testsaslauthd from Ubuntu package sasl2-bin 2.1.28+dfsg1-5ubuntu3.1. Allow about ten minutes if you already know the socket path and a test account.

This utility sends credentials to the daemon. Use a disposable account or a deliberately invalid password while checking connectivity. Do not paste a real password into a shared terminal, shell history, ticket or article. The checks below do not change saslauthd configuration or restart a service.

1. Check the installed command

Run these ordinary, read-only commands first:

$ command -v testsaslauthd
/usr/sbin/testsaslauthd
$ dpkg-query -W -f='${Package} ${Version}\n' sasl2-bin
sasl2-bin 2.1.28+dfsg1-5ubuntu3.1
$ testsaslauthd -h
testsaslauthd: invalid option -- 'h'
testsaslauthd: usage: testsaslauthd -u username -p password
              [-r realm] [-s servicename]
              [-f socket path] [-R repeatnum]

The usage text is the useful help interface here. The manual page does not document a long help option, so do not substitute --help or assume that an option from another SASL utility exists.

2. Find the daemon socket

testsaslauthd talks to the daemon through a Unix socket. The -f option supplies its path. The path is part of the daemon's deployment, so do not guess it from a different host or silently rely on a compiled-in default.

Ask the service configuration and filesystem which socket is present. Reading configuration may be ordinary; listing a directory can require elevated privileges on a locked-down host:

$ systemctl cat saslauthd 2>/dev/null | grep -E -- '-m[ =]|--socket|saslauthd'
$ find /run /var/run /var/spool -maxdepth 5 -type s -name mux -print 2>/dev/null
/var/spool/postfix/var/run/saslauthd/mux

Use the exact path reported by your service. On this machine, saslauthd is configured for the Postfix spool tree, not the more familiar /run/saslauthd/mux. That difference is a common cause of an apparently broken authentication test.

$ SOCKET='/var/spool/postfix/var/run/saslauthd/mux'
$ test -S "$SOCKET" && printf 'socket exists: %s\n' "$SOCKET"
socket exists: /var/spool/postfix/var/run/saslauthd/mux

If test -S fails, stop here. The daemon may be stopped, configured with another path, or exposing a socket that your account cannot inspect. Do not create a replacement socket by hand.

3. Run a safe connectivity and authentication test

The mandatory options are -u for the username and -p for the password. Add the service name and realm when your SASL setup expects them. Use a deliberately invalid password for the first pass:

$ testsaslauthd \
    -u GUIDE_INVALID_USER \
    -p GUIDE_INVALID_PASSWORD \
    -s smtp \
    -f "$SOCKET"
0: NO "authentication failed"

The response proves that the client reached the socket and received a daemon response. The installed command returns status 255 for this failed authentication, so capture it immediately if a script needs to distinguish success:

$ printf 'exit status: %s\n' "$?"
exit status: 255

That status belongs to the command immediately before printf. In a real check, replace the placeholder account and password only at the last possible moment. A successful credential check should return an OK response and status 0; verify the account through the service that owns it rather than assuming that an SMTP account, system account and SASL identity are interchangeable.

4. Separate a bad password from a bad socket

Use a path that definitely does not exist to see the connection failure shape without changing anything on the host:

$ testsaslauthd \
    -u GUIDE_INVALID_USER \
    -p GUIDE_INVALID_PASSWORD \
    -f /tmp/testsaslauthd-guide-no-socket
0: connect() : No such file or directory
$ printf 'exit status: %s\n' "$?"
exit status: 255

Both cases can return a non-zero status, but their output points to different work. NO "authentication failed" means the daemon answered and rejected the credentials. connect() : No such file or directory means the client could not open the named socket. Check the daemon's -m setting, socket permissions and service state before investigating the password.

Do not fix a socket error by changing permissions broadly. If the socket is owned by a service group, run the test as an account that is legitimately allowed to use that group, or ask the administrator to perform the check. Elevated privileges are for inspecting or correcting the service deployment, not for making an unknown password valid.

5. Include realm and service when the deployment needs them

Some backends distinguish identities by realm, and SASL clients commonly select a service name. Pass those values explicitly when your daemon or application configuration specifies them:

$ testsaslauthd \
    -u 'USER_NAME' \
    -p 'PASSWORD_FROM_SECURE_INPUT' \
    -r 'AUTH_REALM' \
    -s 'smtp' \
    -f "$SOCKET"
0: OK "Success."

These are illustrative placeholders, not defaults. The manual page documents the options but does not define a universal realm or service value. Copy the values from the client configuration you are testing. Keep passwords out of scripts and process listings where possible. The command line is visible to local process observers on many systems, and shell history may retain it.

6. Repeat a check only when you need to

The -R option repeats the test the requested number of times. It is useful for checking an intermittent socket or backend response, but it can create repeated authentication attempts and logs. Use a small count:

$ testsaslauthd \
    -u GUIDE_INVALID_USER \
    -p GUIDE_INVALID_PASSWORD \
    -s smtp \
    -f "$SOCKET" \
    -R 2
0: NO "authentication failed"
1: NO "authentication failed"
$ printf 'exit status: %s\n' "$?"
exit status: 255

Do not use a large repeat count against a production account or while diagnosing rate limits. There is nothing to undo after this example because it only sends test requests, but the authentication logs may need to be retained or cleared according to your normal operational policy.