scp vs rsync vs sftp

Three tools, three cases

• scp — old, simple, ssh-based copy. Good for one-shot single-file pushes/pulls.
• rsync — covered last lesson. Smart sync; the everyday choice.
• sftp — interactive ftp-like client over ssh. Good for browsing a remote tree without mounting it.

scp essentials

scp file.txt user@host:/path/         # local → remote
scp user@host:/path/file.txt .         # remote → local
scp -r dir/ user@host:/path/           # recursive
scp -P 2222 file.txt user@host:        # custom port (capital P!)

Note: capital -P for port (lowercase -p means preserve perms, opposite of ssh's -p).

scp's modern protocol

Modern OpenSSH scp uses SFTP by default; the command itself is still supported. The protocol change removes some legacy pathname expansion behavior, so test scripts that depended on the remote shell. Choose rsync, sftp, or scp from the transfer contract rather than a blanket deprecation claim.

sftp interactive

sftp user@host
sftp> pwd
sftp> ls
sftp> cd /var/log
sftp> get app.log         # download
sftp> put local.txt       # upload
sftp> bye

When to use which

• One file, both locations clear → scp is fine.
• Multiple files, repeat operations, want resume + delta → rsync.
• Need to browse the remote tree by hand, decide what to download → sftp.
• Need a mounted directory → evaluate a maintained SSHFS client and its filesystem dependency for this OS; a mount adds caching, disconnect, and permission semantics that a copy does not.

Transfer success is not atomic publication

Copying a large configuration directly to its final path can expose a partial file to readers. Upload under a temporary name, verify checksum and permissions, and rename remotely when the deployment contract requires atomic visibility.

Remote paths cross shell and protocol parsing boundaries

Spaces, wildcards, and colons can be interpreted by the local shell, the client, or the remote side depending on version and protocol. Do not concatenate untrusted input; verify quoting with a small sample.