Beginners Guide to Configuring secure command-line service on remote systems, using OpenSSH

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 (ssh) Command 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: mypass
...output omitted...
[user01@remotehost ~]$

You can the exit command to log out of the remote system.

[user01@remotehost ~]$ exit
logout
Connection to remotehost closed.
[user01@host ~]$

The next ssh command would log you in on the remote server remotehost using the user name user02. Again, you are prompted by the remote system to authenticate with that user’s password.

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

This ssh command would run the hostname command on the remotehost remote system as the user02 user without accessing the remote interactive shell.

[user01@host ~]$ ssh user02@remotehost hostname
user02@remotehost's password: mypass
remotehost.lab.example.com
[user01@host ~]$

Notice that the preceding command displayed the output in the local system’s terminal.

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: mypass

[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 ~]$

The preceding output shows that the user02 user has logged in to the system on the pseudoterminal 0 at 16:13 today from the host with the 172.25.250.10 IP address, and has been idle at a shell prompt for seven minutes and thirty seconds. The preceding output also shows that the user01 user has logged in to the system on the pseudo-terminal 1 and has been idle for the last three seconds after executing the w command.

SSH Host Keys

SSH secures communication through public-key encryption. When an SSH client connects to an SSH server, the server sends a copy of its public key to the client before the client logs in. This is used to set up the secure encryption for the communication channel and to authenticate the server to the client. 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.

If the client has a copy of the key, ssh will compare the key from the known hosts files for that server to the one it received. If the keys do not match, the client assumes that the network traffic to the server could be hijacked or that the server has been compromised, and seeks the user’s confirmation on whether or not to continue with the connection.

If the client does not have a copy of the public key in its known hosts files, the ssh command will ask you if you want to log in anyway. If you do, a copy of the public key will be saved in your ~/.ssh/known_hosts file so that the server’s identity can be automatically confirmed in the future.

[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: mypass
...output omitted...
[user01@newhost ~]$

SSH Known Hosts Key Management

If a server’s public key is changed because the key was lost due to hard drive failure, or replaced for some legitimate reason, you will need to edit the known hosts files to make sure the entry for the old public key is replaced with an entry with the new public key in order to log in without errors.

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