As part of the 8.0 pre-release announcement, the OpenSSH project stated that they consider the scp protocol outdated, inflexible, and not readily fixed. They then go on to recommend the use of sftp or rsync for file transfer instead.
Many users grew up on the scp command, however, and so are not familiar with rsync. Additionally, rsync can do much more than just copy files, which can give a beginner the impression that it’s complicated and opaque. Especially when broadly the scp flags map directly to the cp flags while the rsync flags do not.
This article will provide an introduction and transition guide for anyone familiar with scp. Let’s jump into the most common scenarios: Copying Files and Copying Directories.
For copying a single file, the scp and rsync commands are effectively equivalent. Let’s say you need to ship foo.txt to your home directory on a server named server.
$ scp foo.txt me@server:/home/me/
The equivalent rsync command requires only that you type rsync instead of scp:
$ rsync foo.txt me@server:/home/me/
For copying directories, things do diverge quite a bit and probably explains why rsync is seen as more complex than scp. If you want to copy the directory bar to server the corresponding scp command looks exactly like the cp command except for specifying ssh information:
$ scp -r bar/ me@server:/home/me/
With rsync, there are more considerations, as it’s a more powerful tool. First, let’s look at the simplest form:
$ rsync -r bar/ me@server:/home/me/
Looks simple right? For the simple case of a directory that contains only directories and regular files, this will work. However, rsync cares a lot about sending files exactly as they are on the host system. Let’s create a slightly more complex, but not uncommon, example.
# Create a multi-level directory structure $ mkdir -p bar/baz # Create a file at the root directory $ touch bar/foo.txt # Now create a symlink which points back up to this file $ cd bar/baz $ ln -s ../foo.txt link.txt # Return to our original location $ cd -
We now have a directory tree that looks like the following:
bar ├── baz │ └── link.txt -> ../foo.txt └── foo.txt 1 directory, 2 files
If we try the commands from above to copy bar, we’ll notice very different (and surprising) results. First, let’s give scp a go:
$ scp -r bar/ me@server:/home/me/
If you ssh into your server and look at the directory tree of bar you’ll notice an important and subtle difference from your host system:
bar ├── baz │ └── link.txt └── foo.txt 1 directory, 2 files
Note that link.txt is no longer a symlink. It is now a full-blown copy of foo.txt. This might be surprising behavior if you’re used to cp. If you did try to copy the bar directory using cp -r, you would get a new directory with the exact symlinks that bar had. Now if we try the same rsync command from before we’ll get a warning:
$ rsync -r bar/ me@server:/home/me/ skipping non-regular file "bar/baz/link.txt"
Rsync has warned us that it found a non-regular file and is skipping it. Because you didn’t tell it to copy symlinks, it’s ignoring them. Rsync has an extensive manual section titled “SYMBOLIC LINKS” that explains all of the possible behavior options available to you. For our example, we need to add the –links flag.
$ rsync -r --links bar/ me@server:/home/me/
On the remote server we see that the symlink was copied over as a symlink. Note that this is different from how scp copied the symlink.
bar/ ├── baz │ └── link.txt -> ../foo.txt └── foo.txt 1 directory, 2 files
To save some typing and take advantage of more file-preserving options, use the –archive (-a for short) flag whenever copying a directory. The archive flag will do what most people expect as it enables recursive copy, symlink copy, and many other options.
$ rsync -a bar/ me@server:/home/me/
The rsync man page has in-depth explanations of what the archive flag enables if you’re curious.
There is one caveat, however, to using rsync. It’s much easier to specify a non-standard ssh port with scp than with rsync. If server was using port 8022 SSH connections, for instance, then those commands would look like this:
$ scp -P 8022 foo.txt me@server:/home/me/
With rsync, you have to specify the “remote shell” command to use. This defaults to ssh. You do so using the -e flag.
$ rsync -e 'ssh -p 8022' foo.txt me@server:/home/me/
Rsync does use your ssh config; however, so if you are connecting to this server frequently, you can add the following snippet to your ~/.ssh/config file. Then you no longer need to specify the port for the rsync or ssh commands!
Host server Port 8022
Alternatively, if every server you connect to runs on the same non-standard port, you can configure the RSYNC_RSH environment variable.
Why else should you switch to rsync?
Now that we’ve covered the everyday use cases and caveats for switching from scp to rsync, let’s take some time to explore why you probably want to use rsync on its own merits. Many people have made the switch to rsync long before now on these merits alone.
If you have a slow or otherwise limited network connection between you and your server, rsync can spend more CPU cycles to save network bandwidth. It does this by compressing data before sending it. Compression can be enabled with the -z flag.
Rsync also only copies a file if the target file is different than the source file. This works recursively through directories. For instance, if you took our final bar example above and re-ran that rsync command multiple times, it would do no work after the initial transfer. Using rsync even for local copies is worth it if you know you will repeat them, such as backing up to a USB drive, for this feature alone as it can save a lot of time with large data sets.
As the name implies, rsync can do more than just copy data. So far, we’ve only demonstrated how to copy files with rsync. If you instead want rsync to make the target directory look like your source directory, you can add the –delete flag to rsync. The delete flag makes it so rsync will copy files from the source directory which don’t exist on the target directory. Then it will remove files on the target directory which do not exist in the source directory. The result is the target directory is identical to the source directory. By contrast, scp will only ever add files to the target directory.
For simple use cases, rsync is not significantly more complicated than the venerable scp tool. The only significant difference being the use of -a instead of -r for recursive copying of directories. However, as we saw rsync’s -a flag behaves more like cp’s -r flag than scp’s -r flag does.
Hopefully, with these new commands, you can speed up your file transfer workflow!
This post is missing the difference between dir/ and dir when copying directories, and the actual examples are wrong, as using dir/ will only copy the directory contents, but not the directory itself.
The section on delta transfers misses that you need an extra flag to enable it on local transfers. I think but don’t remember for sure that it’s –no-whole-file.
Hey Daniel, rsync will not copy files that already exist even locally without the –no-whole-file option.
I use –archive in my backup scripts to personal drives but not the –no-whole-file option and observe this behavior.
–whole-file disables the delta transfer algorithim and –no-whole-file overwrites previous uses of –whole-file on the command line to turn it back on. –whole-file is not the default but can be implied by other options you may use that require you to pass –no-whole file.
I think it would be possible to implement the scp interface (or a subset of it) on top of rsync. So without using the scp protocol, but just having a wrapper around the rsync command.
You can do that with a shell alias as far as I know. Something like “alias scp=’rsync -a’ ” in your .bashrc (or .zshrc, or whatever). Once you source the file (source ~/.bashrc, or login again) scp will not call the actual scp binary but rsync with the -a option.
Modifying sftp to act like scp would fix the issue, and be a welcome update. Currently, a batch file has to be written to get sftp to work without interaction. Rebasing scp on sftp is probably something that should have been done years ago.
I use this:
rsync --archive --partial --progress --rsh=ssh "$@"
This works for local and remote transfers.
Vernon Van Steenkist
Not sure why you were using scp if sftp is available. Simply put the URL
in your file manager directory window and you get a VFS where you can easily copy, paste, edit, play, etc remote files with your file manager.
For even more flexibility, use sshfs
sshfs me@server:/home/me home
and now you have a mounted remote file system at sub-directory me through sftp that any program can interact with directly.
From a terminal, mc (Midnight Commander) supports sftp virtual file systems as well.
I agree that using rsync is great for syncing photo directories etc. But for more simple copy and paste operations, I find sftp easier and more flexible – especially paired with a graphical file manager or sshfs.
Note that if you move files and directories around, you may want to add –delete to your rsync command. Otherwise, your destination can become filled with cruft.
good advice. but sshfs is much slower than nfs due to encryption
Can I ask a stupid question?
Why can’t ssh formally do this:
PuTTY Secure Copy client
-sftp force use of SFTP protocol
-scp force use of SCP protocol
Why are we having this conversation again?
This may well work, a lot of us just don’t have Windows.
Pure python implementation of
, using SFTP protocol. Depends on paramiko.
It should be mentioned rsync needs to be installed on the source and destination systems. Some systems don’t install rsync by default, and it will throw an odd message when it fails to start a remote rsync process. This trips me up on occasion. 🙂
It is only required on the system from which the rsync command is run.
rsync doesn’t need to be installed on the opposite system, an ssh with a proper scpserver implementation suffices, and that is the case on most desktop and server openssh based installations (but often not on embedded devices, such as STBs, PVRs).
Robin A. Meade
The rsync man page ( https://download.samba.org/pub/rsync/rsync.1 ) says
If I attempt to rsync to a server without rsync installed, I receive the following error message:
bash: rsync: command not found
I am pretty sure this command:
does NOT produce the output you showed subsequently; i.e., the “bar” directory itself being copied to the remote.
Makes me wonder, did you even try the examples you showed.
rsync does not do encryption. Therefore anyone who uses rsync is vulnerable to man-in-the-middle attacks. Thus the only place where rsync, on its own, can be securely used is a small LAN.
Other than that, rsync can be combined with ssh or a VPN, to make it secure.
So, anyone who recommends plain rsync as a replacement of scp has not been thinking about security.
By default rsync uses ssh if you are using the scp syntax “user@host:”
By saying scp is “outdated, inflexible, and not readily fixed”, does that mean it is insecure in any way? Besides other advantages of rsync, should I stop using scp for security reasons?
In scripts I’ve been using rsync as it is indeed more flexible, but on interactive shell for simple operations I often use scp because it is analog to cp.
Another ssh option, if you have reasonably contemporary machinery and reasonably new ssh is “-c firstname.lastname@example.org” as this will leverage the AES-NI instructions on the CPU. The results are quite staggering.
how about email@example.com?
Also, I would comment how sensitive is rsync to directions. It’s no the same to do
rsync foo server:/bar
rsync foo/ server:/Bar
Nice article! I did not know that scp is outdated. I have used rsync occasionally, indeed, it is a great tool. I know sometimes it is harder to get acquainted to rsync, but after read pre release notes I think I’ll be happy to use rsync instead of scp.
Honestly, I’ve used rsync for bulk data transfers and scp just to copy one or few files. It was a matter of convenience, so I’ll say goodbye to scp.
Updated my system yesterday and rsync got update from 3.1.3 to 3.2.2.
It is receiving updates after 2 two years, maybe we can ask for the caveat of ssh to be addressed somehow.
Maybe an alias:
rsync -w 8022 foo.txt me@server:/home/me/
–ssh-custom-port, –ssh-port, –ssh, -w
This option is an alias for -e ‘ssh -p ‘.
rsync -w 2234 [SOURCE] [user@]host:[DEST]
There is a version 3.2.3 to be released.
On the mention of in flight compression. SCP has the option “-C” which does the same thing, so compression to minimise network traffic is not a valid reason to switch to rsync as scp provides the same facility.
As already mentioned rsync traffic is not encrypted so should never be used anywhere except on an internal physically cabled local network.
A benefit of SCP is that SCP uses ssh keys, so can be used for hands-off (no password prompt) secure copying of individual files.
rsync certainly has it’s uses if you need to keep entire directories in sync in a local environment between two machines, so thanks for this post.
Nehemiah I. Dacres
How are we going to work with remote systems where local shell access is not available? Web Hosting providers don’t give shell access so we can’t rsync and sftp isn’t recursive.
I’m skeptical of this post. Calling SCP outmoded over a resolved CVE? scp has had lasting power for a reason.
If the SCP protocol is outdated, surely that simply means that the implementation of the
command should be changed to use the sftp protocol in its place.
I don’t see why changing protocols should stop us from using a nice simple and intuitive interface,
As a programmer I couldn’t disagree more.
You’re asking for trouble. Not only will that cause compatibility problems it will also cause major confusion. ‘I upgraded and now it’s doing something else!’ No. Bad, bad, bad idea. Very bad idea.
You don’t change the implementation of something like that. Also sftp is different from scp so why would you change the scp command to implement the sftp? As I recall they even use different ports so firewalls would have to be changed too.
There are other reasons that your suggestion is terrible. I don’t mean to be unkind about it but it really is a bad idea for so many reasons and some of the most important ones I just listed.
So just throw it away entirely, and force people to use something less intuitive? Can’t you see that is even worse?
Breaking changes happen in software, changing the underlying protocol of the tool would be such a breaking change. You could do everything in your power to inform sysadmins of the change so that they can adapt to it. Possibly you would only upgrade to the new version in a new version of a distro such as Fedora.
One thing that I didn’t like so much about sftp, if my memory serves me correctly, was that in older versions (e.g. say on RHEL6 hosts) it lacked the -i option, where to use key based authentication you had to type something like
scp -o identityfile=~/.ssh/my_rsa_id …
Also the usage of a batch file
(ok, using -b – you could pipe into sftp or read from a herestring some batch commands)
was a bit awkward in scripting.
As for rsync, I would like to know if rsync would honour any ssh_config option of the ssh client as documented in the ssh_config manpage that you would feed by
e.g. rsync -e ‘ssh -o opt1 -o opt2 … -o optN’ …
Thanks. I use -e for tunneling also:
rsync -[various_options] -e “ssh -p 1234” /dir/ user@localhost:/dir/
There’s another caveat and one that you really should have covered. Let me rephrase that: you really should have covered it. Here – I’ll help by including what’s in the manpage:
this directory" as opposed to "copy the directory by name", but in both cases the attributes of the containing directory are transferred to the containing directory on the destination. In other
words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:
rsync -av /src/foo /dest
rsync -av /src/foo/ /dest/foo
Not knowing this can cause a lot of confusion and directories with files that you intended to be in a subdirectory rather than in the current working directory! You really ought to point this out. It will cause a lot of grief to people! You might also want to point out the dryrun option? If that was used some users might be able to pick up on the problem I described before it’s too late!
…Of course you could always use ssh itself to copy files over e.g. with the pipe tricks. But never mind that.
…and of course the formatting got messed up in my previous post. Typical.