hey guys, sorry for asking a dumb question, but some of the terminology online is not grasping me well, and still leaving me confused


in crontab -e

I have a shell script that contains

rsync /home/willc86 willc86@server02:/home/willc86/backup

the script works good by itself, however i have to put in a password which I understand. i know crontab works, because i used rsync script in the local machine. I am just having problems trying to sync it to another server

how do i get this rsync going in crontab to back it up to another server.

A question, and something to try:

* The password you have to type, is it the password for the key, or the password for the destination server?

* If you copy the contents of the sending account's ~/.ssh/id_rsa.pub to the receiving account's ~/.ssh/authorized_keys does it start working? If not, the answer to the above question becomes quite important.

the password i type in is what i use to log on locally to the server.
example:
username: user1
pass: pass

that will log me in


i am sorry but i dont understand the 2nd part =/
so should i try copying the /id_rsa.pub
to the authorized_keys?

should i generate keys? would it still ask for a password?




i actually checked to see if i have a .ssh/id_rsa.pub file and i dont =/
do i have to generate one?

Good .. I was just making sure you didn't have keys already generated which had their own password.

Yes, run "ssh-keygen" on the sending server (the one running the cron job) and just press Enter when it prompts you for a filepath and for a passphrase. Adding a passphrase to a key is an additional layer of security, but it gets in the way when you're automating tasks like this.

After ssh-keygen has run, there will be a /home/willc86/.ssh/id_rsa.pub file on that server. This is the public key part of the private/public keypair.

It is safe to pass the public key around as long as you keep the private key to yourself (the id_rsa file, without the .pub).

On server02, create a directory /home/willc86/.ssh, and copy the public key id_rsa.pub from the sending server to server02:/home/willc86/.ssh/authorized_keys -- this tells server02 that ssh connections using the private key matched to this public key are to be trusted, and to not require a password.

One last thing is needed: ssh or scp from the sending server to server02, so that the sending server gets an entry in .ssh/known_hosts. Afterwards, you should be able to ssh or scp from the first server to server02 without any prompts or entering a password.

There's a chance your sshd on server02 is configured to disallow this kind of authentication, but it's unlikely. If the instructions here don't work, show the commands you used and their responses, and the contents of /etc/ssh/sshd_config here and we'll sort it out.

thank you so much! it works =)

did exactly that created a key and sent it over to authorized_keys

i do have a question. How does linux know to look in .ssh/authorized_keys if i just did that directory myself. What if I were to rename authorized_keys to something else?

1 members found this post helpful.

rsync defaults to using ssh for its data transport, which means it opens an ssh connection to the remote machine, where an sshd process is listening on TCP port 22.

When the sshd program accepts a connection, it is programmed to look in some standard locations for configuration and authentication data.

One of those locations (which can be overridden via configuration) is the user's .ssh directory. If that .ssh directory exists, it will look for files in it, like "config" and "authorized_keys" and "known_hosts".

It doesn't matter if the directory and the files in it were created by you, or someone else, or a script, or the "ssh-keygen" program, or created for you when the willc86 user account was created. If they exist, and contain information of a format sshd understands, sshd will use them. It's a program, and it was written to behave thus.

If you rename "authorized_keys" to some other name, sshd will not recognize it unless it is reconfigured to look for the file by its new name.

For a description of sshd's configuration/authentication-seeking behavior, see: http://www.manpagez.com/man/8/sshd/ and http://www.manpagez.com/man/5/sshd_config/ :-)

1 members found this post helpful.