Learn › RHCSA (EX200) › Exam Orientation + Essential Tools

SSH and Key-Based Auth

ssh - a hands-on Linux lab on a real virtual machine.

Reach another node with ssh, then remove the password for good with an ed25519 key pair and ssh-copy-id. Covers ssh user@host, remote commands, ~/.ssh/authorized_keys and its strict 700/600 perms, scp and rsync, and known_hosts. Serves EX200 task 58 (key-based SSH) and task 20 (file transfer between nodes).

On the RHCSA exam you are handed two machines, servera and serverb, and a stack of tasks that bounce between them. Configure a service over there. Copy a file back over here. Check whether a daemon is running on the other node. If your instinct is to hunt for a second console tab every time, you will burn minutes you do not have.

There is one command that lets you reach the other machine, run something on it, and come straight back, all from the shell you are already in. It is ssh, the Secure Shell. This lesson makes it muscle memory, then removes the password prompt entirely so you never stop to type a secret again. That no-password setup is a graded EX200 objective on its own.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. It runs on a single node, so it can prove ssh is installed, show your OpenSSH version, and generate a real key pair. What it cannot do is reach a live serverb, because there is no second node here. The true cross-host flow, servera to serverb with no password, is run on the real machines in the module capstone and on the exam, where the second node is provided. Every command you type here is exactly what you type there.

ssh opens an encrypted connection to another machine and drops you into a shell on it, as if you had sat down at its keyboard. Encrypted means everything you send, your password included, is scrambled on the wire so no one listening on the network can read it. It replaced the old, plaintext tools like telnet and rsh, which sent passwords in the clear.

The shape you type is ssh user@host: the account you want on the far side, an @, then the machine's name or address. So ssh root@serverb asks for the root account on the machine called serverb. Add a command on the end, like ssh root@serverb hostname, and ssh runs just that one command over there and hands you the output back here, without opening a full session.

Before any of that, prove the tool is present. ssh -V prints the version and exits. If it prints, ssh is installed and ready. Run it now:

ssh -V

prompt: student@servera:~$ answer: ssh -V output: OpenSSH_9.9p1, OpenSSL 3.5.5 27 Jan 2026 hint: The flag is a capital V, not lowercase. Type ssh, a space, then -V.

ssh -V prints to your error stream, so on some setups it looks like it landed in a different place than normal output. That is expected. The exact build numbers (OpenSSH_9.9p1, the OpenSSL date) will differ slightly on your machine as packages update. What matters is that a version line prints at all, which confirms the client is there.

Typing ssh root@serverb works, but it stops and asks for a password every single time. On the exam you may cross to the other node a dozen times. A dozen password prompts is a dozen chances to fat-finger it, and a dozen small delays. Worse, any automation you write, a script that loops over hosts, cannot pause to type a secret by hand.

The fix is key-based authentication. Instead of a shared password, you make a matched pair of files: a private key you keep secret on servera, and a public key you hand to serverb. The public key is safe to give away; it can only verify the holder of the private key, never reveal it. Once serverb trusts your public key, ssh root@serverb just lets you in, no prompt. Setting this up is EX200 objective 58, and it is the single most useful trick in the exam environment.

ssh-keygen builds the pair. The -t flag names the type of key, the math it is built on. On RHEL 10 the modern default is ed25519, a fast, strong, short key format, so ssh-keygen -t ed25519 is the form to learn and type on the exam.

It asks two questions: where to save the key (press Enter to accept the default, ~/.ssh/id_ed25519) and an optional passphrase (press Enter twice for none in the exam setting). When it finishes, you have two files: id_ed25519, the private key you guard, and id_ed25519.pub, the public key you share. Generate a pair now:

ssh-keygen -t ed25519

prompt: student@servera:~$ answer: ssh-keygen -t ed25519 output: Generating public/private ed25519 key pair. Your identification has been saved in /tmp/gt/idk Your public key has been saved in /tmp/gt/idk.pub The key fingerprint is: SHA256:LfmTSxHGnVPb+PLqo5n+nhI9LiatIFWxWUGbPRUsfSM student@servera The key's randomart image is: +--[ED25519 256]--+

hint: The type flag is -t, and the RHEL 10 default type is the word ed25519.

The fingerprint (the SHA256:... line), the trailing comment (student@servera), and the ASCII randomart picture are unique to the key you just made. Yours will read completely differently, and that is correct: a fingerprint that matched anyone else's would mean the key was not random. The capture above also saved to a testing path (/tmp/gt/idk); on your machine, pressing Enter at the prompt saves to the real default, ~/.ssh/id_ed25519.

The key pair exists, but serverb does not trust it yet. You have to install your public key into a file on serverb called ~/.ssh/authorized_keys. That file is a list of public keys serverb will accept without a password. The clean way to install it is ssh-copy-id user@host, which logs in once with your password, appends your public key to authorized_keys over there, and fixes the permissions for you.

So the full no-password setup is exactly two commands: make the pair, then copy the public half across.

ssh-copy-id root@serverb

ssh-copy-id root@serverb needs a live serverb to log in to, so it is run against the real second node in the module capstone and on the exam, not in this single-node sandbox. It prompts once for serverb's password (the last time you type it), then reports how many keys it added. From that point on, ssh root@serverb lets you straight in. There is no honest output to show here because there is no serverb to reach; you will see it for real on the machines.

SSH is strict about permissions on the key files, and a wrong mode silently makes it fall back to asking for a password. On the far side, ~/.ssh must be 700 (only you can enter it) and ~/.ssh/authorized_keys must be 600 (only you can read it). ssh-copy-id sets these for you. If you ever install the key by hand instead, run chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys, or the login will keep prompting no matter how right the key is.

Reaching the other machine is half the exam; carrying a file there is the other half (EX200 objective 20). Two tools ride on top of SSH to do it.

scp, secure copy, follows the pattern scp source destination, and either side can be remote using the same user@host:path shape. scp report.txt root@serverb:/tmp/ pushes a local file to serverb; flip the arguments to pull one back. rsync -av source dest does the same job but smarter: it copies only what changed, so it is the tool for directories and repeat transfers. Both authenticate exactly the way ssh does, so once your key is installed, neither asks for a password.

scp report.txt root@serverb:/tmp/ and rsync -av /etc/ root@serverb:/tmp/etc/ both need the live serverb, so they run on the real nodes in the capstone and on the exam. The move to memorize is the argument order: scp SOURCE DESTINATION. Reverse them and you overwrite the wrong file. When in doubt about which host you are even on, run hostname; the prompt and that command are your ground truth.

Scaffolding off. No command is printed this time. You have every piece you need.

You have just logged into a fresh servera and you want passwordless SSH to the rest of the lab. The very first step is to create your own key pair, using the modern key type that RHEL 10 uses by default. Make it.

hint: The generator is ssh-keygen, the type flag is -t, and the default RHEL 10 type is ed25519.

Your fingerprint and randomart will not match the capture, and the save path is the real default on your machine. What is worth burning into memory is the two-command spine of objective 58: ssh-keygen -t ed25519 to build the pair, then ssh-copy-id user@host to install the public half. That pair, in that order, is the whole no-password setup.

You earned this cheat sheet. Every row is a command from this lesson:

The first time you connect to a new host, SSH shows its fingerprint and asks you to confirm; type yes and it is saved in ~/.ssh/known_hosts so it never asks again. If a host is ever rebuilt and its key changes, SSH refuses to connect until you clear the stale entry with ssh-keygen -R host. Two commands set up passwordless access for good: ssh-keygen -t ed25519, then ssh-copy-id.

The strict 700 on ~/.ssh and 600 on ~/.ssh/authorized_keys is the number-one reason key login quietly fails on the exam. If you did everything right and it still asks for a password, check those two permissions before you touch anything else.

The practice terminal has shown you the shape of ssh: how to confirm it is installed, how to build the ed25519 key pair RHEL 10 defaults to, and the two-command spine that removes the password prompt. You typed the key generation yourself, from memory, in the challenge.

The essential-tools module ends on one real RHEL 10 machine, the module capstone mission, and a live second node stands beside it. That is where the cross-host flow becomes real: you run ssh-copy-id to a machine that answers, ssh root@serverb in with no password, and scp a file across. It hands you objectives worded the way the exam words them, EX200 task 58 for passwordless SSH and task 20 for moving a file between nodes, and it shows no commands. You read the objective, recall the command, and type it. That recall is what makes it stick under exam pressure.

Finish the other essential-tools lessons, then go set up passwordless SSH on a real pair of machines.

Practice SSH and Key-Based Auth in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.