What is OpenSSH?

OpenSSH implements the Secure Shell or SSH protocol in the Red Hat Enterprise Linux systems. The SSH protocol enables systems to communicate in an encrypted and secure fashion over an insecure network.
You can use the ssh command to create a secure connection to a remote system, authenticate as a specific user, and get an interactive shell session on the remote system as that user. You may also use the ssh command to run an individual command on the remote system without running an interactive shell.

Secure Shell Examples

The following ssh command would log you in on the remote server remotehost using the same user name as the current local user. In this example, the remote system prompts you to authenticate with that user's password.

[user01@host ~]$ ssh remotehost
user01@remotehost's password: 
...output omitted...
[user01@remotehost ~]$ 

The next ssh command would log you in on the remote server remotehost using the user name user02.

[user01@host ~]$ ssh user02@remotehost
user02@remotehost's password: 
...output omitted...
[user02@remotehost ~]$ 

Identifying Remote Users

The w command displays a list of users currently logged into the computer. This is especially useful to show which users are logged in using ssh from which remote locations, and what they are doing.

[user01@host ~]$ ssh user01@remotehost
user01@remotehost's password: 
[user01@remotehost ~]$ w
 16:13:38 up 36 min,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
user02   pts/0    172.25.250.10    16:13    7:30   0.01s  0.01s -bash
user01   pts/1    172.25.250.10    16:24    3.00s  0.01s  0.00s w
[user02@remotehost ~]$ 

SSH host keys

When a user uses the ssh command to connect to an SSH server, the command checks to see if it has a copy of the public key for that server in its local known hosts files. The system administrator may have pre-configured it in /etc/ssh/ssh_known_hosts, or the user may have a ~/.ssh/known_hosts file in their home directory that contains the key.
Set the StrictHostKeyChecking parameter to yes in the user-specific ~/.ssh/config file or the system-wide /etc/ssh/ssh_config to cause the ssh command to always abort the SSH connection if the public keys do not match.

[user01@host ~]$ ssh newhost
The authenticity of host 'remotehost (172.25.250.12)' can't be established.
ECDSA key fingerprint is SHA256:qaS0PToLrqlCO2XGklA0iY7CaP7aPKimerDoaUkv720.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'newhost,172.25.250.12' (ECDSA) to the list of known hosts.
user01@newhost's password: 
...output omitted...
[user01@newhost ~]$ 

SSH Known Hosts Key Management

Public keys are stored in the etc/ssh/ssh_known_hosts and each users' ~/.ssh/known_hosts file on the SSH client. Each key is on one line. The first field is a list of hostnames and IP addresses that share that public key. The second field is the encryption algorithm for the key. The last field is the key itself.

[user01@host ~]$ cat ~/.ssh/known_hosts
remotehost,172.25.250.11 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOsEi0e+FlaNT6jul8Ag5Nj+RViZl0yE2w6iYUr+1fPtOIF0EaOgFZ1LXM37VFTxdgFxHS3D5WhnIfb+68zf8+w=

Each remote SSH server that you conect to stores its public key in the /etc/ssh directory in files with the extension .pub.

[user01@remotehost ~]$ ls /etc/ssh/*key.pub
/etc/ssh/ssh_host_ecdsa_key.pub  /etc/ssh/ssh_host_ed25519_key.pub  /etc/ssh/ssh_host_rsa_key.pub

Generating SSH Keys

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

[user@host ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:vxutUNPio3QDCyvkYm1oIx35hmMrHpPKWFdIYu3HV+w user@host.lab.example.com
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|   .     .       |
|  o o     o      |
| . = o   o .     |
|  o + = S E .    |
| ..O o + * +     |
|.+% O . + B .    |
|=*oO . . + *     |
|++.     . +.     |
+----[SHA256]-----+

If you do not specify a passphrase when ssh-keygen prompts you, the generated private key is not protected.
You can run a helper program called ssh-agent which can temporarily cache your private key passphrase in memory at the start of your session to get true passwordless authentication. This will be discussed later in this section.
The following example of the ssh-keygen command shows the creation of the passphrase-protected private key alongside the public key.

[user@host ~]$ ssh-keygen -f .ssh/key-with-pass
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in .ssh/key-with-pass.
Your public key has been saved in .ssh/key-with-pass.pub.
The key fingerprint is:
SHA256:w3GGB7EyHUry4aOcNPKmhNKS7dl1YsMVLvFZJ77VxAo user@host.lab.example.com
The key's randomart image is:
+---[RSA 2048]----+
|    . + =.o ...  |
|     = B XEo o.  |
|  . o O X =....  |
| = = = B = o.    |
|= + * * S .      |
|.+ = o + .       |
|  + .            |
|                 |
|                 |
+----[SHA256]-----+

The -f option with the ssh-keygen command determines the files where the keys are saved. In the preceding example, the private and public keys are saved in the /home/user/.ssh/key-with-pass /home/user/.ssh/key-with-pass.pub files, respectively.
Once the SSH keys have been generated, they are stored by default in the .ssh/ directory of the user's home directory. The permission modes must be 600 on the private key and 644 on the public key.

Sharing the Public Key

Before key-based authentication can be used, the public key needs to be copied to the destination system. The ssh-copy-id command copies the public key of the SSH keypair to the destination system. If you omit the path to the public key file while running ssh-copy-id, it uses the default /home/user/.ssh/id_rsa.pub file.

[user@host ~]$ ssh-copy-id -i .ssh/key-with-pass.pub user@remotehost
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_rsa.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
user@remotehost's password:
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@remotehost'"
and check to make sure that only the key(s) you wanted were added.

If you omit the path to the private key file while running the ssh command, it uses the default /home/user/.ssh/id_rsa file.

[user@host ~]$ ssh -i .ssh/key-with-pass user@remotehost
Enter passphrase for key '.ssh/key-with-pass':
...output omitted...
[user@remotehost ~]$ exit
logout
Connection to remotehost closed.
[user@host ~]$ 

Using ssh-agent for Non-interactive Authentication

If you log in on a text console, log in using ssh, or use sudo or su, you will probably need to start ssh-agent manually for that session. You can do this with the following command:

[user@host ~]$ eval $(ssh-agent)
Agent pid 10155
[user@host ~]$ 

Once ssh-agent is running, you need to tell it the passphrase for your private key or keys. You can do this with the ssh-add command.

The following ssh-add commands add the private keys from /home/user/.ssh/id_rsa (the default) and /home/user/.ssh/key-with-pass files, respectively.

[user@host ~]$ ssh-add
Identity added: /home/user/.ssh/id_rsa (user@host.lab.example.com)
[user@host ~]$ ssh-add .ssh/key-with-pass
Enter passphrase for .ssh/key-with-pass: redhatpass
Identity added: .ssh/key-with-pass (user@host.lab.example.com)

The following example of the ssh command uses the default private key file to authenticate to an SSH server.

[user@host ~]$ ssh user@remotehost
Last login: Fri Apr  5 10:53:50 2019 from host.example.com
[user@remotehost ~]$ 

The following example of the ssh command uses the /home/user/.ssh/key-with-pass (non-default) private key file to authenticate to an SSH server.

[user@host ~]$ ssh -i .ssh/key-with-pass user@remotehost
Last login: Mon Apr  8 09:44:20 2019 from host.example.com
[user@remotehost ~]$ 

When you log out of the session that started ssh-agent, the process will exit and your the passphrases for your private keys will be cleared from memory.

Configuring the OpenSSH Server

OpenSSH service is provided by a daemon called sshd. Its main configuration file is /etc/ssh/sshd_config.

*Prohibit the Superuser From Logging in Using SSH
*
The OpenSSH server uses the PermitRootLogin configuration setting in the /etc/ssh/sshd_config configuration file to allow or prohibit users logging in to the system as root.
With the PermitRootLogin parameter to yes, as it is by default, people are permitted to log in as root. To prevent this, set the value to no. Alternatively, to prevent password-based authentication but allow private key-based authentication for root, set the PermitRootLogin parameter to without-password.
The SSH server (sshd) must be reloaded for any changes to take effect.

[root@host ~]# systemctl reload sshd

*Prohibiting Password-Based *

Authentication for SSH
Allowing only private key-based logins to the remote command line has various advantages:
• Attackers cannot use password guessing attacks to remotely break into known accounts on the system.
The OpenSSH server uses the PasswordAuthentication parameter in the /etc/ssh/sshd_config configuration file to control whether users can use password-based authentication to log in to the system.

PasswordAuthentication yes

The default value of yes for the PasswordAuthentication parameter in the /etc/ssh/sshd_config configuration file causes the SSH server to allow users to use password-based authentication while logging in. The value of no for PasswordAuthentication prevents users from using password-based authentication.
Keep in mind that whenever you change the /etc/ssh/sshd_config file, you must reload the sshd service for changes to take effect.
Remember, if you turn off password-based authentication for ssh, you need to have a way to ensure that the user's ~/.ssh/authorized_keys file on the remote server is populated with their public key, so that they can log in.