Could not create server TCP listening socket *:6379: bind: Address already in use Redis CentOS access remotely - redis

I've set up Redis on a CentOS 8 Stream virtual machine on an ipv4 address. I've installed it, and configured it, but I cannot access it remotely, I've set:
bind 0.0.0.0
I used to have it set to this...
bind 127.0.0.1 0.0.0.0
However this meant that restarting redis would fail.
Now, whenever I check if Redis is running using the systemctl command, it's running, but when running redis-server within the box I get:
Could not create server TCP listening socket *:6379: bind: Address already in use
And I cannot access it remotely with:
redis-cli -h XXX.XXX.XXX.XXX -a mypass
What am I missing?
I just keep getting:
Could not connect to Redis at XXX.XXX.XXX.XXX:6379: Connection refused

Related

SSH remote port forwarding through bastion server

I'm trying to establish a remote port forwarding to my Mac (target 4004) via a bastion host and Server-A to a Port (1555) on Server B.
So the whole connection is:
Mac:4004 => Bastion:22 => A:22 => B:1555
And the target is my Mac should have a Port 4004 forwarded from B:1555.
What is working so far?
I can connect to Server A with the command ssh user-bastion#user-A#server-A#server-bastion
On Server A I can establish a connection e.g. telnet to B:1555
On my windows client I can remote forward the port B:1555 to my local machine via Putty.
I'm now looking for the ssh command to establish this connection on my Mac.
Commands I tried:
Of course I have already searched for it and I've already tried different versions.
e.g.
ssh -fNT -R 1555:localhost:4004 -J user-bastion#user-A#server-A#server-bastion server-B
ssh -N user-bastion#user-A#server-A#server-bastion -R server-B:1555:localhost:4004
I always receive message like "Warning: remote port forwarding failed for listen port 1555"

Error: Connection reset by peer while connecting to Elastic cache using stunnal method

I am using elastic cache single node shard redis 4.0 later version.
I enabled In-Transit Encryption and gave redis auth token.
I created one bastion host with stunnal using this link
https://aws.amazon.com/premiumsupport/knowledge-center/elasticache-connect-redis-node/
I am able to connect to elastic cache redis node using following way
redis-cli -h hostname -p 6379 -a mypassword
and i can do telnet also.
BUT
when I ping (expected response "PONG") on redis-cli after connection it is giving
"Error: Connection reset by peer "
I checked security group of both side.
Any idea ?
Bastion Host ubuntu 16.04 machine
As I mentioned in question, I was running the command like this:
redis-cli -h hostname -p 6379 -a mypassword
The correct way to connect into a ElastiCache cluster through stunnel should be using "localhost" as the host address,like this:
redis-cli -h localhost -p 6379 -a mypassword
There is explanation for using the localhost address:
when you create a tunnel between your bastion server and the ElastiCache host through stunnel, the program will start a service that listen to a local TCP port (6379), encapsulate the communication using the SSL protocol and transfer the data between the local server and the remote host.
you need to start the stunnel, check if the service is listening on the localhost address (127.0.0.1), and connect using the "localhost" as the destination address: "
Start stunnel. (Make sure you have installed stunnel using this link https://aws.amazon.com/premiumsupport/knowledge-center/elasticache-connect-redis-node/)
$ sudo stunnel /etc/stunnel/redis-cli.conf
Use the netstat command to confirm that the tunnels have started:
$ netstat -tulnp | grep -i stunnel
You can now use the redis-cli to connect to the encrypted Redis node using the local endpoint of the tunnel:
$redis-cli -h localhost -p 6379 -a MySecretPassword
localhost:6379>set foo "bar"
OK
localhost:6379>get foo
"bar"
Most probably ElastiCache Redis Instance is using Encryption in-transit and Encryption at-rest and by design, the Redis CLI is not compatible with the encryption.
You need to setup stunnel to connect redis cluster
https://datanextsolutions.com/blog/how-to-fix-redis-cli-error-connection-reset-by-peer/
"Error: Connection reset by peer" indicates that Redis is killing your connection without sending any response.
One possible cause is you are trying to connect to the Redis node without using SSL, as your connection will get rejected by the Redis server without a response [1]. Make sure you are connecting through the correct port in your tunnel proxy. If you are connecting directly from the bastion host, you should be using local host.
Another option is that you have incorrectly configured your stunnel to not include a version of SSL that is supported by Redis. You should double check the config file is exactly the same as the one provided in the support doc.
It that doesn't solve your problem, you can try to build the cli included in AWS open source contribution.[2] You'll need to check out the repository, follow the instructions in the readme, and then do make BUILD_SSL=yes make redis-cli.
[1] https://github.com/madolson/redis/blob/unstable/src/ssl.c#L464
[2] https://github.com/madolson/redis/blob/unstable/SSL_README.md

Can't change the port number

I changed the port number from 6379 to 6380 but redis still tries to connect through the default port.
It says connection refused and couldn't connect through 127.0.0.1 6379. What can I do?
The command redis-cli -p 6380 will not start a Redis server that will listening to port 6380.
If you want to change the port you must firts kill the redis instance running on default port and then locate the redis.conf file.
Edit the lines:
# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379
cluster-config-file nodes-6379.conf
with your new port.
Finally, start Redis with the edited config file:
./redis-server /path/to/redis/redis.conf
Check if there is a process already using 6379. On MacOS, run:
lsof -i :6380
Then kill whatever is using that port. Make sure you kill the redis instance running on 6379 and restart it on 6380 once you're sure that port is free.

Can't connect to a remote server even though the config seems correct

My Redis instance is running at 192.168.1.101.
Redis version is 4.0.1
I want to to be able to connect this Redis instance from 192.168.1.103, but I can't.
I type redis-cli -h 192.168.1.101 -p 6379 -a myredisPasswordisHere while I'm at 192.168.1.103
It returns
Could not connect to Redis at 192.168.1.101:6379: Connection refused
Could not connect to Redis at 192.168.1.101:6379: Connection refused
Here's the related part of the Redis.conf, it's located in /usr/local/etc/redis.conf. I've installed it via Homebrew.
TL;DR
protected-mode yes
bind 192.168.1.100 192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.104
requirepass myredisPasswordisHere
What's wrong here?
For the redis service to be available for other remote hosts to query it, You need to bind it publicly to serve using bind 0.0.0.0
As the other comments from #Itamar and #Mark clearly mention, bind isn't the list of IP addresses that can connect but rather the interface on the local machine. Once the service is publicly available and running with 0.0.0.0 for your requirement of only allowing specific hosts, you need some kind of a firewall with a whitelist of IP addresses that can access this host which you can achieve with iptables.

SSH Remote Port Forwarding Specify Interface

I use this for remote port forwarding over SSH tunnel:
ssh root#X.X.X.X -R 443:127.0.0.1:443
this binds to 0.0.0.0:443 and forwards to 127.0.0.1:443 .
The remote server has multiple IPs. Is it possible to specify the IP I want to bind to, for instance 10.10.10.1:443, instead of binding to all interfaces?
iptables is not available on the remote server.
I managed to solve it.
On the remote server I set in sshd_config:
GatewayPorts clientspecified
Then I changed the arguments on the client like this:
ssh root#X.X.X.X -R 10.10.10.1:443:127.0.0.1:443
Now it works as expected, SSH binds to port 443 on interface 10.10.10.1 and forwards all traffic over the tunnel to localhost:443 .