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.
[[email protected] ~]$ ssh remotehost [email protected]'s password: mypass ...output omitted... [[email protected] ~]$
You can the exit command to log out of the remote system.
[[email protected] ~]$ exit logout Connection to remotehost closed. [[email protected] ~]$
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.
[[email protected] ~]$ ssh [email protected] [email protected]'s password: mypass ...output omitted... [[email protected] ~]$
This ssh command would run the hostname command on the remotehost remote system as the user02 user without accessing the remote interactive shell.
[[email protected] ~]$ ssh [email protected] hostname [email protected]'s password: mypass remotehost.lab.example.com [[email protected] ~]$
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.
[[email protected] ~]$ ssh [email protected] [email protected]'s password: mypass [[email protected] ~]$ w 16:13:38 up 36 min, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM [email protected] 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 [[email protected] ~]$
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 ﬁles. The system administrator may have pre-conﬁgured it in /etc/ssh/ssh_known_hosts, or the user may have a ~/.ssh/ known_hosts ﬁle 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 ﬁles for that server to the one it received. If the keys do not match, the client assumes that the network trafﬁc to the server could be hijacked or that the server has been compromised, and seeks the user’s conﬁrmation 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 ﬁles, 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 ﬁle so that the server’s identity can be automatically conﬁrmed in the future.
[[email protected] ~]$ 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. [email protected]'s password: mypass ...output omitted... [[email protected] ~]$
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 ﬁles 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 ﬁle on the SSH client. Each key is on one line. The ﬁrst ﬁeld is a list of hostnames and IP addresses that share that public key. The second ﬁeld is the encryption algorithm for the key. The last ﬁeld is the key itself.
[[email protected] ~]$ 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 ﬁles with the extension .pub.
[[email protected] ~]$ 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