How SCP Works — and How It Differs from SFTP Under the Hood

For most administrators, scp is the first secure file-copy command they ever learn. Type scp file.txt user@server:/tmp/, enter a password, watch a progress meter, done. It feels so simple that few people ever ask what is actually happening on the wire — until the day a quoting problem mangles a filename, a vendor appliance rejects the copy, or someone asks in a meeting whether "SCP" and "SFTP" are the same thing and nobody is sure.

They are not the same thing, and the difference is worth understanding. SCP is a genuinely odd protocol: a design inherited from the earliest days of Unix networking, wrapped in modern encryption, and quietly being rebuilt from the inside by current implementations. This article explains the whole picture — where SCP came from, exactly what happens when you run the command, how the SFTP protocol differs underneath, and why one server can speak both. It is part of our SCP & SSH Copying series, and it is the foundation the rest of the series builds on.

One Connection, One Port: SCP Rides SSH

Start with the transport, because it explains SCP's best quality. SSH (Secure Shell) is the encrypted remote-access protocol that administrators use to log in to servers. An SSH session is a single network connection, normally to port 22 on the server. Inside that one connection, SSH does three jobs: it verifies the server's identity, it authenticates you (password or key), and it then carries whatever you do next — a login shell, a command, or a file transfer — through the same encrypted pipe.

SCP is not a standalone network protocol with its own port and its own listener. It is a passenger. When you run scp, the tool opens a normal SSH connection and moves the file inside it. Everything — authentication, the copy instructions, the file bytes — travels through that one encrypted connection to that one port.

The diagram below shows the shape of it: one connection, with the copy conversation happening inside the encrypted channel.

Two pieces of SSH's groundwork matter for every transfer that follows. First, host key verification: before anything else, the server proves its identity with a cryptographic key, and your client compares it against the fingerprint it saw last time (stored in your known_hosts file). That is what stands between you and copying a payroll file to an impostor machine. Second, authentication: password or, better, an SSH key pair. Both happen before a single file byte moves, and both are shared by every tool in this series — scp, sftp, and rsync-over-SSH all inherit them for free.

If you have spent time with FTP, this is the punchline: there is no second connection. FTP famously splits its work across a control connection and a separate data connection, and that split is the root of a whole family of firewall miseries — we cover them in why firewalls block active FTP. SSH-based copying has none of that. One outbound connection to one well-known port, and every firewall between you and the server sees only encrypted traffic on port 22. That single fact is why scp "just works" from almost anywhere an SSH login works.

The Remote-Copy Heritage: From rcp to scp

To understand SCP's personality, you need its family tree. Long before SSH existed, BSD Unix shipped a set of "r-commands": rsh (run a command on a remote machine), rlogin (log in remotely), and rcp (remote copy). They were built for the small, trusting academic networks of the era — no encryption, and authentication that amounted to believing whatever the calling machine said about who you were.

rcp worked in a way that sounds almost naive today: to copy a file to another machine, it simply ran a second copy of itself on that machine, via rsh, and the two processes streamed the file between them over the connection. There was no file-transfer "protocol" in any grand sense — just two copies of one program with a private, minimal understanding.

When SSH arrived and the plaintext r-commands had to die, scp was created as the drop-in replacement: the same command syntax, the same behavior, the same design of running its counterpart on the far side — but carried over SSH's encrypted, properly authenticated connection instead of rsh. That heritage explains things you use every day without thinking:

• The user@host:path syntax, with a colon separating host from path, comes straight from rcp.
• SCP is copy-only. It has no concept of listing a directory, renaming a file, or resuming a transfer, because rcp never did.
• The remote side of the copy is a program being executed, not a service waiting with its own configuration. That detail drives both SCP's flexibility and its sharpest edges.

What Actually Happens When You Run scp

Here is the classic mechanism, step by step, for an upload — scp report.pdf alex@web01:/tmp/:

1. Your scp client opens an SSH connection to web01 and authenticates as alex, exactly as ssh would. All your SSH configuration — keys, aliases, jump hosts — applies, which is why SSH config tricks speed up copies too.
2. Instead of requesting a login shell, the client asks the server to run a command: another scp process, started in a hidden receiving mode (you will see flags like -t, "to", in logs; downloads use -f, "from"). Your interactive command line and the remote receiving process are two instances of the same tool, meeting in the middle.
3. The two processes now speak the minimal, line-based SCP protocol through the encrypted channel. The sender announces each file with a header carrying its permissions, size, and name. The receiver answers with a single acknowledgment byte. Then the raw file bytes flow, followed by another acknowledgment.
4. When everything has been sent, both processes exit and the SSH connection closes.

Downloads mirror the same dance with the roles reversed: the remote process runs in source mode, announces the file, and your local client acknowledges and writes the bytes to disk. Recursive copies simply repeat the pattern — a "enter this directory" record, the files inside it, a "leave the directory" record — walking the tree one entry at a time.

The protocol conversation for a single file, translated into words, is almost comically simple:

sender:    C0644 482391 report.pdf     ← "a file: mode 0644, 482,391 bytes, this name"
receiver:  <OK byte>
sender:    ...482,391 raw file bytes...
sender:    <OK byte>                   ← "that was all of it"
receiver:  <OK byte>                   ← "written successfully"

A few more message types round out the whole vocabulary: a timestamp record sent just before the file header when you use -p (preserve times), a "descend into this directory" record and a matching "pop back out" record used during recursive copies, and error messages. That is the entire protocol. There are no commands for listing, seeking, renaming, or deleting — the vocabulary simply does not contain them.

One consequence deserves a highlight, because it causes real-world breakage: in this classic design, the command that starts the remote scp process is interpreted by the remote user's shell, and the path you typed is part of that command line. The remote shell expands wildcards, splits on spaces, and honors special characters before scp ever sees the path. That is why a remote path containing spaces needs an extra layer of quoting, and why scp 'web01:/logs/*.log' . works at all — the far side's shell expands the star. The full catalogue of those hazards lives in our companion article on SCP's limitations.

SFTP Is a Different Animal

Now contrast that with SFTP, the SSH File Transfer Protocol. Despite the name, SFTP is not FTP wrapped in encryption, and it is not SCP with more features. It is a separate, deliberately designed protocol that also happens to travel inside SSH. (Our SFTP series covers it in depth.)

The differences start with how it is launched. SFTP does not run an arbitrary program through your shell. It is an SSH subsystem — a named service that the SSH server maps to a handler in its own configuration. The client says "start subsystem sftp," and the server starts its configured SFTP handler directly. No shell parses anything, which is why SFTP has none of SCP's quoting hazards: filenames travel inside structured packets as plain data, never as pieces of a command line.

The protocol itself is a real remote-filesystem vocabulary. Where classic SCP has "here comes a file," SFTP has discrete, numbered request messages: open a file, read this many bytes at this offset, write at an offset, close, list a directory, rename, delete, make a directory, read file attributes. Each request carries an ID and gets a matched response, and clients keep many requests in flight at once to fill the pipe.

Two of those details quietly change what is possible:

• Reads and writes specify an offset. That is random access, and it is exactly what makes resuming an interrupted transfer possible in SFTP — and impossible in classic SCP, which only knows how to stream a file from byte zero.
• The vocabulary includes management operations. An SFTP client can browse, rename, delete, and stat. That is why graphical file-transfer clients are built on SFTP, not SCP: a drag-and-drop file manager needs directory listings, and SCP cannot provide one.

Why One Server Speaks Both

Here is the part that confuses people pleasantly: you do not usually choose between an "SCP server" and an "SFTP server." A standard SSH daemon offers both, because both are just things an authenticated SSH session can ask for.

When your client connects, authentication happens first and identically in either case. Then the client makes its request, and the server dispatches it:

• "Run this command" → the shell path. This serves normal ssh commands and classic scp, which is, as we saw, just a command.
• "Start subsystem sftp" → the subsystem path. This serves sftp clients and anything else speaking the SFTP protocol.

One daemon, one port, one set of accounts and keys and logs — two file-transfer faces. This is why disabling one without the other takes deliberate server configuration, and why "can you SSH to it?" is usually the only connectivity question that matters for any of these tools.

The shared front door has an administrative upside worth noticing: there is exactly one place to manage authentication policy, one place keys live, and one log stream recording who connected. It also has a consequence that surprises people the first time: on a stock configuration, anyone who can SCP a file to a Linux box can usually open an interactive shell on it too, because both arrive through the same login. Restricting an account to file transfer only — no shell — is a deliberate server-side setup, and it is one of the standard hardening moves for accounts that exist purely to receive files.

The same holds on dedicated file-transfer servers. On Windows, current systems include an optional OpenSSH server, and purpose-built products implement the SFTP subsystem behind ordinary Windows administration — Sysax Multi Server, for example, gives a Windows machine an SFTP (SSH2) endpoint alongside FTP, FTPS, and HTTPS, with per-user access control and activity logging. From a client's point of view it is all the same conversation: an SSH connection to port 22, then file-transfer requests inside it.

What Modern Implementations Changed

For decades, the classic SCP protocol carried an enormous share of the world's ad-hoc server-to-server copying. But its design aged badly in three ways:

• The shell in the middle. Because remote paths pass through the remote shell, quoting is error-prone, and a hostile filename or crafted server response could historically trick clients into doing unintended things. A protocol where filenames are data, not command-line fragments, is simply safer.
• Trust in the server. In the classic protocol, when you request files, the server-side process announces what it is sending and the client writes what arrives. A malicious or compromised server had room to send files you did not ask for. Clients grew stricter, but the looseness was in the protocol's bones.
• The missing features. No resume, no listings, no verification vocabulary — fixable only by changing the protocol.

The response, in modern OpenSSH and elsewhere, was elegant: keep the beloved command, replace the wire protocol. Current scp implementations can perform the transfer using SFTP as the transport underneath, while the command line you type stays exactly the same. Muscle memory and scripts keep working; the bytes on the wire follow the structured, safer protocol. Some environments retain a flag to force the legacy protocol for compatibility with old devices, and some have removed classic-protocol support entirely.

The switch is mostly invisible, but not perfectly. Behaviors that depended on the remote shell change: wildcard expansion is now performed through SFTP requests rather than by the remote shell, so shell tricks embedded in remote paths (like command substitution) stop working, and quoting edge cases shift. When an old script behaves differently on a new system, or a network appliance accepts one tool and rejects another, this transition is very often the reason. The practical rule: test against the systems you actually use, and when a device only speaks one dialect, note it in your runbook.

SCP and SFTP Side by Side, Under the Hood

The table below condenses the mechanics. It is about how the two work internally — for guidance on which tool to reach for on a given day, see choosing your copy tool.

Why This Matters Day to Day

Understanding the machinery pays off in small, frequent ways. When a copy to a storage appliance fails with a cryptic protocol error, you will think to try the other dialect. When a filename with a space breaks a script, you will know the shell in the middle is the culprit rather than guessing at quote combinations. When someone proposes "an SCP server" for a partner integration, you will know to specify SFTP, because that is the protocol with listings, resume, and clean semantics — and the one every modern client and server has converged on.

It also frames the rest of this series. The gaps in classic SCP's vocabulary become the practical warnings in SCP's limitations. The command itself — flags, one-liners, and the mistakes everyone makes once — is drilled in the scp command, mastered. And because every one of these tools rides SSH, the connection-level tuning in SSH config as a transfer accelerator speeds all of them up at once.

Frequently Asked Questions