Step 1 - Setup public SSH keys
On our origin server, we will generate public SSH keys with no password:
ssh-keygen -f ~/.ssh/id_rsa -q -P "" cat ~/.ssh/id_rsa.pub
This is our public SSH key that can be placed on other hosts to give us access:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLVDBIpdpfePg/a6h8au1HTKPPrg8wuTrjdh0QFVPpTI4KHctf6/FGg1NOgM++hrDlbrDVStKn/b3Mu65//tuvY5SG9sR4vrINCSQF++a+YRTGU6Sn4ltKpyj3usHERvBndtFXoDxsYKRCtPfgm1BGTBpoSl2A7lrwnmVSg+u11FOa1xSZ393aaBFDSeX8GlJf1SojWYIAbE25Xe3z5L232vZ5acC2PJkvKctzvUttJCP91gbNe5FSwDolE44diYbNYqEtvq2Jt8x45YzgFSVKf6ffnPwnUDwhtvc2f317TKx9l2Eq4aWqXTOMiPFA5ZRM/CF0IJCqeXG6s+qVfRjB root@cloudads
Copy this key to your clipboard and login to your destination server.
Place this SSH key into your ~/.ssh/authorized_keys file:
If your SSH folder does not exist, create it manually:
mkdir ~/.ssh chmod 0700 ~/.ssh touch ~/.ssh/authorized_keys chmod 0644 ~/.ssh/authorized_keys
Step 3 - Rsync files over
Rsync is a great utility, as it allows you, among many other things, to copy files recursively with compression, and over an encrypted channel.
We will copy a file from our origin server (198.211.117.101) in /root/bigfile.txt over to our destination server (IP: 198.211.117.129) and save it in /root/bigfile.txt as well.
Login on 198.211.117.101 and rsync the file over to 198.211.117.129:
rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress /root/bigfile.txt 198.211.117.129:/root/
If you are using a different user, for example "username" then you would have to append it in front of destination server. Make sure to have your public key in that user's ~/.ssh/authorized_keys file:
rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress /root/bigfile.txt username@198.211.117.129:/
The SSH options are useful to keep Rsync quiet and not prompting everytime you connect to a new server.
Verify that you have received the file on destination server (198.211.117.129):
ls -la /root/bigfile.txt
And you are all done!
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
author
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Become a contributor for community
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
DigitalOcean Documentation
Full documentation for every DigitalOcean product.
Resources for startups and SMBs
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
The developer cloud
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Get started for free
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.
The SSH command given in this article is dangerous. It leaves you wide open to man-in-the-middle attacks and in day-to-day operation you really should not be specifying those SSH options. The author seems to acknowledge this in the comments but then just glosses right over it.
Instead a better idea is to manually SSH into the server with
ssh <user>@<ip_or_hostname>and accept the host key prompt that SSH gives you. Then instead of using-e "ssh <options>"just use-e ssh.rsyncwon’t prompt you with anything because you’ll have already accepted the other server’s SSH key.Again, the advantage of this method is that you’re not disabling any important security checks. They’re there and on for a reason and disabling them is a very bad idea unless you know exactly what you’re doing and the risk you’re taking.
Am I missing something?
Just one additional - updating hostname in
/etc/hostsfor correct work ofsudoand resolving hostname of new dropletHere’s the command I’m running in trying to send it to root:
rsync -avz -e “ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null” --progress /root/sitio.zip 138.68.9.206:/root/
And here is the full error:
shh: connect to host 138.68.9.206 port 22: No route to host rsync: connection unexpectedly closed (0 bytes recived so far) [sender] rsyng error: unexplaind error (code 255) at io.c(226) [sender=3.1.0]
hi i got some issues. i tried rsync to another stagging server command: rsync -v -e ssh /etc/openvpn graylog.crt olive@192.168.122.225:~ i got this error: Permission denied (publickey). rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(235) [sender=3.1.2] any suggest?
I have access from my pc to both of my droplets with ssh and putty. At my pc I have the public and the private (.ppk) ssh keys. This works fine.
Now I want both droplets to rsync in private network. I assueme I can still use the public and private keys I also use on pc in putty. But where do I put public and private key, so the first droplet knows that he can use this ssh keys to connect to droplet2 ?
In this article I did not saw anything about the private key?!
Super-useful and works like a charm, thank you very much.
I’m having the same issue. It keeps asking for the password. I’m on a windows 8.1 machine using cwRsync_5.4.1_x86_Free to generate my keys and rsync my files.
Had trouble with all the help here but I did find this site http://archive.oreilly.com/pub/h/38
This worked for me: //copied bigfile.text in c:/root/ to server(once logged in of course) rsync -ave ssh /root/ /root/bigfile.txt/
Can you update this tutorial to make it explicit which shell commands are issued on the virtual host and which are entered on the users local pc?
very useful Thanks