CentOS rsync between servers using keyfile to pass credentials
-
@scottalanmiller said in CentOS rsync between servers using keyfile to pass credentials:
Okay, now do the same thing on the second server. Then take the contents of the public key from the first one and populate the /home/user/.ssh/authorized_keys file on the second server with it.
I'd just do ssh-copy-id Its easier. That way there is no chance the SELinux context (or mode) for that file can change.
-
Hi,
I see scott gave you some answers, but I will try to break it down easier otherwise I missunderstood the question.
So in server A and B
run thisssh-keygen -t rsa
And press enter to accept the defaults
Now in both servers under the user account you will see hidden folder called .ssh which can be found
/home/USERNAME/.ssh
or
/root/.sshAnd inside this folder you will find :
id_rsa.pubCopy the contents of this file in both servers A and B into a new file called and name it authorized_keys and place it in the same directory, for example server A will have key 123 server B will have key 456 in this authorized_keys it should have both entries.
And bam thats it , this is SSH pasword less login, not sure if its the same thing but seems easier and better.
-
@msff-amman-Itofficer Yes.....
Except for the root bit, that's not considered a good practice. If you want remote access as root, ssh in with a normal user account and then use sudo. Gives you a way to track what is being done in the logs.
-
This is still requiring the ssh access key, and the root password of the remote host.
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
This is still requiring the ssh access key, and the root password of the remote host.
Which did you do?
-
Generated a public and private key on each host.
Moved the public key onto each host overwriting authorized_keys.
Using
rsync -avztopgr -e "ssh -i $HOME/.ssh/authorized_keys" /home/admin/summit-reg/wp-config.php sr2i:/home/admin/summit-reg/
I'm still asked for root password.
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
This is still requiring the ssh access key, and the root password of the remote host.
???
Two different things! You ssh into the remote with the standard user. Remote access is now established and you're running as if local.
sudo does not require the root password, it requires the user authenticate to the system when used. With sudo you never require the root password. su does require the root password, but good security practice would not have anyone use su.
Also note I say authenticate to the system, a great number of different ways to do that without passwords.
-
@travisdh1 That is the goal, to use the public and private keys to authenticate between the servers and then rsync any changes from host 1 to host 2.
-
Any ideas guys?
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
Any ideas guys?
Any error? What did you do?
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
@travisdh1 That is the goal, to use the public and private keys to authenticate between the servers and then rsync any changes from host 1 to host 2.
Right, using ssh-copy-id is the easiest way to get the ssh keys to the proper places once generated. After that, just use rsync with ssh like normal and it won't ask for a password.
rsync -e ssh user@host:/dir /local/dir
I've distributed keys manually in the past, but ssh-copy-id is so much faster and foolproof.... yes, I can be a fool with ssh keys quite easily.
-
@Reid-Cooper No errors, just a prompt for the root password to connect to the server.
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
@Reid-Cooper No errors, just a prompt for the root password to connect to the server.
Is it root's account that you set the public key to be used for? /root/.ssh instead of /home/user/.ssh
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
@Reid-Cooper No errors, just a prompt for the root password to connect to the server.
Let's back up a step here. Do the local files need root permission to read, and does the remote directory need root permission to write? If so, you do need to create an ssh key for the local machine root and use ssh-copy-id to copy that to the remote one.
-
You could create a user on each system, specific to this task; and give that user restricted passwordless sudo access to only run the specific rsync command you need to have run.
Throw your rsync command in a script and restrict your user's passwordless sudo access to running that specific script. Et voila! Authentication issues resolved.
--edit--
I think this can help point you in the right direction: https://serverfault.com/questions/596940/sudoers-nopasswd-how-to-grant-access-to-a-specific-ln-command
-
Ok well I can ssh between the servers, but both are asking for the root/.ssh/id_rsa passphrase and the root credentials.
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
Ok well I can ssh between the servers, but both are asking for the root/.ssh/id_rsa passphrase and the root credentials.
That is where you would want passwordless sudo access tied to a specific user that will ONLY have that sudo access restricted to running your rsync command.
You'll be able to log into the remote system using your keys, and with passwordless sudo enabled, you'll not be prompted for a password when you run your sudo rsync... command.
-
@RamblingBiped why can't I use the keys generated for this, rather than needing an outside account with passwordless sudo access?
-
The goal is to only use the public and private keys to allow me to sync files from one server to the other via crontab (without needing to be prompted for credentials)
The public and private keys should suffice for that.
-
@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:
@RamblingBiped why can't I use the keys generated for this, rather than needing an outside account with passwordless sudo access?
You can, I was just suggesting how I have set up a similar environment in the past. I didn't want to have to screw around with my user's sudo settings. Also I didn't want a job/task such as this tied to a specific user's account either. By setting it up as a separate user it keeps the task from breaking when I leave the company and they kill my credentials.