OpenSSH

Potential intruders have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:

Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous. If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.

The SSH protocol provides the following safeguards:

Additionally, it also offers the following options:

Two varieties of SSH currently exist: version 1 and version 2. The OpenSSH suite under Fedora uses SSH version 2, which has an enhanced key exchange algorithm not vulnerable to the known exploit in version 1. However, for compatibility reasons, the OpenSSH suite does support version 1 connections as well, although version 1 is disabled by default and needs to be enabled in the configuration files.

The following series of events help protect the integrity of SSH communication between two hosts.

There are two different sets of configuration files: those for client programs (that is, ssh, scp, and sftp), and those for the server (the sshd daemon). System-wide SSH configuration information is stored in the /etc/ssh/ directory as described in System-wide configuration files. User-specific SSH configuration information is stored in ~/.ssh/ within the user’s home directory as described in User-specific configuration files.

For information concerning various directives that can be used in the SSH configuration files, see the ssh_config(5) and sshd_config(5) manual pages.

To start the sshd daemon in the current session, type the following at a shell prompt as root:

To stop the running sshd daemon in the current session, use the following command as root:

If you want the daemon to start automatically at the boot time, type as root:

See Services and Daemons for more information on how to configure services in Fedora.

Note that if you reinstall the system, a new set of identification keys will be created. As a result, clients who had connected to the system with any of the OpenSSH tools before the reinstall will see the following message:

To prevent this, you can backup the relevant files from the /etc/ssh/ directory (see System-wide configuration files for a complete list), and restore them whenever you reinstall the system.

For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user’s password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include telnet, rsh, rlogin, and vsftpd.

These services are not installed by default in Fedora. If required, to make sure these services are not running, type the following commands at a shell prompt:

To disable running these services at startup, type:

See Services and Daemons for more information on how to configure services in Fedora.

To improve the system security even further, generate SSH key pairs and then enforce key-based authentication by disabling password authentication. To do so, open the /etc/ssh/sshd_config configuration file in a text editor such as vi or nano, and change the PasswordAuthentication option as follows:

If you are working on a system other than a new default installation, check that PubkeyAuthentication no has not been set. If connected remotely, not using console or out-of-band access, testing the key-based log in process before disabling password authentication is advised.

To be able to use ssh, scp, or sftp to connect to the server from a client machine, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.

Fedora 31 uses SSH Protocol 2 and RSA keys by default (see Protocol Versions for more information).

Using public key cryptography for authentication requires copying the public key from every client to every server that the client intends to log into. This system does not scale well and can be an administrative burden. Using a public key from a certificate authority (CA) to authenticate client certificates removes the need to copy keys between multiple systems. While the X.509 Public Key Infrastructure Certificate system provides a solution to this issue, there is a submission and validation process, with associated fees, to go through in order to get a certificate signed. As an alternative, OpenSSH supports the creation of simple certificates and associated CA infrastructure.

OpenSSH certificates contain a public key, identity information, and validity constraints. They are signed with a standard SSH public key using the ssh-keygen utility. The format of the certificate is described in /usr/share/doc/openssh-version/PROTOCOL.certkeys.

The ssh-keygen utility supports two types of certificates: user and host. User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users. For certificates to be used for user or host authentication, sshd must be configured to trust the CA public key.

Support for certificate authentication of users and hosts using the new OpenSSH certificate format was introduced in Fedora 13, in the openssh-5.4p1-1.fc13 package. If required, to ensure the latest OpenSSH package is installed, enter the following command as root:

Two types of certificates are required, host certificates and user certificates. It is considered better to have two separate keys for signing the two certificates, for example ca_user_key and ca_host_key, however it is possible to use just one CA key to sign both certificates. It is also easier to follow the procedures if separate keys are used, so the examples that follow will use separate keys.

The basic format of the command to sign user’s public key to create a user certificate is as follows:

Where -s indicates the private key used to sign the certificate, -I indicates an identity string, the certificate_ID, which can be any alpha numeric value. It is stored as a zero terminated string in the certificate. The certificate_ID is logged whenever the certificate is used for identification and it is also used when revoking a certificate. Having a long value would make logs hard to read, therefore using the host name for host certificates and the user name for user certificates is a safe choice.

To sign a host’s public key to create a host certificate, add the -h option:

Host keys are generated on the system by default, to list the keys, enter a command as follows:

Hosts that are to allow certificate authenticated log in from users must be configured to trust the CA’s public key that was used to sign the user certificates, in order to authenticate user’s certificates. In this example that is the ca_user_key.pub.

Publish the ca_user_key.pub key and download it to all hosts that are required to allow remote users to log in. Alternately, copy the CA user public key to all the hosts. In a production environment, consider copying the public key to an administrator account first. The secure copy command can be used to copy the public key to remote hosts. The command has the following format:

Where host_name is the host name of a server the is required to authenticate user’s certificates presented during the login process. Ensure you copy the public key not the private key. For example, as root:

For remote user authentication, CA keys can be marked as trusted per-user in the ~/.ssh/authorized_keys file using the cert-authority directive or for global use by means of the TrustedUserCAKeys directive in the /etc/ssh/sshd_config file. For remote host authentication, CA keys can be marked as trusted globally in the /etc/ssh/known_hosts file or per-user in the ~/.ssh/ssh_known_hosts file.

To avoid being presented with the warning about an unknown host, a user’s system must trust the CA’s public key that was used to sign the host certificates. In this example that is ca_host_key.pub.

A certifcate is a signed public key. The user’s and host’s public keys must be copied to the CA server for signing by the CA server’s private key.

Create an administrator account, in this example admin, and a directory to receive the user’s keys. For example:

Set the permissions to allow keys to be copied in:

It is possible to sign a host key using a CA key stored in a PKCS#11 token by providing the token library using the -D and identifying the CA key by providing its public half as an argument to the -s option:

In all cases, certificate_ID is a "key identifier" that is logged by the server when the certificate is used for authentication.

Certificates may be configured to be valid only for a set of users or host names, the principals. By default, generated certificates are valid for all users or hosts. To generate a certificate for a specified set of principals, use a comma separated list with the -n option as follows:

and for hosts:

Additional limitations on the validity and use of user certificates may be specified through certificate options. A certificate option may disable features of the SSH session, may be valid only when presented from particular source addresses or may force the use of a specific command. For a list of valid certificate options, see the ssh-keygen(1) manual page for the -O option.

Certificates may be defined to be valid for a specific lifetime. The -V option allows specifying a certificates start and end times. For example:

A certificate that is presented at a time outside this range will not be considered valid. By default, certificates are valid indefinitely starting from UNIX Epoch.

To view a certificate, use the -L to list the contents. For example, for a user’s certificate:

To vew a host certificate:

If a certificate is stolen, it should be revoked. Although OpenSSH does not provide a mechanism to distribute the revocation list it is still easier to create the revocation list and distribute it by other means then to change the CA keys and all host and user certificates previously created and distributed.

Keys can be revoked by adding them to the revoked_keys file and specifying the file name in the sshd_config file as follows:

Note that if this file is not readable, then public key authentication will be refused for all users.

A new key revocation list can be generated as follows:

To add lines to the list, use the -u option to update the list:

where integer is the line number.

To test if a key has been revoked, query the revocation list for the presence of the key. Use a command as follows:

A user can revoke a CA certificate by changing the cert-authority directive to revoke in the known_hosts file.

The ssh utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the rlogin, rsh, and telnet programs.

Similarly to the telnet command, log in to a remote machine by using the following command:

For example, to log in to a remote machine named penguin.example.com, type the following at a shell prompt:

This will log you in with the same user name you are using on the local machine. If you want to specify a different user name, use a command in the following form:

For example, to log in to penguin.example.com as USER, type:

The first time you initiate a connection, you will be presented with a message similar to this:

Users should always check if the fingerprint is correct before answering the question in this dialog. The user can ask the administrator of the server to confirm the key is correct. This should be done in a secure and previously agreed way. If the user has access to the server’s host keys, the fingerprint can be checked by using the ssh-keygen command as follows:

Type yes to accept the key and confirm the connection. You will see a notice that the server has been added to the list of known hosts, and a prompt asking for your password:

After entering the password, you will be provided with a shell prompt for the remote machine.

Alternatively, the ssh program can be used to execute a command on the remote machine without logging in to a shell prompt:

For example, the /etc/redhat-release file provides information about the Fedora version. To view the contents of this file on penguin.example.com, type:

After you enter the correct password, the user name will be displayed, and you will return to your local shell prompt.

scp can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to rcp.

To transfer a local file to a remote system, use a command in the following form:

For example, if you want to transfer taglist.vim to a remote machine named penguin.example.com, type the following at a shell prompt:

Multiple files can be specified at once. To transfer the contents of .vim/plugin/ to the same directory on the remote machine penguin.example.com, type the following command:

To transfer a remote file to the local system, use the following syntax:

For instance, to download the .vimrc configuration file from the remote machine, type:

The sftp utility can be used to open a secure, interactive FTP session. In its design, it is similar to ftp except that it uses a secure, encrypted connection.

To connect to a remote system, use a command in the following form:

For example, to log in to a remote machine named penguin.example.com with USER as a user name, type:

After you enter the correct password, you will be presented with a prompt. The sftp utility accepts a set of commands similar to those used by ftp (see A selection of available sftp commands).

For a complete list of available commands, see the sftp(1) manual page.

To open an X11 session over an SSH connection, use a command in the following form:

For example, to log in to a remote machine named penguin.example.com with USER as a user name, type:

When an X program is run from the secure shell prompt, the SSH client and server create a new secure channel, and the X program data is sent over that channel to the client machine transparently.

Note that the X Window system must be installed on the remote system before X11 forwarding can take place. Enter the following command as root to install the X11 package group:

X11 forwarding can be very useful. For example, X11 forwarding can be used to create a secure, interactive session of the Print Settings utility. To do this, connect to the server using ssh and type:

The Print Settings tool will appear, allowing the remote user to safely configure printing on the remote system.

SSH can secure otherwise insecure TCP/IP protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client.

Port forwarding works by mapping a local port on the client to a remote port on the server. SSH can map any port from the server to any port on the client. Port numbers do not need to match for this technique to work.

To create a TCP/IP port forwarding channel which listens for connections on the localhost, use a command in the following form:

For example, to check email on a server called mail.example.com using POP3 through an encrypted connection, use the following command:

Once the port forwarding channel is in place between the client machine and the mail server, direct a POP3 mail client to use port 1100 on the localhost to check for new email. Any requests sent to port 1100 on the client system will be directed securely to the mail.example.com server.

If mail.example.com is not running an SSH server, but another machine on the same network is, SSH can still be used to secure part of the connection. However, a slightly different command is necessary:

In this example, POP3 requests from port 1100 on the client machine are forwarded through the SSH connection on port 22 to the SSH server, other.example.com. Then, other.example.com connects to port 110 on mail.example.com to check for new email. Note that when using this technique, only the connection between the client system and other.example.com SSH server is secure.

Port forwarding can also be used to get information securely through network firewalls. If the firewall is configured to allow SSH traffic via its standard port (that is, port 22) but blocks access to other ports, a connection between two hosts using the blocked ports is still possible by redirecting their communication over an established SSH connection.