Seems iptables was filtering everything out. Solution was to create a REDIS chain.
iptables -N REDIS
iptables -A REDIS -s 192.168.10.1 -j ACCEPT
iptables -A REDIS -s 192.168.10.2 -j ACCEPT
iptables -A REDIS -j LOG --log-prefix "unauth-redis-access"
iptables -A REDIS -j REJECT --reject-with icmp-port-unreachable
iptables -I INPUT -p tcp --dport 6379 -j REDIS
Hat tip to http://www.golja.org/blog/monitoring-traffic-with-iptables/
I had a similar issue but on a derivative of Arch Linux.
Redis had to be installed for OpenVAS and I was getting a permission error after attempting to start the service like this:
systemctl start redis.service
The error was visible using:
journalctl -xeu redis.service
as recommended by the systemctl command output.
When it attempted to create the Unix socket in /run (also linked from /var/run) it would fail because it could not create the file. I could manually created a redis subdirectory under /run using sudo and change the owner to the redis user then started redis but the directory kept disappearing later.
I tried re-installing with pacman because I was a bit lost but that didn't seem to help.
Solution in my case
After running
sudo systemctl enable redis.service
I can start the service and /run/redis (also linked as /var/run/redis) is present with a PID and Unix socket file as configured with the unixsocket entry in my config file.
I can confirm it's accessible with:
redis-cli -s /run/redis/redis.sock
After a reboot it's still good.
Best Answer
Setting the
requirepassconfiguration directive causes the server to require password authentication with theAUTHcommand before sending other commands. The redis.conf file states that clearly: