INFO-3182 – Operating Systems Linux

Module 17a – SecureShell

Introduction

SecureShell, commonly known as SSH, is a network protocol and set of tools that permit users and
systems to communicate in a secure way. The network protocol is always encrypted. The tools include a
server service and several client programs. The client programs support interactive terminal sessions,
command execution, file transfer, file copy, and on some systems remote file system mounting on a
system running the server service.

Installing SSH

Most modern operating systems, including Linux, Microsoft Windows, and Apple MacOS come with
some, if not all, of the client programs pre-installed. The server service is pre-installed on some Linux
systems. Other operating systems have the server service optionally available. For example, all CentOS
Stream 9 systems have the SSH server installed by default, but Ubuntu 24.04 does not. The SSH server
can be installed by selecting it during the installation of an Ubuntu 24.04 server system, but it must be
installed separately on an Ubuntu 24.04 desktop system.

The commands to install the SSH server on Ubuntu 24.04 are:

sudo apt-get update
sudo apt-get install openssh-server

and on CentOS Stream 9, the command, if necessary, is:

sudo dnf install openssh-server

The client programs are in the openssh-clients package on CentOS Stream 9 and the openssh-client
package on Ubuntu 24.04, if needed.

Working with the SSH server service.

As noted above, the SSH server service (sshd.service on CentOS Stream 9 and ssh.service on Ubuntu
24.04) is often installed and started as part of the Linux operating system installation. This service, like
most Linux services today, runs under the control of systemd, so stopping, starting, reloading, etc. the
service is done using the systemctl command.

Page 1 of 11
 INFO-3182 – Operating Systems Linux

The well-known port for the SSH protocol is 22/TCP but this can be changed if necessary. Appropriate
firewall rules are required to permit clients to connect to the server service. On CentOS Stream 9, a
firewall rule is automatically added when the server service is installed. This firewall rule permits
connections from anywhere, so is not ideal. Ubuntu 24.04 does not have a running firewall by default, so
a firewall rule is not required. However, before putting any Ubuntu 24.04 system into service, its firewall
needs to be enabled, and the appropriate rules added.

SSH client programs

The SSH client programs that are usually installed by default are:

• ssh – Provides remote interactive sessions and remote command execution.

• scp – Provides remote file copy functionality.
• sftp – Provides interactive file transfer functionality.
• ssh-keygen – Used to generate a public key pair for user authentication.
• ssh-copy-id – Used to transfer public keys to a remote SSH server.

CAUTION: Some people see the SSH tools, especially sftp, as being tools like Telnet, ftp and rcp with an
encryption layer wrapped around them in a similar way to HTTP and HTTPS. This is not the case, These
tools and the SSH protocol were built to be encrypted right from the start.

Connecting to a server using the ssh command

The most common use of the SSH server service and client tools is to run remote terminal sessions. This
is done using the ssh client program. Figure 1 shows a user connecting to an SSH server for the first
time using the ssh command. The user initiates the connection by issuing the command:
ssh [email protected]

Where:

• thall is the username of the account on the server to login as.

• 192.168.101.20 is the IP address of the server. The name of the server can also be used
provided there is a /etc/hosts file entry or a DNS record for it.

The first time a user connects to a server using any of the SSH tools that establish a connection with a
server, the server’s host public key is transferred to the client. The user must accept the server host
public key by responding with yes at the prompt to allow the connection to be established. After
accepting the key, it is saved in a file named known_hosts in the ~/.ssh directory. This message will not
appear again for this user and server. If a host’s public key changes after it has been added to a user’s

Page 2 of 11
 INFO-3182 – Operating Systems Linux

known_hosts file, a warning message is displayed. The user must then take the action described in the
warning before a connection can be established.

After accepting the host public key, the user is prompted to enter their password.

Figure 1 Screenshot of a user connecting to a server via ssh for the first time. The host key must be accepted by the user before
the connection is allowed to establish.

Upon successful login and before the shell prompt appears, messages may be displayed to the user. The
content of these messages is distribution dependent. In Figure 1, some login history is displayed.

Securing SSH

One might think that since SSH uses encryption for all communication it is secure. Communications are
secured, but not necessarily as well as might be needed. Another thing to think about is the use of
passwords for authentication, anytime passwords are in use there is the possibility of password cracking
attacks. A third point is whether administrator accounts like root should be allowed to login via an SSH
session.

As discussed in an earlier module, it is considered poor practice to permit the root user to log directly
into a Linux system except in special circumstances. This carries into the configuration of SSH as well, the
root user should not be allowed to log in directly using any SSH tools. While locking the root account and
possibly setting root’s shell to /sbin/nologin may seem adequate, it will not prevent password cracking
attacks from being attempted via SSH.

Every Linux SSH server service has a configuration file /etc/ssh/sshd_config containing many
configuration settings. This file contains many commented out configuration settings. Commented out
configuration settings show the default value for the setting. The recommended approach for changing
the value of a setting is to uncomment it and change the value, as necessary.

Page 3 of 11
 INFO-3182 – Operating Systems Linux

One of these settings is one that permits or blocks attempts to login as the root user. This setting should
always be set to block root login attempts. The name of this setting varies depending on the Linux
distribution being used.

On CentOS Stream 9 and Ubuntu 24.04 systems, the setting that controls whether root can login via SSH
or not is PermitRootLogin. It can have one of four values:

• prohibit-password – This value prevents the root user logging in with a password but
allows root to log in using key-based authentication. This is the default value.
• yes – The root user is permitted to login using both password and key-based authentication.
• forced-command-only – This value permits the root user to login using key-based
authentication provided that the command to be executed is specified as part of the call to the
ssh command on the client system.
• no – This value prevents the root user from logging in via SSH.

The most secure of these values is no. This is the value that should always be used except in special
circumstances.

Preventing the root user from being able to login to a Linux system via SSH is a big improvement in
security, but what about regular user accounts. Regular users cannot be prevented from logging in,
especially administrators with sudo privileges, otherwise everyone will need access to the system
console. Forcing everyone to use the system console is not practical.

The SSH server service supports three methods to get around the use of simple password
authentication: multi-factor authentication using the Google Authenticator software and a password,
using both a public key and password, or using just a public key. All three methods work effectively and
eliminate the use of passwords alone. Google authenticator requires a smart phone or similar device
with the software installed on it, the authentication services on the SSH server must be configured to
use Google authenticator (the package to do this is provided by a third party not Google) and the SSH
server requires Internet access. both public key authentication methods are part of the SSH software
and only require connectivity between the client and server systems. The process to create and deploy
these keys is discussed later in this module, this section discusses only the server configuration settings
related to using keys successfully.

By default, any user except root can log into a Linux system running an SSH server with either a
password or a public key. This is controlled by the settings PubkeyAuthentication and
PasswordAuthentication, both have yes as their defaults. Changing the value of either one to no
disables that authentication method.

To use both a public key and a password, set both the previous settings to yes, then add the following
setting to the sshd_config file (it is not included in the file provided by many Linux distributions):
AuthenticationMethods publickey,password

The AuthenticationMethods settings lists all the authentication methods that must succeed before a
user is granted access to a system via SSH. The example above says that a valid key must be sent to the
server and the password for the user must be correct before the user is allowed to access the system.

Page 4 of 11
 INFO-3182 – Operating Systems Linux

CAUTION: Make sure at least one administrator has set up public key authentication before turning off
password authentication or requiring both a public key and a password. Turning off password
authentication or requiring both a public key and a password without an administrator having public key
access will render SSH useless as a means of accessing and managing a system.

There have been two major versions of SSH over the years. Thankfully, version one is now obsolete
along with all its security issues. SSH version 2 is a much better set of software, and it supports a wide
variety of encryption algorithms of varying ages and strengths. Many governmental and business
organizations must meet certain legal and industry standards for their information technology
environments. This means that not all encryption algorithms supported by the SSH protocol, and its
software are acceptable in all environments. It is beyond the scope of this course to go into details
about the many encryption algorithms and their relationship to laws and industry standards. However,
security and system administrators need to explore the requirements they must meet in this area and
configure their systems accordingly. On some Linux distributions of SSH, the default encryption
algorithm set can be adjusted by using settings in the sshd_config file, others require the modification of
files within the OpenSSL configuration file directory.

Public keys in SSH

Host keys

On every SSH server or client system there are a set of public key pairs used by the server and client
software to establish the encrypted connections between the client and server systems. These are
asymmetric key pairs that are used to identify the hosts and negotiate a symmetric key for data transfer.
These keys are automatically generated and should never be changed by a user. These key pairs are in
the /etc/ssh directory along with the configuration files. Each key pair is stored in two files, one with the
public key and the other with the private key. The private key is never transmitted over the network.

Modern SSH systems have three different public keys, one for each of the supported asymmetric
algorithm types, Elliptic Curve, RSA, and ed25519 (ed25519 is not allowed by some laws and standards
in the US). Of these Elliptic Curve is considered the best because it is believed to be the only one that
will survive the introduction of quantum computing, when it eventually arrives.

The key and encryption algorithm used for a connection between systems is negotiated during
connection establishment, with the most secure one supported by both the client and server usually
being selected.

Page 5 of 11
 INFO-3182 – Operating Systems Linux

User keys

Users can use public keys to authenticate with a server when establishing a connection via SSH. These
user keys are always asymmetric and can be Elliptic Curve, RSA, ed25519 or DSA. Elliptic Curve keys
should have a key length of 384 or 521 (yes 521) bits. RSA keys should have a key length of 3072 bits or
greater. ed25519 keys have a fixed key length which cannot be changed. DSA keys are based on an old
technology which is no longer considered secure and should not be used.

There are no user keys for SSH on a Linux system by default. If a user needs to authenticate with a server
using public keys, the keys must be generated by the user on the client system and the public key
transferred to the server system. The key generation command is ssh-keygen.

Figure 2 Screenshot of the ssh-keygen command being used to generate an Elliptic Curve authentication public key pair with a
key length of 384 bits.

Figure 2 shows the use of the ssh-keygen command to generate an Elliptic Curve key pair with 384
bits. The command is:
ssh-keygen -t ecdsa -b 384

Where:

Page 6 of 11
 INFO-3182 – Operating Systems Linux

• -t specifies the type of key to generate. The default for this parameter is dsa which should never
be used today, so this parameter must be used to specify the type of key to create. The most
common values are ecdsa and rsa.
• -b specifies the number of bits in the key. For ecdsa keys the recommended bit length is 384
with 521 as an alternate. For rsa keys, the recommended number of bits is 3072 or greater,
common values are 3072 and 4096.

Some security specialists suggest that using Elliptic Curve keys with 521 bits is not a good idea because
these keys are not a multiple of 2 in length. This introduces a slight risk of buffer overflow attacks
because of the way systems allocate memory. At the time of writing, no such attacks have been
reported. Instead, they recommend always using 384-bit keys.

The ssh-keygen command generates two files for each public key it generates, one containing the
private key and the other containing the public key. As the command is running the user is prompted for
the location and name of the files. Accept the default name and location whenever possible, other
commands are easier to use when the defaults are used. The private key should never be moved from
the system it is created on, although it is possible to do so. The public key needs to be copied to every
SSH server where it is to be used for authentication.

The command asks for a passphrase (password) for the private key. While a passphrase is optional, it is a
protection for the private key, ensuring that no one can use a given key pair without the passphrase.

Figure 3 Screenshot showing a long directory listing of the ~/.ssh directory after generating the key. The two public key files are
shown along with the known_hosts files and a backup of it.

Figure 3 shows a long directory listing of the ~/.ssh directory where all user-specific SSH files are stored.
The two files for the Elliptic Curve public key are id_ecdsa (private key) and id_ecdsa.pub (public key).

To use this key pair, the public key must be copied to the hosts where it is to be used for authentication.
Some users choose to use one key pair for all SSH servers, others choose to use multiple key pairs. Using
multiple key pairs requires that each pair of key files have a unique name, making it a bit harder to use
the ssh, sftp and other SSH client programs. For this example, only one key pair is used.

Page 7 of 11
 INFO-3182 – Operating Systems Linux

If ordinary password authentication is enabled on the SSH server, the ssh-copy-id command can be used
by any user to copy their public key to a server. If this is not the case, then an administrator must copy
the user’s public key for them and add it to the end of the user’s ~/.ssh/authorized_keys file (this is why
both password and public key authentication are enabled by default).

Figure 4 shows the ssh-copy-id command being used to transfer the user’s public key to a SSH server.
Even though it is copying the key to make public key authentication work, this command still tries to use
public key authentication because it found a private key with the default filename to use. After the
public key authentication fails, the command falls back to password authentication. When password
authentication succeeds, the public key is copied to the server. Part of the operation of the ssh-copy-id
command is that it appends the new key to the end of the user’s ~/.ssh/authorized_keys file on the
server.

Figure 4 Screenshot showing the ssh-copy-id command being used to transfer a user's public key to a SSH server. Notice that it
tried to use key authentication before falling back to password authentication.

Figure 5 Screenshot showing an attempt to connect to a server using the ssh command using a public key pair with a passphrase
on the private key. A prompt for the private key's passphrase is displayed.

Page 8 of 11
 INFO-3182 – Operating Systems Linux

Public key authentication takes precedence over password authentication when they are both
configured and only one of them is required. So, the next time a user attempts to log in to a server with
their public key on it via any SSH client, public key authentication will be tried first. Figure 5 shows an
attempt to use public key authentication when the private key has a passphrase on it. The connection
cannot be established properly until the user enters the correct passphrase.

Once the passphrase is provided, authentication completes, and the connection is established properly.
Figure 6 shows the working interactive terminal session that opened when the correct passphrase was
entered in the dialog shown in Figure 5. Notice that the password prompt was not displayed in the
terminal window.

Figure 6 Screenshot showing a newly stablished ssh terminal session using public key authentication. No password prompt was
displayed.

Other useful SSH server configuration settings

There are many other configuration settings available for the SSH server. Some of them can have a
bearing on system security. A few commonly used ones are given below.

Banner

The Banner setting allows an administrator to specify a greeting banner that is displayed before login
completes. When password authentication is used, the message appears immediately before the
password prompt. While displaying a banner will not stop a system being attacked, putting a warning
against unauthorized use in it will help in the prosecution of unauthorized access to a system.

By default, there is no banner as indicated by the setting shown below.

#Banner none

Uncommenting the Banner setting and changing its value to the fully qualified name of a file containing
the message (as shown below) will cause a banner message to be displayed at every login attempt.
Banner /etc/ssh/sshd_banner

Page 9 of 11
 INFO-3182 – Operating Systems Linux

Figure 7 shows an example of using the Banner setting. Public key authentication is being used, so the
password prompt is not displayed.

Since this message may have legal implications, it is best to get assistance from an organization’s legal
department to word it properly.

Figure 7 Screenshot demonstrating the use of the Banner setting. The banner message is displayed before authentication
completes.

Automatic Client Logout

By default, an SSH server does not automatically log out client sessions( ClientAliveInterval is 0), but it
does try sending messages to the client to check if the session is still active (ClientAliveCountMax 3). It
will send three messages before determining that a session is no longer alive
#ClientAliveInterval 0
#ClientAliveCountMax 3

Many organizations implement policies that require inactive users to be logged out automatically after a
certain period of inactivity. Uncommenting the ClientAliveInterval and ClientAliveCountMax settings and
changing their values enables automatic logout. The example settings below will log a user out after 5
minutes (300 seconds) of inactivity.
ClientAliveInterval 300
ClientAliveCountMax 0

X windows forwarding

X windows is a graphical processing service that provides the basis for all graphical desktops on Linux
and Unix systems. It is also the inspiration for most other graphical user interfaces in computing and pre-
dates Microsoft Windows and Apple’s Mac OS by several years. While X windows is primarily a local
service, it does have the ability to run in a client/server mode via a network connection. However, the
client server mode has numerous security-related issues in it. Years ago, the SSH developers found a
way to forward X windows client/server traffic through a SSH connection, thus providing an encrypted

Page 10 of 11
 INFO-3182 – Operating Systems Linux

method for sending the traffic over the network. Unfortunately, this has not completely mitigated the
security issues in the X windows client/server mode.

Even so, the default setting for the X11Forwarding configuration setting in sshd_config was set to yes for
many years. The default value has been changed to no on most modern Linux systems. This setting
should be set to no unless X windows forwarding is critical for some application.

The setting name and default value for X windows forwarding today is:
#X11Forwarding no

Tunnelling

SSH servers can be configured to allow general port forwarding or tunnelling between client and server
systems. The security risks involved vary depending on the applications being forwarded, but the use of
any form of tunnelling should be avoided. There are four settings that can appear in the sshd_config file
related to tunnelling. The first three are usually part of any default sshd_config file but the last one is
not and should be added. Ensure that the value for each setting is no. For some of them no is the
default, but not all. Specifically, AllowStreamLocalForwarding, the one that is not part of many
sshd_config files by default, has a default value of yes.
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no
AllowStreamLocalForwarding no

When changing any of these settings, test the system carefully. There may be unexpected critical use of
one or mModule 16a – Network Time Protocolore of them.

Page 11 of 11