Operating systems

Use SCP for quick, secure file transfers

When you need to securely transfer a single file, SCP may be the ideal tool. It provides an encrypted transfer using the SSH protocol.

SCP, short for "Secure Copy", is a command line utility designed to transfer files across the network. Its interface is a work-alike for the venerable rcp utility, but the scp command provides the additional benefit of an encrypted transfer using the SSH protocol. If you have the standard OpenSSH suite installed on your system, you have SCP.

Because SCP is a one-shot command line tool, transferring files once for every time you type the command without showing the directory hierarchy on the far side of the connection, it is probably most suitable to repeatedly updating a single file or directory on a remote system after changes are made. In more general terms, it is useful for the same uses to which you would put the cp command when transferring files from one place to another on a single local system, but designed for use across network connections between computers that both have an SSH suite installed.

The command syntax for SCP, as described in the Unix manpage, is:

scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 ... [[user@]host2:]file2

A simplified form that will work for most uses is:

scp [options] [-P port] [source:]file [destination:]location

The -P option allows you to specify a nonstandard port in case the remote system with which you intend initiate a file transfer is configured to use a port other than 22 for its SSH server daemon. This is a point of some annoyance among many users of the OpenSSH suite, because the same option for the standard ssh command is -p, but it is easily settled by checking the manpage or using the --help option for either command to check the syntax.

If you are transferring a file from your current working directory on the local machine to a remote machine, the [source:] part of the command is unneeded. In that case, you only need to specify the name of the file in the current directory. If you intend to transfer a file from a remote system, however, you will need to specify the machine using a network address or -- if hostname resolution is set up via DNS, WINS, or local hosts file -- hostname. Whether the source is the local machine or a remote machine, you will need to specify the entire path to the file when you name the file if it is not located in your current working directory.

Essentially the same rules apply to the [destination:] part of the command syntax as apply to the [source:] part. If you are transferring to the current working directory on the local machine, you need only specify the name of the new file you are creating with the scp command. If you wish to keep the filename the same when copying it, you can leave out the filename and simply specify the current working directory with ./ as you would if using cp to copy from another directory on the local machine to the current working directory.

When copying entire directories, the recursive copy option must be used, or the scp command will fail. At this point, the use of scp diverges somewhat from that of cp, because cp uses -R to specify recursive copy, while scp uses -r.

If you want to copy your rTorrent session directory, .session, from your user directory on a computer with hostname foo to another computer with hostname bar, and want to copy it to the same username's home directory without changing its name on the remote computer, your command might look something like this:

scp -r ~/.session bar:~/

Similarly, copying from the remote machine to the local machine under the same conditions would look something like this:

scp -r bar:~/.session ~/

Note that, on the vast majority of Linux distributions, BSD Unix OSes, and commercial UNIX OSes, ~ is shorthand for the path to the current user's home directory.

The most common use to which I put SCP is making incremental changes to a file, uploading to a remote Web server, and testing the result in the browser. In one terminal emulator, I have the file open in Vim so that I can make changes and save them without closing the editor, allowing me to undo changes as needed if I do not like the results. In another terminal emulator window, I use an scp command something like the following to upload the file:

scp index.html user@example.com:/var/www/html/

The user@ reflects the fact that there is rarely a user account on a remote Web server with the same name as the username for the account on the local machine where I am editing the file. The /var/www/html/ path is the default path for the Apache Webserver document root. I add the slash at the end of the destination path any time I transfer a file to a remote machine to ensure that, if there is a typo in the path, I will not accidentally copy it to the wrong directory under a new filename. For instance, if I left the trailing slash off the directory and accidentally typed only two Ws in the path, I would get this command:

scp index.html user@example.com:/var/ww/html

If there happens to be a ww directory in that location, but there is no html directory inside it, I might end up accidentally creating a new file called html in the ww directory that is a duplicate of index.html on my local machine.

Once I have uploaded that file to the correct location once, I do not have to retype the command every time I want to upload a new copy while making incremental changes to the file. Using the shell's history capability, I can just press the up arrow key once to recall the last command typed in that terminal emulator, then press enter, and the previous command -- in this case the scp command -- will be repeated. In this manner, I find SCP far simpler to use than FTP work-alikes when working on a particular back-end file for a Website, and I get the additional benefit of strong encryption protecting the network connection so that nobody will be able to harvest my username and password by eavesdropping on the network.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

8 comments
nickbhavsar
nickbhavsar

SolarWinds just added a new SFTP/SCP Server tool to Engineer's Toolset. It makes it much easier for network engineers to use SCP. Free eval download at www.solarwinds.com/products/toolsets/

Frank.Meisschaert
Frank.Meisschaert

scp is a good tool for small files, but for large files the protocol overhead comes into play. In my experience down and uploads via https are up to 10 times faster and outweigh in certain circumstances the extra complexity associated with an https setup.

mteodor
mteodor

You should use sftp command instead of 'scp'!!

neilb
neilb

Yes, I use scp all the time. I also like rsync, which normally uses ssh as a transport. Only send the changes between files and directories on two different machines. I used it in conjunction with inotifywait and a script monitoring for events to synchronise two servers in real time. Regards Neil

delphi9_1971
delphi9_1971

Create a VM in VMWare Server and install a Linux Server in to it and then install OpenSSH. You get a full featured SSH server and the price is right!

w60152d
w60152d

I'm not very familiar with the standards that might apply to this matter. Which standard are you saying specifies sftp over scp? Thank you.

speculatrix
speculatrix

"scp -r" will recursively copy but you're better off with rsync as you can control it better - and if you need to stop and restart and get incremental copy it has intelligence. use "rsync -av localdir/file host:remote" or "rsync -av host:remotedir/file localdir/" for example

delphi9_1971
delphi9_1971

An OpenSSH server will allow you to connect with both SCP and SFTP. The former is for quick encrypted file transfers, the latter is a full featured Secure FTP protocol that will work with clients like FileZilla. I use SCP to copy my Router and Switch configurations to back them up. SCP allows me to do this automatically using Cisco's Archive construct or directly from the IOS CLI. I then connect to the backup server using SFTP to recover or review those backup configurations from a rich client like FileZilla. This beats TFTP which A: has problems with files over 16 MB (think IOS images) and B: adds a layer of encryption over my configs that FTP does not since Level 7 encryption on cisco devices is easy to break. This protects my configs in transit and C: uses TCP to guarentee delivery of my files, as TFTP uses UDP.

Editor's Picks