0% found this document useful (0 votes)
31 views11 pages

Skill 4 Solution

Skill Solution fo the Redhat linux

Uploaded by

raunakhgnis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
31 views11 pages

Skill 4 Solution

Skill Solution fo the Redhat linux

Uploaded by

raunakhgnis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Skill Experiment - 4

To set up and verify secure SSH access using key-based authentication by


AIM
generating SSH key pairs and configuring the server and client.

This experiment focuses on enhancing SSH security by replacing password-


based authentication with key-based authentication. The process includes
Description
generating SSH key pairs, configuring the SSH server to accept key-based
authentication, and verifying the setup by securely accessing the server.

Commands ssh-keygen, ssh-copy-id, systemctl

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

1. What are the benefits of using key-based authentication over


password-based authentication in SSH?
2. How does the ssh-keygen command enhance security in SSH
communication?
Viva Questions
3. What is the purpose of the authorized_keys file on the SSH server?
4. Why is it recommended to disable password authentication after
setting up key-based authentication?
5. How does the SSH agent help in managing SSH keys?
Setting up key-based SSH authentication is a method to enhance the security of remote server
access by using a pair of cryptographic keys instead of traditional passwords. Here's a detailed
explanation of each step:

1. Generating SSH Key Pairs

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.

• The public key is intended to be shared with remote servers.

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.

2. Copying the Public Key to the Remote Server

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.

3. Manually Adding the Public Key (Alternative Method)

If the ssh-copy-id command is not available or you prefer manual configuration:

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

4. Configure the SSH Server for Key-Based Authentication

The SSH server on the remote machine must be configured to accept key-based authentication:

• Edit the SSH server configuration file (/etc/ssh/sshd_config) to ensure that


PubkeyAuthentication is set to yes.

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

6. Disable Password Authentication

To further enhance security:

• You can disable password-based authentication entirely by setting


PasswordAuthentication no in the SSH configuration file.

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

7. Verifying Key-Based SSH Access

Once the setup is complete, you should test the configuration:

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

8. Testing with SSH Agent

If your private key is secured with a passphrase:

• 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

1. Generating SSH Key Pairs

Start by generating an SSH key pair on your local machine:

ssh-keygen -t rsa -b 4096

• When prompted, accept the default file location (~/.ssh/id_rsa) and choose a
passphrase for added security.

2. Copying the Public Key to the Remote Server

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.

3. Manually Adding the Public Key (Alternative Method)

If ssh-copy-id is not available, you can manually add the public key:

• On your local machine, display 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

chmod 700 ~/.ssh

nano ~/.ssh/authorized_keys

• Paste the public key into this file, then save and close it:

chmod 600 ~/.ssh/authorized_keys

4. Configure the SSH Server for Key-Based Authentication

Ensure that the SSH server is configured to allow key-based authentication:

• Open the SSH configuration file:

sudo nano /etc/ssh/sshd_config

• Make sure the following options are set:

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

5. Restart the SSH Service

After making changes to the SSH configuration, restart the SSH service to apply them:
sudo systemctl restart sshd

6. Disable Password Authentication

To enforce key-based authentication and enhance security, you can disable password
authentication:

• Open the SSH configuration file again:

sudo nano /etc/ssh/sshd_config

• Find and set the following option:

PasswordAuthentication no

• Restart the SSH service again:

sudo systemctl restart sshd

7. Verifying Key-Based SSH Access

Test the key-based authentication by attempting to log in to the remote server:

ssh user@remote_server

• If everything is configured correctly, you should log in without needing to enter a


password.

8. Testing with SSH Agent

If you used a passphrase for your SSH key, you can use ssh-agent to cache the passphrase and
avoid entering it each time:

• Start the ssh-agent:

eval "$(ssh-agent -s)"

• Add your private key to the agent:

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

This completes the setup of key-based SSH authentication on RHEL/CentOS.


Chapter 10 | Configure and Secure SSH

Guided Exercise

Configure SSH Key-based Authentication


In this exercise, you configure a user to use key-based authentication for SSH.

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.

Before You Begin


As the student user on the workstation machine, use the lab command to prepare your
system for this exercise.

This command prepares your environment and ensures that all required resources are
available.

[student@workstation ~]$ lab start ssh-configure

Instructions
1. Log in to the serverb machine as the student user.

[student@workstation ~]$ ssh student@serverb


...output omitted...
[student@serverb ~]$

2. Switch to the operator1 user on the serverb machine. Use redhat as the password.

[student@serverb ~]$ su - operator1


Password: redhat
[operator1@serverb ~]$

3. Generate a set of SSH keys. Do not enter a passphrase.

[operator1@serverb ~]$ ssh-keygen


Generating public/private rsa key pair.
Enter file in which to save the key (/home/operator1/.ssh/id_rsa): Enter
Created directory '/home/operator1/.ssh'.
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in /home/operator1/.ssh/id_rsa.
Your public key has been saved in /home/operator1/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:JainiQdnRosC+xXh [email protected]
The key's randomart image is:

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.

[operator1@serverb ~]$ ssh-copy-id operator1@servera


/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/
operator1/.ssh/id_rsa.pub"
The authenticity of host 'servera (172.25.250.10)' can't be established.
ED25519 key fingerprint is SHA256:h/hEJa/anxp6AP7BmB5azIPVbPNqieh0oKi4KWOTK80.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter
out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted
now it is to install the new keys
operator1@servera's password: redhat

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'operator1@servera'"


and check to make sure that only the key(s) you wanted were added.

5. Execute the hostname command on the servera machine remotely by using the ssh
command without accessing the remote interactive shell.

[operator1@serverb ~]$ ssh operator1@servera hostname


servera.lab.example.com

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.

[operator1@serverb ~]$ ssh-keygen


Generating public/private rsa key pair.
Enter file in which to save the key (/home/operator1/.ssh/id_rsa): Enter
/home/operator1/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in /home/operator1/.ssh/id_rsa
Your public key has been saved in /home/operator1/.ssh/id_rsa.pub
...output omitted...

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.

[operator1@serverb ~]$ ssh operator1@servera hostname


operator1@servera's password: ^C
[operator1@serverb ~]$ ssh -v operator1@servera hostname
OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
...output omitted...
debug1: Next authentication method: publickey
debug1: Offering public key: /home/operator1/.ssh/id_rsa RSA
SHA256:ad597Zf64xckV26xht8bjQbzqSPuOXQPXksGEWVsP80
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-
mic,password
debug1: Trying private key: /home/operator1/.ssh/id_dsa
debug1: Trying private key: /home/operator1/.ssh/id_ecdsa
debug1: Trying private key: /home/operator1/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/operator1/.ssh/id_ed25519
debug1: Trying private key: /home/operator1/.ssh/id_ed25519_sk
debug1: Trying private key: /home/operator1/.ssh/id_xmss
debug1: Next authentication method: password
operator1@servera's password: ^C

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.

[operator1@serverb ~]$ ssh-copy-id operator1@servera


...output omitted...
operator1@servera's password: redhat

RH124-RHEL9.0-en-2-20220609 319
Chapter 10 | Configure and Secure SSH

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'operator1@servera'"


and check to make sure that only the key(s) you wanted were added.
[operator1@serverb ~]$ ssh operator1@servera hostname
servera.lab.example.com

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.

[operator1@serverb ~]$ ssh-keygen -f .ssh/key2


Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): redhatpass
Enter same passphrase again: redhatpass
Your identification has been saved in .ssh/key2.
Your public key has been saved in .ssh/key2.pub.
The key fingerprint is:
SHA256:OCtCjfPm5QrbPBgqb [email protected]
The key's randomart image is:
+---[RSA 3072]----+
|O=X* |
|OB=. |
|E*o. |
|Booo . |
|..= . o S |
| +.o o |
|+.oo+ o |
|+o.O.+ |
|+ . =o. |
+----[SHA256]-----+

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.

[operator1@serverb ~]$ ssh-copy-id -i .ssh/key2.pub operator1@servera


/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/key2.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter
out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted
now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'operator1@servera'"


and check to make sure that only the key(s) you wanted were added.

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.

[operator1@serverb ~]$ ssh -i .ssh/key2 operator1@servera hostname


Enter passphrase for key '.ssh/key2': redhatpass
servera.lab.example.com

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.

[operator1@serverb ~]$ eval $(ssh-agent)


Agent pid 1729
[operator1@serverb ~]$ ssh-add .ssh/key2
Enter passphrase for .ssh/key2: redhatpass
Identity added: .ssh/key2 ([email protected])

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.

[operator1@serverb ~]$ ssh -i .ssh/key2 operator1@servera hostname


servera.lab.example.com

12. Open another terminal on the workstation machine and log in to the serverb machine
as the student user.

[student@workstation ~]$ ssh student@serverb


...output omitted...
[student@serverb ~]$

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

[student@serverb ~]$ su - operator1


Password: redhat
[operator1@serverb ~]$

13.2. Log in to the servera machine as the operator1 user.


The command prompts you to enter the passphrase interactively because you do not
invoke the SSH connection from the same shell where you started the ssh-agent
program.

[operator1@serverb ~]$ ssh -i .ssh/key2 operator1@servera


Enter passphrase for key '.ssh/key2': redhatpass
...output omitted...
[operator1@servera ~]$

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.

[operator1@servera ~]$ exit


logout
Connection to servera closed.
[operator1@serverb ~]$

14.2. Return to the workstation system as the student user.

[operator1@serverb ~]$ exit


logout
[student@serverb ~]$ exit
logout
Connection to serverb closed.
[student@workstation ~]$

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.

[student@workstation ~]$ lab finish ssh-configure

This concludes the section.

322 RH124-RHEL9.0-en-2-20220609

You might also like