I am working with Redis 3.2 and while connecting to the sentinel from a differnt machine I get the following error:
Trying X.X.X.X...
Connected to X.X.X.X.
Escape character is '^]'.
-DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
Connection closed by foreign host.
Can somene help me resolve this?
From redis 3.2, Sentinel by default, is not reachable from interfaces other than localhost.
Either use the 'bind' directive to bind to a list of network interfaces, or disable protected mode with "protected-mode no" by adding it to this configuration file.
For example you may use one of the following:
bind 127.0.0.1 192.168.1.1
protected-mode no
For testing, you can try
redis-server --protected-mode no
This will set Redis protected mode to no.
As from documentation suggested steps.
1) Just disable protected mode sending the command 'CONFIG SET
protected-mode no' from the loopback interface by connecting to Redis
from the same host the server is running, however MAKE SURE Redis is
not publicly accessible from internet if you do so. Use CONFIG REWRITE
to make this change permanent.
2) Alternatively you can just disable the protected mode by editing
the Redis configuration file, and setting the protected mode option to
'no', and then restarting the server.
3) If you started the server manually just for testing, restart it
with the '--protected-mode no' option.
4) Setup a bind address or an authentication password. NOTE: You only
need to do one of the above things in order for the server to start
accepting connections from the outside.
Related
The scenario is as follows: I have a VPS (Droplet) in Digital Ocean (DO), I connect via putty-ssh, however I must have another user enabled with root privileges and with password access (without ssh), this is because When there are connection problems through putty-ssh, I must enter through my DO account, and access the droplet console using that user with a password to fix the problem. This usually happens every time I restart the server and I can not connect with any user from putty, the connection is rejected. The solution is simple, restart ufw and everything solved.
However I open a door for hackers who can easily break this user password with all privileges. The idea is to allow this user to connect only from my personal IP, but the Ubuntu firewall only allows IP / port / application rules, no user can be referenced. How could I solve this problem?
After much research and testing and more tests, specifically with the commands telnet and login, I discovered something I did not know; when the SSH service is active, only ssh connection with a private key is allowed, no other connection is allowed, even with ssh+password. This feature, either integrated into Ubuntu, or is implemented by Digital Ocean, I guess the first.
Considering this, there is no problem that raised in this question; no one can connect to the server unless you have the private key, and if you also only allow the ssh connection from a specific IP, the security is very good. By configuring the firewall in this simple way, it will be sufficient:
ufw status verbose
To Action From
-- ------ ----
8000 ALLOW IN Anywhere
6666/tcp ALLOW IN 15.15.15.15
8000(v6) ALLOW IN Anywhere (v6)
Port 8000 for incoming requests from HTTP and HTTPS clients, which will be managed by django, and any port other than the default 22 for ssh, specifying the private IP of my computer, I can only connect from my computer with the corresponding private key. We will also have to modify the ssh configuration file which is the file /etc/ssh/sshd_config replacing port 22, PasswordAuthentication no and restarting the service with service ssh restart.
I have attempted everything recommended by the following error message:
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
My /etc/redis/sentinel.conf:
daemonize yes
sentinel myid XXX
sentinel monitor master XXX 6379 2
sentinel down-after-milliseconds master 60000
sentinel config-epoch master 0
protected-mode no
bind 0.0.0.0
port 26379
EDIT: My /etc/redis/redis.conf:
port 6379
bind 0.0.0.0
protected-mode no
I've also tried adding sentinel auth-pass master XXX.
My entire backend is on private subnets. I'm VPN'd into my datacenter behind the firewall, coming from the same private network, and I can still only connect locally without getting that frustrating error message.
Server Environment: Debian 8, Redis 3.2.6
Client Environment: Ubuntu 16.10, redis-cli 3.2.1
Redis instances: 3
Sentinel instances: 3
I've done not just one, but 3/4 of the things suggested (didn't set the command-line flags). Does anyone have any guidance or ideas? I'm clearly missing something that I've been unable to figure out from the error message, documentation, Stackoverflow, Google, and trial & error. I figured I'd post a question here first, before diving into the source code.
Any help is appreciated. Thanks!
... and, yes, I've restarted the daemons after configuration changes. :)
https://www.reddit.com/r/redis/comments/3zv85m/new_security_feature_redis_protected_mode/
As you know we got several problems from unprotected Redis instances exposed to the internet. I covered the reason why a restrictive binding to 127.0.0.1 by default may be an usability concern and, even worse, may not fix the problem (hey just comment the "bind" statement and restart!) in my blog post.
The same blog post introduced an attack that was heavily used by script kiddies to break into Redis instances (serious security researchers where already able to do this, I guess).
So I finally decided to do something before Redis 3.2 official release: Protected mode is the result and will be merged into 3.2 RC2.
The feature is already available in the unstable branch, introduced by this commit. This is how it works.
If and only if:
Protected mode is enabled (this is the default both in the configuration file and in the configless default).
AND IF No AUTH password is configured.
AND IF No "bind" directive is used in order to restrict Redis to certain interfaces.
Then Redis only accepts connections from the loopback IPv4 and IPv6 addresses. External connections are accepted just for the time to send the client an error that makes the user aware of what is happening:
> PING
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients.
In this mode connections are only accepted from the lookback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:
Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent.
Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server.
If you started the server manually just for testing, restart it with the --protected-mode no option.
Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
This should protect errors in a reasonable way while providing users with a clue instead of a connection refused. Please share your feedbacks so that we can make changes to this feature if needed, before it will get merged into Redis 3.2 RC2. Thanks.
log:Creating Server TCP listening socket （myip:port）: bind: Cannot assign requested address
my redis.conf
bind 10.114.234.11
when i cofig like this
bind 127.0.0.1
it works well
You likely do not currently have any interfaces set up for the 10.x.x.x subnet. If you're on any flavor of Linux, ifconfig should be able to tell you which interfaces are currently set up. For example, I'm running Mint 17:
$ ifconfig | grep "inet addr"
inet addr:127.0.0.1 Mask:255.0.0.0
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
So I (like you) would not be able to bind Redis (or most any other service requesting a TCP socket) to 10.x.x.x. If you are really trying to listen for connections on that subnet, you will need to change your network setup (how exactly that would be done depends largely on your operating system).
I also faced same issue while setting up redis for remote access. I was using google cloud platform and we created Google compute engine VM instance where we installed our Redis server. Redis doesn't ship with by default with security configured. You have to perform some steps to secure it. By updating IP address in redis.conf in bind will allow access only from that IP addresses. When we were doing it, we were getting same error.
To solve this issue we haven't added IP addresses in redis.conf file instead in Google cloud firewall rules when we add port open record in network -> IP ranges you can specify IP address which you want allow to access redis. In redis.conf file update from bind 127.0.0.1 to bind 0.0.0.0. So basically we will restrict it from Google cloud firewall rules dashboard.
Below are steps to add IP address restrictions:
Login to your google cloud console
Navigate to VPC Network -> Firewall Rules
Click on CREATE FIREWALL RULE or edit existing one if it's already there
In Source IP ranges add your IP address to allow access only - See below screenshot
Once you create this rule add this source tags under your VM instances network type and you are done.
I have faced the same issue when I changed the default redis.conf to custom Redis conf and after changing the bind as below then it started working, Please be aware that the below conf will open the Redis connection from all sources.
bind 127.0.0.1 -::1 to bind 0.0.0.0 -::1
At /etc/redis/redis.conf
Please change
bind 127.0.0.1 ::1
to
bind 0.0.0.0
then restart
/etc/init.d/redis-server restart
It's work to me
I can't access to AWS EC2 instance from one day.
(AMI: ubuntu/images/ebs/ubuntu-precise-12.04-amd64-server-20121001 (ami-22ad1223))
$ ssh -v -i mykey.pem ubuntu#XXX.XXX.XXX.XXX
OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: connect to address xxx.xxx.xxx.xxx port 22: Operation timed out
ssh: connect to host xxx.xxx.xxx.xxx port 22: Operation timed out
This is my "Security Groups" setting in EC2.
I did not change the setting from the time had a good connection.
Ports Protocol Source
22 tcp 0.0.0.0/0
80 tcp 0.0.0.0/0
3000 tcp 0.0.0.0/0
3006 tcp 0.0.0.0/0
I've tried many times to restart the server.
Web server is going well. However SSH connection is not.
What could be problem and how to make it work?
My usual checklist:
On AWS console: is the Instance up and healthy?
Is it in a public Subnet?
Does it have a public ip?
Does the VPC have an associated Internet Gateway?
Does it have the Routing Table to the Internet Gateway? (Attached to the subnet?)
Are the Network ACL rules default?
Does the Security group allow ping? If yes, does the ping work?
Does the Security group allow SSH inbound?
If there is still no clue, then fire up a new instance (from a base AMI) in the same VPC. Connect to it via SSH. If it was successful, try to ssh from that instance.
I too faced the same issue. Actually, by mistake, I deleted the default Internet Gateway.
Go to VPC and click "Internet Gateways" from the left menu.
Click "Create internet gateway" button and provide Name tag (any name - optional) and click create.
By default, it is detached. So click the Actions drop-down and select "Attach to VPC" and attach it with default VPC
Now go to "Route Table" and select default route table and edit the route by clicking "Edit routes" button under Routes tab
Then in the Destination text box provide "0.0.0.0/0" and in target select the newly created Internet gateway (starts with igw-alphanumeric) and save the route.
Now you should be able to SSH EC2 instance.
For newbies to AWS, like me, remember the hostname can change if you reboot or stop/start your instances. So remember to use the right hostname - visible in the description of your instance each time you ssh.
If this happens "from one day", the IP your AWS EC2 instance associated with may be blocked from this day.
If the IP is blocked, you need to add a new dynamic IP and associate this new dynamic IP with your AWS EC2 instance.
Steps:
1.Go to "Elastic IPs".
2.Allocate new address.
3.Choose this new address. Click "Actions" and "Associate address".
4.Select your instance and Click "Associate".
In my case, adding new dynamic IP to my AWS EC2 instance fix the problem.(My problem was I can't access to AWS EC2 instance from one day too)
Kindly create a new security group and select type SSH
SSH
TCP
22
0.0.0.0/0
In addition to Adam's answer, also check if your public subnet's RT table is using the IGW and the private Subnets' RT has 0.0.0.0/0 -> NAT instance Id.
Check that you are connecting to the public dynamic IP or associate an ElasticIP and connect to it.
I was using public wifi in the library and that was not letting me connect, which I came to know when I switched to my mobile hotspot wifi (password protected). Try switching to a protected network.
Even I also faced this same problem, good to know i have not allowed from route table.
Check EC2 Instance associated
And try these steps
subnet,Route table and allowed CIDR blocks
key pair associated with EC2 Instance
security group ssh port 22 allowed or not.
If you are accessing from a new machine, then make sure the IP of the machine you are accessing from is included in the inbound rules. If not add a rule
SSH | TCP | Port:22 | Source: MY IP
For me, I had to delete all my rules for the security group for the particular instance and create new rules for the same ssh, http and https
For some reason after stopping the instance and starting it later, my IP changed... probably because I switched my wifi connectivity device.
But putting new rules with the new IP address worked! You can check the ip by googling "myip"
Well, if this happened all of a sudden, try disconnecting and connecting back to your VPN (if accessing through a VPN). It might work!
I was able to fixed it simply by following this instruction
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html
It sets up your private key pair as well as security group. The issue I think mainly because the default security group doesn't has a ssh inbound for your local IP setup.
If none of the troubleshooting steps above work for you, make sure that your EC2 container meets all system requirements for the application(s) you're running on the container. SSH will sometimes not be able to start if the memory runs out before getting to the SSH service.
Example: I was perfectly able to SSH into my EC2 container when I first launched it. I then proceeded to install Mailcow. My issue with SSH arose after restarting my container because the application I had installed required heavy services -- Docker, for example. After reading the system requirements from Mailcow, I realized a t2.micro wasn't even close to what I needed to run everything. I changed to a t3.large, and all worked perfectly.
Even after doing this for awhile, you can sometimes forget the most basic steps and requirements.
Try stopping the ec2 instance and then restarting. It worked for me!
I'm trying to setup JMeter in a distributed mode.
I have a server running on an ec2 intance, and I want the master to run on my local computer.
I had to jump through some hopes to get RMI working correctly on the server but was solved with setting the "java.rmi.server.hostname" to the IP of the ec2 instance.
The next (and hopefully last) problem is the server communicating back to the master.
The problem is that because I am doing this from an internal network, the master is sending its local/internal ip address (192.168.1.XXX) when it should be sending back the IP of my external connection (92.XXX.XXX.XXX).
I can see this in the jmeter-server.log:
ERROR - jmeter.samplers.RemoteListenerWrapper: testStarted(host) java.rmi.ConnectException: Connection refused to host: 192.168.1.50; nested exception is:
That host IP is wrong. It should be the 92.XXX.XXX.XX address. I assume this is because in the master logs I see the following:
2012/07/29 20:45:25 INFO - jmeter.JMeter: IP: 192.168.1.50 Name: XXXXXX.local FullName: 192.168.1.50
And this IP is sent to the server during RMI setup.
So I think I have two options:
Tell the master to send the external IP
Tell the server to connect on the external IP of the master.
But I can't see where to set these commands.
Any help would be useful.
For the benefit of future readers, don't take no for an answer. It is possible! Plus you can keep your firewall in place.
In this case, I did everything over port 4000.
How to connect a JMeter client and server for distributed testing with Amazon EC2 instance and local dev machine across different networks.
Setup:
JMeter 2.13 Client: local dev computer (different network)
JMeter 2.13 Server: Amazon EC2 instance
I configured distributed client / server JMeter connectivity as follows:
1. Added a port forwarding rule on my firewall/router:
Port: 4000
Destination: JMeter client private IP address on the LAN.
2. Configured the "Security Group" settings on the EC2 instance:
Type: Allow: Inbound
Port: 4000
Source: JMeter client public IP address (my dev computer/network public IP)
Update: If you already have SSH connectivity, you could use an SSH tunnel for the connection, that will avoid needing to add the firewall rules.
$ ssh -i ~/.ssh/54-179-XXX-XXX.pem ServerAliveInterval=60 -R 4000:localhost:4000 jmeter#54.179.XXX.XXX
3. Configured client $JMETER_HOME/bin/jmeter.properties file RMI section:
note only the non-default values that I changed are included here:
#---------------------------------------------------------------------------
# Remote hosts and RMI configuration
#---------------------------------------------------------------------------
# Remote Hosts - comma delimited
# Add EC2 JMeter server public IP address:Port combo
remote_hosts=127.0.0.1,54.179.XXX.XXX:4000
# RMI port to be used by the server (must start rmiregistry with same port)
server_port=4000
# Parameter that controls the RMI port used by the RemoteSampleListenerImpl (The Controler)
# Default value is 0 which means port is randomly assigned
# You may need to open Firewall port on the Controller machine
client.rmi.localport=4000
# To change the default port (1099) used to access the server:
server.rmi.port=4000
# To use a specific port for the JMeter server engine, define
# the following property before starting the server:
server.rmi.localport=4000
4. Configured remote server $JMETER_HOME/bin/jmeter.properties file RMI section as follows:
#---------------------------------------------------------------------------
# Remote hosts and RMI configuration
#---------------------------------------------------------------------------
# RMI port to be used by the server (must start rmiregistry with same port)
server_port=4000
# Parameter that controls the RMI port used by the RemoteSampleListenerImpl (The Controler)
# Default value is 0 which means port is randomly assigned
# You may need to open Firewall port on the Controller machine
client.rmi.localport=4000
# To use a specific port for the JMeter server engine, define
# the following property before starting the server:
server.rmi.localport=4000
5. Started the JMeter server/slave with:
jmeter-server -Djava.rmi.server.hostname=54.179.XXX.XXX
where 54.179.XXX.XXX is the public IP address of the EC2 server
6. Started the JMeter client/master with:
jmeter -Djava.rmi.server.hostname=121.73.XXX.XXX
where 121.73.XXX.XXX is the public IP address of my client computer.
7. Ran a JMeter test suite.
JMeter GUI log output
Success!
I had a similar problem: the JMeter server tried to connect to the wrong address for sending the results of the test (it tried to connect to localhost).
I solved this by setting the following parameter when starting the JMeter master:
-Djava.rmi.server.hostname=xx.xx.xx.xx
It looks as though this wont work Distributed JMeter Testing explains the requirements for load testing in a distributed environment. Number 2 and 3 are particular to your use case I believe.
The firewalls on the systems are turned off.
All the clients are on the same subnet.
The server is in the same subnet, if 192.x.x.x or 10.x.x.x ip addresses are used.
Make sure JMeter can access the server.
Make sure you use the same version of JMeter on all the systems. Mixing versions may not work correctly.
Might be very late in the game but still. Im running this with jmeter 5.3.
So to get it work by setting up the slaves in aws and the controller on your local machine.
Make sure your slave has the proper localports and hostname. The hostname on the slave should be the ec2 instance public dns.
Make sure AWS has proper security policies.
For the controller (which is your local machine) make sure you run with the parameter '-Djava.rmi.server.hostname='. You can get the ip by googling "my public ip address". Definately not those 192.xxx.xxx.x or 172.xx.xxx.
Then you have to configure your modem to port forward your machine that is used to be your controller. The port can be obtained when from the slave log (the ones that has the FINE: RMI RenewClean....., yeah you have to set the log to verbose). OR set DMZ and put your controller machine. Dangerous, but convinient just for the testing time, don't forget to off it after that
Then it should work.