Documentation for a newer release is available. View Latest

OpenSSH

SSH (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as FTP, Telnet, or rlogin, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.

The ssh program is designed to replace older, less secure terminal applications used to log into remote hosts, such as telnet or rsh. A related program called scp replaces older programs designed to copy files between hosts, such as rcp. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.

Fedora includes the general OpenSSH package, openssh, as well as the OpenSSH server, openssh-server, and client, openssh-clients, packages. Note, the OpenSSH packages require the OpenSSL package openssl-libs, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.

The SSH Protocol

Why Use SSH?

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:

Interception of communication between two systems: The attacker can be somewhere on the network between the communicating parties, copying any information passed between them. He may intercept and keep the information, or alter the information and send it on to the intended recipient.

This attack is usually performed using a packet sniffer, a rather common network utility that captures each packet flowing through the network, and analyzes its content.
Impersonation of a particular host: Attacker’s system is configured to pose as the intended recipient of a transmission. If this strategy works, the user’s system remains unaware that it is communicating with the wrong host.

This attack can be performed using a technique known as DNS poisoning, or via so-called IP spoofing. In the first case, the intruder uses a cracked DNS server to point client systems to a maliciously duplicated host. In the second case, the intruder sends falsified network packets that appear to be from a trusted host.

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.

Main Features

The SSH protocol provides the following safeguards:

No one can pose as the intended server: After an initial connection, the client can verify that it is connecting to the same server it had connected to previously.
No one can capture the authentication information: The client transmits its authentication information to the server using strong encryption.
No one can intercept the communication: All data sent and received during a session is transferred using strong encryption, making intercepted transmissions extremely difficult to decrypt and read.

Additionally, it also offers the following options:

It provides secure means to use graphical applications over a network: Using a technique called X11 forwarding, the client can forward X11 (X Window System) applications from the server. Note that if you set the ForwardX11Trusted option to yes or you use SSH with the -Y option, you bypass the X11 SECURITY extension controls, which can result in a security threat.
It provides a way to secure otherwise insecure protocols: The SSH protocol encrypts everything it sends and receives. Using a technique called port forwarding, an SSH server can become a conduit to securing otherwise insecure protocols, like POP, and increasing overall system and data security.
It can be used to create a secure channel: The OpenSSH server and client can be configured to create a tunnel similar to a virtual private network for traffic between server and client machines.
It supports Kerberos authentication: OpenSSH servers and clients can be configured to authenticate using the GSSAPI (Generic Security Services Application Program Interface) implementation of the Kerberos network authentication protocol.

Protocol Versions

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. Protocol version 1 was removed from OpenSSH suite and is no longer supported.

Event Sequence of an SSH Connection

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

A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
The transport layer of the connection between the client and remote host is encrypted using a symmetric cipher.
The client authenticates itself to the server.
The client interacts with the remote host over the encrypted connection.

Transport Layer

The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.

Once an SSH client contacts a server, key information is exchanged so that the two systems can correctly construct the transport layer. The following steps occur during this exchange:

The key exchange algorithm is determined
The public key signature algorithm is determined
The symmetric encryption algorithm is determined
The message authentication algorithm is determined
Keys are exchanged

During the key exchange, the server identifies itself to the client with a unique host key. If the client has never communicated with this particular server before, the server’s host key is unknown to the client and it does not connect. OpenSSH notifies the user that the authenticity of the host cannot be established and prompts the user to accept or reject it. The user is expected to independently verify the new host key before accepting it. In subsequent connections, the server’s host key is checked against the saved version on the client, providing confidence that the client is indeed communicating with the intended server. If, in the future, the host key no longer matches, the user must remove the client’s saved version before a connection can occur.

Always verify the integrity of a new SSH server

It is possible for an attacker to masquerade as an SSH server during the initial contact since the local system does not know the difference between the intended server and a false one set up by an attacker. To help prevent this, verify the integrity of a new SSH server by contacting the server administrator before connecting for the first time or in the event of a host key mismatch.

SSH is designed to work with almost any kind of public key algorithm or encoding format. After an initial key exchange creates a hash value used for exchanges and a shared secret value, the two systems immediately begin calculating new keys and algorithms to protect authentication and future data sent over the connection.

After a certain amount of data has been transmitted using a given key and algorithm (the exact amount depends on the SSH implementation, encryption algorithm and configuration), another key exchange occurs, generating another set of hash values and a new shared secret value. Even if an attacker is able to determine the hash and shared secret value, this information is only useful for a limited period of time.

Authentication

Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.

SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.

Channels

After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called multiplexing^[1]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.

Both clients and servers can create a new channel. Each channel is then assigned a different number on each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions do not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection.

Channels also support flow-control, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the client receives a message that the channel is open.

The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.

Configuring OpenSSH

In order to perform tasks described in this section, you must have superuser privileges. To obtain them, log in as root by typing:

su -

Configuration Files

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.

Table 1. System-wide configuration files
File	Description
`/etc/ssh/moduli`	Contains Diffie-Hellman groups used for the "Diffie-Hellman group exchange" key exchange method, which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. If the file is not available, fixed groups will be used. Other key exchange methods do not need this file.
`/etc/ssh/ssh_config`	The default SSH client configuration file. Note that it is overridden by `~/.ssh/config` if it exists.
`/etc/ssh/sshd_config`	The configuration file for the sshd daemon.
`/etc/ssh/ssh_host_ecdsa_key`	The ECDSA private key used by the sshd daemon.
`/etc/ssh/ssh_host_ecdsa_key.pub`	The ECDSA public key used by the sshd daemon.
`/etc/ssh/ssh_host_rsa_key`	The RSA private key used by the sshd daemon.
`/etc/ssh/ssh_host_rsa_key.pub`	The RSA public key used by the sshd daemon.
`/etc/ssh/ssh_host_ed25519_key`	The EdDSA private key used by the sshd daemon.
`/etc/ssh/ssh_host_ed25519_key.pub`	The EdDSA public key used by the sshd daemon.
`/etc/pam.d/sshd`	The PAM configuration file for the sshd daemon.
`/etc/sysconfig/sshd`	Configuration file for the `sshd` service.

Table 2. User-specific configuration files
File	Description
`~/.ssh/authorized_keys`	Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file.
`~/.ssh/id_ecdsa`	Contains the ECDSA private key of the user.
`~/.ssh/id_ecdsa.pub`	The ECDSA public key of the user.
`~/.ssh/id_rsa`	The RSA private key used by ssh.
`~/.ssh/id_rsa.pub`	The RSA public key used by ssh.
`~/.ssh/id_ed25519`	The EdDSA private key used by ssh.
`~/.ssh/id_ed25519.pub`	The EdDSA public key used by ssh.
`~/.ssh/known_hosts`	Contains host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting to the correct SSH server.

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.

Starting an OpenSSH Server

Make sure you have relevant packages installed

To run an OpenSSH server, you must have the openssh-server package installed. See Installing Packages for more information on how to install new packages in Fedora 34.

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

~]# systemctl start sshd.service

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

~]# systemctl stop sshd.service

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

~]# systemctl enable sshd.service
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

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:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.

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.

Requiring SSH for Remote Connections

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:

systemctl stop telnet.service
systemctl stop rsh.service
systemctl stop rlogin.service
systemctl stop vsftpd.service

To disable running these services at startup, type:

systemctl disable telnet.service
systemctl disable rsh.service
systemctl disable rlogin.service
systemctl disable vsftpd.service

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

Using Key-based Authentication

To improve the system security even further, generate SSH key pairs and then enforce key-based authentication by disabling password authentication. To do so, create a drop-in configuration file, for example /etc/ssh/sshd_config.d/01-local.conf. Make sure it is lexicographically before the 50-redhat.conf file, providing Fedora defaults. In a text editor such as vi or nano insert the PasswordAuthentication option as follows:

PasswordAuthentication no

If you are working on a system other than a new default installation, check that PubkeyAuthentication no has not been set in neither /etc/ssh/sshd_config nor any included file from drop-in directory. 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 34 uses SSH Protocol 2 and RSA keys by default (see Protocol Versions for more information).

Do not generate key pairs as root

If you complete the steps as root, only root will be able to use the keys.

Backup your ~/.ssh/ directory

If you reinstall your system and want to keep previously generated key pairs, backup the ~/.ssh/ directory. After reinstalling, copy it back to your home directory. This process can be done for all users on your system, including root.

Generating Key Pairs

To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:

Generate an RSA key pair by typing the following at a shell prompt:

~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_rsa):

Press Enter to confirm the default location, ~/.ssh/id_rsa, for the newly created key.

Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.

After this, you will be presented with a message similar to this:

Your identification has been saved in /home/USER/.ssh/id_rsa.
Your public key has been saved in /home/USER/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|             E.  |
|            . .  |
|             o . |
|              . .|
|        S .    . |
|         + o o ..|
|          * * +oo|
|           O +..=|
|           o*  o.|
+-----------------+

By default, the permissions of the ~/.ssh/ directory are set to rwx------ or 700 expressed in octal notation. This is to ensure that only the USER can view the contents. If required, this can be confirmed with the following command:
```
~]$ ls -ld ~/.ssh
drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
```
To copy the public key to a remote machine, issue a command in the following format:
```
 ssh-copy-id user@hostname
```
This will copy the most recently modified ~/.ssh/id*.pub public key if it is not yet installed. Alternatively, specify the public key’s file name as follows:
```
ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname
```
This will copy the content of ~/.ssh/id_rsa.pub into the ~/.ssh/authorized_keys file on the machine to which you want to connect. If the file already exists, the keys are appended to its end.

To generate an ECDSA key pair for version 2 of the SSH protocol, follow these steps:

Generate an ECDSA key pair by typing the following at a shell prompt:

~]$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_ecdsa):

Press Enter to confirm the default location, ~/.ssh/id_ecdsa, for the newly created key.

Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.

After this, you will be presented with a message similar to this:

Your identification has been saved in /home/USER/.ssh/id_ecdsa.
Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com
The key's randomart image is:
+--[ECDSA  256]---+
|       .+ +o     |
|       . =.o     |
|        o o +  ..|
|         + + o  +|
|        S o o oE.|
|           + oo+.|
|            + o  |
|                 |
|                 |
+-----------------+

By default, the permissions of the ~/.ssh/ directory are set to rwx------ or 700 expressed in octal notation. This is to ensure that only the USER can view the contents. If required, this can be confirmed with the following command:
```
~]$ ls -ld ~/.ssh
              ~]$ ls -ld ~/.ssh/
drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
```
To copy the public key to a remote machine, issue a command in the following format:
```
ssh-copy-id USER@hostname
```
This will copy the most recently modified ~/.ssh/id*.pub public key if it is not yet installed. Alternatively, specify the public key’s file name as follows:
```
ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
```
This will copy the content of ~/.ssh/id_ecdsa.pub into the ~/.ssh/authorized_keys on the machine to which you want to connect. If the file already exists, the keys are appended to its end.

See Configuring ssh-agent for information on how to set up your system to remember the passphrase.

Never share your private key

The private key is for your personal use only, and it is important that you never give it to anyone.

Configuring ssh-agent

To store your passphrase so that you do not have to enter it each time you initiate a connection with a remote machine, you can use the ssh-agent authentication agent.

To save your passphrase for a certain shell prompt, use the following command:

~]$ ssh-add
Enter passphrase for /home/USER/.ssh/id_rsa:

Note that when you log out, your passphrase will be forgotten. You must execute the command each time you log in to a virtual console or a terminal window.

Using OpenSSH Certificate Authentication

Introduction to SSH Certificates

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,