Sftp And Scp - Learning Module

Loading content...

0/240

SCP Protocol: The Secure Copy Legacy

The Simplicity That Became a Weakness

Secure Copy Protocol (SCP) holds a unique position in the history of secure file transfer. Born alongside SSH in 1995, SCP was designed with a single, elegant goal: provide the familiar semantics of the Unix cp command while leveraging SSH's encryption. For over two decades, system administrators reached for scp as naturally as they reached for cp—the syntax was nearly identical, the mental model trivial.

Yet this simplicity came at a cost. SCP's design, inherited from Berkeley's rcp (remote copy) protocol from the 1980s, carried fundamental limitations that became increasingly problematic:

No directory browsing capability
Limited file metadata handling
No resume for interrupted transfers
Protocol-level security vulnerabilities discovered in 2019

In April 2022, OpenSSH 9.0 formally deprecated SCP's legacy protocol, switching the scp command to use SFTP protocol internally by default. Understanding SCP remains valuable for historical context, legacy system integration, and appreciating why SFTP became the preferred solution.

What You Will Learn

By the end of this page, you will understand SCP's architectural design and its relationship to SSH, the SCP protocol mechanics including command structure and data flow, practical usage patterns and command-line syntax, the security vulnerabilities that led to deprecation, migration strategies from SCP to SFTP, and scenarios where SCP knowledge remains relevant.

SCP Architecture and Origins

SCP's architecture reflects its heritage as a secure replacement for BSD's rcp (remote copy) command, created in the era of trusted local networks and the .rhosts authentication model.

Historical Context: From rcp to scp

In the 1980s, BSD Unix introduced rcp for copying files between systems. Users configured .rhosts files specifying trusted hosts; commands like rcp server:/path/file ./local worked seamlessly—and completely without encryption. When SSH emerged in 1995, scp provided identical functionality over SSH's secure channel.

The Simplicity Principle:

SCP operates on a fundamentally different model than SFTP:

SCP Design Philosophy

•One-shot operation — Each scp command is complete in itself
•No state — No handles, sessions, or persistence between commands
•Command-tunneling — Executes scp on remote system through SSH exec
•Stream-based — Data flows as continuous stream, not random-access
•Minimal protocol — Simple text headers, no binary encoding

Resulting Characteristics

•No interactive browsing possible
•Must know exact paths beforehand
•Cannot resume partial transfers
•No random-access file operations
•Minimal server-side requirements

How SCP Uses SSH:

Unlike SFTP's subsystem model, SCP operates through SSH's remote command execution:

SCP Connection Architecture

Connection Flow

SCP Connection Model vs SFTP:
 
SFTP:
┌──────────┐                              ┌──────────────┐
│  Client  │ ─── SSH Channel ──────────→ │ sftp-server  │
│          │     (subsystem request)      │ (subsystem)  │
└──────────┘                              └──────────────┘
             Binary SFTP protocol ←→
 
 
SCP:
┌──────────┐                              ┌──────────────┐
│  scp     │ ─── SSH Channel ──────────→ │ scp -t/-f    │
│ (client) │     (exec request)           │ (remote scp) │
└──────────┘                              └──────────────┘
             Stream data + text headers ←→
 
 
When you run: scp localfile user@server:/remote/path
 
1. Local scp establishes SSH connection to server
2. SSH authenticates user
3. Local scp requests remote execution of:
   "scp -t /remote/path"   (-t = 'to' mode, receiving files)
4. Remote scp runs in receive mode
5. Local scp sends file data through SSH channel
6. Remote scp writes to filesystem
7. Both sides exit, connection closes
 
For download: scp user@server:/remote/file ./local
              Remote runs "scp -f /remote/file" (-f = 'from' mode, sending files)

The -t and -f Flags

The -t (to) and -f (from) flags are internal to SCP protocol negotiation. Users never type them directly. When you run 'scp file remote:path', your local scp automatically invokes 'scp -t path' on the remote. These flags signal which role each side plays in the transfer.

SCP Protocol Mechanics

SCP uses a simple text-based protocol for metadata, with raw binary data transfer for file contents. Understanding this protocol reveals both its elegance and its vulnerabilities.

Protocol Message Types:

SCP defines a handful of control messages, all text-based with newline terminators:

SCP Protocol Messages
Prefix	Format	Direction	Purpose
C	Cmmmm size filename	Sender→Receiver	Announce file with permissions, size, name
D	Dmmmm 0 dirname	Sender→Receiver	Enter directory (recursive mode)
E	E	Sender→Receiver	Exit directory level
T	Tmtime 0 atime 0	Sender→Receiver	Set modification and access times
(null)	\0	Both	Acknowledgment (success)
(0x01)	\x01message	Receiver→Sender	Warning message
(0x02)	\x02message	Receiver→Sender	Fatal error, abort transfer

File Transfer Sequence:

SCP Transfer Protocol

Upload: scp report.pdf user@server:/home/user/
 
Sender (local)                       Receiver (remote scp -t)
    │                                          │
    │  [SSH connection established]            │
    │  [Remote exec: scp -t /home/user/]       │
    │                                          │
    │           ←──────── \0 ───────────────── │  Ready acknowledgment
    │                                          │
    │  ─── T1642345678 0 1642345600 0
 ────→ │  Timestamps (optional with -p)
    │                                          │
    │           ←──────── \0 ───────────────── │  Timestamp accepted
    │                                          │
    │  ─── C0644 102400 report.pdf
 ───────→ │  File header:
    │                                          │    mode=0644, size=102400 bytes
    │                                          │
    │           ←──────── \0 ───────────────── │  Ready to receive
    │                                          │
    │  ─── [102400 bytes of file data] ─────→ │  Raw file content
    │                                          │
    │  ─── \0 ──────────────────────────────→ │  Transfer complete
    │                                          │
    │           ←──────── \0 ───────────────── │  File accepted
    │                                          │
    │  [Connection closes]                     │

Protocol Vulnerability: CVE-2019-6111

The SCP protocol's trust model is fundamentally flawed. When you request files from a malicious server, the server controls what filenames and content it sends. An attacker-controlled server could send '.bashrc' when you requested 'report.txt', or include hidden files in directory transfers. The client trusts the server's file metadata without validation. This vulnerability class led to SCP's deprecation.

SCP Command Usage and Syntax

Despite deprecation, the scp command remains available in modern OpenSSH, now using SFTP protocol internally while maintaining familiar syntax. Understanding command usage helps both with legacy systems and the modern hybrid implementation.

Basic Syntax:

SCP Command Patterns
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# Basic file upload (local to remote)
scp localfile.txt user@remote:/path/to/destination/
 
# Basic file download (remote to local)
scp user@remote:/path/to/file.txt ./local/directory/
 
# Copy with custom SSH port
scp -P 2222 file.txt user@remote:/path/
 
# Recursive directory copy
scp -r /local/directory user@remote:/remote/parent/
 
# Preserve file attributes (mode, times)
scp -p file.txt user@remote:/path/
 
# Verbose output for debugging
scp -v file.txt user@remote:/path/
 
# Quiet mode (suppress progress meter)
scp -q largefile.iso user@remote:/path/
 
# Limit bandwidth (in Kbit/s)
scp -l 1000 hugefile.tar user@remote:/path/  # ~125KB/s
 
# Use specific identity file (private key)
scp -i ~/.ssh/deploy_key file.txt user@remote:/path/
 
# Enable compression (good for text, bad for already-compressed)
scp -C logfile.txt user@remote:/path/
 
# Remote-to-remote copy (proxied through local machine)
scp user1@server1:/file.txt user2@server2:/destination/
 
# Copy multiple files
scp file1.txt file2.txt user@remote:/path/
 
# Wildcard patterns (expands locally before transfer)
scp *.log user@remote:/var/log/archive/

Important Command Options:

SCP Command Options Reference
Option	Long Description	Common Use Case
-r	Recursively copy entire directories	Backing up directory trees
-p	Preserve modification times, access times, and modes	Maintaining file attributes
-P port	Connect to specified port on remote host	Non-standard SSH port
-i identity	Use specified identity file for authentication	Automated scripts with deploy keys
-C	Enable compression in SSH layer	Text files over slow links
-l limit	Limit bandwidth usage (Kbit/s)	Preventing network saturation
-q	Quiet mode, disable progress meter	Scripted transfers, logging
-v	Verbose mode for debugging	Troubleshooting connection issues
-3	Copy between two remotes via local host	When remotes can't directly connect
-F config	Use specified SSH config file	Custom SSH configurations
-o option	Pass options directly to SSH	Any SSH option as ssh_config
-O	Use legacy SCP protocol (not SFTP)	Compatibility with old servers
-s	Use SFTP protocol internally	Default in OpenSSH 9.0+

The -O Flag: Forcing Legacy Protocol

Starting with OpenSSH 9.0, scp uses SFTP internally by default. If you encounter compatibility issues with old SFTP-unaware servers, use 'scp -O' to force the legacy SCP protocol. However, this should be a last resort—prefer upgrading the server if possible.

SCP Limitations and Design Constraints

SCP's simplicity creates inherent limitations that SFTP was designed to address. Understanding these constraints explains why SFTP became the preferred protocol.

Fundamental Limitations:

What SCP Cannot Do

•No Directory Listing — SCP cannot list remote directory contents. You must know the exact path before transferring. No browsing, no autocomplete, no discovery.
•No Resume/Restart — If a transfer is interrupted, you must start over completely. There's no mechanism to determine where the previous transfer stopped or to continue from that point.
•No Partial File Access — SCP transfers complete files sequentially. You cannot read the middle of a file, append to an existing file, or perform random-access operations.
•No Remote Operations — Beyond copying, SCP cannot rename, delete, create directories, or modify file attributes remotely. Each operation requires separate SSH commands.
•No Atomic Rename — SCP writes directly to the target filename. Interrupted transfers leave partial files. SFTP can write to temp files and rename atomically.
•Limited Metadata — SCP preserves basic POSIX permissions and timestamps (-p flag) but lacks support for extended attributes, ACLs, or platform-specific metadata.

Comparison: SCP Operations vs SFTP Capabilities:

Capability Comparison
Operation	SCP Support	SFTP Support	Workaround for SCP
Upload file	✓ Native	✓ Native	—
Download file	✓ Native	✓ Native	—
List directory	✗ None	✓ READDIR	Separate ssh ls command
Resume transfer	✗ None	✓ OPEN + seek offset	Manual split/combine
Create directory	✗ None	✓ MKDIR	Separate ssh mkdir
Delete file	✗ None	✓ REMOVE	Separate ssh rm
Rename file	✗ None	✓ RENAME	Separate ssh mv
Check file exists	✗ None	✓ STAT	Separate ssh test -e
Get file size	✗ None	✓ STAT	Separate ssh stat
Modify permissions	✗ None	✓ SETSTAT	Separate ssh chmod
Symbolic links	Partial (copy target)	✓ SYMLINK/READLINK	Copy with ssh readlink
Preserve times	✓ -p flag	✓ atime/mtime	—

The Wrapper Script Problem

To compensate for SCP's limitations, administrators often created wrapper scripts combining scp with ssh commands for listing, permission changes, and directory creation. These scripts were fragile (shell quoting issues), inefficient (multiple connections), and security-risky (command injection). SFTP provides all these operations through a single, secure protocol.

Security Vulnerabilities and Deprecation

The SCP protocol carries fundamental security vulnerabilities that cannot be fixed without breaking backward compatibility. These issues crystallized the decision to deprecate SCP in favor of SFTP.

The Trust Model Problem:

SCP's protocol places excessive trust in the remote server. When downloading files, the client trusts the server to send exactly what was requested. This trust is misplaced.

SCP Security Vulnerabilities (CVE-2019 Series)

•CVE-2019-6111: Arbitrary File Overwrite — A malicious server can send files with different names than requested. Requesting 'report.txt' could deliver 'malware.sh'. The client's filename validation was insufficient.
•CVE-2019-6109: ANSI Code Injection — File names could contain ANSI escape sequences that manipulate terminal output, hiding actions from users. Progress meters could be faked.
•CVE-2019-6110: Object Name Validation Bypass — Specially crafted responses could bypass existing filename validation, enabling directory traversal attacks (../../../etc/passwd).

Attack Scenario:

Malicious SCP Server Attack

Attack Flow

User runs: scp untrusted@evil.server:data.csv ./
 
Expected behavior:
  Server sends: C0644 1000 data.csv
 
                [file contents]
  
  Result: ./data.csv created
 
Actual attack:
  Server sends: C0644 1000 data.csv
 
                [file contents for data.csv]
                \0
                C0644 5000 .bashrc
   <- MALICIOUS PAYLOAD
                [malicious bash config]
                \0
  
  Result: ./data.csv AND ./.bashrc created!
          Next shell login executes attacker's code.
 
Why this works:
1. Client requests single file
2. Server sends requested file (looks normal)
3. Server sends additional unrequested file  
4. Client lacks validation that transfer should be complete
5. Malicious file written to predictable location
 
Mitigation in patched versions:
- Strict validation of received filenames against request
- Rejection of additional files beyond request count
- But: Protocol fundamentally trusts server too much

Why SFTP Doesn't Have These Issues:

SFTP's design inherently protects against these attacks:

SFTP Security Advantages

•Client-Initiated Operations — In SFTP, the client opens specific files by path and controls what's written locally. Server cannot inject unexpected data.
•Request-Response Pairing — Each SFTP request gets exactly one response. No mechanism for server to send unrequested data.
•Binary Protocol — No ANSI escape sequences possible in protocol messages. File names are length-prefixed binary strings, not line-delimited.
•Separate Control and Data — File data is requested explicitly with READ operations. Metadata comes through separate ATTRS responses.

The Deprecation Timeline

OpenSSH 8.0 (April 2019): Announced SCP protocol would be replaced with SFTP. OpenSSH 9.0 (April 2022): Default changed to SFTP protocol for scp command. The legacy protocol remains available via -O flag but is not recommended. Organizations should migration scripts and automation to use sftp or scp's new SFTP-based implementation.

Modern SCP: SFTP Under the Hood

Starting with OpenSSH 9.0, the scp command maintains its familiar syntax while using SFTP protocol internally. This hybrid approach preserves user experience while eliminating protocol vulnerabilities.

How It Works:

Modern vs Legacy SCP

Protocol Selection

Command: scp file.txt user@server:/path/
 
OpenSSH 8.x (Legacy Default):
┌──────────────────────────────────────────────────────────────────┐
│ scp → SSH connection → remote exec "scp -t /path/" → SCP protocol│
└──────────────────────────────────────────────────────────────────┘
 
OpenSSH 9.x+ (SFTP Default):
┌──────────────────────────────────────────────────────────────────┐
│ scp → SSH connection → SFTP subsystem request → SFTP protocol   │
└──────────────────────────────────────────────────────────────────┘
 
Force legacy: scp -O file.txt user@server:/path/
Force SFTP:   scp -s file.txt user@server:/path/
 
Detection:
  scp -v file.txt user@server:/path/ 2>&1 | grep -i sftp
  # If using SFTP: "Transferring file ... via SFTP"
  # If using SCP:  "Sending file ... via scp"

Behavioral Differences:

While the command syntax remains identical, subtle differences emerge from the protocol change:

Legacy SCP vs Modern (SFTP-based) SCP
Behavior	Legacy SCP (-O)	Modern SCP (SFTP)	Impact
Directory expansion	Remote shell globs	SFTP REALPATH/STAT	Different wildcard handling
Symlink handling	Follows links by default	Depends on server config	Potential behavior change
Error messages	Remote shell output	SFTP status codes	Different error text
File overwrite	Immediate overwrite	Can fail on permission	Stricter checking
Space in path	Requires quoting	Handled correctly	Fewer escaping issues
Performance	Single data stream	Multi-request capable	Potentially faster
Resume capability	Not available	Theoretically possible	Not exposed in scp CLI

Migration Strategy

For scripts depending on scp, test with modern OpenSSH before upgrading in production. Watch for: wildcard expansion differences, symbolic link behavior, and error message parsing. When possible, migrate directly to sftp command for better compatibility and full SFTP feature access.

Server Compatibility:

The modern scp requires the remote server to have SFTP subsystem available. Most servers do, but exceptions exist:

•Embedded/IoT devices — May have minimal SSH with no SFTP server
•Restricted environments — Some configurations disable SFTP for security
•Very old servers — Pre-OpenSSH 2.0 systems lack SFTP
•Non-OpenSSH implementations — Some SSH servers have limited SFTP support

Falling Back to Legacy

If modern scp fails with SFTP errors, use 'scp -O' to fall back to legacy protocol. However, audit the server for security compliance—lacking SFTP often indicates outdated or non-standard SSH implementation.

When SCP Knowledge Remains Valuable

Despite deprecation, understanding SCP serves practical purposes in specific scenarios.

Valid Use Cases for Legacy SCP:

Where Legacy SCP May Be Required

•Extremely Old Systems — Legacy UNIX systems (Solaris, HP-UX, AIX) may have SSH without SFTP subsystem. If upgrading isn't possible, legacy SCP is the only option.
•Embedded Devices — Network equipment, IoT devices, and embedded Linux often ship with minimal BusyBox SSH lacking SFTP.
•Chroot Environments Without internal-sftp — Some restricted shell setups that predate internal-sftp may rely on legacy SCP.
•Protocol Debugging — Understanding SCP protocol helps debug transfer issues, parse logs, and understand what legacy scripts actually do.

When to Instead Use SFTP:

Prefer SFTP/Modern SCP For

•All new implementations — There's no reason to implement legacy SCP support in new tools.
•Interactive file management — Use sftp command or graphical clients for browsing.
•Automated backup/sync — rsync over SSH or dedicated SFTP clients provide better functionality.
•Large file transfers — SFTP's resume capability is essential for unreliable networks.
•Security-conscious environments — Legacy SCP's vulnerabilities make it inappropriate for sensitive data.

The Practical Bottom Line

Use the scp command with its modern SFTP implementation for convenience. Use sftp directly for interactive sessions and advanced operations. Reserve 'scp -O' (legacy protocol) only for connecting to systems that cannot support SFTP. Always prefer upgrading legacy systems to modern SSH when feasible.

Summary: The SCP Story

We've thoroughly examined SCP—its origins, protocol mechanics, limitations, vulnerabilities, and modern evolution. Let's consolidate the essential knowledge.

Key Takeaways

•SCP descended from rcp — Designed to secure BSD's remote copy with SSH encryption, maintaining familiar cp-like syntax.
•Simple command-tunneling model — SCP executes 'scp -t/-f' on remote systems through SSH exec, exchanging files over the channel.
•Text-based protocol — 'C' headers for files, 'D' for directories, null bytes for acknowledgment—simple but vulnerable.
•Fundamental limitations — No directory listing, no resume, no random access, no remote operations beyond copy.
•Critical security vulnerabilities — Server can inject arbitrary files (CVE-2019-6111) due to misplaced trust model.
•Deprecated in OpenSSH 9.0 — Modern scp uses SFTP internally; legacy protocol available only via -O flag.
•Legacy knowledge remains valuable — Understanding SCP helps with old systems and protocol debugging.

What's Next:

Having explored both SFTP and SCP protocols individually, the next page examines SSH integration—how these protocols leverage SSH's authentication, encryption, and configuration systems. You'll learn about SSH key management, tunneling, and the configuration options that affect secure file transfer in production environments.

Page Complete

You now understand SCP's complete story—from its origins as a secure rcp replacement through its deprecation and replacement by SFTP. This knowledge enables informed decisions about file transfer tools and helps maintain legacy systems requiring SCP compatibility.