3.1 Access Remote Systems Using SSH

Remote access is a core RHCSA (EX200) essential-tools skill. On Red Hat Enterprise Linux, remote shell access is provided by OpenSSH. You connect with the ssh client; the remote machine runs the sshd daemon. Exam scenarios frequently place you on one host and require you to configure or verify another host over the network. Configurations you change for SSH must remain correct after reboot—the same persistence rule that applies across EX200 objectives.

Why SSH Matters on the Exam

Performance-based tasks are not limited to a single console. You may:

• Log into a secondary server to install packages, edit configs, or check services
• Copy keys or verify that sshd is enabled so administrators can reach the system later
• Troubleshoot “cannot connect” by checking the service, firewall, and listen port

OpenSSH encrypts the session. Unlike unencrypted legacy tools (telnet, rsh), SSH protects credentials and command traffic. RHEL ships OpenSSH components as packages such as openssh-clients (client tools) and openssh-server (the daemon). In a normal RHEL server install, the client is present; ensure the server package and service are installed and running when the machine must accept remote logins.

Basic Connection Syntax

The most common form is:

ssh username@hostname_or_ip

Examples:

ssh student@servera.lab.example.com
ssh root@192.168.122.50
ssh -p 2222 admin@bastion.example.com

Useful client options for administrators:

If you omit the username, ssh uses your local account name. On multiuser systems that is often wrong for remote admin work—always be explicit when the remote account differs.

After a successful login you receive a remote shell. Exit with exit or Ctrl+D. That ends only the session; it does not stop sshd on the server.

Host Keys and known_hosts

The first time you connect to a host, the client shows the remote host key fingerprint and asks whether to continue. If you accept, the client stores the key in ~/.ssh/known_hosts (for that local user). Later connections compare the presented key to the stored one.

• Match — connection proceeds (trust established for that host identity)
• Mismatch — ssh warns about a possible man-in-the-middle attack or that the server was rebuilt with a new host key

On a lab rebuild, a mismatch is common: the VM was recreated and generated new host keys under /etc/ssh/. Administrators often remove the stale line for that host from ~/.ssh/known_hosts (or use ssh-keygen -R hostname) and reconnect carefully after verifying the new fingerprint through a trusted channel.

Do not habitually disable host-key checks (StrictHostKeyChecking=no) on production systems. For exam labs, understand the mechanism so a WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED message does not block you from finishing a task.

System-wide known hosts can also appear in /etc/ssh/ssh_known_hosts, but day-to-day troubleshooting almost always starts with the user’s ~/.ssh/known_hosts.

Authentication: Passwords and Keys

Password authentication

If the server allows it, ssh prompts for the remote account password. Server policy lives in /etc/ssh/sshd_config (and drop-in files under /etc/ssh/sshd_config.d/ on modern RHEL). Settings such as PasswordAuthentication control whether password logins are accepted. After editing server config, validate and reload:

sudo sshd -t
sudo systemctl reload sshd

sshd -t tests syntax before you break remote access. Prefer reload over a full restart when possible so existing sessions stay up while new settings apply.

Public-key authentication

Key-based login is common for automation and for admin accounts:

1. Generate a key pair on the client (if you do not already have one): ssh-keygen (default files ~/.ssh/id_ed25519 / id_ed25519.pub or RSA variants).
2. Install the public key on the remote account’s ~/.ssh/authorized_keys (tools like ssh-copy-id user@host automate this when password login still works).
3. Connect; the client proves possession of the matching private key.

Private keys stay on the client and must remain mode-restricted (typically 600). Public keys are safe to distribute to servers you administer. For RHCSA, know the paths and that key auth is configured per remote user under that user’s home directory—not only under root.

Client Config: ~/.ssh/config

For repeated admin tasks, put defaults in ~/.ssh/config (permissions typically 600):

Host servera
    HostName servera.lab.example.com
    User student
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host bastion
    HostName 10.0.0.5
    User admin
    Port 2222

Then ssh servera expands those options. This file is client-side and persists for that user across reboots as long as the home directory (and file) remain. It does not configure the remote daemon.

Command-line options override config file settings for a single invocation—useful when testing without editing the file.

Server Service Control and Persistence

On the machine that must accept SSH:

sudo systemctl status sshd
sudo systemctl start sshd
sudo systemctl enable --now sshd

• start — run now until stop or reboot
• enable — create the systemd symlink so sshd starts at boot
• enable --now — both at once (preferred when the exam requires lasting remote access)

Because EX200 grades persistence after reboot, finishing “SSH works right now” is incomplete if sshd is not enabled (or if a firewall rule you added was not made permanent—firewall details appear in networking/security objectives, but the same reboot mindset applies).

Confirm listening with ss -tlnp | grep ssh or systemctl status sshd after changes. Package install alone does not always mean the service is enabled; verify explicitly.

Practical Exam Workflow

1. From your workstation or primary lab host, ssh user@target.
2. If the connection fails: ping/name resolution, systemctl is-active sshd on the target (via console), listen port, and host firewall allowing SSH.
3. Accept or fix host keys using known_hosts knowledge—not by blindly disabling checks without understanding risk.
4. Use ~/.ssh/config for multi-host labs so you do not mistype users and ports under time pressure.
5. After any server-side sshd_config change: sshd -t, reload, and retest from a second session before closing your only working login.

Common Pitfalls

• Editing /etc/ssh/sshd_config but forgetting to reload sshd
• Enabling password or key policy in the wrong file or with a syntax error that prevents sshd from starting
• Assuming ssh root@host works when root login is disabled by policy (PermitRootLogin)
• Leaving sshd disabled so a grader reboot loses remote access
• Confusing client ~/.ssh/config with server sshd_config

Master the client connection path, host-key trust model, basic identity files, and systemd enablement. Those skills unlock every later objective that assumes you can reach another RHEL system over the network.