What is "AUTH" in Redis and how to use and when to use it. It will be helpful if you provide a few examples.
The AUTH command is used to prevent unauthorized access to a Redis instance. You specify a password in the Redis config file. A client that wants to connect to the Redis instance must first call the AUTH command with the correct password in which case the server replies with the OK status code and starts accepting commands. If the password is incorrect or the AUTH command is not called first, all subsequent calls to the Redis instance fail.
Example:
redis 127.0.0.1:6379> AUTH abcd#1234
Related
I am using Redis to store the access token. I want to know if I need to encrypt the token before saving to redis. If yes then please explain why.I am using C# and Stackexchange.Redis library.
As it is stated in the security section of redis documentation
Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.
So it is better to secure the instance instead of every individual data in it. Redis doesn't support encryption, as you mentioned you need to handle in application layer. You need to wrap the commands by encrypt/decrypt methods.
For extra security, i think you must use authentication by setting password at configuration file. It can be a long one and will be saved in the configuration file so every command will require auth as a prerequisite.
If your concern is security of the instances communicating with redis, that's another topic. auth will not help just like encryption secret. Since both secrets are in the hand of attacker, he can retrieve the original data.
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 wondering to encrypt the password for ssl setup of kafka cluster.
my current setup:
listeners=SSL://:9095, PLAINTEXT://:9094
ssl.keystore.location=keystore.jks
ssl.keystore.password=password
ssl.key.password=phoenix
ssl.truststore.location=keystore.jks
ssl.truststore.password=password
security.inter.broker.protocol=SSL
but I dont want to have a plain password , expecting the encrypted this password
I don't think kafka provides any option for storing encrypted password. This doc specifically says Since we are storing passwords in the broker config, it is important to restrict access via file system permissions.
The following worked for me:
Updating Password Configs Dynamically
Password config values that are dynamically updated are encrypted before storing in ZooKeeper. The broker config password.encoder.secret must be configured in server.properties to enable dynamic update of password configs. The secret may be different on different brokers.
Source: http://kafka.apache.org/documentation/#dynamicbrokerconfigs
I tried reading Artifactory user guide but the instructions on SSH authentication were not clear. Can someone explain how to do SSH authentication in Artifactory?
Actually, enabling SSH on Artifactory is fairly straight forward, the client is what may require some additional debugging if it is unable to connect for any reason. The steps for enabling SSH on Artifactory are available in the online documentation for SSH Integration. You simply need to create a key pair on any machine with ssh-keygen installed (most linux distros will have this by default), then click on Admin, select Security -> SSH Server, click Enable SSH and add in the private and public key just created. Select a port and set the custom base url if necessary and Save.
Now, the user in Artifactory that wishes to authenticate with SSH needs to add his public key to his profile. This can be done by simply logging in and clicking your username in the top right corner of Artifactory. Under this section, you will need to add your password again and then you can simply paste the public key in the SSH section, you can read about this process in Updating Your Profile.
That's it, Artifactory is now ready for SSH for that particular user, and any other user can add their public key to their profile to use SSH authentication.
Configuring the client depends on which client you are attempting to setup. The most common use case is GitLFS, so I will share some documentation for setting up Git LFS with SSH to Artifactory.
Most of what you need to setup Git LFS can be found in JFrog's Git LFS Repository Authenticating with SSH documentation, or in JFrog's public solution on Git LFS Authentication. The latter contains an example of what the git config file should look like and also contains relevant information on setting up SSH authentication with an nginx reverse proxy (if you have one configured and running).
If this doesn't answer your question, can you please provide some more details on which client you are using to authenticate and specifically what is not working (any relevant error messages or log output), both Artifactory and client-side.
Our current infrastructure uses ssh keys for passwordless login to our Linux servers.
As our infrastructure grows, managing these authorised keys is getting harder.
As we also have an Active Directory (AD) server, I would like to authenticate the users over ssh using this mechanism, but maintain the passwordless nature of ssh keys.
Is it possible to authenticate the users over ssh without password, using some AD mechanism?
This is usually done via SSH key certificates in order to keep the password-less nature and at the same time have a Central Authority that can be trusted to generate new certificates for each account.
LDAP/Active directory use on login is not advised - apart from having to use passwords, it also becomes a single point of failure for access to any system it manages.
See RedHat documentation on how to do this and also Facebook's good write up on their use of certificate authentication with SSH.
Option 1
This is a good article explaining how to do this.
Storing SSH keys in Active Directory for easy deployment
Basically, it will allow people to post their public keys to your Active Directory and then you can set up a cron script on your servers to fetch a copy of the public keys every 5 minutes or so.
Option 2
You could also use a file server that has all your keys and get each server to fetch from there using a cron script. Obviously, you need a way to verify each key's authenticity especially if you are using FTP or some other insecure protocol. This could be achieved using GPG. You could have a company master GPG key that signs all the employee keys.
Personally, I like option 2 the best because I think it is more secure, but either method should work. Hope this helps!
My approach would be to reduce the problem to an already solved one by
Use active directory to authenticate without password and establish an HTTPS connection using Kerberos. The Dzone Tutorial Configuring Tomcat 7 Single Sign-on with SPNEGO might be a good starting point for that approach.
Wrap SSH into the https-protocol like, see section Wrapping SSH in HTTP(S) at https://unix.stackexchange.com/questions/190490/how-to-use-ssh-over-http-or-https