ExamFinch.com My Study

Study guide

3.1 Access Remote Systems Using SSH

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

3.1 Access Remote Systems Using SSH

Key Takeaways Explain This Topic AI

OpenSSH is the standard remote-access stack on RHEL: the client is the ssh command, and the server is the sshd service (package openssh-server).

First connections store the remote host key in ~/.ssh/known_hosts; a later key mismatch is a security warning, not something to ignore on production systems.

Password or key-based login both work on the exam; persistent client settings belong in ~/.ssh/config and server settings in /etc/ssh/sshd_config (restart sshd after server changes).

RHCSA tasks must survive reboot: enable sshd with systemctl enable --now sshd so remote access returns after a restart.

Use ssh user@host, optional -p for non-default ports, and -i for a private key path when the default identity is not enough.

Last updated: August 2026

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:

  • Option Purpose
  • p port Connect to a non-default SSH port (default is 22 )
  • i /path/to/key Use a specific private key for authentication
  • l user Specify login name (equivalent to user@host )
  • v / -vv Increase verbosity for connection debugging
  • o Option=value Pass a single config option on the command line

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:

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).

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).

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

From your workstation or primary lab host, ssh user@target .

If the connection fails: ping/name resolution, systemctl is-active sshd on the target (via console), listen port, and host firewall allowing SSH.

Accept or fix host keys using known_hosts knowledge—not by blindly disabling checks without understanding risk.

Use ~/.ssh/config for multi-host labs so you do not mistype users and ports under time pressure.

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.