I have access to two instances of Redis.
Connected locally with redis-cli, when I ping I get the response PONG
127.0.0.1:6379> ping
PONG
Managed by Digital Ocean connected by redli with --tls option, when I ping I get nil:
Connected to 5.0.9
> ping
nil
What does it mean? It is a problem with redli, Digital Ocean, TLS, Redis version? Why do I get different responses? How can I debug this problem?
Logs from Digital Ocean:
other queries like echo "Hello" also have nil response.
Related
I have been researching this Redis error for days now...
I created a GCP Memorystore Redis instance and received the following internal IP endpoint:
10.xxx.xxx.xxx:6378
I created a small GCE instance and made sure that zone matched the Redis instance:
us-central1-f
However, I when I ssh into the VM, connect to Redis, and issue a PING, I get the following error response
Protocol error, got "\x15" as reply type byte
Any idea why I am getting this error?
If the Redis instance was configured with an AUTH string and/or TLS encryption, you would need to pass these credentials when connecting to it.
I received the same error when using your command to connect to my encrypted instance. This can be done in two ways as far as I tested (from a GCE instance in the same VPC as Redis):
1. Using the redis-cli, you could use the following command to authenticate (see here for information on the flags used in the command):
redis-cli -h <ip_addres> -p <port> -a <auth_string> --tls --cacert <path/to/certificate_file.pem>
Note: the certificate file would need to be installed to your VM.
2. The GCP Memorystore documentation recommends using telnet and Stunnel to connect to a secured and encrypted instance.
Something not included in the documentation is that after running telnet localhost 6378 in step 4, you would need to pass the AUTH string in the telnet console:
AUTH <auth_string>
+OK
PING
+PONG
After that, you can PING the instance in step 5, skipping sending the AUTH string will return this error: -NOAUTH Authentication required. Besides that, you should follow as documented the rest of the steps.
I've got three servers, HC(home client), ECS(elastic computing server), TS(target server). TS has a whitelist containing Ip of ECS but not HC, hence a proper way for HC to login to TS is through ssh forwarding. I got both two kinds of ssh forwarding method to work below,
Method I: make a tunnel between HC and ECS:
on HC: ssh -L HC_Port:TS_Ip:22 ECS
command ssh -p HC_Port 127.0.0.1 on HC works to ssh login to TS
Method II: make a tunnel between ECS and TS:
on HC: ssh -L 0.0.0.0:ECS_Port:127.0.0.1:22 ECS
command ssh -p ECS_Port ECS_Ip on HC also works to ssh login to TS
Suppose some sensitive data is transmitted through ssh within a tunnel, which method is more safe and provider of ECS is not that easy to get the decrypted data. Many thanks!
I believe Method I is a better choice. The key pair to encrypt and decrypt data transmitted between home client and target server is absolutly unknown to the elastic computing server. while Method II isn't.
I am trying to create a bridge with Azure IoT Hub.
The configuration of mosquitto bridge is following:
connection Azure
address <my_hub_name>.azure-devices.net:8883
# error | information | notice | warning | all | debug
log_dest stdout
log_type all
## Auth Info
remote_username <my_hub_name>.azure-devices.net/<my_dev_name>/?api-version=2018-06-30
remote_password <SAS>
remote_clientid <my_dev_name>
bridge_cafile cert.pem
## some config
try_private false
cleansession true
start_type automatic
bridge_insecure false
bridge_protocol_version mqttv311
bridge_tls_version tlsv1.2
notifications false
## Topics
topic devices/<my_dev_name>/messages/events/# out
And I get the following output:
Opening ipv6 listen socket on port 1883.
Bridge local.<my_dev_name> doing local SUBSCRIBE on topic devices/<my_dev_name>/messages/events/#
Connecting bridge Azure (<my_hub_name>.azure-devices.net:8883)
Bridge <my_dev_name> sending CONNECT
Received CONNACK on connection local.<my_dev_name>.
Bridge local.<my_dev_name> sending UNSUBSCRIBE (Mid: 1, Topic: devices/<my_dev_name>/messages/events/#)
Received UNSUBACK from local.<my_dev_name>
Socket error on client local.<my_dev_name>, disconnecting.
Bridge local.<my_dev_name> doing local SUBSCRIBE on topic devices/<my_dev_name>/messages/events/#
Connecting bridge Azure (<my_hub_name>.azure-devices.net:8883)
Bridge <my_dev_name> sending CONNECT
Received CONNACK on connection local.<my_dev_name>.
Bridge local.<my_dev_name> sending UNSUBSCRIBE (Mid: 1, Topic: devices/<my_dev_name>/messages/events/#)
Received UNSUBACK from local.<my_dev_name>
Socket error on client local.<my_dev_name>, disconnecting.
...
Wireshark shows that for unknown reason Azure sends me a packet with FIN bit set, which results into connection reset.
At the same time mosquitto_pub is able to send a packet with same parameters (host, username, password). The utility mosquitto_sub also works without errors, but does not receive any of messages published by mosquitto_pub.
Spent several days trying to figure out the correct configuration without any success (including, of course, search on stackoverflow). I will be very appreciated for any hints.
As far as I know, nobody could connect to our IoT Hub before, so probably there maybe an issue with created hub. Unfortunately, learn.microsoft.com looks more like a quest rather than a help.
EDITED: corrected the topic parameter in configuration from "in" to "out".
As inferred from the comments.
The problem will be that the 2 bridges will have generated the same client id.
Client IDs need to be unique across all clients connected to the broker. If a second client connects with the same client id the spec says the broker must disconnect the fist one.
The disconnected client then tries to reconnect and this results in the other broker being kicked off, which then starts a feedback loop with each client kicking the other off as it reconnects.
Almost all connection errors were resolved by accurate setup of certificate and broker configuration. Except one and its description follows.
We create a bridge with above credentials (certificate, SAS login/password/clientid) - everything works fine.
The bridge is configured with following topic rule:
topic # both 0 /devices/ devices/<my_dev_name>/messages/events/
If I publish the following to my local broker:
mosquitto_pub \
-h 10.0.2.15 -p 1883 \
-t "/devices/foobar" \
-m "{\"foo\" : \"bar\"}" \
-d
everything is fine. But if I publish a bit more long topic
mosquitto_pub \
-h 10.0.2.15 -p 1883 \
-t "/devices/foo/foobar" \
-m "{\"foo\" : \"bar\"}" \
-d
I get connection reset error:
1607623721: Received PUBLISH from mosq-52yqOrz6C6riwvUUF3 (d0, q0, r0, m0, '/devices/foo/foobar1', ... (16 bytes))
1607623721: Sending PUBLISH to local.<my_dev_name> (d0, q0, r0, m0, 'devices/<my_dev_name>/messages/events/foo/foobar1', ... (16 bytes))
1607623721: Received DISCONNECT from mosq-52yqOrz6C6riwvUUF3
1607623721: Client mosq-52yqOrz6C6riwvUUF3 disconnected.
1607623721: Socket error on client local.<my_dev_name>, disconnecting.
I do not understand why Azure disconnects my bridge. I can make about a hundred messages to the topic /devices/foobar in 2-3 seconds without any complaints, but only one message to /devices/foo/foobar results into immediate socket error.
Probably, there is some restriction, but I can not find any of them, except the total maximum number of messages during one day.
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
Let me explain my very strange problem. I have one server (Linux Debian Jessie) which had access to my git repository on gitlab.com
Two days ago, I tried to pull some modifications on this server with a simple git pull. I received an error message :
ssh: connect to host gitlab.com port 22: Connection timed out
Si I have done some tests
1. TELNET
To understand why, I have tried a telnet on 22 port = TIMEOUT
2. IPTABLES
I checked my iptables to be sure that SSH port was allowed. It is. If I try a telnet on another service for example like github.com, it works. So I'm allowed in OUTPUT on this port.
3. PING
I thought a ip translation problem. I have done a ping, I obtain this message :
PING 104.210.2.228 (104.210.2.228) 56(84) bytes of data.
--- 104.210.2.228 ping statistics ---
87 packets transmitted, 0 received, 100% packet loss, time 86534ms
4. FAIL2BAN
I use fail2ban, so I have checked if gitlab was in jail address, but it seems not.
So my problem is that I can't reach gitlab.com
If I try from my local machine or from another server, I don't have this problem. It works.
I can't reach gitlab.com only from this server but I don't know why. Maybe someone has an idea which cans be very precious to help me ?
Probably some modification of firewall caused this. For a quick solution use http protocol instead of ssh. Change your url in the git config file to http.
git config --local -e
change entry of
url = git#gitlab.com:username/repo.git , to
url = https://gitlab.com/username/repo.git
You need to give your username and password to authenticate yourself while making a push or pull though as it's http based.