LPI Linux Certification/Secure Shell (SSH)

Detailed Objectives (212.3)

(LPIC-2 Version 4.5)

Weight: 4

Description: Candidates should be able to configure an SSH server. This objective includes managing keys and configuring SSH for users. Candidates should also be able to forward an application protocol over SSH and manage the SSH login.

Key Knowledge Areas:

• OpenSSH configuration files, tools, and utilities.
• Login restrictions for the superuser and the normal users.
• Managing and using server and client keys to login with and without password.
• Usage of multiple connections from multiple hosts to guard against loss of connection to remote host following configuration changes.

Files, terms, and utilities:

• ssh
• sshd
• /etc/ssh/sshd_config
• /etc/ssh/
• Private and public key files
• PermitRootLogin, PasswordAuthentication, AllowUsers, X11Forwarding

Secure Shell (OpenSSH)

Overview

Description: The candidate should be able to configure sshd to allow or deny root logins, enable or disable X forwarding. This objective includes generating client keys, generating a user's public/private key pair, adding a public key to a user's authorized_keys file, and configuring ssh-agent for all users. Candidates should also be able to configure port forwarding to tunnel an application protocol over ssh, disable non-root logins during system maintenance, configure trusted clients for ssh logins without a password, and make multiple connections from multiple hosts to guard against loss of connection to remote host following configuration changes.

OpenSSH

OpenSSH is a free, open source implementation of the SSH (Secure SHell) protocols. It replaced tools from a bygone era, namely telnet, ftp, rlogin, rsh, and rcp, with secure, encrypted network connectivity tools. OpenSSH supports the SSH 2.0 protocol.

All communications using OpenSSH tools, including passwords, are encrypted. Telnet and FTP used cleartext passwords and sent all information unencrypted. That information could be intercepted, the passwords could be retrieved, and then your system could be compromised by an unauthorized person logging in to your system using one of the intercepted passwords. Or observers in the middle could have monitored and even recorded all the unencrypted data send over the net. Thus the OpenSSH set of utilities should be used instead of unencrypted utilities to avoid these security problems.

Another reason to use OpenSSH is that it can automatically forward the DISPLAY variable to the client machine. In other words, if you are running the X Window System on your local machine, and you log in to a remote machine using the ssh command, when you execute a program on the remote machine that requires X, it will be displayed on your local machine. This is convenient if you prefer graphical system administration tools but do not always have physical access to your server.

The ssh client allows you to securely log in to and execute commands on a remote system. Logging in to a remote machine with ssh is similar to how it once was with telnet. For example, to log in to a remote machine named penguin.example.net, type the following command at a shell prompt:

 ssh penguin.example.net

The first time you use ssh to a remote machine, you will see a message similar to the following:

The authenticity of host 'penguin.example.net (198.51.100.86)' can't be established.
ED25519 key fingerprint is SHA256:vYSNKOoCHReBzmdJy3SiUJGiV5YlWHIUls070tKdBzI.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? 

Next, you'll see a prompt asking for your password for the remote machine. After entering your password, you will be at an interactive shell prompt for the remote machine. If you use ssh without any command line options, the username that you are logged in as on the local client machine is passed to the remote machine. If you want to specify a different username, use the following command with the -l option to choose another account on the remote system:

 ssh -l username penguin.example.net

You can also use the syntax ssh username@penguin.example.net. The ssh command can be used to execute a command on the remote machine without logging in to a shell prompt. The syntax is ssh hostname command. For example, if you want to execute the command ls /usr/share/doc on the remote machine penguin.example.net, type the following command at a shell prompt:

 ssh penguin.example.net 'ls /usr/share/doc'

After you enter the correct password, the contents of the directory /usr/share/doc from the remote system will be displayed, and you will return to your local shell prompt.

The scp command can be used to transfer files between machines over a secure, encrypted connection. Its interface is similar to rcp of yore but its default is to actually run sftp under the hood.

The general syntax to copy a local file to a remote system is scp localfile user@hostname:/newfilename. The localfile specifies the name of the source file, and the set of user@hostname:/newfilename specifies the destination. For example, to copy a local file named shadowman to your account on the remote system at penguin.example.net, type the following at a shell prompt (replace "user" with your username):

 scp shadowman user@penguin.example.net:/home/user

This will transfer the local file shadowman to /home/user/shadowman on penguin.example.net.

The general syntax to copy a remote file to the local system is scp user@hostname:/remotefile /newlocalfile. The name remotefile specifies the source, and the name newlocalfile specifies the destination.

Multiple files can be specified as the source. For example, to copy the contents of the directory /downloads to an existing directory called uploads on the remote machine penguin.example.net, type the following at a shell prompt:

scp /downloads/* username@penguin.example.net:/uploads/

The sftp utility can be used to open a secure, interactive session to upload and download files. The interface looks somewhat similar to old ftp except that sftp has been designed from the ground up to work over SSH and thus uses a secure, encrypted connection. The general syntax is sftp username@hostname.com. Once authenticated, you can use a set of commands similar to with FTP to upload, download, rename, and so on. Refer to the sftp manual page for a list of these commands. To read the manual page, execute the command man sftp at a shell prompt. The sftp utility has been available since OpenSSH version 2.5.0p1 and higher.

Generating Key Pairs

If you wish to greatly improve the security of your remote system when you use ssh, scp, or sftp to connect to a remote machine, you can generate an authorization key pair.

Note: Some older systems or hardware tokens may require RSA, but generally Ed25519 should be used nowadays.

Warning : Each User Needs Their Own Key Pair ! Ideally each user-system tuple should have their own key pair !

Keys must be generated for each user. The following steps generate a new key pair for the user who wants to connect to a particular remote system. The key generation must be done by that particular user's account. If you complete the following steps as root, only root will be able to use the keys.

Ed25519 keys are used as the default by OpenSSH since version 9.5. Old RSA keys can still be generated if needed by swapping out Ed25519 for RSA in the instructions below by changing the -t option. The -C option is for embedding a comment within the key itself. Having a comment inside the key makes it easier to manage larger numbers of keys over time. The key pair can also have a custom name if specified by the -f option.

1. To generate an Ed25519 key pair, type the following command at a shell prompt:

 ssh-keygen -t ed25519 \
        -C 'a note about who the key is for, where it connects to' \
        -f ~/.ssh/id_ed25519

The -f option in that example is redundant because the default file location is ~/.ssh/id_ed25519 anyway. However, it is included to show how it works in case a unique file name is needed. Then, when prompted, enter a passphrase different from your account password and confirm it by entering it again.

(A passphrase is a string of words and characters used to authenticate a user. Passphrases differ from passwords in that you can use spaces or tabs in the passphrase. Passphrases are generally longer than passwords because they are usually phrases instead of just a word.)

2. If not already set, change the permissions of your .ssh directory on the remote system using the command chmod 750 ~/.ssh so that only your account has write access.

3. Append the contents of ~/.ssh/id_ed25519.pub into ~/.ssh/authorized_keys on the remote system to which you want to connect. If the file ~/.ssh/authorized_keys doesn't exist, you can just copy the file ~/.ssh/id_ed25519.pub to the remote system and give it the name ~/.ssh/ there.

RSA is slowly being phased out but some older systems and hardware tokens might still need them. You can make RSA keys using the above steps, but swap out "ed25519" with "rsa" each time.

The Next Step with Keys, set PasswordAuthentication to "no"

Once you can log in with keys, set the "PasswordAuthentication" directive to "no" in the server configuration following the steps in the next section. With remote systems it is very important to be careful and not get locked out.

Guard Against Loss of Connection to Remote Host During Re-configuration

This is one method to guard against loss of access to the remote host when re-configuring the SSH service. For this you will need root access on the remote system, access to a second port for SSH besides port 22 for that system, and the ability to reload the configuration for sshd itself.

As root on the remote system, create and edit a new configuration file, then test it before deployment. The line below creates a copy to work with.

 cp -p /etc/ssh/sshd_config /root/sshd_config.test

Next, launch an editor with which to make changes. After that, launch a separate, single-use SSH instance listening on port 2222 which uses that test configuration. The session information will be logged to a separate file, /root/sshd_config.test.log Observe that the full path to sshd must be used to get it to run.

 nano /root/sshd_config.test
 /usr/sbin/sshd -d \
        -p 2222 \
        -E /root/sshd_config.test.log \
        -f /root/sshd_config.test

With that extra SSH instance running in the one terminal window, open another terminal window and connect to it by connecting to the remote system on port 2222. This extra SSH process is a one-off instance. It will end when your test session ends. A key advantage of running an extra SSH instance like this is that there will be a custom log file containing the entirety of that one session, nothing more, nothing less.

 ssh -p 2222 penguin.example.net

If the session did not connect or did not work as required, examine the custom log file for clues, then re-edit the test configuration and try again.

 less -X /root/ssh_config.test.log

If the session worked as required, go on to put the test configuration file into production. But first make a backup copy of the old configuration file. Once you have a copy, then have the SSH service reload the configuration file. Do this while still logged in as root on the remote system.

 cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.old
 cp /root/sshd_config.test /etc/ssh/sshd_config

Once the SSH service is re-started, and before disconnecting the original session, open another local terminal window and ensure that you really can still login to the remote system.

Deny root Logins

The recommended best practices are to prevent direct, remote access to the root account and login to a regular user account first.

If, and only if, you have established the ability to 1) login via another account and 2) access root via su or other means, remote access to root can be disabled by changing the configuration file.

 PermitRootLogin no

Once tested using the steps in the above section, have the SSH service reload the configuration file to deploy the changes.

X Forwarding

You can forward the X11 port through SSH to enable encrypted X11 connections. There's no need to export a DISPLAY variable or even to call the xhost utility.

On the server-side you must check the file /etc/ssh/sshd_config to be sure that the "X11Forwarding" option is set to "yes".

The, on the client-side, use the -X option :

 ssh -X user@remotehost

When the remote host prompt appears, start a X11 application and it will be seen locally:

 chromium &

A browser window from the remote host will open on your local desktop. However, it can feel a bit slow as there can be a bit of latency when working that way.

Exercises

1. Check the manual page for ssh. What do the options -p, -l, and -i do?

2. Find out how to verify the remote SSH server's host key out of band.

3. Generate a key pair for SSH and use it to login to the remote system.

4. Check the manual page for sshd_config. What do the directives PasswordAuthentication and PermitRootLogin do?

5. Check the manual page for sftp. What do the options -P and -i do?

6. Connect to a remote system using sftp and down load a file.

7. Use X11 forwarding to run a remote, graphical program but have it rendered locally.