File Transfer

The basic pattern

Receiver listens, sender connects. Direction of the shell redirect decides who sends.

# Receiver, start this FIRST
nc -l 8080 > received.bin

# Sender
nc 10.0.0.5 8080 < file.bin

Reversed, so the listener is the one holding the file:

# Sender listens
nc -l 8080 < file.bin

# Receiver connects and pulls
nc 10.0.0.5 8080 > received.bin

Either works. Listening on the sender is handy when the receiver is the box you can reach out from but not into, which is the usual firewall shape.

Knowing when it finished

This is the part that goes wrong. netcat transfers a byte stream with no length header, no checksum, and no end-of-file marker, so the receiver cannot tell a completed transfer from a truncated one.

# Sender closes the connection at EOF, so the receiver exits
nc -N 10.0.0.5 8080 < file.bin           # OpenBSD nc
ncat --send-only 10.0.0.5 8080 < file.bin  # Ncat

# Or wait a moment after EOF then quit
nc -q 0 10.0.0.5 8080 < file.bin

# macOS nc has neither, so bound it externally
timeout 60 nc 10.0.0.5 8080 < file.bin

Always verify afterward. A transfer that looks fine can be short:

# On both sides
sha256sum file.bin       # Linux
shasum -a 256 file.bin   # macOS
wc -c file.bin

If the sizes differ, the connection closed early. There is no retry and no resume, so send it again.

Directories, with tar

netcat moves one stream, so tar provides the structure.

# Receiver
nc -l 8080 | tar xvf -

# Sender
tar cvf - ./mydir | nc -N 10.0.0.5 8080

# Compressed, worth it over a slow link
nc -l 8080 | tar xzvf -
tar czvf - ./mydir | nc -N 10.0.0.5 8080

# Preserve permissions and ownership, run the receiver as root
nc -l 8080 | sudo tar xpvf -

- as the tar file argument means stdin or stdout. tar c writes to stdout, tar x reads stdin, so the pipe direction does the rest.

Compression choice on a fast LAN: skip it. gzip becomes the bottleneck above roughly 100 MB/s. On a WAN, tar cz or zstd wins comfortably.

# zstd, much faster than gzip at similar ratios
tar cf - ./mydir | zstd -3 | nc -N 10.0.0.5 8080
nc -l 8080 | zstd -d | tar xvf -

Progress

netcat prints nothing while transferring, so a large file looks like a hang. Insert pv.

# Sender side, with a total so the ETA is real
pv file.bin | nc -N 10.0.0.5 8080

# Receiver side, when you know the expected size
nc -l 8080 | pv -s 2G > received.bin

# Both, with tar
tar cf - ./mydir | pv | nc -N 10.0.0.5 8080

Without pv, ls -l on the receiver's partial file is the low-tech equivalent.

Disks and block devices

# Clone a partition over the network
# Receiver
nc -l 8080 | dd of=/dev/sdb bs=4M

# Sender
dd if=/dev/sda bs=4M | nc -N 10.0.0.5 8080

# Compressed image, skipping zero blocks
dd if=/dev/sda bs=4M | gzip -1 | nc -N 10.0.0.5 8080
nc -l 8080 | gunzip | dd of=/dev/sdb bs=4M

dd of=/dev/sdb overwrites a whole device with no confirmation. Verify the target name with lsblk immediately before running it. Getting this wrong destroys data with no recovery.

Unmount the source first, or the image is inconsistent.

Rate limiting

An unthrottled transfer will saturate the link and take down whatever else shares it.

# pv caps the rate, 10 MB/s here
pv -L 10m file.bin | nc -N 10.0.0.5 8080

# throttle, if available
cat file.bin | throttle -M 10 | nc -N 10.0.0.5 8080

No encryption, no integrity, no auth

Plain netcat sends bytes in cleartext to anyone who connects to the port. Anyone on the path can read or alter the stream, and the listener accepts the first connection that arrives, which may not be yours.

Encrypted alternatives, in order of preference:

# Ncat with TLS, the smallest change
ncat -lk --ssl 8443 > received.bin
ncat --ssl --send-only 10.0.0.5 8443 < file.bin

# ssh, if you have credentials. Encrypted and authenticated
tar czf - ./mydir | ssh user@10.0.0.5 'tar xzf - -C /dest'
scp file.bin user@10.0.0.5:/dest/
rsync -avP file.bin user@10.0.0.5:/dest/

# openssl, when you only have openssl on both ends
openssl s_server -quiet -accept 8443 \
  -cert cert.pem -key key.pem > received.bin
openssl s_client -quiet -connect 10.0.0.5:8443 < file.bin

Use rsync or scp when SSH is available. They are encrypted, authenticated, resumable, and verify integrity. netcat transfer is for hosts with no SSH, no shared credentials, and a one-time need, such as a rescue initramfs or a stripped container.

ncat --ssl without --ssl-verify encrypts but does not authenticate, so it stops passive eavesdropping and not an active attacker.

Comparison