Command-Line File Transfer Tools Compared

All three ride on an SSH connection, so they inherit its security model: the client verifies the server's host key (pinned on first use in known_hosts), the user authenticates with a key or password, and everything travels inside the encrypted SSH channel. There is no third party in the path. The cost is access: you need an account on the remote machine and a network path to its SSH port, which rules them out for handing a file to a colleague, a client or a locked-down container.

scp

The OpenSSH manual notes that since OpenSSH 9.0, scp uses the SFTP protocol for transfers by default; -O selects the legacy SCP protocol for servers without SFTP support. The command line is unchanged, but quoting and wildcard behaviour can differ slightly from the old protocol.

scp ./build.tar.gz [email protected]:/srv/releases/
scp -r [email protected]:/var/log/app ./app-logs
scp -O legacy-host:/data/file.bin .     # force the old SCP protocol

sftp

Interactive, and the one SSH tool with built-in resume for single files: reget and reput continue partial transfers, on the assumption that the partial copy matches the remote file.

sftp [email protected]
sftp> get -R /var/log/app ./app-logs
sftp> reget /srv/backups/db.dump      # resume an interrupted download

rsync

rsync's delta-transfer algorithm sends only the differences between source and destination, which makes it the right choice for repeated syncs and for large directory trees. --partial keeps partly transferred files, and --append-verify continues them and checks the whole file afterwards.

rsync -az --partial -e ssh ./dist/ [email protected]:/srv/app/
rsync -a --append-verify [email protected]:/srv/backups/db.dump ./

Magic Wormhole was designed for the case SSH cannot serve: two people, no shared accounts, no open ports. The sender gets a code such as 7-crossover-clockwork, reads it out, and the receiver types it in.

Under the hood, both clients connect to a mailbox (rendezvous) server, a WebSocket relay that delivers small messages between them. They run SPAKE2, a password-authenticated key exchange, using the code as the password. PAKE is the important part: the mailbox server never learns a key it could use, and an attacker who wants in must guess the code during the exchange. The documentation puts the default code at 16 bits, so an attacker gets a 1-in-65,536 chance, one attempt per code, and a failed attempt makes the real exchange fail visibly. Codes are single-use.

The file then moves over a direct TCP connection if one can be made, or through a transit relay that joins two outbound connections (the project calls it the moral equivalent of a TURN server). Data is encrypted with NaCl secretbox under the PAKE-derived key, so the relay forwards ciphertext. Both clients must stay running until the transfer finishes.

# sender
wormhole send ./dataset.parquet
# Wormhole code is: 7-crossover-clockwork

# receiver
wormhole receive 7-crossover-clockwork

# longer code for higher-value transfers
wormhole send --code-length=3 ./dataset.parquet

croc follows the same idea: a code phrase feeds a PAKE that produces the end-to-end encryption key. Its README describes transfers as peer to peer with a relay fallback, sends multiple files and folders in one command, and supports resuming interrupted transfers. The relay is easy to self-host (croc relay, TCP ports 9009-9013 by default), and a SOCKS5 proxy such as Tor can be set on both peers.

On Linux and macOS the receiver passes the code in the CROC_SECRET environment variable rather than as an argument, so it does not leak through the process list. Custom code phrases must be at least six characters.

# sender
croc send ./dataset.parquet ./reports/
# prints a code phrase

# receiver (Windows)
croc <code-phrase>
# receiver (Linux / macOS)
CROC_SECRET=<code-phrase> croc

# your own relay
croc relay
croc --relay "relay.example.com:9009" send ./dataset.parquet

SRIFT takes a different approach: the recipient installs nothing. srift quick-share keeps an outbound WebSocket from the sender's machine to the SRIFT server and prints a https://srift.app/d/<token> link. When someone opens it, the server asks the sender's process for the bytes and forwards them to the download as they arrive; nothing is stored. Because the sender only makes outbound HTTPS connections on port 443, it works from servers, containers and CI runners that accept no inbound traffic (see getting files off a remote server and moving files out of containers).

srift quick-share ./dataset.parquet --encrypt --once --ttl 1h
# https://srift.app/d/<token>#k=<key>

SRIFT_LINK_PASSWORD='<passphrase>' srift quick-share ./reports/   # folder as .tar.gz, password-protected
srift links revoke <token>                       # cut a link off early

# encrypted link: open it in a browser (decrypts in the page), or
srift get "https://srift.app/d/<token>#k=<key>"

# link created without --encrypt: any HTTP client works
curl -fLOJ "https://srift.app/d/<token>"

• Encryption. With --encrypt the file is sealed with AES-256-GCM before it leaves the sender, and the key travels after the #, which browsers never send to servers, so the relay handles ciphertext. Plain curl would download that ciphertext; use a browser or srift get. Without --encrypt, the link is protected by TLS only and the SRIFT server sees the file name and contents in transit.
• Lifetime. There is no default expiry: the link works while the sender's daemon or process is serving it. --once, --max-downloads and --ttl narrow that.
• Folders. Directories are packed as .tar.gz, always excluding .git and node_modules.

The same transport is what lets AI coding agents hand you files through SRIFT's MCP server, and the security architecture documents exactly what the server can see in each mode.

The tools differ most in how they decide that the other end is the right one, and that matters more than cipher choices.

• SSH keys authenticate both sides cryptographically and keep working for years. The weak point is the first connection, where you accept a host key, and the operational cost of distributing accounts.
• PAKE codes (Magic Wormhole, croc) are short but strong in a specific way: they can only be guessed online, during the exchange, and a wrong guess is noticed. A code that has been used, or overheard after the transfer, is worthless. Nobody in the middle, including the rendezvous server, can derive the key.
• Bearer links (SRIFT quick-share, and cloud share links in general) carry a random token too long to guess, but anyone who has the full URL can download while the link is live. Links get pasted into chat histories, ticket systems and browser history, and --encrypt keeps the key from the server, not from whoever reads the link.

• Both machines are yours and SSH is open: rsync for anything repeated or large, sftp when you need to resume a single big file, scp for a quick copy.
• Two people with terminals, one-off: Magic Wormhole for the simplest secure handoff; croc if you want resume, several paths at once, or your own relay.
• The recipient has only a browser, or the sender is behind a firewall that allows only outbound HTTPS: a streamed link such as SRIFT quick-share, with --encrypt and a short lifetime. The firewall and proxy guide covers why outbound 443 is often the only door open.
• Asynchronous delivery to someone who will download days later: none of these; use storage.