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.
Last updated: August 2026

10.4 Securely Transfer Files Between Systems

Quick Answer: Copy over SSH with scp, sftp, or rsync -e ssh. Authenticate as with ssh user@host. Use user@host:path for remote locations, -r (scp) or -a (rsync) for directory trees, then verify with ls or checksums. Do not use unencrypted ftp/rcp when 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

OptionPurpose
-rRecursive directory copy
-P portSSH port if not 22 (capital P for scp)
-pPreserve mtime/mode (lowercase)
-i identityPrivate key file
-vVerbose (debug auth/path issues)
-CCompression
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

  1. Wrong direction — carefully read which host has the file.
  2. Forgetting -r for directories.
  3. -p vs -P — port is -P on scp; on ssh port is -p.
  4. Spaces in paths — quote paths: user@host:"/path/with space/file".
  5. 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/
OptionMeaning
-aArchive: recurse, preserve symlinks, perms, times, etc.
-vVerbose
-zCompress during transfer
-e sshUse SSH as remote shell (often default for user@host form)
--deleteMake destination mirror source by deleting extras (dangerous—only if task wants mirror)
-n / --dry-runShow what would happen
--progressProgress 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:

MethodUsage
PasswordInteractive prompt (may be disabled by policy)
Public keyssh-copy-id beforehand; scp -i key ...
Agentssh-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?

NeedPrefer
One-off file or small treescp
Interactive browse/put/getsftp
Large tree, repeat sync, bandwidth efficiencyrsync -a -e ssh
Exact mirror including deletesrsync --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)

  1. Prefer key auth and strong host key verification (known_hosts).
  2. Do not scp sensitive files to shared world-readable directories without need.
  3. Use dedicated transfer accounts when policy requires.
  4. On first connect, verify host keys if the exam environment warns you—accept only expected lab hosts.
  5. rsync --delete can wipe remote data—dry-run first.

Common traps

  1. Using FTP because the word “transfer” appeared—objective wants secure methods.
  2. scp -p 2222 intending port 2222—wrong; use -P 2222.
  3. rsync trailing slash creating unexpected nesting.
  4. Assuming root remote paths work without root login or sudo on server.
  5. Forgetting network path — wrong IP/hostname.
  6. Not verifying after copy—exam tasks often depend on the file being on the other host.
  7. 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.

Test Your Knowledge

Which command securely copies a local directory tree to a remote host over SSH in one shot?

A
B
C
D
Test Your Knowledge

You must use SSH on port 2222 with scp. Which option is correct?

A
B
C
D
Test Your Knowledge

Which rsync invocation best performs an archive-mode sync of a local tree to a remote host over SSH with a dry-run first?

A
B
C
D
Test Your Knowledge

scp to server1 fails immediately, and ssh user@server1 also fails. What should you fix first?

A
B
C
D