Learn › RHCSA (EX200) › Operate Running Systems
scp - a hands-on Linux lab on a real virtual machine.
Move a file safely between two hosts over ssh. scp up and scp down with the colon marking the remote side, scp -r for whole directories, the interactive sftp session with get and put, and rsync -av as the efficient alternative that preserves attributes and re-syncs only changes. Serves EX200 operating-systems task 20: securely transfer a file between two nodes.
The exam hands you two machines: servera, where you are logged in, and serverb, sitting somewhere else on the network. A task says: take this file and put it safely on the other box. You cannot walk a USB stick between them. You cannot email it. Anything you send over the network could be read in transit unless it is encrypted.
That is EX200 operating-systems task 20: securely transfer a file between two nodes. The tool is not a new protocol you have to learn from scratch. It is ssh, the secure shell you already trust for logins, wearing a different hat. Three commands ride on top of it. scp does a quick copy, sftp runs an interactive session, and rsync is the efficient version. By the end of this lesson you will know the shape of all three.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. A real cross-host copy, servera to serverb, happens on the exam machines and in this module's capstone, not in this sandbox. Here you learn the exact command SHAPE you will type there, and you confirm the tooling with a version check that reads the same on every RHEL 10 box.
scp stands for secure copy. It copies a file from one machine to another over an encrypted ssh connection. Nothing crosses the network in the clear. If you can ssh to a host, you can scp to it, because scp uses the same connection, the same port 22, and the same login.
The shape is cp with a hostname bolted on. Plain cp copies between two paths on one machine. scp copies between two paths where either one can live on a remote host, written as user@host:/path. The colon is the hinge: everything before it is who and where, everything after it is the path on that machine.
scp is old, and it recently changed under the hood in a way the exam cares about. For decades it spoke its own quirky copy protocol. Modern OpenSSH rewrote it to ride the SFTP protocol instead, the same one sftp uses, which is safer and more predictable. On RHEL 10 you get that modern scp.
You can prove which OpenSSH you are on with one command. ssh -V prints the version and exits. Note the capital V. A lowercase -v would try to open a verbose connection instead. Run the version check:
ssh -V
prompt: student@servera:~$ answer: ssh -V output: OpenSSH_9.9p1, OpenSSL 3.5.5 27 Jan 2026 hint: The version flag is a capital V, not lowercase: ssh -V
OpenSSH_9.9p1. That is a modern OpenSSH, so its scp already rides the SFTP protocol under the hood. You did not have to configure anything; the version is proof the secure-transfer tools are installed and current. The OpenSSL half is the crypto library doing the actual encryption. One command told you the whole transfer stack is present and ready.
Before any of these commands can reach serverb without stopping to ask for a password, you set up key-based authentication first, which was the previous lesson. On the exam you generate a key with ssh-keygen, push it with ssh-copy-id, and only then do scp and sftp run cleanly. This sandbox has no second host and no key set up. So it teaches the command shape, and the real copy happens where the keys are.
The most common task is sending a file up to another box. Read the direction off the command: the local path comes first, the remote destination comes second. So scp SOURCE user@host:DEST copies from here to there.
Picture the exam task: copy your local report.txt into /tmp/ on serverb, logging in as root. The command names the local file, then root@serverb: for who and where, then /tmp/ for the path on that machine:
scp report.txt root@serverb:/tmp/
prompt: student@servera:~$ answer: scp report.txt root@serverb:/tmp/ output: hint: Local path first, then the remote as user@host:/path. Copy report.txt to /tmp/ on serverb as root: scp report.txt root@serverb:/tmp/
That is the workhorse form. report.txt is the source, on your machine. root@serverb:/tmp/ is the destination: user root, host serverb, path /tmp/. The colon splits the login from the path. On a real pair of hosts, with keys in place, scp prints a progress line and the file lands in /tmp/. In this sandbox there is no second host to answer. That is exactly why the exam step of setting up keys and hosts comes first.
The same command runs in reverse. Put the remote path first and the local path second, and now you are downloading. scp user@host:SOURCE DEST copies from there to here. The only thing that changed is which side of the command carries the colon.
Fetch /etc/hostname off serverb and drop it into your home directory under a new name so you remember where it came from:
scp root@serverb:/etc/hostname ~/serverb-name.txt
prompt: student@servera:~$ answer: scp root@serverb:/etc/hostname ~/serverb-name.txt output: hint: Remote first this time. Put root@serverb:/etc/hostname first, then the local name: scp root@serverb:/etc/hostname ~/serverb-name.txt
Same tool, opposite direction. Because the user@host: part is now the FIRST argument, scp reads it as the source and pulls the file down. The second argument, ~/serverb-name.txt, is the local destination, and naming it there both saves the file and renames it in one move. The rule to burn in: whichever path carries the colon is the remote one, and its position, first or second, decides upload versus download.
Get the direction wrong and you copy the wrong way, sometimes over the file you meant to keep. Read the task out loud: is the file going TO the remote (local path first) or coming FROM it (remote path first)? The colon marks the remote side; its position marks the direction. Confirm every transfer afterward with ls -l on the destination.
Point plain scp at a directory and it refuses, because by default it copies single files only. The fix is one flag. -r means recursive: descend into the directory and copy everything inside it, subfolders and all. It is the same -r you already know from cp -r.
Send the entire /etc/sysconfig directory up to /tmp/ on serverb, contents included, by adding -r right after the command:
scp -r /etc/sysconfig root@serverb:/tmp/
prompt: student@servera:~$ answer: scp -r /etc/sysconfig root@serverb:/tmp/ output: hint: Add the recursive flag right after scp, then the same source and destination: scp -r /etc/sysconfig root@serverb:/tmp/
The -r flag told scp to walk into /etc/sysconfig and carry every file and subfolder across, landing as /tmp/sysconfig on serverb. Without -r, the same command fails with not a regular file and copies nothing. This is a classic exam slip: the copy seems to run, but a directory quietly did not make it. If a folder is your source, -r is not optional.
Sometimes you do not know the exact remote path yet. You need to look around the far machine first, then grab what you find. That is what sftp is for. Instead of one-shot copies, it opens an interactive session on the remote host and gives you a small prompt, sftp>, where you type commands.
You connect the same way you would with ssh: name the user and host. Once connected, four commands do almost everything. ls lists remote files, cd moves around the remote tree, get FILE downloads a file to your machine, and put FILE uploads one. bye ends the session.
Open a session to serverb as root:
sftp root@serverb
prompt: student@servera:~$ answer: sftp root@serverb output: hint: Just sftp and the user@host, no colon and no path this time: sftp root@serverb
With keys and a real serverb, this drops you at an sftp> prompt on the remote machine. From there you browse with ls and cd, pull a file down with get report.txt, and push one up with put newfile.txt. You leave with bye. The mental split: cd and ls move you around the REMOTE side, while get and put move the FILES. Reach for sftp when you need to find the file first; reach for scp when you already know the exact path.
There is a third tool the exam accepts and real engineers prefer for anything large or repeated: rsync. It also runs over ssh, so it is just as secure, but it is smarter. On a second run it copies only the parts that changed, which makes re-syncing a big directory fast instead of full-again.
The form you memorize is rsync -av SOURCE DEST. The -a flag means archive: copy recursively and preserve permissions, timestamps, and ownership, so the copy is a faithful twin of the original. The -v flag means verbose: print each file as it goes so you can see the transfer happen.
Mirror a local /etc/skel/ directory up to /tmp/ on serverb, preserving everything:
rsync -av /etc/skel/ root@serverb:/tmp/skel/
prompt: student@servera:~$ answer: rsync -av /etc/skel/ root@serverb:/tmp/skel/ output: hint: The archive-and-verbose form is -av, then source then remote destination: rsync -av /etc/skel/ root@serverb:/tmp/skel/
rsync -av is the everyday copy that does the right thing: -a preserves permissions, times, and ownership while copying recursively, and -v shows you each file. On a real host it prints the file list and a short transfer summary. Its edge appears on the SECOND run, where it moves only what changed instead of everything again. For one small file scp is simpler; for a directory you copy more than once, rsync -av is the tool an engineer reaches for.
A trailing slash on the rsync source matters. rsync -av dir/ dest/ copies the CONTENTS of dir into dest, while rsync -av dir dest/ copies the directory dir itself into dest. When a task says the files must land directly in the destination, keep the trailing slash on the source.
Scaffolding off. No command is printed this time. You have every piece you need.
A task wants you to fetch the file /etc/motd from serverb, logging in as root, and save it into your current directory as motd-from-b. Think about which path carries the colon, and which side it has to be on so the copy comes FROM the remote and lands here. One scp line does it.
prompt: student@servera:~$ answer: scp root@serverb:/etc/motd motd-from-b output: hint: Downloading means the remote path goes FIRST. Put root@serverb:/etc/motd first, then the local name motd-from-b.
scp root@serverb:/etc/motd motd-from-b. Because the root@serverb: path came first, scp read it as the source and pulled the file down; the bare motd-from-b second argument saved it locally under the new name. That single move, remote-first for a download, is task 20 in miniature. Flip the two arguments and you would be trying to upload a local file that does not exist. Position is direction.
You earned this cheat sheet. Every row is a form you just ran or built:
The one rule to carry into the exam: the path with the colon is the remote one, and whether it sits first or second decides download versus upload. Everything else, -r for directories, sftp to browse, rsync -av for the big or repeated copy, hangs off that.
Always verify a transfer. After any copy, run ls -l on the destination (or ssh user@host ls -l /path) and confirm the file is really there with the size you expect. On the exam, a transfer you did not verify is a task you cannot trust, and verifying takes one extra command.
The practice terminal has shown you the shape of secure transfer: ssh -V to confirm the tooling, scp up and scp down with the colon marking the remote side, -r for directories, the interactive sftp session with get and put, and rsync -av as the efficient alternative. Every one of those you typed yourself.
The operating-systems module mission is where you run these against a real RHEL 10 machine, with a second node to reach and key-based auth to set up first. The mission hands you objectives that use exactly what you practiced here: move a file securely from one host to another and verify it arrived. One difference from this lesson: the mission shows no commands. You read the objective, recall the scp or sftp or rsync form, and type it. That recall is what makes it stick on exam day.
Finish the other operating-systems lessons, then go move a file across the wire for real.
Practice scp and sftp Secure Transfer in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.