Skill 4 Solution
Skill 4 Solution
Perform the below to Set Up Key-Based Authentication for Secure SSH Access
• Generating SSH Key Pairs
• Copying the Public Key to the Remote Server
In Lab (This lab
• Manually Adding the Public Key (Alternative Method)
is ideal to be
• Configure the SSH Server for Key-Based Authentication
done RHA
• Restart the SSH Service
portal)
• Disable Password Authentication
• Verifying Key-Based SSH Access
• Testing with SSH Agent
The first step involves creating a pair of SSH keys on your local machine. This key pair consists
of a private key and a public key:
• The private key is stored securely on your local machine and should never be shared.
To generate the keys, you use the ssh-keygen command. You can specify the type of encryption
(e.g., RSA with 4096-bit key length) and optionally add a passphrase for extra security. The keys
are typically saved in the ~/.ssh directory on your local machine.
To authenticate using SSH keys, the public key needs to be added to the remote server:
• The ssh-copy-id command simplifies this process by copying your public key to the
correct location on the remote server.
• The command automatically appends your public key to the ~/.ssh/authorized_keys file
on the remote server, creating the necessary directories and setting the correct
permissions if they don’t already exist.
This step ensures that when you attempt to log in, the server can match your private key with the
corresponding public key in the authorized_keys file.
• You can manually copy the public key by displaying its contents using cat
~/.ssh/id_rsa.pub on your local machine.
• Then, you paste this key into the ~/.ssh/authorized_keys file on the remote server.
• You must ensure the .ssh directory has the correct permissions (700 for the directory
and 600 for the authorized_keys file) to prevent unauthorized access.
The SSH server on the remote machine must be configured to accept key-based authentication:
• The AuthorizedKeysFile directive should point to the location of the authorized_keys file
(usually ~/.ssh/authorized_keys).
• These settings allow the SSH server to recognize and accept public keys for
authentication.
5. Restart the SSH Service
After making changes to the SSH configuration file, you must restart the SSH service:
• This step ensures that the new settings are loaded and applied to all subsequent SSH
connections.
• This action forces all users to use SSH keys for logging in, which is more secure than
using passwords, as keys are much harder to crack.
• Attempt to log in to the remote server using SSH. If the setup is correct, the server will
not prompt for a password but will use the private key on your local machine to
authenticate the session.
• You can use ssh-agent to cache the passphrase during your session, so you don’t have
to enter it each time you use the key.
• The ssh-add command adds your private key to the ssh-agent, making it available for
use without needing to re-enter the passphrase for each SSH connection.
Conclusion
By setting up key-based SSH authentication, you significantly improve the security of your
remote server connections. SSH keys provide a stronger form of authentication than passwords,
which are vulnerable to brute force attacks and can be easily compromised. Additionally,
disabling password authentication and using an SSH agent adds further layers of security and
convenience.
Setting Up Key-Based Authentication for Secure SSH Access in RHEL/CentOS
• When prompted, accept the default file location (~/.ssh/id_rsa) and choose a
passphrase for added security.
Use the ssh-copy-id command to copy your public key to the remote server:
ssh-copy-id user@remote_server
• Replace user with your remote server username and remote_server with the server's IP
address or hostname.
• You will need to enter the remote user's password for the last time.
If ssh-copy-id is not available, you can manually add the public key:
cat ~/.ssh/id_rsa.pub
• On the remote server, open the ~/.ssh/authorized_keys file for the user (create the file if
it doesn’t exist):
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys
• Paste the public key into this file, then save and close it:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
After making changes to the SSH configuration, restart the SSH service to apply them:
sudo systemctl restart sshd
To enforce key-based authentication and enhance security, you can disable password
authentication:
PasswordAuthentication no
ssh user@remote_server
If you used a passphrase for your SSH key, you can use ssh-agent to cache the passphrase and
avoid entering it each time:
ssh-add ~/.ssh/id_rsa
• Now try logging into the remote server again, and it should not ask for your passphrase
during that session:
ssh user@remote_server
Guided Exercise
Outcomes
• Generate an SSH key pair without passphrase protection.
• Generate an SSH key pair with passphrase protection.
• Authenticate with both passphrase-less and passphrase-protected SSH keys.
This command prepares your environment and ensures that all required resources are
available.
Instructions
1. Log in to the serverb machine as the student user.
2. Switch to the operator1 user on the serverb machine. Use redhat as the password.
RH124-RHEL9.0-en-2-20220609 317
Chapter 10 | Configure and Secure SSH
+---[RSA 3072]----+
|E+*+ooo . |
|.= o.o o . |
|o.. = . . o |
|+. + * . o . |
|+ = X . S + |
| + @ + = . |
|. + = o |
|.o . . . . |
|o o.. |
+----[SHA256]-----+
4. Send the public key of the SSH key pair to the operator1 user on the servera machine,
with redhat as the password.
5. Execute the hostname command on the servera machine remotely by using the ssh
command without accessing the remote interactive shell.
The preceding ssh command does not prompt you for a password because it uses
the passphrase-less private key against the exported public key to authenticate as
the operator1 user on the servera machine. This approach is not secure because
anyone who has access to the private key file can log in to the servera machine as the
operator1 user. The secure alternative is to protect the private key with a passphrase,
which is a following step.
6. Generate another set of SSH keys with the default name and without a passphrase,
overwriting the previously generated SSH key files. Try to connect to the servera machine
by using the new SSH keys. The ssh command asks for a password, because it cannot
authenticate with the SSH key. Run again the ssh command with the -v (verbose) option
to verify it.
Send the new public key of the SSH key pair to the operator1 user on the servera
machine, to replace the previous public key. Use redhat as the password for the
318 RH124-RHEL9.0-en-2-20220609
Chapter 10 | Configure and Secure SSH
operator1 user on the servera machine. Execute the hostname command on the
servera machine remotely by using the ssh command without accessing the remote
interactive shell to verify that it works again.
6.1. Again generate another set of SSH keys with the default name and without a
passphrase, overwriting the previously generated SSH key files.
6.2. Try to connect to the servera machine by using the new SSH keys. The ssh
command asks for a password, because it cannot authenticate with the SSH key.
Press Ctrl+c to exit from the ssh command when it prompts for a password. Run
again the ssh command with the -v (verbose) option to verify it. Press again Ctrl+c
to exit from the ssh command when it prompts for a password.
6.3. Send the new public key of the SSH key pair to the operator1 user on the servera
machine, to replace the previous public key. Use redhat as the password for the
operator1 user on the servera machine. Execute the hostname command on
the servera machine remotely by using the ssh command without accessing the
remote interactive shell to verify that it works again.
RH124-RHEL9.0-en-2-20220609 319
Chapter 10 | Configure and Secure SSH
7. Generate another set of SSH keys with passphrase-protection. Save the key as /home/
operator1/.ssh/key2. Use redhatpass as the passphrase of the private key.
8. Send the public key of the passphrase-protected key pair to the operator1 user on the
servera machine. The command does not prompt you for a password because it uses the
public key of the passphrase-less private key that you exported to the servera machine in
the preceding step.
320 RH124-RHEL9.0-en-2-20220609
Chapter 10 | Configure and Secure SSH
9. Execute the hostname command on the servera machine remotely by using the ssh
command. Use the /home/operator1/.ssh/key2 key as the identity file. Specify
redhatpass as the passphrase, which you set for the private key in the preceding step.
The command prompts you for the passphrase that you used to protect the private key of
the SSH key pair. If an attacker gains access to the private key, then the attacker cannot use
it to access other systems because a passphrase protects the private key itself. The ssh
command uses a different passphrase from the operator1 user on the servera machine,
and so users must know both.
Use the ssh-agent program, as in the following step, to avoid interactively typing the
passphrase while logging in with SSH. Using the ssh-agent program is both more
convenient and more secure when the administrators log in to remote systems regularly.
10. Run the ssh-agent program in your Bash shell and add the passphrase-protected private
key (/home/operator1/.ssh/key2) of the SSH key pair to the shell session.
The command starts the ssh-agent program and configures the shell session to use
it. Then, you use the ssh-add command to provide the unlocked private key to the
ssh-agent program.
11. Execute the hostname command on the servera machine remotely without accessing a
remote interactive shell. Use the /home/operator1/.ssh/key2 key as the identity file.
The command does not prompt you to enter the passphrase interactively.
12. Open another terminal on the workstation machine and log in to the serverb machine
as the student user.
13. On the serverb machine, switch to the operator1 user and remotely log in to the
servera machine. Use the /home/operator1/.ssh/key2 key as the identity file to
authenticate using the SSH keys.
13.1. Use the su command to switch to the operator1 user. Use redhat as the password
for the operator1 user.
RH124-RHEL9.0-en-2-20220609 321
Chapter 10 | Configure and Secure SSH
14. Exit and close all extra terminals and return to the workstation machine.
14.1. Exit and close extra terminal windows. The exit commands leave the operator1
user's shell; terminate the shell session where ssh-agent is active; and return to the
student user's shell on the serverb machine.
Finish
On the workstation machine, change to the student user home directory and use the lab
command to complete this exercise. This step is important to ensure that resources from previous
exercises do not impact upcoming exercises.
322 RH124-RHEL9.0-en-2-20220609