Using SCP to Transfer Files and Folders

SCP (Secure Copy Protocol) is a command-line tool for securely transferring files and folders between a local computer and a remote machine. SCP runs on top of the SSH protocol, so the entire data transfer process is encrypted by default without additional configuration. In daily practice, SCP is very often used by engineers to upload files from local to a server, download files from a server to local, or move files and folders between two servers at once. Without needing to install additional tools, SCP is usually already available by default on Linux and macOS, making it a practical choice for fast and secure file transfer needs.

Basic SCP Syntax

The basic structure of the SCP command is simple and consistent for all types of transfers:

scp [options] source destination

These three parts each have their own role. options are additional parameters that change the transfer behavior, for example -r for folders or -P for a custom port. source is the origin file or folder, which can be local or on a remote machine. destination is the location where the file will be copied, also local or remote — the combination of source and destination is what determines the transfer direction.

To specify a location on a remote machine, SCP uses a special path format:

user@host:/destination/path

This format consists of user (the account used for authentication), host (the address or hostname of the remote machine), and /destination/path (the file location on that machine, separated from the host by a colon). If either side (source or destination) doesn’t use the user@host: format, SCP treats that side as a local path on the computer where the command is run.

It’s important to understand that SCP actually works by running SSH behind the scenes to open a connection, then transferring data through that connection. This is why all authentication options that apply to regular SSH — like SSH keys, passphrases, or custom ports — also apply to SCP, because both essentially use the same transport mechanism.

flowchart LR
    A[scp command] --> B[Open an SSH connection]
    B --> C{Authentication}
    C -- Success --> D[Open a data transfer channel]
    D --> E[Copy files/folders]
    C -- Failed --> F[Error: Permission denied]

SCP Usage Examples

Transferring a File from Local to Remote

scp file.txt user@server:/home/user/

This command copies file.txt from the local computer to the user’s home directory on the server. Because the destination ends with / without a specific file name, SCP will use the original file name (file.txt) at the destination location.

Transferring a File from Remote to Local

scp user@server:/home/user/log.txt ~/Downloads/

The direction is reversed from the previous example — the source is now on the remote, and the destination is local. The log.txt file from the server will be copied to the Downloads folder on the local computer. Note that the position of the source and destination arguments always follows the same order (scp source destination), regardless of the transfer direction.

Transferring Folders Recursively

By default, SCP can only copy a single file, not a folder with its contents. To copy a folder, use the -r (recursive) option:

scp -r project/ user@server:/home/user/

The -r option tells SCP to enter the project/ folder and copy all files and subfolders inside it recursively. Without this option, SCP will display an error because it doesn’t know how to handle a directory as a single transfer unit.

Transferring Between Two Servers

SCP can also move files directly between two remote machines, without the file having to pass through the local computer first:

scp user1@serverA:/data/file.zip user2@serverB:/backup/

This command is usually run from a local computer (or any third machine with SSH access to both servers), and copies the file from server A to server B. Technically, the data still flows through the computer running the command — SCP doesn’t actually create a direct connection between serverA and serverB without passing through the client running the command.

sequenceDiagram
    participant Client as Computer (running scp)
    participant ServerA as Server A
    participant ServerB as Server B

    Client->>ServerA: SSH connection, read file.zip
    ServerA-->>Client: Stream file.zip data
    Client->>ServerB: SSH connection, write file.zip
    Client--xServerB: Data stream forwarded

SCP Options Frequently Used

Besides -r, SCP has several other options often used in daily work:

Example Using a Custom Port

Servers configured with a non-default SSH port (not 22) need the -P option (capital letter) to specify the correct port:

scp -P 2222 file.txt user@server:/home/user/

Note that the port option in SCP uses a capital -P, unlike the regular ssh command which uses lowercase -p for the same purpose. Capitalization mistakes on this flag are a common source of errors when switching between ssh and scp commands.

Example Using an SSH Key

For servers that don’t allow password login and only accept SSH key authentication, use the -i option to specify the matching private key:

scp -i ~/.ssh/id_rsa file.txt user@server:/home/user/

This is commonly used on cloud servers (like EC2 instances or VPSes) that by default have password authentication disabled and only allow access via a registered SSH key.

Transferring Multiple Files at Once with Wildcards

SCP also supports shell wildcards to copy several files matching a pattern in one command, without needing to run SCP repeatedly for each file:

scp *.log user@server:/home/user/logs/

This command copies all files with the .log extension in the current working directory to the logs/ folder on the server. Note that wildcards on the local side are expanded by the local shell before being sent to SCP, while wildcards on the remote side need different handling — quotes are needed so the expansion happens on the remote side, not the local side:

scp user@server:'/home/user/logs/*.log' ~/Downloads/

The single quotes around the remote path prevent the local shell from trying to expand that wildcard first (which would definitely fail because that path doesn’t exist locally), so the *.log expansion only happens after the command reaches the server side.

SCP Security

Because SCP runs on top of SSH, it inherits all of that protocol’s security characteristics. Transferred data is encrypted end-to-end, so it’s safe from eavesdropping even over public networks like cafe WiFi or shared hotspots. Authentication can use a password or SSH key, following the same configuration as regular SSH access to that machine.

However, there’s one important limitation to understand: SCP doesn’t support transfer resume. If the connection drops midway — for example due to an unstable network while moving a large file — the process must be restarted from scratch, with no mechanism to continue from the last successfully transferred point.

Don’t rely on SCP for transferring very large files (tens of gigabytes or more) over unstable networks. Without resume capability, a connection dropping at the last minute means the entire transfer must be restarted from zero — wasting significant time and bandwidth for large files.

Monitoring Progress and Optimizing Transfers

By default, SCP displays a simple progress bar in the terminal during the transfer — including percentage, transfer speed, and estimated remaining time. This display is usually enough for monitoring a single file transfer, but less informative when transferring many files at once with the -r option, because the progress bar only appears one at a time for each file.

For transfers involving many small files, compression with the -C option can help speed up the process, especially on networks with limited bandwidth:

scp -C -r project/ user@server:/home/user/

The -C option enables data compression before sending over the network, then decompresses on the receiving side. For files already compressed beforehand (like .zip, .jpg, or .mp4), this option doesn’t help much and actually adds CPU overhead without meaningful benefit, because that data is already near its minimal size. But for text files, source code, or raw logs that aren’t compressed, -C can significantly speed up transfers over slow connections.

One other thing often overlooked is the impact of large transfers on concurrent SSH connections. If you run SCP for a large file while also having an interactive SSH session open to the same server, that transfer can consume most of the available bandwidth and make the interactive session feel slow to respond. For environments with limited bandwidth, scheduling large transfers outside working hours or using rsync with a bandwidth limit option (--bwlimit) could be a better solution.

Practical SCP Usage Tips

• Use absolute paths to avoid wrong locations, especially when relative paths could be confusing between the local working directory and the remote home directory
• Make sure the remote user has write permission in the destination directory before transferring, or SCP will fail with a permission denied error
• For large or recurring transfers, consider rsync as a more robust alternative
• Always check the SSH port first if a connection fails — many servers use non-default ports for security reasons

Insufficient write permission is one of the most common failures when using SCP — its error message sometimes isn’t immediately clear in saying “permission denied”, but instead appears as an ambiguous transfer failure. Checking the destination directory permission with ls -ld /destination/path on the server before attempting the transfer can save debugging time.

When Is SCP Not Recommended?

SCP is less suitable in the following scenarios:

SCP is less ideal if:
  ✗ Transferring very large files prone to disconnection
  ✗ Need automatic resume after a failed connection
  ✗ Need periodic folder synchronization (only changed files)

SCP is still sufficient for:
  ✓ One-time file or folder transfers of reasonable size
  ✓ Quick needs without installing additional tools
  ✓ Simple automated scripts run occasionally

In the non-ideal scenarios above, rsync or SFTP are better choices. rsync supports incremental synchronization — only the changed parts of files are retransferred, not the whole file from scratch — and can resume interrupted transfers with the --partial flag. SFTP, on the other hand, provides a more interactive interface for exploring remote directories, similar to FTP but still running over SSH.

To understand when each tool is more appropriate, here’s a comparison of the three:

As an illustration of a practical comparison: if you need to back up a 50GB folder every night, and only a small portion of files change from day to day, rsync will be far more efficient because it only transfers the files that actually changed. SCP, by contrast, would recopy the entire 50GB every time it runs, regardless of how much actually changed — clearly inefficient for this kind of use case.

Summary

• SCP runs on top of SSH, so the entire data transfer is encrypted by default without additional configuration.
• The basic syntax is scp [options] source destination, with remote paths using the user@host:/path/ format.
• Use the -r option to copy folders, -P (capital letter) for a custom port, and -i to specify a particular SSH key.
• SCP doesn’t support transfer resume — a dropped connection means the transfer must be restarted from scratch.
• Suitable for one-time file or folder transfers of reasonable size, without needing to install additional tools.
• For large files, unstable connections, or periodic synchronization needs, use rsync or SFTP instead.
• Check the write permission of the destination directory before transferring to avoid confusing failures.