10.4 Securely Transfer Files Between Systems
Key Takeaways
- Transfer files securely over SSH using scp, sftp, and rsync-over-SSH—traffic is encrypted and authenticates with the same credentials or keys as ssh.
- scp copies files/directories in one shot; sftp provides an interactive or batch filesystem-like session; rsync efficiently syncs trees and can resume/delta-copy.
- Syntax pattern is user@host:/path for remote sides; watch direction (push vs pull) and whether you need -r for directories with scp.
- Non-interactive exam work often prefers scp or rsync -av -e ssh; ensure sshd is reachable and firewall allows SSH before blaming the copy tool.
- Verify transfers with ls, checksums (sha256sum), or size comparisons; permissions and SELinux contexts may need adjustment after copy depending on the task.
10.4 Securely Transfer Files Between Systems
Quick Answer: Copy over SSH with
scp,sftp, orrsync -e ssh. Authenticate as withssh user@host. Useuser@host:pathfor remote locations,-r(scp) or-a(rsync) for directory trees, then verify withlsor checksums. Do not use unencryptedftp/rcpwhen the objective says secure transfer.
Why this skill is on EX200
Operate running systems includes securely transferring files between systems. In multi-host labs you move:
- Archives of web content or configs
- SSH public keys (related security objective)
- Backup tarballs
- Scripts and packages between workstation and server
“Securely” means encrypted in transit with authentication—practically SSH-based tools on RHEL.
Prerequisites checklist
Before blaming scp:
# From client
ping -c 2 server.example.com # if ICMP allowed—optional
ssh user@server.example.com # login must work first
systemctl is-active sshd # on the server
firewall-cmd --list-services # ssh should be allowed if firewalld is on
If ssh fails, file transfer tools that use SSH will also fail. Fix sshd, firewall, routing, DNS/hosts, or credentials first (skills from other sections).
scp — secure copy
scp copies files over SSH in a cp-like style.
Push local → remote
scp /path/local.txt user@remote:/path/on/remote/
scp -r /path/localdir user@remote:/path/on/remote/
scp file1 file2 user@remote:/var/tmp/
Pull remote → local
scp user@remote:/var/tmp/data.tgz .
scp -r user@remote:/etc/myapp/ ./myapp-backup/
Useful options
| Option | Purpose |
|---|---|
-r | Recursive directory copy |
-P port | SSH port if not 22 (capital P for scp) |
-p | Preserve mtime/mode (lowercase) |
-i identity | Private key file |
-v | Verbose (debug auth/path issues) |
-C | Compression |
scp -P 2222 -i ~/.ssh/id_rsa app.tgz admin@10.0.0.20:/var/tmp/
scp -rp /srv/www user@web1:/srv/
Note: OpenSSH has moved toward deprecating legacy scp protocol internals in favor of SFTP under the hood in modern versions—behavior remains “scp command” for exams. If scp is missing, use sftp or rsync.
Common scp mistakes
- Wrong direction — carefully read which host has the file.
- Forgetting
-rfor directories. -pvs-P— port is-Pon scp; onsshport is-p.- Spaces in paths — quote paths:
user@host:"/path/with space/file". - Trailing path — remote directory must exist or you specify a full destination filename.
sftp — interactive secure FTP over SSH
sftp opens a session (still SSH—not classic cleartext FTP).
sftp user@remote
# inside:
sftp> pwd
sftp> lpwd
sftp> ls
sftp> lls
sftp> cd /var/tmp
sftp> lcd /home/student
sftp> put local.tgz
sftp> get remote.tgz
sftp> put -r localdir
sftp> get -r remotedir
sftp> bye
Batch / non-interactive:
sftp user@remote <<'EOF'
cd /var/tmp
put report.csv
bye
EOF
# or
echo 'get /var/tmp/a.tgz' | sftp user@remote
Use sftp when you need to browse the remote filesystem interactively or script simple put/get without rsync features.
rsync over SSH — efficient sync
rsync copies deltas and is excellent for directories and repeated syncs.
# Push
rsync -av -e ssh /path/localdir/ user@remote:/path/remotedir/
# Pull
rsync -av -e ssh user@remote:/path/remotedir/ /path/localdir/
| Option | Meaning |
|---|---|
-a | Archive: recurse, preserve symlinks, perms, times, etc. |
-v | Verbose |
-z | Compress during transfer |
-e ssh | Use SSH as remote shell (often default for user@host form) |
--delete | Make destination mirror source by deleting extras (dangerous—only if task wants mirror) |
-n / --dry-run | Show what would happen |
--progress | Progress meter |
rsync -avz --progress -e ssh ~/project/ user@build:/srv/project/
rsync -avn -e ssh ~/project/ user@build:/srv/project/ # dry run first
Trailing slash semantics (critical)
# Copies *contents* of localdir into remotedir
rsync -av localdir/ user@host:remotedir/
# Copies the directory localdir as a child of remotedir
rsync -av localdir user@host:remotedir/
Misplaced slashes create nested wrong trees—verify with ssh user@host ls after transfer.
Authentication patterns
Same as SSH:
| Method | Usage |
|---|---|
| Password | Interactive prompt (may be disabled by policy) |
| Public key | ssh-copy-id beforehand; scp -i key ... |
| Agent | ssh-add then tools reuse agent |
ssh-copy-id user@remote
scp secrets.tgz user@remote:/root/ # as permitted
Exam images may pre-seed keys or use passwords—read the exam notes. Do not spend the whole exam generating keys unless the task requires key setup (security domain).
Which tool should you choose?
| Need | Prefer |
|---|---|
| One-off file or small tree | scp |
| Interactive browse/put/get | sftp |
| Large tree, repeat sync, bandwidth efficiency | rsync -a -e ssh |
| Exact mirror including deletes | rsync --delete (only when intended) |
All three are secure when using SSH. Avoid ftp, telnet, unencrypted http put, or rsh/rcp for this objective.
End-to-end exam workflows
Workflow A — Copy a tarball to a server and extract
tar czf /tmp/site.tgz -C /srv www
scp /tmp/site.tgz admin@server1:/var/tmp/
ssh admin@server1 'sudo tar xzf /var/tmp/site.tgz -C /var/www'
Workflow B — Pull logs for analysis
scp root@server1:/var/log/secure /tmp/server1-secure
less /tmp/server1-secure
Workflow C — Sync project directory with rsync
rsync -av -e ssh /home/student/app/ student@app01:/home/student/app/
ssh student@app01 'ls -la /home/student/app | head'
Workflow D — Non-default SSH port
scp -P 2222 file user@host:/tmp/
rsync -av -e 'ssh -p 2222' file user@host:/tmp/
sftp -P 2222 user@host
Remember scp/sftp -P vs ssh/rsync’s ssh -p.
Verification
# Sizes and names
ls -l file
ssh user@host ls -l /path/file
# Checksums
sha256sum file
ssh user@host sha256sum /path/file
# Recursive count
find dir | wc -l
ssh user@host "find /path/dir | wc -l"
If SELinux contexts matter on the destination (web content, home .ssh), restore contexts after unpack:
ssh user@host 'sudo restorecon -Rv /var/www/html'
Permissions: scp/rsync -a preserve modes to a point, but ownership on the remote becomes the login user unless you escalate on the server after transfer.
Connectivity and firewall notes
On the server:
sudo systemctl start sshd
sudo systemctl enable sshd
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload
If transfers hang, check:
# client
ssh -vvv user@host
# server
sudo journalctl -u sshd -b --no-pager | tail
sudo firewall-cmd --list-all
ss -tlnp | grep sshd
Security hygiene (exam + real life)
- Prefer key auth and strong host key verification (
known_hosts). - Do not scp sensitive files to shared world-readable directories without need.
- Use dedicated transfer accounts when policy requires.
- On first connect, verify host keys if the exam environment warns you—accept only expected lab hosts.
rsync --deletecan wipe remote data—dry-run first.
Common traps
- Using FTP because the word “transfer” appeared—objective wants secure methods.
- scp -p 2222 intending port 2222—wrong; use
-P 2222. - rsync trailing slash creating unexpected nesting.
- Assuming root remote paths work without root login or sudo on server.
- Forgetting network path — wrong IP/hostname.
- Not verifying after copy—exam tasks often depend on the file being on the other host.
- Firewalled SSH after hardening—open service/port before transfer tasks in multi-step labs.
Relationship to other chapters
- SSH access (essential tools): login and keys underpin every method here.
- Archives: tar/gzip content, then scp/rsync the archive.
- Firewall/security: SSH must be allowed for transfer.
- Permissions/SELinux: destination use may need context/permission fixes after copy.
Section checkpoint
You should transfer files securely with scp, sftp, and rsync over SSH, choose the right tool and direction, handle ports and recursion correctly, ensure sshd connectivity first, verify data on the far side, and avoid insecure cleartext copy tools. That satisfies EX200 secure file transfer expectations.
Which command securely copies a local directory tree to a remote host over SSH in one shot?
You must use SSH on port 2222 with scp. Which option is correct?
Which rsync invocation best performs an archive-mode sync of a local tree to a remote host over SSH with a dry-run first?
scp to server1 fails immediately, and ssh user@server1 also fails. What should you fix first?