🚨 Redis Error Guide: 'NOAUTH Authentication required' — Send AUTH Before Commands

Overview

NOAUTH Authentication required means the Redis instance has a password configured (via requirepass or an ACL user) and the client sent a command before authenticating. Redis rejects everything except AUTH (and HELLO) until a valid credential is provided on that connection.

The literal error clients receive:

(error) NOAUTH Authentication required.

This is different from WRONGPASS (you sent credentials but they were wrong). NOAUTH means you sent no credentials at all on a server that requires them. It usually appears right after someone enables requirepass, or when a client’s connection string is missing the password, or when a pooled connection reconnected without re-authing.

Symptoms

• Every command returns NOAUTH Authentication required until AUTH succeeds.
• Started immediately after enabling requirepass or rotating a password.
• Some pooled connections work while freshly opened ones fail (or vice versa).

redis-cli PING

(error) NOAUTH Authentication required.

redis-cli -a 'S3cret' PING

PONG

Common Root Causes

1. requirepass is set but the client sends no password

The instance requires auth; the client connection string omits it.

redis-cli -a 'S3cret' CONFIG GET requirepass 2>/dev/null

1) "requirepass"
2) "S3cret"

A non-empty requirepass means every connection must AUTH first.

2. ACL user with a password, default user disabled

Redis 6+ ACLs: the default user may be nopass off / disabled, so clients must authenticate as a named user.

redis-cli -a 'S3cret' ACL WHOAMI
redis-cli -a 'S3cret' ACL LIST

user default off ...
user app on #<hash> ~app:* +@all

default off means anonymous access is refused; clients must AUTH app <password>.

3. Password not propagated to the client config

The app’s Redis URL lacks the password, or the secret was rotated on the server but not in the client’s environment.

# Redis URL must carry the password
# redis://:S3cret@10.0.0.20:6379/0
grep -Eri 'REDIS_URL|REDIS_PASSWORD' /etc/myapp/ 2>/dev/null

4. Pooled connection reconnected without re-auth

A client library that does not re-run AUTH after a dropped connection will hit NOAUTH on the new socket.

redis-cli -a 'S3cret' CLIENT LIST | head

Diagnostic Workflow

Step 1: Confirm the server requires auth

# If you have the password:
redis-cli -a '<PASS>' CONFIG GET requirepass 2>/dev/null
grep -E '^requirepass|^user ' /etc/redis/redis.conf

A set requirepass or ACL user lines confirm auth is required.

Step 2: Verify AUTH works with the expected credential

redis-cli -h <HOST> -p 6379 -a '<PASS>' PING 2>/dev/null
# ACL user form:
redis-cli -h <HOST> -p 6379 --user app --pass '<PASS>' PING 2>/dev/null

PONG confirms the credential is correct; the app is simply not sending it.

Step 3: Inspect ACLs and users

redis-cli -a '<PASS>' ACL WHOAMI
redis-cli -a '<PASS>' ACL LIST
redis-cli -a '<PASS>' ACL GETUSER default

Step 4: Check what the client is actually sending

redis-cli -a '<PASS>' CLIENT LIST | grep -E 'user=|name='
# unauthenticated connections show user=default with limited access

Step 5: Check the log around the change

sudo journalctl -u redis-server --no-pager | grep -iE 'requirepass|ACL|auth' | tail

Example Root Cause Analysis

At 09:05, minutes after a security change, the worker fleet starts logging NOAUTH Authentication required on every Redis call. Nothing else changed, so the timing points straight at the new requirepass.

Confirming the server side, the password was set live and rewritten to config:

redis-cli -a 'NewS3cret' CONFIG GET requirepass    # -> NewS3cret

redis-cli -a 'NewS3cret' PING returns PONG, so the credential is valid — the workers simply are not sending it. Their REDIS_URL is redis://10.0.0.20:6379/0, with no password segment. The fix is to update the secret in the client config and reload the workers:

# Correct URL carries the password
# redis://:NewS3cret@10.0.0.20:6379/0
sudo sed -i 's#redis://10.0.0.20#redis://:NewS3cret@10.0.0.20#' /etc/myapp/redis.env
sudo systemctl restart myapp-worker

After the restart the workers authenticate on connect and NOAUTH disappears. Longer term the password moved into a managed secret so a rotation updates server and all clients together, and the team adopted ACL users per service instead of a shared requirepass.

Prevention Best Practices

• Store the Redis password in a managed secret and inject it into both server and every client so a rotation is atomic.
• Prefer Redis 6+ ACL users per service (ACL SETUSER app on >pass ~app:* +@all) over a single shared requirepass, for least privilege and auditability.
• Ensure client libraries re-run AUTH on reconnect (most do when the password is in the connection URL, not sent manually once).
• Validate the connection string in config management; a missing password segment is the most common cause.
• Never log the password; use --no-auth-warning or the REDISCLI_AUTH env var instead of -a on shared shells.
• Keep protected-mode yes and TLS so credentials are not sniffable.
• Drop the client error into the free incident assistant, and see more Redis guides.

Quick Command Reference

# Does the server require auth?
redis-cli -a '<PASS>' CONFIG GET requirepass 2>/dev/null
grep -E '^requirepass|^user ' /etc/redis/redis.conf

# Verify the credential works
redis-cli -h <HOST> -a '<PASS>' PING 2>/dev/null
redis-cli -h <HOST> --user app --pass '<PASS>' PING 2>/dev/null

# ACL inspection
redis-cli -a '<PASS>' ACL WHOAMI
redis-cli -a '<PASS>' ACL LIST
redis-cli -a '<PASS>' ACL GETUSER default

# What clients are connected as
redis-cli -a '<PASS>' CLIENT LIST | grep -E 'user=|name='

Conclusion

NOAUTH Authentication required means the server wants a password and the client sent none. The typical root causes are:

1. requirepass is set but the client connection string omits the password.
2. An ACL setup where default is disabled and clients must AUTH as a named user.
3. A rotated password not propagated to the client config.
4. A pooled connection that reconnected without re-running AUTH.

Confirm the credential works with redis-cli -a <pass> PING, then fix the client side — nearly always a missing or stale password in the connection URL. Distinguish it from WRONGPASS (a wrong credential) to know whether you are chasing a missing secret or an incorrect one.