Require authentication on Memcached

The fix/etc/memcached.conf

# Requires a binary built with --enable-sasl
-S

If you see this

This server is not built with SASL support.

The -S flag was accepted by the parser but the binary was compiled without --enable-sasl. No configuration fixes this; it needs a different build. — memcached/memcached.c

ERROR: You cannot allow the ASCII protocol while using SASL.

SASL authentication only exists in the binary protocol, so enabling it forces every client onto binary. A client library speaking ASCII will stop working. — memcached/memcached.c

Authfile [/etc/memcached.auth] has a malformed entry. Should be 'user:password'

The -Y auth file wants one user:password pair per line and nothing else — no spaces around the colon, no comments, no blank trailing structure. — memcached/memcached.c

“Memcached has no authentication” is not quite right

It is the most repeated sentence about this software, and it is close enough to true that it keeps getting repeated — but the accurate version is more useful:

Memcached has two authentication mechanisms, both off by default, and both build-time options. The defaults are settings.sasl = false and settings.auth_file = NULL. So a stock daemon really does accept every connection, but that is a configuration state rather than a missing feature.

The distinction matters because it changes what you do. “No authentication” leads people to conclude the network is the only possible control and stop there. In fact you can often turn something on — and where you genuinely cannot, knowing why tells you the network control has to be airtight.

SASL — the real one

-S enables SASL authentication. Two consequences follow immediately, and memcached states both as hard errors rather than warnings:

• It forces the binary protocol. SASL is not implemented in the ASCII protocol, so -S together with ASCII is refused outright. Every client has to speak binary.
• It rules out UDP. Binary SASL and UDP cannot be enabled together. Not a practical loss, since UDP should be off anyway.

The larger obstacle is the build. SASL needs ./configure --enable-sasl, and distribution packages frequently omit it — which is exactly why the “memcached has no authentication” folklore persists. If -S gives you This server is not built with SASL support., no amount of configuration will help; you need a different binary.

Credentials come from the system SASL configuration (typically /etc/sasl2/memcached.conf plus a sasldb2 database created with saslpasswd2), not from a memcached file.

The ASCII auth file, and its caveat

-Y <file> enables a much simpler scheme: a plain file of user:password lines that works with the ASCII protocol.

-Y /etc/memcached.auth

sudo install -m 600 -o memcache -g memcache /dev/null /etc/memcached.auth
printf 'appuser:%s\n' "$(openssl rand -base64 24)" | sudo tee /etc/memcached.auth

Be aware it is still labelled (EXPERIMENTAL) in the current help text. That is memcached’s own word, not a hedge added here, and it is the honest reason not to present this as the default recommendation. It is simpler than SASL, it avoids the rebuild, and it is a genuine improvement over nothing — but it carries an upstream caveat, your client library has to support the set handshake, and credentials cross the wire in the clear unless TLS is on.

Where this leaves you

Be honest about the ordering. Authentication here is worth having and is not the primary control:

1. Bind it properly. This is the one that always works, needs no rebuild, and is rated critical for that reason.
2. Add authentication if your build supports it. Defence in depth for the case where the network boundary turns out to be wrong.
3. If neither mechanism is available, treat the network control as load-bearing rather than as a first layer — firewall the port and consider the Unix socket, which removes the network surface entirely.

This is why the page is high and not critical: on most installs it is not the control that closes the exposure, and pretending otherwise would send people rebuilding a binary when a -l flag was the actual fix.

Verify it worked

Ask the running server what it thinks is enabled:

printf 'stats settings\r\n' | nc 127.0.0.1 11211 | grep -Ei 'auth|sasl'

auth_enabled_ascii reports the auth file path, or no when unset.

Check whether the binary can do SASL at all before planning around it:

memcached -h | grep -i sasl

No output means the feature is not in this build.

Then prove authentication is actually enforced, which is the only claim that counts. From a client host, connect without credentials:

printf 'get some-key\r\n' | nc YOUR_SERVER 11211

With ASCII auth on, expect an error rather than a value or END. If you get a normal response, the daemon is not requiring anything — check the flags the process really received:

ps -o args= -C memcached

Before you apply this

Enabling authentication breaks every existing client at the moment of restart, and memcached has no reload — so this is a restart, and a restart also empties the cache. Two disruptions at once.

-S is the more disruptive of the two because it also forces the binary protocol. A client configured for ASCII will not simply fail to authenticate, it will fail to speak at all. Confirm every client library supports binary and SASL before you enable it, and update their configuration in the same maintenance window.

The safe order:

1. Update clients to send credentials first, while the server still does not require them. Clients that authenticate against a server that is not asking generally keep working.
2. Restart the server with -S or -Y once every client is ready.
3. Verify from a client host, not from the server.

Have the rollback ready — removing the flag and restarting reverts it, at the cost of a second cold cache:

sudo systemctl restart memcached

If you use -Y, the file holds plaintext passwords. It must not be world-readable, and it should not be in the same directory as anything you back up casually:

sudo chmod 600 /etc/memcached.auth
sudo chown memcache:memcache /etc/memcached.auth

Related

• Bind Memcached to localhost — the control that does the work on most installs.
• Enable TLS — without it, these credentials cross the network in the clear.