Exploring PAM Configuration Files

PAM configuration files are located in the /etc/pam.d/ directory. Listing 16.2 shows this directory’s files on a CentOS distribution.

Listing 16.2: Viewing the /etc/pam.d/ directory’s contents

$ ls /etc/pam.d/
atd                     gdm-pin           postlogin-ac       su
chfn                    gdm-smartcard     ppp                sudo
chsh                    ksu               remote             sudo-i
config-util             liveinst          runuser            su-l
crond                   login             runuser-l          system-auth
cups                    other             setup              system-auth-ac
fingerprint-auth        passwd            smartcard-auth     systemd-user
fingerprint-auth-ac     password-auth     smartcard-auth-ac  vlock
gdm-autologin           password-auth-ac  smtp               vmtoolsd
gdm-fingerprint         pluto             smtp.postfix       xrdp-sesman
gdm-launch-environment  polkit-1          sshd               xserver
gdm-password            postlogin         sssd-shadowutils
$

Notice in Listing 16.2 that there is a login configuration file. This file is displayed snipped in Listing 16.3.

Listing 16.3: Viewing the /etc/pam.d/login file’s contents

$ cat /etc/pam.d/login
#%PAM-1.0
[…]
auth       include      postlogin
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
[…]
session    optional     pam_keyinit.so force revoke
[…]
$

The records in a PAM configuration file have a specific syntax. That syntax is as follows:

TYPE CONTROL-FLAG PAM-MODULE [MODULE-OPTIONS]

The TYPE, sometimes called a context or module interface, designates a particular PAM service type. The four PAM service types are shown in Table 16.1.

The PAM-MODULE portion of the /etc/pam.d/ configuration file record is simply the file name of the module that will be doing the work. For example, pam_nologin.so is shown in the /etc/pam.d/login configuration file, back in Listing 16.3. Additional modules options can be included after the module’s file name.

A designated PAM-MODULE is called in the order it is listed within the PAM configuration file. This is called the module stack. Each PAM-MODULE returns a status code, which is handled via the record’s CONTROL-FLAG setting. Together these status codes and settings create a final status, which is sent to the application. Table 16.2 lists the various control flags and their responses or actions.

The /etc/pam.d/ configuration files’ module stack process of providing a final status is a little confusing. A simplification to help you understand the progression is depicted in Figure 16.1.

Using Figure 16.1 as a guide, imagine the application subject (user) needs authentication to access the system. The appropriate /etc/pam.d/ configuration file is employed. Going through the authentication module stack, the user passes through the various security checkpoints. At each checkpoint, a guard (PAM module) checks a different requirement, determines whether or not the user has the required authentication, and issues a fail or success card. The final guard reviews the status cards along with their control flags listed on his clipboard. This guard determines whether or not the subject may proceed through the “System Access” doorway. Of course, keep in mind that if any of the checkpoints are listed as requisite, and the user fails that checkpoint, he would be immediately tossed out.

Enforcing Strong Passwords

When a password is modified via the passwd command, PAM is employed. These various PAM modules can help to enforce strong passwords:

• pam_unix.so
• pam_pwhistory.so
• pam_pwquality.so

The pam_unix.so module performs authentication using account and password data stored in the /etc/passwd and /etc/shadow files.

The pam_pwhistory.so module checks a user’s newly entered password against a history database to prevent a user from reusing an old password. The password history file, /etc/security/opasswd, is locked down. Passwords are also stored salted and hashed, using the same hashing algorithm employed for passwords stored in the /etc/shadow file.

To use the pam_pwhistory.so module, you must modify one of the /etc/pam.d configuration files. Along with specifying the password type and the module name, you can set one or more of the MODULE-OPTIONS listed in Table 16.3.

For Ubuntu, you need to put this configuration information in the /etc/pam.d/ common-password and /etc/pam.d/common-auth files. For other distributions, you put this configuration in the system’s default /etc/pam.d/ files password-auth and system-auth.

A snipped example of the newly modified CentOS /etc/pam.d/password-auth file is shown in Listing 16.4.

Listing 16.4: Viewing the modified /etc/pam.d/password-auth file

# grep password /etc/pam.d/password-auth
[…]
password    required      pam_pwhistory.so
password    sufficient    pam_unix.so […] use_authtok
[…]
#

In Listing 16.4, the grep command is employed to search for PAM password type records. The newly added pam_pwhistory.so module record uses a required control flag and no options. Note that the next record is for the pam_unix.so module and it uses the use_authtok option, which tells the module to use the password already entered instead of prompting for it again. Typically, it is best to place the password history record directly above this pam_unix.so record.

Now that password history is being enforced, you can test it by trying to reset your password to the current password. A snipped example is shown in Listing 16.5.

Listing 16.5: Trying to reuse an old password after password history is enforced

$ passwd
Changing password for user Christine.
Changing password for Christine.
(current) UNIX password:
New password:
BAD PASSWORD: The password is the same as the old one
[…]
passwd: Have exhausted maximum number of retries for service
$

Using pam_pwquality.so, you can enforce rules for new passwords, such as setting a minimum password length. You can configure needed directives within the /etc/security/pwquality.conf file or pass them as module options. A snipped example of the file is shown in Listing 16.6.

Listing 16.6: Viewing the /etc/security/pwquality.conf file’s contents

$ cat /etc/security/pwquality.conf
# Configuration for systemwide password quality limits
[…]
# difok = 5
[…]
# minlen = 9
[…]
# dcredit = 1
[…]
$

There are several password quality directives you can set within the pwquality.conf file. Table 16.4 describes the more common ones.

To help you understand Table 16.4’s credit directives, let’s focus on the dcredit setting. If you set dcredit = -3, this means that three digits must be in the new password. If you set dcredit = 3, this means that if there are three digits in the new password, the password required length minlen has now been reduced by three.

Once you have the pwquality.conf file directives completed, you’ll need to enable the pam_pwquality.so module within the proper /etc/pam.d/ configuration file. This is similar to how the pwhistory.so module is handled.

Locking Out Accounts

A brute-force attack occurs when a malicious user attempts to gain system access via trying different passwords over and over again for a particular system account. To prevent these attacks, you can lock out a user account after a certain number of failed attempts.

The pam_tally2.so and pam_faillock.so modules allow you to implement account lockout. Which one you choose depends upon your distribution (for example, pam_faillock is not installed by default on Ubuntu) as well as the various module options you wish to employ.

The two modules share three key module options. They are as described in Table 16.5.

On a current Ubuntu distribution, it is typically better to use the pam_tally2.so module. Keep in mind on a current CentOS distro, it may not work well. In Listing 16.7 a snipped display of a modified /etc/pam.d/common-auth file includes this module.

Listing 16.7: Viewing an Ubuntu /etc/pam.d/common-auth file’s contents

$ cat /etc/pam.d/common-auth
auth    required     pam_tally2.so  deny=2 silent
[…]
auth    […]          pam_unix.so nullok_secure
[…]
$

The pam_tally2.so configuration in Listing 16.7 allows only two failed login attempts prior to locking the account. Also, it does not automatically unlock the account after a certain time period.

The pam_tally2 command allows you to view failed login attempts. Listing 16.8 shows an example of this on an Ubuntu distribution.

Listing 16.8: Employing the pam_tally2 utility to view login failures

$ sudo pam_tally2
Login   Failures Latest failure     From
user1       4    11/08/19 16:28:14  /dev/pts/1
$

In Listing 16.8, the user1 account has four login attempt failures. Since the pam_tally2.so module option is set to deny=2, the account is now locked. You cannot unlock an account that has been locked by PAM via the usermod or passwd utility. Instead, you have to employ the pam_tally2 command and add the -r (or --reset) and -u (or --user) options as shown in Listing 16.9. This wipes out the login failure tally so that the account is no longer locked out.

Listing 16.9: Using the pam_tally2 utility to reset login failure tallies

$ sudo pam_tally2 -r -u user1
Login           Failures Latest failure     From
user1               4    11/08/19 16:28:14  /dev/pts/1
$
$ sudo pam_tally2
$

On a current CentOS distribution, it is typically better to use the pam_faillock.so module. Listing 16.10 shows a snipped display of a modified /etc/pam.d/system-auth file that includes this module.

Listing 16.10: Viewing a CentOS /etc/pam.d/system-auth file’s contents

# cat /etc/pam.d/system-auth
[…]
auth        required      pam_env.so
auth        required      pam_faillock.so preauth silent audit deny=2
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        [default=die] pam_faillock.so authfail audit deny=2
auth        sufficient    pam_faillock.so authsucc audit deny=2
[…]
account     required      pam_faillock.so
account     required      pam_unix.so
[…]
#

Notice in Listing 16.10 that there are four pam_faillock.so module records. Within these records are a few options and one control flag that have not yet been covered:

• preauth: If there have been a large number of failed consecutive authentication attempts, block the user’s access.
• audit: If a nonexistent user account is entered, log the attempted account name.
• [default=die]: Returned code treated as a failure. Return to the application immediately.
• authfail: Record authentication failure into the appropriate user tally file.
• authsucc: Identify failed authentication attempts as consecutive or non-consecutive.

To have pam_faillock.so work correctly, you need to modify the password-auth file as well and add the exact same records as were added to the Listing 16.10 file. It is also located in the /etc/pam.d/ directory.

The faillock command allows you to view failed login attempts. Listing 16.11 shows an example of this on a CentOS distribution.

Listing 16.11: Using the faillock utility to view and reset login failure tallies

# faillock
user1:
When                Type  Source   Valid
2018-11-08 17:47:23 TTY   tty2         V
2018-11-08 17:47:31 TTY   tty2         V
#
# ls -F /var/run/faillock
user1
#
# faillock --reset --user user1
#
# faillock
user1:
When                Type  Source   Valid
#

Notice in Listing 16.11 that the faillock utility displays records for each failed login attempt. In this case, since deny=2 is set, the user1 account is locked out. To unlock the account, the faillock command is used again with the appropriate options. Another item to note within Listing 16.11 is the /var/run/faillock directory. When the pam_faillock.so module is configured, each user receives a failed login attempt tally file within this directory. However, the file is not created until a login failure first occurs.

Limiting Root Access

It is best to employ the sudo command (see Chapter 15) to gain super user privileges as opposed to logging into the root user account. Even better is to have the root account disabled for login via its /etc/shadow file record. However, if you absolutely must log in to the root account, you can limit the locations where this is done.

If properly configured, the pam_securetty.so PAM module and the /etc/securetty file are used to restrict root account logins. They do so by limiting root logins only to devices listed in the secure TTY file. A snipped listing of this file on an Ubuntu distro is shown in Listing 16.12.

Listing 16.12: Viewing the /etc/securetty file

$ cat /etc/securetty
# /etc/securetty: list of terminals on which root is allowed to login.
# See securetty(5) and login(1).
[…]
console

# Local X displays […]
:0
:0.0
:0.1
[…]
# Virtual consoles
tty1
tty2
tty3
tty4
[…]
$

To understand the /etc/securetty file records, you need to understand how TTY terminals are represented. When you log in to a virtual console, typically reached by pressing a Ctrl+Alt+Fn key sequence, you are logging into a terminal that is represented by a /dev/tty* file. For example, if you press Ctrl+Alt+F2 and log into the tty2 terminal, that terminal is represented by the /dev/tty2 file. Notice that the /etc/securetty file records in Listing 16.12 only show the virtual console terminal name (e.g., tty4) and not its device file.

When you log into the system via its graphical interface, a who or w command’s output will show something similar to :0 in your process’s TTY column. In Listing 16.12, you can find records for those logins as well.

If you then open a terminal emulator program, you are opening a TTY terminal, called a pseudo-TTY, that is represented by a /dev/pts/* file, such as /dev/pts/0. These TTY terminals are not listed within the /etc/securetty file because the user has already logged into the graphical environment.

The pam_securetty.so module is typically placed within either the /etc/pam.d/login and/or the /etc/pam.d/remote configuration files. An example of this is shown snipped on an Ubuntu distribution in Listing 16.13.

Listing 16.13: Finding the files that use the pam_securetty.so module

$ grep pam_securetty /etc/pam.d/*
/etc/pam.d/login:auth […] pam_securetty.so
$

On this Ubuntu distribution, only the login PAM configuration file includes the pam_securetty.so module. Notice in Listing 16.13 that the PAM service type used for this module is auth.

Getting Certificates

A few members of the PKI team are the certificate authority (CA) structure and CA-issued digital certificates. After verifying a person’s identity, a CA issues a digital certificate to the requesting person. The digital certificate provides identification proof along with an embedded key, which now belongs to the requester. The certificate holder can now use the certificate’s key to encrypt data and sign it using the certificate. This provides authenticity and validation for those that will decrypt the data, especially if it is transmitted over a network.

Digital certificates issued from a CA take effort to obtain as well as money. If you are simply developing a new application, are in its testing phase, or are practicing for a certification exam, you can generate and sign your own certificate. This type of certificate is called a self-signed digital certificate. While self-signed certificates are useful in certain situations, they should never be used in a production environment.

Discovering Key Concepts

It is critical to understand cipher keys and their role in the encryption/decryption process. Cipher keys come in two flavors—private and public/private.

Private Keys Symmetric keys, also called private or secret keys, encrypt data using a cryptographic algorithm and a single key. Plain text is both encrypted and decrypted using the same key, and it is typically protected by a password called a passphrase. Symmetric key cryptography is very fast. Unfortunately, if you need others to decrypt the data, you have to share the private key, which is its primary disadvantage.

Public/Private Key Pairs Asymmetric keys, also called public/private key pairs, encrypt data using a cryptographic algorithm and two keys. Typically the public key is used to encrypt the data and the private key decrypts the data. The private key can be protected with a passphrase and is kept secret. The public key of the pair is meant to be shared.

Asymmetric keys are used by system users as well as many applications, such as SSH. Figure 16.2 provides a scenario of using a public/private key pair between two people.

Notice in Figure 16.2 that in order for Bob to encrypt data (a message in this case) for Helen, he must use her public key. Helen in turn uses her private key to decrypt the data. However, problems occur if Bob is not sure that he is really getting Helen’s public key. He may be getting a public key from a nefarious user named Evelyn and accidentally send his encrypted message to her. This is a man-in-the-middle attack. Digital signatures, which are covered later, help in this situation.

Securing Data

An important concept in PKI and cryptography is hashing. Hashing uses a one-way mathematical algorithm that turns plain text into a fixed-length ciphertext. Because it is one way, you cannot “de-hash” a hashed ciphertext. The ciphertext created by hashing is called a message digest, hash, hash value, fingerprint, or signature.

The beauty of a cryptographic message digest is that it can be used in data comparison. For example, if hashing produces the exact same message digest for plain-text FileA and for plain-text FileB, then both files contain the exact same data. This type of hash is often used in cyber-forensics.

Be aware that simple message digests, called non-salted and non-keyed message digests, are created only using the plaintext file as input. This hash can be strengthened by adding salt, which is random data added along with the input file to protect the hash from certain malicious attacks. A salted hash is used in the /etc/shadow file to protect passwords.

A keyed message digest is created using the plaintext file along with a private key. This cryptographic hash type is strong against multiple malicious attacks and often employed in Linux applications, such as SSH.

Signing Transmissions

Another practical implementation of hashing is in digital signatures. A digital signature is a cryptographic token that provides authentication and data verification. It is simply a message digest of the original plain-text data, which is then encrypted with a user’s private key and sent along with the ciphertext.

The ciphertext receiver decrypts the digital signature with the sender’s public key so the original message digest is available. The receiver also decrypts the ciphertext and then hashes its plain-text data. Once the new message digest is created, the data receiver can compare the new message digest to the sent message digest. If they match, the digital signature is authenticated, which means the encrypted data did come from the sender. Also, it indicates the data was not modified in transmission.

Exploring Basic SSH Concepts

You’ll typically find OpenSSH (www.openSSH.com) installed by default on most distributions. However, if for some reason you are unable to use basic SSH services, you may want to check if the needed OpenSSH packages are installed (managing packages was covered in Chapter 13). Table 16.6 shows the distributions used by this book and their basic OpenSSH service package names.

To create a secure OpenSSH connection between two systems, use the ssh command. The basic syntax is as follows:

ssh [options] username@hostname

For a successful encrypted connection, both systems (client and remote) must have the OpenSSH software installed and the sshd daemon running. A snipped example is shown in Listing 16.14 connecting from a CentOS system to a remote openSUSE Linux server.

Listing 16.14: Using ssh to connect to a remote system

$ ssh C[email protected]
The authenticity of host '192.168.0.105 (192.168.0.105)' can't be established.
ECDSA key fingerprint is SHA256:BnaCbm+ensyrkflKk1rRSVwxHi4NrBWOOSOdU+14m7w.
ECDSA key fingerprint is MD5:25:36:60:b7:99:44:d7:74:1c:95:d5:84:55:6a:62:3c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.105' (ECDSA) to the list of known hosts.
Password:
[…]
Have a lot of fun...
Christine@linux-1yd3:~> ip addr show | grep 192.168.0.105
    inet 192.168.0.105/24 […] dynamic eth1
Christine@linux-1yd3:~>
Christine@linux-1yd3:~> exit
logout
Connection to 192.168.0.105 closed.
$
$ ls .ssh
known_hosts
$

In Listing 16.14, the ssh command uses no options, includes the remote system account username, and uses the remote system’s IPv4 address instead of its hostname. Note that you do not have to use the remote system account username if the local account name is identical. However, in this case, you do have to enter the remote account’s password to gain access to the remote system.

The OpenSSH application keeps track of any previously connected hosts in the ~/.ssh/known_hosts file. This data contains the remote servers’ public keys.

If you have not used ssh to log in to a particular remote host in the past, you’ll get a scary looking message like the one shown in Listing 16.14. The message just lets you know that this particular remote host is not in the known_hosts file. When you type yes at the message’s prompt, it is added to the collective.

The rsync utility, which was covered in Chapter 3, can employ SSH to quickly copy files to a remote system over an encrypted tunnel. To use OpenSSH with the rsync command, add the username@hostname before the destination file’s location. An example is show in Listing 16.15.

Listing 16.15: Using rsync to securely transfer a file over SSH

$ ls -sh Project4x.tar
40K Project4x.tar
$
$ rsync Project4x.tar [email protected]:~
Password:
$

In Listing 16.15, the Project4x.tar file is sent to a remote system using the rsync command and OpenSSH. Notice that the remote system’s username and IP address has an added colon (:). This is to designate that the file is being transferred to a remote system. If you did not add the colon, the rsync command would not transfer the file. It would simply rename the file to a file name with Christine@ and tack on the IP address too.

After the colon, the file’s directory destination is designated. The ~ symbol indicates to place the file in the user’s home directory. You could also give the file a new name, if desired.

You can also use the ssh command to send commands to a remote system. Just add the command, between quotation marks, to the ssh command’s end. An example is shown in Listing 16.16.

Listing 16.16: Using ssh to send a command to a remote system

$ ssh [email protected] "ls -sh Project4x.tar"
Password:
40K Project4x.tar
$

In Listing 16.16, the command checks if our file was properly transferred to the remote system. The Project4x.tar file was successfully moved.

Configuring SSH

It’s a good idea to review the various OpenSSH configuration files and their directives. Ensuring that your encrypted connection is properly configured is critical for securing remote system communications. Table 16.7 lists the primary OpenSSH configuration files.

If you need to make SSH configuration changes, it is essential to know which configuration file(s) to modify. The following guidelines can help:

• For an individual user’s connections to a remote system, create and/or modify the client side’s ~/.ssh/config file.
• For every user’s connection to a remote system, create and modify the client side’s /etc/ssh/ssh_config file.
• For incoming SSH connection requests, modify the /etc/ssh/sshd_config file on the server side.

There are several OpenSSH configuration directives. You can peruse them all via the man pages for the ssh_config and sshd_config files. However, there are a few vital directives for the sshd_config file:

• AllowTcpForwarding: Permits SSH port forwarding. (See Chapter 8.)
• ForwardX11: Permits X11 forwarding. (See Chapter 8.)
• PermitRootLogin: Permits the root user to log in through an SSH connection. Typically, should be set to no.
• Port: Sets the port number the OpenSSH daemon (sshd) listens on for incoming connection requests. (Default is 22.)

An example of why you might change the client’s ssh_config or ~/.ssh/config file is when the remote system’s SSH port is modified in the sshd_config file. In this case, if the client-side configuration files were not changed to match this new port, the remote user would have to modify their ssh command’s options. An example of this is shown snipped in Listing 16.17. In this listing, the remote Ubuntu server has OpenSSH listening on port 1138, instead of the default port 22, and the user must use the -p option with the ssh command to reach the remote server.

Listing 16.17: Using ssh to connect to a non-default port on a remote system

$ ssh -p 1138 192.168.0.104
[…]
[email protected]'s password:
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-36-generic x86_64)
[…]
Christine@Ubuntu1804:~$
Christine@Ubuntu1804:~$ ip addr show | grep 192.168.0.104
    inet 192.168.0.104/24 […]
Christine@Ubuntu1804:~$
Christine@Ubuntu1804:~$ exit
logout
Connection to 192.168.0.104 closed.
$

To relieve the OpenSSH client users of this trouble, create or modify the ~/.ssh/config file for individual users, or for all client users, modify the /etc/ssh/ssh_config file. Set Port to 1138 within the configuration file. This makes it easier on both the remote users and the system administrator.

Generating SSH Keys

Typically, OpenSSH will search for its system’s public/private key pairs. If they are not found, OpenSSH automatically generates them. These key pairs, also called host keys, are stored in the /etc/ssh/ directory within files. Listing 16.18 shows key files on a Fedora distribution.

Listing 16.18: Looking at OpenSSH key files on a Fedora system

$ ls -1 /etc/ssh/*key*
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub
$

In Listing 16.18, both private and public key files are shown. The public key files end in the .pub file name extension, while the private keys have no file name extension. The file names follow this standard:

ssh_host_KeyType_key

The key file name’s KeyType corresponds to the digital signature algorithm used in the key’s creation. The different types you may see on your system are as follows:

• dsa
• rsa
• ecdsa
• ed25519

There may be times you need to manually generate these keys or create new ones. In order to do so, the ssh-keygen utility is employed. In Listing 16.19, a snipped example of using this utility is shown on a Fedora system.

Listing 16.19: Using ssh-keygen to create new public/private key pair

$ sudo ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
Generating public/private rsa key pair.
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
[…]
$

The ssh-keygen has several options. For the commands in Listing 16.19, only two are employed. The -t option sets the KeyType, which is rsa in this example. The -f switch designates the private key file to store the key. The public key is stored in a file with the same name, but the .pub file extension is added. Notice that this command asks for a passphrase, which is associated with the private key.

Authenticating with SSH Keys

Entering the password for every command employing SSH can be tiresome. However, you can use keys instead of a password to authenticate. A few steps are needed to set up this authentication method:

1. Log into the SSH client system.
2. Generate an SSH ID key pair.
3. Securely transfer the public SSH ID key to the SSH server computer.
4. Log into the SSH server system.
5. Add the public SSH ID key to the ~/.ssh/authorized_keys file on the server system.

Let’s look at these steps in a little more detail. First, you should log into the client system via the account you will be using as the SSH client. On that system, generate the SSH ID key pair via the ssh-keygen utility. You must designate the correct key pair file name, which is id_TYPE, where TYPE is dsa, rsa, or ecdsa. An example of creating an SSH ID key pair on a client system is shown snipped in Listing 16.20.

Listing 16.20: Using ssh-keygen to create an SSH ID key pair

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/Christine/.ssh/id_rsa.
Your public key has been saved in /home/Christine/.ssh/id_rsa.pub.
[…]
$
$ ls .ssh/
id_rsa  id_rsa.pub  known_hosts
$

Notice in Listing 16.20 the key file’s name. The ssh-keygen command in this case generates a private key, stored in the ~/.ssh/id_rsa file, and a public key, stored in the ~/.ssh/id_rsa.pub file. You may enter a passphrase if desired. In this case, no passphrase was entered.

Once these keys are generated on the client system, the public key must be copied to the server system. Using a secure method is best, and the ssh-copy-id utility allows you to do this. Not only does it copy over your public key, it also stores it in the server system’s ~/.ssh/authorized_keys file for you. In essence, it completes steps 3 through 5 in a single command. A snipped example of using this utility is shown in Listing 16.21.

Listing 16.21: Using ssh-copy-id to copy the SSH public ID key

$ ssh-copy-id -n [email protected]
[…]
Would have added the following key(s):

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsP[…]
8WJVE5RWAXN[…]
=-=-=-=-=-=-=-=
$ ssh-copy-id  C[email protected]
[…]Source of key(s) to be installed: "/home/Christine/.ssh/id_rsa.pub"
[…]
[email protected]'s password:

Number of key(s) added: 1
[…]
$

Notice in Listing 16.21 that the ssh-copy-id -n command is employed first. The -n option allows you to see what keys would be copied and installed on the remote system without actually doing the work (a dry run).

The next time the command is issued in Listing 16.21, the -n switch is removed. Thus, the id_rsa.pub key file is securely copied to the server system, and the key is installed in the ~/.ssh/authorized_keys file. Notice that when using the ssh-copy-id command, the user must enter their password to allow the public ID key to be copied over to the server.

Now that the public ID key has been copied over to the SSH server system, the ssh command can be used to connect from the client system to the server system with no need to enter a password. This is shown along with using the scp command in Listing 16.22. Note that at the IP address’s end, you must add a colon (:) when using the scp command to copy over files.

Listing 16.22: Testing out password-less SSH connections

$ ssh [email protected]
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-36-generic x86_64)
[…]
Christine@Ubuntu1804:~$ ls .ssh
authorized_keys  known_hosts
Christine@Ubuntu1804:~$
Christine@Ubuntu1804:~$ exit
logout
Connection to 192.168.0.104 closed.
$
$ scp Project4x.tar [email protected]:~
Project4x.tar      100%   40KB   6.3MB/s   00:00
$
$ ssh [email protected]
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-36-generic x86_64)
[…]
Christine@Ubuntu1804:~$ ls
Desktop    Downloads         Music     Project4x.tar  Templates
Documents  examples.desktop  Pictures  Public         Videos
Christine@Ubuntu1804:~$ exit
logout
Connection to 192.168.0.104 closed.
$

Authenticating with the Authentication Agent

Another method to connect to a remote system with SSH is via the authentication agent. Using the agent, you only need to enter your password to initiate the connection. After that, the agent remembers the password during the agent session. A few steps are needed to set up this authentication method:

1. Log into the SSH client system.
2. Generate an SSH ID key pair and set up a passphrase.
3. Securely transfer the public SSH ID key to the SSH server computer.
4. Log into the SSH server system.
5. Add the public SSH ID key to the ~/.ssh/authorized_keys file on the server system.
6. Start an agent session.
7. Add the SSH ID key to the agent session.

Steps 1 through 5 are nearly the same steps performed for setting up authenticating with SSH ID keys instead of a password. One exception to note is that a passphrase must be created when generating the SSH ID key pair for use with an agent. An example of setting up an ECDSA key to use with an SSH agent is shown snipped in Listing 16.23.

Listing 16.23: Generating and setting up an ID key to use with the SSH agent

$ ssh-keygen -t ecdsa -f ~/.ssh/id_ecdsa
Generating public/private ecdsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/Christine/.ssh/id_ecdsa.
[…]
$ ssh-copy-id  -i ~/.ssh/id_ecdsa C[email protected]
[…]
Number of key(s) added: 1
[…]
$

Once you have the key pair properly created with a passphrase on the remote system, securely transmitted, and installed on the server’s authorized key file, you can employ the ssh-agent utility to start an SSH agent session. After the session is started, add the private ID key to the session via the ssh-add command. A snipped example of this is shown in Listing 16.24.

Listing 16.24: Starting an SSH agent session and adding an ID key

$ ssh-agent /bin/bash
[Christine@localhost ~]$
[Christine@localhost ~]$ ssh-add ~/.ssh/id_ecdsa
Enter passphrase for /home/Christine/.ssh/id_ecdsa:
Identity added: /home/Christine/.ssh/id_ecdsa (/home/Christine/.ssh/id_ecdsa)
[Christine@localhost ~]$
[Christine@localhost ~]$ ssh C[email protected]
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-36-generic x86_64)
[…]
Christine@Ubuntu1804:~$ exit
logout
Connection to 192.168.0.104 closed.
[Christine@localhost ~]$
[Christine@localhost ~]$ exit
exit
$

Notice in Listing 16.24 that the ssh-agent command is followed by /bin/bash, which is the Bash shell. This command starts a new session, an agent session, with the Bash shell running. Once the private SSH ID key is added using the ssh-add command and entering the private passphrase, you can connect to remote systems without entering a password or passphrase again. However, if you exit the agent session and start it up again, you must re-add the key and reenter the passphrase.

An SSH agent session allows you to enter the session one time and add the key, then connect as often as needed to remote systems via encrypted SSH methods without entering a password or passphrase over and over again. Not only does this provide security, it provides convenience, which is a rare combination.

Using SSH Securely

There are a few things you can do to enhance SSH’s security on your systems:

• Use a different port for SSH than the default port 22.
• Disable root logins via SSH.
• Manage TCP Wrappers.

One item touched upon earlier in this chapter is not using port 22 as the SSH port for any public-facing systems. You change this by modifying the Port directive in the /etc/ssh/sshd_config file to another port number. Keep in mind that there are advantages and disadvantages to doing this. It may be a better alternative to beef up your firewall as opposed to changing the default SSH port.

Another critical item is disabling root login via SSH. By default, any system that allows the root account to log in and has OpenSSH enabled permits root logins via SSH. Because root is a standard username, malicious attackers can use it in brute-force attacks. Since root is a super user account, it needs extra protection.

To disable root login via SSH, edit the /etc/ssh/sshd_config file. Set the PermitRootLogin directive to no, and either restart the OpenSSH service or reload its configuration file.

TCP Wrappers are an older method for controlling access to network-based services. If a service can employ TCP Wrappers, it will have the libwrap library compiled with it. You can check for support by using the ldd command as shown snipped in Listing 16.25. In this listing on an Ubuntu system, you can see that TCP Wrappers can be used by the SSH service.

Listing 16.25: Using the ldd command to check for TCP Wrappers support

$ which sshd
/usr/sbin/sshd
$
$ ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 […]
$

TCP Wrappers employ two files to determine who can access a particular service. These files are /etc/hosts.allow and /etc/hosts.deny. As you can tell by their names, the hosts.allow file typically allows access to the designated service, while the hosts.deny file commonly blocks access. These files have simple record syntax:

service: IPaddress…

The search order of these files is critical. For an incoming service request, the following takes place:

• The hosts.allow file is checked for the remote IP address.
  • If found, access is allowed, and no further checks are made.
• The hosts.deny file is checked for the remote IP address.
  • If found, access is denied.
  • If not found, access is allowed.

Because access is allowed if the remote system’s address is not found in either file, it is best to employ the ALL wildcard in the /etc/hosts.deny file:

ALL: ALL

This disables all access to all services for any IP address not listed in the /etc/hosts.allow file. Be aware that some distributions use PARANOID instead of ALL for the address wildcard.

The record’s IPaddress can be either IPv4 or IPv6. To list individual IP addresses in the hosts.allow file, you specify them separated by commas as such:

sshd: 172.243.24.15, 172.243.24.16, 172.243.24.17

Typing in every single IP address that is allowed to access the OpenSSH service is not necessary. You can specify entire subnets. For example, if you needed to allow all the IPv4 addresses in a Class C network access on a server, you specify only the first three address octets followed by a trailing dot as such:

sshd: 172.243.24.