SSH Key-based Authentication

SSH Key-based Authentication

You can configure an SSH server to allow you to authenticate without a password by using key-based authentication. This is based on a private-public key scheme.

To do this, you generate a matched pair of cryptographic key files. One is a private key, the other a matching public key. The private key file is used as the authentication credential and, like a password, must be kept secret and secure. The public key is copied to systems the user wants to connect to, and is used to verify the private key. The public key does not need to be secret.

You put a copy of the public key in your account on the server. When you try to log in, the SSH server can use the public key to issue a challenge that can only be correctly answered by using the private key. As a result, your ssh client can automatically authenticate your login to the server with your unique copy of the private key. This allows you to securely access systems in a way that doesn't require you to enter a password interactively every time.

- Configure

1. Generating SSH Keys

To create a private key and matching public key for authentication, use the ssh-keygen command. Do not enter a passphrase. By default, your private and public keys are saved in your ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files, respectively

If you do not specify a passphrase when ssh-keygen prompts you, the generated private key is not protected. In this case, anyone with your private key file could use it for authentication. If you set a passphrase, then you will need to enter that passphrase when you use the private key for authentication. (Therefore, you would be using the private key's passphrase rather than your password on the remote host to authenticate.)

2. Sharing the Public Key

Before key-based authentication can be used, the public key needs to be copied to the destination system. Use the ssh-copy-id command to send the public key of the SSH key pair to operator1 on servera.

After the public key is successfully transferred to a remote system, you can authenticate to the remote system using the corresponding private key while logging in to the remote system over SSH.
Execute the hostname command on servera remotely using SSH without accessing the remote interactive shell.

Notice that the preceding ssh command did not prompt you for a password because it used the passphrase-less private key against the exported public key to authenticate as operator1 on servera. This approach is not secure, because anyone who has access to the private key file can log in to servera as operator1. The secure alternative is to protect the private key with a passphrase, which is the next step.

3. Generate another SSH keys with passphrase-protection.

Save the key as /home/operator1/.ssh/key2.
Warning

If you do not specify the file where the key gets saved, the default file (/home/user/.ssh/id_rsa) is used. You have already used the default file name when generating SSH keys in the preceding step, so it is vital that you specify a non-default file, otherwise the existing SSH keys will be overwritten

4. Send the public key of the passphrase-protected key pair to operator1 on servera.

Notice that the preceding ssh-copy-id command did not prompt you for a password because it used the public key of the passphrase-less private key that you exported to servera in the preceding step.

5. Execute the hostname command

Execute the hostname command on servera remotely with SSH without accessing the remote interactive shell. Use /home/operator1/.ssh/key2 as the identity file. Specify redhatpass as the passphrase, which you set for the private key in the preceding step.
Notice that the preceding ssh command prompted you for the passphrase you used to protect the private key of the SSH key pair. This passphrase protects the private key. Should an attacker gain access to the private key, the attacker cannot use it to access other systems because the private key itself is protected with a passphrase. The ssh command uses a different passphrase than the one for operator1 on servera, requiring users to know both.

You can use ssh-agent, as in the following step, to avoid interactively typing in the passphrase while logging in with SSH. Using ssh-agent is both more convenient and more secure in situations where the administrators log in to remote systems regularly.

Using ssh-agent for Non-interactive Authentication

1. Run ssh-agent

Run ssh-agent 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 preceding eval command started ssh-agent and configured this shell session to use it. You then used ssh-add to provide the unlocked private key to ssh-agent.

2. Execute the hostname command

Execute the hostname command on servera remotely without accessing a remote interactive shell. Use /home/operator1/.ssh/key2 as the identity file.
Notice that the preceding ssh command did not prompt you to enter the passphrase interactively.

3. Open another terminal

Open another terminal then Open SSH session to servera as operator1.
Notice that the preceding ssh command prompted you to enter the passphrase interactively because you did not invoke the SSH connection from the shell that you used to start ssh-agent.

Prevent users from directly logging in as root over ssh.

1. Confirm that you can successfully log in

Confirm that you can successfully log in to servera as root using redhat as the password.

2. Set PermitRootLogin 

Set PermitRootLogin to no in /etc/ssh/sshd_config and reload sshd. You may use vim /etc/ssh/sshd_config to edit the configuration file of sshd.

3. Open a terminal and try to log into servera as root.

This should fail because you disabled root user login over SSH in the preceding step.
By default, the ssh command attempts to authenticate using key-based authentication first and then, if that fails, password-based authentication

Prevent users from logging in to the system using SSH password-based authentication.

1. Confirm that you can successfully log in to servera as operator3 

2. Set PasswordAuthentication 

Set PasswordAuthentication to no in /etc/ssh/sshd_config and reload sshd. You may use vim /etc/ssh/sshd_config to edit the configuration file of sshd.

3. Open a second terminal and try to log into servera as operator3.

This will fail because the SSH key is not configured for operator3, and the sshd service on servera does not allow the use of passwords for authentication