Secure Copy Protocol (SCP): How It Works and When to Use It

Secure Copy Protocol (SCP) moves files over an encrypted SSH connection using a syntax most engineers can write from memory. That simplicity is also the problem: SCP’s underlying protocol dates back to 1983’s rcp, it has shipped with disclosed vulnerabilities including a 2020 command injection flaw and a 2026 privilege escalation bug, and OpenSSH itself now defaults to a safer transfer method behind the same command name.

Published: April 2026. Updated: August 2026. Reviewed by Encryption Consulting’s SSH and Key Management team.

What Is Secure Copy Protocol (SCP) and How Does It Work?

SCP is a command-line tool that copies files between a local host and a remote host, or between two remote hosts, over an existing SSH connection. It exists because the original Remote Copy Protocol (RCP) it’s built on had no encryption at all. SCP takes RCP’s simple copy semantics and layers SSH’s authentication and encryption on top, so a file in transit can’t be read or altered by anyone sitting on the network path.

Under the hood, an SCP transfer runs in two possible directions once the SSH tunnel is up. Sink mode pushes files from the local host to the remote host; source mode pulls files from the remote host to the local host. Which mode runs depends entirely on how the command is written, not on any separate flag: SCP just launches a corresponding scp process on the far end and streams file data through the SSH channel.

The basic command structure is:

scp [options] source destination

To push a local file to a remote host:

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

To pull that same file back down to the current local directory:

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

That trailing period matters: it tells SCP to write the file into the directory the command is run from. Add -r to copy an entire directory recursively. For authentication, password login works but SSH key authentication is the standard for anything automated or repeated:

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

Other flags worth knowing: -v for verbose output when a connection is misbehaving, -P to set a non-default SSH port, and -p to preserve file modification times and permissions on the copy. Forgetting the colon in the remote path is the most common mistake, since without it SCP treats the whole argument as a local path instead of a remote one.

SCP vs. SFTP vs. Rsync over SSH: How Do They Compare?

All three tools move files over an encrypted SSH channel, but they get there through very different protocol designs, and that difference is exactly what drives their security and reliability gaps. SFTP itself grew out of the same need SCP addressed: see our breakdown of Secure File Transfer Protocol (SFTP) and its advantages for a closer look at that protocol on its own.

The legacy scp/rcp protocol works by having the local scp client invoke a remote scp process with undocumented flags (-t for sink, -f for source), then passing file paths that the remote shell partly interprets, including wildcard expansion. That shell involvement is the root of SCP’s worst-known flaws. SFTP replaces this entirely with a purpose-built, packet-based request-response protocol: the client asks for discrete operations (open, read, write, stat, rename) and the server responds, with no shell command construction involved at any point. Rsync-over-SSH takes a third approach, using SSH purely as a secure transport while rsync’s own protocol handles the actual comparison and transfer, including delta-encoding so only the changed portions of a file move across the wire.

Capability	SCP	SFTP	Rsync over SSH
Transfer model	Shell-based push/pull	Request-response subsystem	Delta-sync over SSH transport
Resume interrupted transfer	No	Yes, partial file support	Yes, built for it
Directory sync / incremental copy	No, always full-file copy	Limited, per-session	Yes, native strength
Interactive remote browsing	No	Yes (ls, cd, rm in-session)	No
Shell command construction on remote side	Yes, legacy protocol only	No	No (rsync protocol, not shell)
Default in OpenSSH 9.0+	scp now uses SFTP internally	Yes	N/A, separate tool
Best fit	Quick, scripted one-off copies on trusted, patched hosts	General-purpose secure file transfer, automation, compliance logging	Large datasets, mirroring, repeated syncs, unreliable links

In practice, most teams should default to SFTP for anything beyond a single ad hoc copy, and reach for rsync when the workload is really about synchronization rather than one-time delivery.

What Are SCP’s Known Security Limitations?

SCP’s legacy scp/rcp protocol has two disclosed, CVE-tracked vulnerabilities that security teams should know about before standardizing on it for new deployments.

CVE-2020-15778 is a command injection vulnerability in the scp client through OpenSSH 8.3p1 (CVSS 3.1 score: 7.4, high). A destination argument containing backtick characters can be interpreted and executed as a shell command on the remote side, because the legacy protocol passes filenames through the remote shell rather than treating them as pure data. OpenSSH’s maintainers have stated they intentionally do not validate what they call “anomalous argument transfers,” on the reasoning that stricter validation risked breaking long-standing scripts and workflows. That stance is exactly why the flaw sat without a full upstream fix for so long, even as several downstream distributions shipped their own mitigations.

CVE-2026-35385 is a more recent privilege escalation issue affecting OpenSSH before version 10.3 (CVSS 3.1 score: 7.5, high). When a file is downloaded with scp as root using the legacy protocol (the -O flag) without also passing -p to preserve file mode, the resulting file can end up installed as setuid or setgid, an outcome most administrators would not expect or intend. That’s a real privilege escalation path on any system where root routinely pulls files over SCP. The fix shipped in OpenSSH 10.3p1.

Both issues trace back to the same root cause: the legacy scp/rcp protocol trusts the remote side more than a modern transfer protocol should, and it was never designed with today’s threat model in mind. That’s precisely why, starting with OpenSSH 9.0 in 2022, the scp command switched to using the SFTP protocol under the hood by default. Running scp on a current OpenSSH build no longer speaks the vulnerable legacy protocol unless someone explicitly forces it with the -O flag. Red Hat went further in RHEL 9, formally deprecating the legacy scp/rcp protocol path and flagging it for eventual removal, precisely because, as Red Hat put it, the protocol “carries multiple security risks and issues that have no straightforward solutions” since it “is inherently trustworthy of authenticated sessions.”

The practical takeaway: if your systems are on a current OpenSSH release, typing scp today likely already runs over SFTP. If you’re still forcing -O for compatibility with older systems, or running unpatched OpenSSH versions, you’re exposed to both CVEs above.

Who Should Own the SSH Keys Behind SCP Transfers?

SCP is only as secure as the SSH key authenticating it, and unlike a TLS certificate, an SSH key has no built-in expiration date. Ownership needs to be assigned explicitly, or keys simply accumulate. In practice, lifecycle ownership splits across three roles:

• Security or identity team: owns the issuance policy, the approved key types and lengths, and the central inventory of every key in use, including keys embedded in scripts and CI/CD pipelines.
• System or application owners: own the authorized_keys entries on their own hosts and are accountable for removing access when a user, service, or contract ends.
• Platform or DevOps teams: own automated file-transfer keys used by build pipelines, backup jobs, and integrations, and are responsible for scoping each key to the single host and command it actually needs.

Without one of these roles clearly on the hook, SSH keys default to whoever generated them, which is how organizations end up with keys nobody remembers granting and nobody is willing to delete.

When Should You Rotate the SSH Keys SCP Relies On?

Rotation should be triggered by events, not just a calendar, though a calendar backstop still matters. The triggers that should force an SSH key rotation for any account used with SCP or SFTP include:

1. A fixed maximum key age, commonly 90 to 180 days for interactive user keys and shorter for high-privilege service accounts.
2. An employee or contractor offboarding, or a role change that removes the need for a given host’s access.
3. Suspected or confirmed compromise of a workstation, build server, or the key material itself.
4. A disclosed vulnerability in the SSH client, server, or key-generation library in use, such as CVE-2026-35385 above.
5. Migration of a system to new infrastructure, which is a natural point to reissue rather than copy keys forward.
6. Discovery, during an access review, of a key that no longer maps to a documented owner or purpose.

Manual rotation across dozens or hundreds of hosts is where most organizations quietly give up, which is the real argument for centralized SSH key management rather than a stronger rotation policy on paper.

What Access Policy Should Govern File-Transfer Permissions?

File-transfer access should follow the same least-privilege discipline as any other production access, with a few SCP- and SFTP-specific controls layered on:

• Disable password authentication for SCP/SFTP-capable accounts and require key- or certificate-based authentication instead.
• Restrict by user and group with AllowUsers or AllowGroups directives, and by source IP range where transfers only ever originate from known networks.
• Chroot and restrict SFTP-only accounts using OpenSSH’s ChrootDirectory and ForceCommand internal-sftp, so a file-transfer account can never open an interactive shell.
• Scope service-account keys narrowly with a command= restriction in authorized_keys so an automation key can run exactly one transfer command against one path, nothing else.
• Require approval for new access to production hosts rather than allowing self-service key additions, and time-bound any exception access.

These controls matter more than the choice of SCP versus SFTP itself. A well-scoped SCP account on a hardened, patched host is safer than an unrestricted SFTP account with a shared key and no logging.

How Do You Produce Audit Evidence for File Transfers?

Auditors and incident responders both need the same thing: a record of who transferred what, to or from where, and when. That evidence comes from a few concrete controls:

• Set LogLevel VERBOSE on SSH servers handling file transfers so authentication events include the specific key fingerprint used, not just the username.
• Enable SFTP subsystem logging, which records individual file operations (open, read, write, rename, remove) in a way SCP’s shell-based model cannot match.
• Forward SSH and SFTP logs to a centralized, tamper-evident log store or SIEM, with retention that meets your compliance obligations (commonly one year or longer under PCI DSS and SOC 2).
• Run periodic access reviews that reconcile every authorized_keys entry against a documented owner and business justification.
• Map file-transfer logging and key inventory controls directly to the relevant control families in frameworks like ISO/IEC 27001, SOC 2, and PCI DSS, so the same evidence serves both security and audit purposes.

This is the area where SFTP has a structural edge over SCP: because every operation is a discrete, logged request rather than a shell command, SFTP audit trails are far easier to reconstruct after the fact.

What Does a Secure File-Transfer Deployment Workflow Look Like?

Whether you land on SCP, SFTP, or rsync, the rollout process for a new secure file-transfer path should follow the same sequence:

1. Confirm the OpenSSH version on every host involved, and patch to at least 10.3p1 to close CVE-2026-35385, or to a version at or beyond 9.0 so scp defaults to the SFTP protocol.
2. Choose the right tool for the workload: SFTP for general-purpose and automated transfers, rsync for large or repeated syncs, SCP only for quick, manual, one-off copies on hosts you trust and control.
3. Generate scoped SSH keys per system or service, using modern key types (Ed25519 preferred, RSA 3072-bit or larger where Ed25519 isn’t supported), never a single shared key across multiple integrations.
4. Restrict server-side access with AllowUsers/AllowGroups, chrooted SFTP where appropriate, and command= restrictions on automation keys.
5. Enable verbose logging and route it to centralized storage before the first production transfer runs, not after an incident.
6. Document ownership and rotation schedule for every key created, tied to the triggers above.
7. Test the failure path: confirm what happens on an interrupted transfer, a revoked key, and a misconfigured permission, before relying on the setup in production.

How Do SCP and SFTP Support Differ Across Platforms?

Linux, macOS, and most Unix systems ship with OpenSSH’s scp and sftp clients and servers built in, so support is consistent as long as the OpenSSH version is current. Windows closed that gap starting with Windows 10 version 1809 (released in 2018), when Microsoft integrated the OpenSSH client and server directly into the OS, making both commands available natively from PowerShell or Windows Terminal without third-party tools like PuTTY.

Enterprise Linux distributions have started actively steering users away from the legacy scp protocol. RHEL 9 deprecated the legacy scp/rcp protocol path, defaulting new transfers to the SFTP-based behavior introduced in OpenSSH 9.0 and warning that the legacy path will eventually be removed entirely. That deprecation surfaces one practical wrinkle worth planning for: SCP and SFTP handle symlinks and tilde-expanded paths differently, so transfers between a modern host and a legacy one that rely on ~ shortcuts can behave unexpectedly. Using absolute paths sidesteps the issue.

For organizations running a mix of OpenSSH versions across Linux, Windows, and macOS fleets, or legacy network appliances with older embedded SSH stacks, the practical answer isn’t to chase every platform’s default behavior individually. It’s to manage the SSH keys and access policy centrally, so the transfer protocol a given host happens to default to matters less.

How Should You Respond to a Compromised File-Transfer Credential?

When an SSH key used for SCP or SFTP is suspected of being compromised, speed matters more than process perfection. A practical response sequence:

1. Revoke immediately. Remove the key from every authorized_keys file it appears in, or revoke the corresponding SSH certificate if one was issued.
2. Contain lateral movement. Check whether the same key or key material was reused across other hosts or services, and revoke there too.
3. Preserve and review logs. Pull SSH and SFTP logs covering the suspected exposure window to identify what was actually accessed or transferred.
4. Rotate related credentials. Any key generated on the same compromised workstation, or any key an attacker could plausibly have touched, should be treated as suspect and rotated.
5. Check for planted access. Review host keys and authorized_keys files for entries the legitimate owner didn’t add.
6. Notify stakeholders per your incident response and, where applicable, regulatory disclosure requirements.
7. Run a post-incident review to identify how the key was exposed, and close that specific gap, whether it’s an unencrypted key on disk, an over-broad access grant, or a missing rotation policy.

Organizations that can answer “which key, which hosts, since when” within minutes of a report are the ones with a real SSH key inventory in place before the incident happens, not the ones assembling one during it.

Limitations

Beyond the security issues covered above, SCP carries functional limitations that make it a poor fit for anything beyond quick, manual transfers. It cannot resume an interrupted transfer: if a copy fails partway through, from a dropped connection or a network blip, the entire transfer starts over from scratch. It has no concept of incremental sync, so changing one line in a large file still means copying the whole file again. And because it lacks the delta-transfer optimizations that tools like rsync are built around, SCP is more resource- and bandwidth-intensive for repeated or large-scale transfers. These gaps, combined with the security limitations above, are exactly why SCP is best reserved for occasional, one-off copies rather than production file-transfer pipelines.

What Would Encryption Consulting Recommend?

For new deployments, we’d point teams toward SFTP over SCP, and toward rsync-over-SSH for anything involving large or repeated synchronization. But the protocol choice is rarely where the real risk sits. In nearly every SCP or SFTP environment we assess, the actual exposure is unmanaged SSH keys: keys with no documented owner, no rotation schedule, and no audit trail tying a transfer back to a person or a service.

That’s the gap SSH Secure is built to close. It gives you a centralized inventory of every SSH key across your environment, automated rotation tied to the triggers described above, and policy enforcement so file-transfer keys stay scoped to the single host and command they need. For teams that also issue and manage TLS or code-signing certificates, pairing that with CertSecure Manager keeps certificate and key lifecycle visibility in one place rather than split across tools. And where private keys need to live in a hardened, FIPS 140-3 validated environment rather than on disk, HSM-as-a-Service removes that risk entirely.

If you’re not sure where your organization stands today, our Encryption Advisory Services team can run a focused assessment of your SSH key inventory and file-transfer access controls and hand you a prioritized remediation plan, not just a list of findings.

Frequently Asked Questions

Is SCP still safe to use in 2026?
On a current, patched OpenSSH build, running scp is reasonably safe because it now uses the SFTP protocol by default, not the vulnerable legacy scp/rcp protocol. The risk returns if you force the -O flag for compatibility, or if the host is running an unpatched OpenSSH version affected by CVE-2020-15778 or CVE-2026-35385.

What is the actual difference between SCP and SFTP?
SCP’s legacy protocol builds and runs shell commands on the remote host to copy files. SFTP is a dedicated, packet-based protocol where the client requests discrete file operations and the server responds, with no remote shell command construction involved. That architectural difference is why SFTP supports resuming transfers, interactive browsing, and more precise logging, while SCP does not.

Why did CVE-2020-15778 matter for SCP users?
It showed that a maliciously crafted destination path, using backtick characters, could get executed as a command on the remote server during a legacy-protocol SCP transfer. OpenSSH’s maintainers chose not to add strict validation, citing compatibility concerns, which is part of why the industry shifted default behavior instead of patching around the flaw indefinitely.

Should I switch every workflow from SCP to SFTP?
For anything automated, compliance-relevant, or repeated, yes. For a genuinely one-off manual copy between two trusted, patched hosts, SCP running over the modern SFTP-backed default is fine. The bigger priority in either case is managing the SSH key behind the transfer, not just picking the protocol.

Does rsync use SSH the same way SCP does?
Rsync commonly runs over an SSH transport for encryption and authentication, the same way SCP and SFTP do, but the file comparison and transfer logic is rsync’s own protocol layered on top. That’s what gives rsync delta-transfer efficiency and resume support that plain SCP cannot offer.

Conclusion

SCP still has a place for a quick, manual, one-off copy between two trusted hosts. But for anything automated, repeated, or subject to compliance review, SFTP is the better-engineered choice, and it’s already what a modern scp command runs over by default. Rsync-over-SSH takes over from there when the job is really about synchronizing large or frequently changing datasets rather than delivering a single file.

None of that matters much, though, if the SSH keys behind the transfer have no owner, no rotation schedule, and no audit trail. Getting the protocol right is an afternoon’s work. Getting SSH key lifecycle management right is the part that actually keeps file transfers secure over time, and it’s where most organizations still have real gaps to close.

References

• OpenSSH 9.0 Release Notes, OpenSSH.org
• CVE-2020-15778, National Vulnerability Database
• CVE-2026-35385 Advisory, GitHub Advisory Database
• OpenSSH SCP Deprecation in RHEL 9, Red Hat
• OpenSSH Manual Pages (scp, sftp), OpenSSH.org