Configuring SSH and remote access. The problem it solves is sending commands and files between computers over the internet without letting attackers intercept them. For the EX200 exam, you must know how to set up SSH so you can manage Red Hat Enterprise Linux servers from anywhere.
Jump to a section
A simple way to picture Configuring SSH and Remote Access
A night security guard named Priya works at a gated office complex. She sits in a small booth at the main entrance. Her job is to let authorised people in and keep everyone else out. She doesnt just open the gate for anyone who knocks. First, she asks for identification. Then she checks her clipboard to see if that person is on the approved list. If they are, she opens the gate and notes the time they entered. She also keeps a log of everything she does.
Now imagine Priya gets a new responsibility. She needs to let people copy files from the office server while they are working remotely. She cant just give everyone the master key to the building. Instead, she gives each approved worker a personal passcode that is unique to them. When a worker arrives at the gate, they present their unique passcode. Priya verifies it against her list and then escorts them to a special locked cabinet where they can grab or drop off files. She never leaves the cabinet unlocked. She locks it again as soon as the worker leaves.
In this analogy, the office building is the server. Priya is the SSH daemon (sshd) process running on the server. The unique passcode is the SSH key pair. The locked cabinet is the encrypted connection. The clipboard is the authorised keys file. Priya never trusts someone just because they claim to be from the company. She always checks their unique passcode. She never lets anyone wander around the building without supervision. This is exactly how SSH works. It authenticates the user, encrypts the entire session, and then allows secure file transfer or remote command execution. Priya could also set up a temporary day pass for a visitor. In SSH terms, that is password authentication. But the permanent workers always use their personal passcode keys because it is safer and more convenient for repeated access.
SSH stands for Secure Shell. It is a protocol that lets you log into a remote computer and run commands as if you were sitting right in front of it. Before SSH existed, people used tools like Telnet or rsh. Those tools sent everything in plain text. Anyone listening on the network could see your username, your password, and every command you typed. SSH fixes that by encrypting everything.
Encryption means scrambling the data so that only the intended recipient can unscramble it. Imagine writing a secret letter in a language only your friend understands. Even if someone steals the letter, they cannot read it. SSH uses a similar principle but with mathematics.
SSH has two main parts: the client and the server. The SSH client is a program you run on your local machine. The command is usually ssh. The SSH server is a program that runs on the remote machine and listens for incoming connections. The server program is called sshd (SSH daemon). A daemon is just a background process that waits for something to happen.
When you type ssh user@hostname, your client contacts the server on the remote machine. The server sends its public key to the client. This is like the server showing you its ID card. The client and server then negotiate a shared secret key. This shared key is used to encrypt all the traffic for that session.
Authentication is the next step. The server needs to know you are who you say you are. There are two main ways to authenticate in SSH: password authentication and key-based authentication. Password authentication is simpler. You type your password, and the server checks it. But passwords can be guessed or stolen. Key-based authentication is much more secure. You generate a pair of cryptographic keys on your client machine. A cryptographic key is a long string of random characters. One key is private. You keep it secret on your client machine. The other key is public. You copy the public key to the server. When you connect, your client proves it has the private key without actually sending the key over the network. The server verifies this proof using your public key.
For file transfer, SSH provides two main tools: scp (secure copy) and sftp (SSH File Transfer Protocol). scp works like the old cp command but over the network. You specify the source and destination paths, and it copies files securely. sftp is like a secure version of FTP. It lets you browse directories, upload, and download files interactively.
SSH also supports port forwarding. This allows you to tunnel other network traffic through the encrypted SSH connection. For example, you could securely access a web server running on a remote machine by forwarding a local port to that remote port.
Configuration files are important for customising SSH behaviour. The main server configuration file is /etc/ssh/sshd_config. The main client configuration file is /etc/ssh/ssh_config or ~/.ssh/config for per-user settings. In these files, you can change the default port, disable root login, allow or deny specific users, and much more.
On Red Hat Enterprise Linux, the SSH server is usually installed and running by default. You can check its status with systemctl status sshd. You can start, stop, or restart it with systemctl.
Key files to know include ~/.ssh/authorized_keys on the server. This file contains the public keys that are allowed to log in as that user. The ~/.ssh/known_hosts file on the client records the public keys of servers you have connected to. This helps prevent man-in-the-middle attacks where someone pretends to be the server.
In summary, SSH replaces insecure remote login and file transfer methods. It provides encryption, strong authentication, and many useful features for system administration.
Generate an SSH Key Pair
Run ssh-keygen -t ed25519 on your local machine. This creates a private key (id_ed25519) and a public key (id_ed25519.pub) in ~/.ssh/. The -t flag specifies the key type. Ed25519 is a modern, secure algorithm recommended over RSA for new deployments. You can optionally add a passphrase for extra security.
Copy the Public Key to the Remote Server
Use ssh-copy-id user@remotehost. This command automatically appends your public key to the ~/.ssh/authorized_keys file on the remote server. It also creates the ~/.ssh directory with correct permissions if it does not exist. If ssh-copy-id is not available, you can manually append the public key using cat id_ed25519.pub | ssh user@remotehost 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'.
Test Key-Based Authentication
Run ssh user@remotehost. If key-based authentication is working, you will be logged in without being prompted for a password. If you set a passphrase on the private key, you will be prompted for that passphrase instead. Verify that the connection succeeds and that you are logged in as the correct user.
Configure SSH Server Settings
Edit /etc/ssh/sshd_config as root. Common changes include setting PermitRootLogin no to block direct root login, PasswordAuthentication no to disable password-based logins, and Port 2222 to change the default listening port. After saving the file, run systemctl restart sshd to apply the changes. Always test the new configuration in a second terminal session before closing the current one to avoid locking yourself out.
Transfer a File Using scp
Run scp /local/file.txt user@remotehost:/remote/directory/. This copies the local file to the specified directory on the remote host. For directories, use scp -r /local/directory/ user@remotehost:/remote/directory/. The -r flag copies recursively. The connection is encrypted, so the file content is protected during transit.
Transfer Files Interactively Using sftp
Run sftp user@remotehost to start an interactive session. Use put localfile to upload a file to the current remote directory. Use get remotefile to download a file to the current local directory. Use ls to list files on the remote host and cd to change remote directories. Type exit or bye to end the session.
Configure Client-Side SSH Aliases
Edit ~/.ssh/config. Add entries like: Host myserver\nHostName 192.168.1.100\nUser myuser\nPort 2222\nIdentityFile ~/.ssh/mykey. This allows you to type ssh myserver instead of the full connection string. The configuration file can include multiple hosts with different settings.
An IT professional at a medium-sized company needs to manage fifty Red Hat Enterprise Linux servers. These servers host the company's customer database, web application, and internal file shares. The servers are in a data centre across town. The IT pro works from home three days a week. They cannot drive to the data centre every time a server needs a configuration change. SSH is their primary tool.
At 9 AM, the IT pro receives an alert that a web server is running low on disk space. They open a terminal on their laptop and type: ssh webadmin@webserver01.example.com. The first time they connect to that server, they see a message like "The authenticity of host 'webserver01.example.com' can't be established." This is because the client has never seen this server's host key before. The IT pro verifies the key fingerprint by checking it against a secure record maintained by the team. They type "yes" and the server is added to their known_hosts file. Now they can run commands like df -h to check disk space, or du -sh /var/log to find large log files. They delete old log files and the alert clears.
Later that morning, a junior developer needs to deploy a new version of the web application. The IT pro sets up a secure file transfer using sftp. They type sftp webadmin@webserver01.example.com and then use put /local/path/newapp.war /opt/tomcat/webapps/ to upload the file. The transfer is encrypted, so even if someone is eavesdropping on the network, they cannot see the application code.
The company recently had a security audit. The auditor required that SSH must not allow password logins. The IT pro edits /etc/ssh/sshd_config on all servers. They change the line PasswordAuthentication yes to PasswordAuthentication no. Then they run sudo systemctl restart sshd on each server. Now every user must use key-based authentication. The IT pro generates a new key pair on their laptop using ssh-keygen -t ed25519. They then use ssh-copy-id user@server to copy the public key to each server. They also set up a centralised management system using Ansible to push the authorised_keys file to all servers.
Another task involves granting temporary access to a contractor who is troubleshooting a performance issue. The IT pro creates an account for the contractor and adds their public key to the authorised_keys file. They also set a time limit by configuring the account to expire or by using a forced command in the authorised_keys file that restricts what the contractor can run.
The IT pro also uses SSH port forwarding to securely access a database server that is only reachable from inside the data centre network. They run ssh -L 5432:dbserver01:5432 admin@jumpserver.example.com. This creates a tunnel. Now the IT pro can connect their local database client to localhost port 5432, and the traffic is securely forwarded to the actual database server.
In a disaster recovery scenario, they need to restore a backup from a remote server. They use rsync over SSH: rsync -avz -e ssh backup@remoteserver:/backups/db_latest.sql /local/restore/. The data is compressed and encrypted during transfer.
If a server becomes unresponsive to SSH, the IT pro must use an out-of-band management interface like IPMI or a console in the data centre. But for day-to-day tasks, SSH is the lifeline. They rely on it to update software, check logs, restart services, and monitor system health. They also configure SSH to use non-default ports on some high-security servers to reduce automated attacks. They set up fail2ban to block IP addresses that repeatedly try wrong passwords. They regularly audit the auth log file (/var/log/secure) to look for suspicious login attempts.
EX200 tests your ability to configure SSH for remote access and file transfer on Red Hat Enterprise Linux. The exam does not ask you to write essays about SSH theory. It gives you tasks in a lab environment. You must complete those tasks using the command line.
Key topics you will be tested on:
Generate SSH key pairs using ssh-keygen. You must know the default key type (RSA) and the recommended type (Ed25519 or ECDSA). You might be asked to generate a key pair with a specific number of bits or a specific comment.
Copy the public key to a remote server using ssh-copy-id. This command adds your public key to the ~/.ssh/authorized_keys file on the remote server. You must know that the default target file is ~/.ssh/authorized_keys and that the directory ~/.ssh must have the correct permissions (700) and the authorized_keys file must have permissions 600 or 644.
Configure the SSH server by editing /etc/ssh/sshd_config. Common directives you must know: Port, PermitRootLogin, PasswordAuthentication, PubkeyAuthentication, AllowUsers, DenyUsers, ClientAliveInterval, MaxAuthTries. The exam may ask you to disable root login, change the listening port, or require key-based authentication. After editing the config file, you must restart the sshd service using systemctl restart sshd.
Use scp to copy files between directories on different servers. You must know the syntax: scp [options] source destination. For example, scp file.txt user@host:/path/to/destination/. You must also know how to copy entire directories recursively with the -r option.
Use sftp to transfer files interactively. You must know basic sftp commands like get, put, ls, cd, and exit.
Configure client-side SSH options using ~/.ssh/config. This file can set default usernames, ports, and key files for specific hosts. The exam may ask you to create an alias for a host so that ssh myalias connects to a specific server with specific options.
Traps that exam questions set:
File and directory permissions. The exam will set the permissions incorrectly on ~/.ssh or authorized_keys. You must recognise that if the directory is world-writable or the file has too permissive permissions, SSH will refuse to use key authentication. You must fix them with chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys.
SELinux context. The exam environment uses SELinux enforcing. If you copy a file to ~/.ssh/authorized_keys with the wrong SELinux context, SSH will deny access. Use restorecon -Rv ~/.ssh to reset the context correctly.
Firewall. The exam might block the SSH port (default 22) in the firewall. You must add a rule to allow the port using firewall-cmd. If you change the SSH port in sshd_config, you must also add a new firewall rule and remove or keep the old one as needed.
Mistaking sshd_config with ssh_config. sshd_config is for the server. ssh_config (or ~/.ssh/config) is for the client. Editing the wrong file will not produce the expected result.
Restarting the service. After changing sshd_config, you must restart sshd. The exam may present a scenario where you change the config but forget to restart, and the connection test fails because the old settings are still in effect.
Key passphrases. ssh-keygen can accept a passphrase. The exam might test that you can generate a key without a passphrase using the -N '' option, or that you understand the key is still secure even without a passphrase because it is stored with restricted permissions.
known_hosts mismatch. If a server's host key changes (for example, the server was rebuilt), SSH will warn about a host key mismatch. You must know how to remove the old host key using ssh-keygen -R hostname or manually editing the known_hosts file.
To pass, practice every command until you can type it without thinking. Use man pages during the exam if you need to check syntax. Focus on file transfer commands (scp, sftp) and configuration file editing. Know how to verify your work by testing the connection. Do not skip the SELinux and firewall steps because they are common points of failure.
SSH encrypts all traffic between client and server, including passwords, commands, and transferred files.
Key-based authentication is more secure than password authentication because the private key never leaves your client machine.
Use ssh-keygen to generate a key pair and ssh-copy-id to safely copy the public key to a remote server.
The server configuration file /etc/ssh/sshd_config controls authentication methods, ports, and user access restrictions.
After editing sshd_config, you must restart the sshd service with systemctl restart sshd for changes to take effect.
File and directory permissions for ~/.ssh must be 700 and ~/.ssh/authorized_keys must be 600 or SSH will refuse key authentication.
scp and sftp are part of the SSH suite and provide secure file transfer without additional tools.
SELinux context on the .ssh directory may need to be restored with restorecon after copying files.
The known_hosts file on the client stores server host keys to prevent man-in-the-middle attacks.
Port forwarding allows you to tunnel other network protocols through an SSH connection for secure remote access.
These come up on the exam all the time. Here's how to tell them apart.
SSH Key Authentication
Uses a pair of cryptographic keys (private and public).
The private key never leaves the client machine.
More secure because it resists brute force and phishing attacks.
SSH Password Authentication
Uses a shared secret text string (password).
The password is sent over the encrypted channel to the server.
Vulnerable to brute force attacks and password guessing.
scp (Secure Copy)
Non-interactive, one-shot file copy.
Syntax similar to cp command.
Good for scripting and automation.
sftp (SSH File Transfer Protocol)
Interactive session with commands like ls, cd, get, put.
Allows browsing directories before transferring.
Better for manual file management.
~/.ssh/authorized_keys
Located on the SSH server.
Contains public keys of authorised users.
Used to authenticate the client to the server.
~/.ssh/known_hosts
Located on the SSH client.
Contains public keys of servers the client has connected to.
Used to verify the identity of the server to prevent man-in-the-middle attacks.
ssh_config
Client-side configuration file.
Controls how the ssh client behaves.
Located at /etc/ssh/ssh_config (global) or ~/.ssh/config (user).
sshd_config
Server-side configuration file.
Controls how the sshd daemon behaves.
Located at /etc/ssh/sshd_config.
Port 22 (Default SSH)
Standard default port for SSH traffic.
Scanned by automated bots and attackers frequently.
Easier for legitimate users because no extra configuration needed.
Custom Port (e.g., 2222)
Non-default port set in sshd_config.
Reduces automated scan noise, but not a security feature.
Requires client to specify port with -p flag or in config file.
Mistake
SSH key authentication is the same as using a password. You just type a different string.
Correct
SSH key authentication uses a pair of mathematically linked keys. The private key stays on your local machine and is never sent over the network. The server uses your public key to verify that you possess the private key. This is fundamentally different from sending a password, which is a shared secret that travels from your client to the server.
New users see that they still have to type a passphrase on the private key sometimes, so they think the mechanism is similar to a password. They do not understand the cryptographic proof that happens behind the scenes.
Mistake
You can copy your private key to the server to make authentication work.
Correct
You only copy the public key to the server. The private key must remain only on your local machine. If you copy the private key anywhere else, anyone with access to that copy can impersonate you.
The terms 'private' and 'public' are confusing. Beginners assume both keys need to be on the server because the server needs to 'know' you. They do not grasp the asymmetric cryptography concept.
Mistake
SSH is only for logging into a remote shell. It cannot transfer files.
Correct
SSH includes secure file transfer protocols like scp and sftp. Both encrypt the data in transit. scp is a command-line tool for copying files. sftp is an interactive file transfer session.
The name 'Secure Shell' strongly implies a shell (command line). Beginners do not associate it with file transfer because they have used separate tools like FTP before.
Mistake
Changing the SSH port from the default (22) is a complete security solution that prevents all attacks.
Correct
Changing the port only stops automated scanners that target port 22. It does not protect against targeted attacks, brute force attacks on the new port, or vulnerabilities in the SSH protocol itself. It is a minor inconvenience to attackers at best.
Many online guides recommend 'security through obscurity' tactics like changing the port. Beginners overestimate its effectiveness and think it replaces proper authentication and firewall rules.
Mistake
If you set PasswordAuthentication to no in sshd_config, you cannot use any password at all, even for sudo commands over SSH.
Correct
PasswordAuthentication in sshd_config only controls whether SSH authentication itself accepts passwords. It has no effect on sudo password prompts that happen after you are logged in. You can still be prompted for a sudo password over SSH.
Beginners confuse the authentication layer of SSH (logging into the server) with the authentication layer of the operating system (elevating privileges). They think disabling password authentication for SSH disables passwords entirely.
Mistake
SSH keys are stored in the same location on every Linux distribution.
Correct
The default location for user SSH keys is ~/.ssh/, but the global configuration files can differ. Red Hat Enterprise Linux uses /etc/ssh/ for system-wide keys and configuration. Other distributions might use /etc/openssh/ or similar. The exam specifically tests Red Hat paths.
Beginners often learn from tutorials written for Ubuntu or other distributions. They apply the same paths to RHEL and get confused when the files are not found or the configuration is different.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
This usually means the server does not have your public key in the authorized_keys file, or the permissions on your ~/.ssh directory or authorized_keys file are wrong. Check that your public key is appended correctly and that ~/.ssh has 700 permissions and authorized_keys has 600 permissions.
ssh is the client program you run on your local machine to connect to a remote server. sshd is the daemon (server) program that runs on the remote machine and listens for incoming SSH connections.
Yes. If you generate a key pair without a passphrase (using ssh-keygen -t ed25519 -N ''), you can log in without typing anything. If you use a passphrase, you will be prompted for that passphrase each time you use the key.
Edit /etc/ssh/sshd_config on the server and change the Port directive. Then restart the sshd service with systemctl restart sshd. You also need to update the firewall to allow traffic on the new port.
Use the syntax scp user@remotehost:/path/to/remote/file /path/to/local/destination/. The source is the remote path, and the destination is your local path.
This means the remote server's host key has changed since you last connected, or you are connecting to a different server. It is a security warning. If the change is legitimate (for example, the server was rebuilt), remove the old host key from your known_hosts file using ssh-keygen -R hostname.
You've finished Configuring SSH and Remote Access. Continue through the EX200 study guide to build a complete picture of the exam.
Done with this chapter?