RED HAT ENTERPRISE LINUX

Accessing Remote
Systems Using SSH

Access Remote Systems Using SSH

CIS126RH | RHEL System Administration 1
Mesa Community College

Linux administrators rarely sit in front of the systems they manage. SSH — the Secure Shell protocol — is the standard tool for remote access on every RHEL server. This module covers how SSH works, how to connect to remote systems, and how to configure key-based authentication so you never need to type a password again. These skills are tested on the RHCSA exam.

Learning Objectives

1. Explain how SSH works — Describe the client-server model and how SSH encrypts connections
2. Connect to a remote system with ssh — Use the ssh command with common options to open remote shell sessions
3. Configure SSH key-based authentication — Generate a key pair with ssh-keygen and deploy the public key with ssh-copy-id
4. Use the SSH client config file — Define host aliases and options in ~/.ssh/config to simplify connections

What is SSH?

SSH — the Secure Shell protocol — provides an encrypted channel for remote login and command execution over an untrusted network.

• Replaced insecure protocols: telnet, rsh, rlogin
• All traffic — including passwords and commands — is encrypted end-to-end
• Uses a client-server model: your workstation is the client, the remote system runs the server
• The server daemon is sshd; the client command is ssh
• Default port: 22/TCP

Basic SSH Connection

The ssh command connects you to a remote host and opens a shell session.

# Connect as the same username you are logged in as locally
$ ssh servera

# Connect as a specific user
$ ssh student@servera
$ ssh -l student servera

# Connect to a non-default port
$ ssh -p 2222 student@servera

# Run a single command on the remote host — no interactive shell
$ ssh student@servera hostname
servera.lab.example.com

# End the session
$ exit
logout
Connection to servera closed.

Host Key Verification

The first time you connect to a new host, SSH asks you to verify its host key.

$ ssh student@servera
The authenticity of host 'servera (192.168.1.10)' can't be established.
ED25519 key fingerprint is SHA256:abc123...xyz789.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'servera' (ED25519) to the list of known hosts.

• Type yes to accept and save the key — future connections skip this prompt
• The key is saved in ~/.ssh/known_hosts on your local system
• If the key changes unexpectedly, SSH warns you — this may indicate a security problem

SSH Authentication Methods

SSH supports two main ways to prove your identity to the remote server.

Why Prefer Key-Based Authentication?

• No password travels over the network — even encrypted
• Not vulnerable to brute-force password attacks
• Can be used without a password prompt (with a passphrase-less key or ssh-agent)
• Required for many automation tools: Ansible, scripts, cron jobs

Generating an SSH Key Pair

Use ssh-keygen to generate a public and private key pair on your local system.

# Generate a key pair — accept defaults or choose your own path
$ ssh-keygen
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/student/.ssh/id_ed25519): [Enter]
Enter passphrase (empty for no passphrase): [passphrase or Enter]
Enter same passphrase again: [passphrase or Enter]
Your identification has been saved in /home/student/.ssh/id_ed25519
Your public key has been saved in /home/student/.ssh/id_ed25519.pub

# View the public key — this is what you share
$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3Nza...long-string... student@workstation

Deploying the Public Key

To use key-based authentication, copy your public key to the remote server's ~/.ssh/authorized_keys file.

The Easy Way: ssh-copy-id

# Copy your public key to the remote host — prompts for password once
$ ssh-copy-id student@servera
Number of key(s) added: 1
Now try logging into the machine with: ssh 'student@servera'

# Confirm key-based login works — no password prompt
$ ssh student@servera
[student@servera ~]$

The Manual Way

# On the remote server — create the directory and file if missing
$ mkdir -p ~/.ssh
$ chmod 700 ~/.ssh
$ cat id_ed25519.pub >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

SSH File Permissions

SSH is strict about file permissions. Wrong permissions silently disable key-based login without an error message that explains why.

# Check and fix SSH directory permissions
$ ls -la ~/.ssh/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/id_ed25519

The SSH Client Config File

The file ~/.ssh/config lets you define settings for each host so you do not have to type long options every time you connect.

# ~/.ssh/config — one Host block per remote system

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

Host jump
    HostName     bastion.example.com
    User         admin
    Port         2222

With that config in place, ssh servera uses all of those settings automatically.

Common ssh Options

Copying Files with scp and sftp

SSH includes two tools for transferring files securely over the same encrypted channel.

scp — Secure Copy

# Copy a local file to a remote host
$ scp report.txt student@servera:/home/student/

# Copy a remote file to the current local directory
$ scp student@servera:/etc/hostname .

# Copy a directory recursively
$ scp -r mydir/ student@servera:/tmp/

sftp — Interactive File Transfer

# Open an interactive sftp session
$ sftp student@servera
sftp> ls
sftp> get remotefile.txt
sftp> put localfile.txt
sftp> exit

The sshd Server

The sshd daemon runs on the remote system and listens for incoming SSH connections. Its behaviour is controlled by /etc/ssh/sshd_config.

# Check whether sshd is running
$ systemctl status sshd

# Start, stop, or restart the daemon
$ sudo systemctl restart sshd

# View active (non-comment, non-blank) config lines
$ grep -vE '^(#|$)' /etc/ssh/sshd_config

Hardening the SSH Server

Two configuration changes significantly improve SSH security on production servers.

Disable Direct Root Login

# In /etc/ssh/sshd_config
PermitRootLogin no

# Reload sshd to apply
$ sudo systemctl reload sshd

Disable Password Authentication

# Only do this after confirming key-based login works!
PasswordAuthentication no

$ sudo systemctl reload sshd

Using ssh-agent

If your private key has a passphrase, ssh-agent stores the unlocked key in memory so you only type the passphrase once per session.

# Start the agent and set environment variables
$ eval $(ssh-agent)
Agent pid 12345

# Add your private key to the agent — prompts for passphrase once
$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/student/.ssh/id_ed25519:
Identity added: /home/student/.ssh/id_ed25519

# All subsequent ssh connections use the key without prompting
$ ssh student@servera
[student@servera ~]$

# List keys currently loaded in the agent
$ ssh-add -l

Troubleshooting SSH Connections

# First step for any SSH problem: verbose output
$ ssh -v student@servera

# Check the server auth log for rejected attempts
$ sudo tail /var/log/secure

Knowledge Check

Answer these before moving to the next slide.

1. What command connects you to servera as user admin?
2. What file on the remote server must contain your public key for key-based login to work?
3. What permissions must the ~/.ssh/ directory have, and why?
4. What is the purpose of ssh-copy-id?
5. You changed a setting in /etc/ssh/sshd_config. What must you do next?
6. Key-based login is failing. What is the first command you should run to diagnose the problem?

Knowledge Check — Answers

1. ssh admin@servera or ssh -l admin servera
2. The public key must be in ~/.ssh/authorized_keys on the remote server, in the home directory of the user you are logging in as.
3. The ~/.ssh/ directory must be 700 — readable and writable by the owner only, with no group or world permissions. SSH refuses to use keys if the directory or files are too permissive, to protect against other users reading your keys.
4. ssh-copy-id copies your public key to a remote server's authorized_keys file and sets the correct permissions automatically, using password authentication for the one-time setup.
5. Reload or restart the sshd service: sudo systemctl reload sshd or sudo systemctl restart sshd. Then confirm it is still running: systemctl is-active sshd
6. Run ssh -v student@servera for verbose client-side output. Also check sudo tail /var/log/secure on the server for the server-side view.

Key Takeaways

1. SSH encrypts all traffic — login, commands, and file transfers. It replaced insecure tools like telnet. The client command is ssh; the server daemon is sshd listening on port 22.
2. Key-based authentication is preferred. Generate a key pair with ssh-keygen, deploy the public key with ssh-copy-id, and connect without a password prompt.
3. Permissions are enforced silently. The ~/.ssh/ directory must be 700 and authorized_keys must be 600. Wrong permissions disable key login with no clear error message.
4. Always test before closing your session. After editing sshd_config, reload sshd and verify it is running from a second terminal window — before closing your current connection.

Graded Lab

• Connect to servera as student using password authentication and confirm your hostname with hostname
• Generate an Ed25519 key pair on your workstation using ssh-keygen
• Deploy your public key to servera using ssh-copy-id
• Confirm key-based login works — connect to servera without a password prompt
• Create a ~/.ssh/config entry for servera with your username and key file, then connect using just ssh servera
• On servera, view the active lines of /etc/ssh/sshd_config using grep to filter out comments and blank lines

Next: Log in and switch users in multi-user targets