Red Hat System Administration I
- SectionAccess the Remote Command Line with SSH
- Guided Exercise: Access the Remote Command Line
- Configure SSH Key-based Authentication
- Guided Exercise: Configure SSH Key-based Authentication
- Customize OpenSSH Service Configuration
- Guided Exercise: Customize OpenSSH Service Configuration
- Lab: Configure and Secure SSH
- Summary
Abstract
| Goal | Configure secure command-line service on remote systems with OpenSSH. |
| Objectives |
|
| Sections |
|
| Lab |
Configure and Secure SSH |
The OpenSSH package provides the Secure Shell, or SSH protocol, in Red Hat Enterprise Linux. With SSH protocol, systems can communicate in an encrypted and secure channel over an insecure network.
Use the ssh command to create a secure connection to a remote system, authenticate as a specific user, and obtain an interactive shell session on the remote system.
The ssh command can run a session on a remote system without running an interactive shell.
The following ssh command logs you in on the hosta remote server by using the same username as the current local user.
The remote system prompts you to authenticate with the developer1 user's password in this example.
[developer1@host ~]$ssh hostadeveloper1@hosta's password:...output omitted... [developer1@hosta ~]$redhat
Use the exit command to log out of the remote system.
[developer1@hosta ~]$ exit
logout
Connection to hosta closed.
[developer1@host ~]$The following ssh command logs you in on the hosta remote server with the developer2 username.
The remote system prompts you to authenticate with the developer2 user's password.
[developer1@host ~]$ssh developer2@hostadeveloper2@hosta's password:...output omitted... [developer2@hosta ~]$shadowman
The following ssh command runs the hostname command on the hosta remote system as the developer2 user without accessing the remote interactive shell.
[developer1@host ~]$ssh developer2@hosta hostnamedeveloper2@hosta's password:hosta.lab.example.com [developer1@host ~]$shadowman
This command displays the output in the local system's terminal.
The w command displays a list of users that are currently logged in to the system.
It also displays the remote system location and commands that the user ran.
[developer1@host ~]$ssh developer1@hostadeveloper1@hosta's password:[developer1@hosta ~]$redhatw16:13:38 up 36 min, 1 user, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT developer2 pts/0 172.25.250.10 16:13 7:30 0.01s 0.01s -bash developer1 pts/1 172.25.250.10 16:24 3.00s 0.01s 0.00s w [developer2@hosta ~]$
The output shows that the developer2 user logged in to the system on the pseudo-terminal 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 output also shows that the developer1 user logged in to the system on the pseudo-terminal 1, and has been idle for three seconds after executing the w command.
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 logging in. This key helps to set up secure encryption for the communication channel and to authenticate the client's system.
When a user runs the ssh command for connecting to an SSH server, the command checks for a copy of the server's public key in its local known hosts file.
The key might be preconfigured in the /etc/ssh/ssh_known_hosts file, or the user might have the ~/.ssh/known_hosts file that contains the key in their home directory.
If the client has a copy of the key, then the ssh command compares the key from the known hosts server files to the key that it received.
If the keys do not match, then the client assumes that the network traffic to the server is compromised, and prompts the user to confirm whether to continue with the connection.
The StrictHostKeyChecking parameter is set in the user-specific ~/.ssh/config file, or in the system-wide /etc/ssh/ssh_config file, or by specifying the -o StrictHostKeyChecking= option of the ssh command.
If the
StrictHostKeyCheckingparameter is set toyes, then thesshcommand always aborts the SSH connection if the public keys do not match.If the
StrictHostKeyCheckingparameter is set tono, then thesshcommand enables the connection and adds the key of the target host to the~/.ssh/known_hostsfile.
If the target host SSH key changed since the last time that you connected to it, then the ssh command asks for confirmation to log in and accept the new key.
If you accept the new key, then a copy of the public key is saved in the ~/.ssh/known_hosts file to automatically confirm the server's identity on subsequent connections.
Note
Red Hat recommends to set the StrictHostKeyChecking parameter to yes in the user-specific ~/.ssh/config file or in the system-wide /etc/ssh/ssh_config file, so that the ssh command always aborts the SSH connection if the public keys do not match.
[developer1@host ~]$ssh hostbThe authenticity of host 'hostb (172.25.250.12)' can't be established. ECDSA key fingerprint is SHA256:qaS0PToLrqlCO2XGklA0iY7CaP7aPKimerDoaUkv720. Are you sure you want to continue connecting (yes/no)?no[developer1@host ~]$
Verify the fingerprint of the target server's SSH host key by using the ssh-keygen command.
In this example, the ssh-keygen command is run on the hostb target server.
The ssh-keygen command displays the key fingerprint so that you can match it to the output of the ssh command and verify that the key is valid.
Use the -lf options to list the public key fingerprint in the host's default public key file.
Because you cannot connect over SSH, you must verify the target host's key fingerprint by logging in locally. Use an out-of-band communication method to share public keys, such as a phone call or video conference.
[developer1@hostb ~]$ ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
256 SHA256:qaS0PToLrqlCO2XGklA0iY7CaP7aPKimerDoaUkv720 root@server (ECDSA)After you verify the key on the target host, you can accept the key and connect to the target host.
[developer1@host ~]$ssh hostbThe authenticity of host 'hostb (172.25.250.12)' can't be established. ECDSA key fingerprint is SHA256:qaS0PToLrqlCO2XGklA0iY7CaP7aPKimerDoaUkv720. Are you sure you want to continue connecting (yes/no)?yesWarning: Permanently added 'hostb,172.25.250.12' (ECDSA) to the list of known hosts. developer1@hostb's password:...output omitted... [developer1@hostb ~]$redhat
Information about known remote systems and their keys are stored in either of the following places:
The system-wide
/etc/ssh/ssh_known_hostsfile.The
~/.ssh/known_hostsfile in each user's home directory.
The /etc/ssh/ssh_known_hosts file is a system-wide file that stores the public keys for hosts that the system knows.
You must create and manage this file, either manually or through some automated method such as by using Ansible or a script that uses the ssh-keyscan utility.
A server's public key might have changed because the key was lost due to hard drive failure or it was replaced for some legitimate reason.
In that case, to successfully log in to that system, the /etc/ssh/ssh_known_hosts file must be modified to replace the previous public key entry with the new public key.
If you connect to a remote system and the public key of that system is not in the /etc/ssh/ssh_known_hosts file, then the SSH client searches for the key in the ~/.ssh/known_hosts file.
Each known host key entry consists of one line that contains three fields:
The first field is the list of hostnames and IP addresses that share the public key.
The second field is the encryption algorithm that is used for the key.
The last field is the key itself.
[developer1@host ~]$ cat ~/.ssh/known_hosts
server1 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOmiLKMExRnsS1g7OTxMsOmgHuUSGQBUxHhuUGcv19uT
server1 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC8WDOooY+rh6NPa9yhLsNQXBqcQknTL/WSd3zPvHLLd7KaC4IiEUxnwbfLBit8tRcirbQFxO20Am
...output omitted...If the IP address or the public key of the remote system changes, and you try to connect to that system again via SSH, then the SSH client detects that the key entry for that system in the ~/.ssh/known_hosts file is no longer valid.
A warning message states that the remote host identification changed, and that you must modify the key entry.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:hxttxb/qVi1/ycUU2wXF6mfGH++Ya7WYZv0r+tIkg4I. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/user/.ssh/known_hosts:12 ECDSA host key for server1.example.com has changed and you have requested strict checking. Host key verification failed.
If you do not know why the key changed, then verify the new key fingerprint, because this key might be an actual attack on your network. Use an out-of-band method for verification, such as speaking with the system administrator of the target system.
If you know why the key changed, such as an IP address change, then resolve this problem by removing the relevant key entry from the ~/.ssh/known_hosts file, and then reconnect to the system to receive the new key entry.
The line number of the relevant key entry is specified in the warning message. You can also find and remove the relevant key entry by running the following command:
[developer1@host ~]$ ssh-keygen -R remotesystemname -f ~/.ssh/known_hosts
# Host remotesystemname found: line 12
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.oldReferences
ssh(1), w(1), and hostname(1) man pages
For more information, refer to Using Secure Communications Between Two Systems with OpenSSH at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/securing_networks/assembly_using-secure-communications-between-two-systems-with-openssh_securing-networks
