I have a redis-server instance running, everything works fine if I try to connect to it via code e.g python. The problem is, redis-cli tool doesn't connect. Here's what I get when I run redis-cli:
Could not connect to Redis at 127.0.0.1:6379: �
not connected>
Could not connect to Redis at 127.0.0.1:6379: (
not connected>
Looking at the response, it's adding some characters after the port, in this case : � and : (
What could be the problem here? I've also tried redis-cli -h 127.0.0.1 -p 6379 but to no avail.
Note: Redis server is working fine.
Related
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
I have a health check I'm trying to use that executes the redis-cli command from the redis servers to the redis-sentinels remotely.
redis-cli -h 10.10.10.10 -p 26379 SENTINEL MASTER testing
There is a logic that sorts out whether there is a quorum and it all works fine unless a sentinel's network interface is unavailable. The redis-cli command hangs indefinitely in this case and the health check fails even though there are two healthy sentinels with a quorum.
I can't seem to find a way to set a timeout for the redis-cli on the client side to prevent it from hanging. Is there a way with redis-cli to do this or will I have to go outside the command to ensure it doesn't hang indefinitely?
I decided to use the timeout command to wrap the redis-cli command. It seems to work very well for my purposes!
timeout 3 redis-cli -h 10.10.10.10 -p 26379 SENTINEL MASTER testing
I am using redis 2.4 . When I change the port in "redis.conf" file to another port redis-cli stops working. It shows
Could not connect to Redis at 127.0.0.1:6379: Unknown error not
connected>
The redis.conf file dictates the server's behavior. To tell the command line interface to connect to your newly-defined-non-default port, use the -p switch, e.g.:
$ redis-cli -p 12758
I have a Spark installation running under YARN on a remote cluster, with a firewall between me and the head node. I can use a ssh tunnel to access the head node:
> ssh -N -f -L 10000:remotenode:10000 between_machine
and this setup works, for example, to access a HiveServer2 running on remotenote. If Spark was running in cluster mode, I would need to just do the same for the 7077 port and direct the pyspark client to localhost with
> ssh -N -f -L 7077:remotenode:7077 between_machine
> ./pyspark --master spark://localhost:7077
How can I do that with Spark running under the YARN scheduler?
If you are looking for a port to connect, here is a quote from the doc:
You can access this interface by simply opening
http://:4040 in a web browser. If multiple SparkContexts
are running on the same host, they will bind to successive ports
beginning with 4040 (4041, 4042, etc).
If you are just looking for a more universal way to get to the host via ssh "tunnel", you could try ssh working as socks proxy:
ssh user#host -D 20000
And then configuring your browser to connect via socks proxy (host - localhost, port - 20000).
On my local machine I have an SSH tunnel setup for postgres like so:
ssh -fNL 5434:127.0.0.1:5432 user#host
Then running psql -h localhost --port 5434 works just fine and dandy, giving me a postgres terminal.
Then, on my VM (VirtualBox), I have the host vmhost defined as 192.168.56.1. SSHing into vmhost works fine- connects to the host.
But, running from the vm psql -h vmhost --port 5434 yields:
psql: could not connect to server: Connection refused
Is the server running on host "vmhost" (192.168.56.1) and accepting
TCP/IP connections on port 5434?
Is there some kind of SSH tunnel forwarding magic thing that's not happening here? How can I allow this to work?
You want to use the -g option when opening the SSH connection. Otherwise, only localhost itself can connect to the tunnel.
Use
ssh -fNL '*:5434:127.0.0.1:5432' user#host
Note the '*' used as the binding address.