Running the command redis-server it returns:
The server is now ready to accept connections on port 6379
Trying to connect in my browser localhost:6379 I get this message:
Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.
Can anyone help me fix this error please?
You'll need to use a Redis client to connect to Redis, not your browser. Look at this page for a few https://redis.io/clients, or use redis-cli, or even just plain Telnet.
Related
I think there is a simple answer to this question, but everything I find online is about preventing SSH client connections from timing out.
In this case, the client has established a connection to the server, and remains connected. Then the connection is disrupted, say the ethernet cable is unplugged, or the router is powered off.
When this happens, the client connection is not dropped.
The ssh client connection is part of a script and the line that performs the ssh login looks like this:
ssh -Nn script#example.com
The .ssh/config contains the following parameters:
Host *
ServerAliveInterval 60
ServerAliveCountMax 2
When these disconnects occur, I'd like the client ssh connection to timeout, and allow the script to attempt reconnect...
Thanks!
I guess I was wrong about this being a simple question, since no one was able to provide an answer.
My further reading and asking led to one reply on the openssh IRC channel, around 2022-06-06. I was advised that the options:
ServerAliveInterval 60
ServerAliveCountMax 2
Often don't disconnect the client as one might expect.
The ssh_config man page:
ServerAliveCountMax
Sets the number of server alive messages (see below) which
may be sent without ssh(1) receiving any messages back from
the server. If this threshold is reached while server alive
messages are being sent, ssh will disconnect from the server,
terminating the session...
The default value is 3. If, for example, ServerAliveInterval
(see below) is set to 15 and ServerAliveCountMax is left at
the default, if the server becomes unresponsive, ssh will
disconnect after approximately 45 seconds.
Seems to pretty conclusively state that disconnecting on lack of server response is the intention of these parameters. However, in practice this doesn't happen in all cases. Maybe the caveat here is: "while server alive messages are being sent"?
If the application calls for a reliable client disconnect when the server becomes unresponsive, the advice was to implement an external method, separate from the ssh client login script, that monitors server responsiveness, and kills the ssh client process on timeout.
I installed redis on my computer and opened 1 redis-server and 2 redis-cli. If I type "shutdown save" command in the first redis-cli terminal, it will close both the server and the first redis-cli. Then, the second redis-cli won't be able to communicate with redis-server anymore because it has already been shutdown by the other redis-cli. It just doesn't make sense to me. IMO, a server is a standalone service and should always be running. A client should be able to connect/disconnect with a server but never disable a server. Why would Redis allow a client to disable a server which could be shared by many other clients? Consider if the redis server is on a remote machine and the redis clients are on other machines, wouldn't it be very dangerous since if one of the clients shut down the remote server then all other clients will be influenced?
If you don't want clients to execute the SHUTDOWN command (or any other for that matter), you can use the rename-command configuration directive.
As of the upcoming Redis v6, ACL are expected to provide a better degree of control over admin and application command.
No, I think you are getting it wrong. It's application responsibility to allow/disallow certain specific action on remote server. You can simply disallow certain commands so that single cli cannot take down the redis-server.
I am trying to connect to SFTP server using notepad++ plugin NppFTP. However, while connecting to the remote server I always get below error:
Connecting
[SFTP] Connection failed : Timeout connecting to <IP address>
Unable to connect
Disconnected
Here are the important configuration details set in NppFTP window for your reference:
Port: 22
Connection Type: SFTP
Authentication: Try password authentication
I tried to go through some of the solutions stated in few the questions in Stack Overflow but to no avail.
Would really appreciate your suggestions/pointers to resolve this. If it is related to SSH private key, would appreciate if you can provide the steps as well.
Edit: I am able to access the server using another FTP tool FileZilla which eliminates any mess with the access front.
You need to find out more about where the issue is:
Can you ping the server you are trying to connect to?
ping 166.178.233.70
Did you try connecting with another ftp tool, like FileZilla, that gives more detailed log information?
The possible issues are numerous:
The ftp server config: set up to exclude connections from certain ip addresses or domains, requires public/private keys...
Your local connection/VPN is not passing the connection.
It may require a
I got the same issue. The problem was solved after I updated NppFTP.
in my case, I changed the wifi connection then, it works.
I discovered today that if I ssh-forward the local port X to ssh server port Y, and no process is listening on port Y, I can still connect to local port X (I don't get the usual "connection refused" error).
I did my test with 2 different SSH clients on a windows host connecting to a linux server.
After a bit of reflexion, I came to the conclusion that from a pure network point of view, this is the behaviour I should expect: the SSH client is actually listening on localhost:X, so the connection is possible.
Nevertheless, this leads to a problematic situation in which I have an apparently connected socket that talks to nobody. Even sending data on the socket is a successful operation.
So my question: does the SSH protocol manage this situation in some ways, i.e. do I have strategies for detecting this situation? And if yes, may I hope support for this feature on some SSH clients and APIs (today I'm using ssh.net, that does not seem to offer this feature).
If not, how would you proceed for detecting the situation? Timeout on answer?
Thanks for your help,
Alberto.
The only logical behavior would be to close client connection if the server can't connect to the remote side, but that would not be much better than just a hanging connection.
Also there can happen situation when the SSH server is waiting for the remote connection for a minute or two before giving up, so the client's connection will be opened for this period of time anyway.
So there's actually no logical alternative rather than a hanging client connection.
I want to check if Push Notification can be done using a hosting server before purchasing hosting plan.what is the shortest way to check this.Also i have godaddy.com's hosting plan can i use push notification from godaddy's hosting server?
You can confirm definitively by using telnet and specifying which port to connect to. From the command line run:
MyServer:~ Home$ telnet gateway.sandbox.push.apple.com 2195
Trying 17.149.34.143...
Connected to gateway.sandbox.push-apple.com.akadns.net.
Escape character is '^]'.
If there is an error connecting then it will just hang and not return - the above shows a working example where I can connect.
You'll need an SSH login to your hosting service to test it this way, and unfortunately you are unlikely to be able to test it without buying an account - so you probably have to rely on asking their customer services.
Be aware that basic hosting packages normally just provide an FTP login to let you serve up files, you'll usually have to pay extra to get a hosting package which provides SSH access (which you'll need if you are going to run code to connect to the Apple Push Notification Servers).
if your system does not have telnet, you can make use of curl to do the job.
curl -v telnet://gateway.sandbox.push.apple.com:2195
here -v is for verbose output
Use Curl if telnet command is not available.
curl -v telnet://gateway.sandbox.push.apple.com:2195
* Rebuilt URL to: telnet://gateway.sandbox.push.apple.com:2195/
* Trying 17.188.137.190...
* TCP_NODELAY set
* Connected to gateway.sandbox.push.apple.com (17.188.137.190) port 2195 (#0)
Press Escape to close the connection
* Closing connection 0
I also had this issue with GoDaddy. Amazon Web Services did the trick for me. It allows you to easily deploy a PHP script which can be called anywhere on the web.
I just purchased my Godaddy account to find out it blocks all connections except 80 and one other. In other words we can't use the 2195 connection that is required. If you find another one please let me know.