What the command actually does
You type `scp backup.tar.gz user@server:/srv/backups/` and a minute later the file is there. No flags, no config, no ceremony. That is the whole appeal, and it is also the whole problem.
SCP is not really a protocol anymore. It is a command that rides on SSH, and since OpenSSH 9.0 it does not even use its own transfer mechanism. What you get is a thin, predictable tool that does one thing. Whether that is the right tool for you depends on what you are actually moving.
What the command actually does
When you run `scp`, OpenSSH opens an SSH connection to the remote host. Authentication happens exactly as it would with `ssh`: host keys, then a password or a key pair. Everything after that travels inside that encrypted channel.The syntax mirrors `cp`, which is why nobody needs a manual to start using it:
``` scp document.txt user@server.example.com:/home/user/ ```
And the other direction:
``` scp user@server.example.com:/home/user/log.txt ./ ```
That symmetry is the reason `scp` survived three decades of tooling churn. You already know how to use it the first time you see it.
The part that changed in 2022
For most of its life, `scp` used an RCP-derived protocol tunneled through SSH. It worked, but the error handling was poor and the protocol had quirks that showed up in edge cases.OpenSSH 8.8, released 26 September 2021, announced the change. OpenSSH 9.0, released 8 April 2022, made it real: `scp` now uses SFTP as its transport by default.
You probably did not notice. The command looks identical, the flags are the same, your scripts kept running. What changed is underneath — better error reporting, more reliable transfers, and behavior that matches what `sftp` has been doing for years.
The name is now slightly dishonest. `scp` is a wrapper around SFTP functionality inside OpenSSH, not a separate protocol. Nobody renamed it because nobody wanted to explain that to a million shell scripts.
When scp is the right tool
One file, one direction, one time. That is the sweet spot.Deploying a config file, pulling a log, pushing a build artifact to a server you already have SSH access to. `scp` does this without asking you to learn anything.
It is also the correct choice for scripting. The exit codes are meaningful, the syntax is stable, and it is installed everywhere. OpenSSH ships by default on virtually every Linux distribution, on macOS, and on Windows 10 and 11. You will not find a server where `scp` is missing.
That universality is worth more than features. A tool that exists on every machine you will ever touch beats a better tool you have to install first.
When it is not
If you are moving a directory tree, `scp -r` works but it is the wrong answer. It re-copies everything, every time. No delta transfer, no resume, no compression worth mentioning.`rsync` handles that. It transfers only changed blocks, supports resumption after a dropped connection, and compresses in transit. The cost is a slightly less obvious syntax and the fact that `rsync` must be present on both ends. On a fresh minimal container, it often is not.
If you want to browse, list, and move files interactively, `sftp` is the better fit. Same SSH foundation, but you get `ls`, `cd`, `get`, `put`, and a prompt. For a one-off copy, that is more ceremony than you need.
Then there is the cost nobody mentions until it bites: `scp` has no resume. Drop the connection at 90 percent of a 4 GB transfer and you start over from zero. If your network is reliable and your files are small, this never matters. If you are pushing database dumps across a flaky link, it matters a lot.
The flags you will actually use
A handful of options cover most real usage.A non-standard SSH port needs `-P`, capital, because lowercase `-p` already means "preserve timestamps" from `cp`:
``` scp -P 2222 document.txt user@server.example.com:/home/user/ ```
A specific key:
``` scp -i ~/.ssh/deploy_key document.txt user@server.example.com:/home/user/ ```
Bandwidth limiting, in Kbit/s, useful when you do not want to saturate a production link:
``` scp -l 8000 backup.tar.gz user@server.example.com:/srv/backups/ ```
Recursive copy of a directory:
``` scp -r ./configs user@server.example.com:/etc/myapp/ ```
That is roughly the whole toolbox. Everything beyond this is a sign you want `rsync`.
The graphical layer
Desktop SSH clients wrap `scp` and `sftp` behind drag-and-drop. You drag a file into a window, it appears on the server. Under the hood it is the same SSH connection and the same transfer code.This is genuinely useful if you move files rarely and do not want to hold the syntax in your head. It is useless for automation, because there is nothing to script. Headless servers do not have windows.
Pick the GUI if you are doing this a few times a month. Pick the command line if you are doing it a few times a day. Most people end up with both, which is fine.
The honest comparison
`curl` can speak SCP as a transfer protocol, which tells you something about how embedded it is in the ecosystem. It is not the tool you reach for, but it is there.`rsync` is more capable and more complex. `sftp` is more interactive and slower for single files. Plain `scp` is the smallest possible thing that solves the problem, and that is its entire value proposition.
The trade is simple. You give up resume, delta transfer, and directory efficiency. You get a command that works identically on every machine you will ever SSH into, with syntax you never have to look up.
For a config file at 2 AM, that trade is obviously correct. For a 40 GB migration over a hotel wifi connection, it is obviously wrong, and you will find out roughly an hour in.
Where it lands
The migration to SFTP in OpenSSH 9.0 did not make `scp` obsolete. It made it honest — a stable front end over a transport that finally handles errors properly.What you choose depends on three things: how big your files are, how reliable your connection is, and whether the other end has `rsync` installed. Answer those and the tool picks itself.
If you cannot answer the second one, you already know which command you are going to type.