goroboro/user-documentation
0
0
Fork 0
forked from server/user-documentation
Code Pull requests Activity

Add topics for SSH Administration.

Browse source 
These topics are effectively a migration of content from:
https://forge.fedoraproject.org/docs-archive/sysadmin-guide/src/branch/main/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc
The intention here is to create Server Administration documentation about OpenSSH. In this pass, the original topic is migrated and chunked into 4 topics that can be separated out if needed. The content remains largely faithful to the original text, but I have inserted some comment blocks as placeholders for additional content that I intend to add at a future date. The following key differences apply to the original topic:

1. The obvious chunking is applied to separate the content into logical groupings, as part of this I corrected some xrefs so that they would continue to work, and also updated some of the topic titles so that they would make sense in the structure.
2. In SSH-Advanced-Usage.adoc, I removed a small section that referenced Fedora 13 and which just seemed completely obsolete and redundant. The section was previously named "Support for SSH Certificates".
3. In SSH-Advanced-Usage.adoc, I changed the directory listing for outputs to the command: ls -l /etc/ssh/ssh_host* -- I did this because the outputs showed SSH 1 keys and DSA keys, which just aren't supported any more. So the output just looked really wrong.

Other than these changes, I haven't changed text or performed extensive validation, yet.

I intend to do significant rework on this content in a separate set of PRs.
This commit is contained in:
Rowan Puttergill 2026-06-15 15:02:51 +01:00
commit b4e0cc12f6
4 changed files with 1464 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

136
modules/ROOT/pages/administration/SSH-About.adoc Normal file
View file

@ -0,0 +1,136 @@
= About SSH and OpenSSH
The Fedora Docs team
:revdate: 2026-06-12
:tags: SSH, Security, Access
[abstract]
`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 [command]#rlogin#, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
The [application]*ssh* program is designed to replace older, less secure terminal applications used to log into remote hosts, such as [command]#telnet# or [command]#rsh#. A related program called [command]#scp# replaces older programs designed to copy files between hosts, such as [command]#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, [package]*openssh*, as well as the OpenSSH server, [package]*openssh-server*, and client, [package]*openssh-clients*, packages. Note, the OpenSSH packages require the OpenSSL package [package]*openssl-libs*, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
[[s2-ssh-why]]
== Why Use SSH?
indexterm:[SSH protocol,security risks]
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.
[[s2-ssh-features]]
== Main Features
indexterm:[SSH protocol,features]indexterm:[OpenSSH,SSH]
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 [option]`ForwardX11Trusted` option to `yes` or you use SSH with the [option]`-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.
[[s2-ssh-versions]]
== Protocol Versions
indexterm:[SSH protocol,version 1]indexterm:[SSH protocol,version 2]
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.
[[s2-ssh-conn]]
== Event Sequence of an SSH Connection
indexterm:[SSH protocol,connection sequence]
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.
[[s2-ssh-protocol-conn-transport]]
=== Transport Layer
indexterm:[SSH protocol,layers,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
[WARNING]
====
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.
[[s2-ssh-protocol-authentication]]
=== Authentication
indexterm:[SSH protocol,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.
[[s2-ssh-protocol-connection]]
=== Channels
indexterm:[SSH protocol,layers,channels]
After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called _multiplexing_pass:attributes[{blank}]footnote:[A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.]. 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.
////
[[s2-ssh-key-types]]
== SSH Host and User Key Types
NOTE: This section is a placeholder. It should give a conceptual overview of
the key algorithms referenced throughout these SSH topics (RSA, ECDSA, and
Ed25519) -- what they are, and current recommendations (Ed25519 is now
generally preferred over RSA and ECDSA for new keys). Practical steps for
generating user key pairs are covered in xref:SSH-Client.adoc[OpenSSH Client
Configuration], and the host key files generated by the server are listed in
xref:SSH-Server.adoc[OpenSSH Server Configuration].
////
[[s1-openssh-additional-resources]]
== Additional Resources
indexterm:[OpenSSH,additional resources]indexterm:[OpenSSL,additional resources]
For more information about the SSH protocol, see the resources listed below.
* link:++https://www.openssh.com/++[OpenSSH Home Page] — The OpenSSH home page containing further documentation, frequently asked questions, links to the mailing lists, bug reports, and other useful resources.
* link:++https://www.openssl.org/++[OpenSSL Home Page] — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.

706
modules/ROOT/pages/administration/SSH-Advanced-Usage.adoc Normal file
View file

@ -0,0 +1,706 @@
= Advanced SSH Usage
The Fedora Docs team
:revdate: 2026-06-12
:tags: SSH, Security, Access
[abstract]
This topic walks through common SSH use cases that combine server-side configuration with client-side commands: certificate-based authentication, X11 forwarding, and port forwarding. It focuses on example configuration and commands for typical scenarios -- for complete directive and option references, see xref:SSH-Server.adoc[OpenSSH Server Configuration] and xref:SSH-Client.adoc[OpenSSH Client Configuration]. For background on the SSH protocol, see xref:SSH-About.adoc[About SSH and OpenSSH].
[[sec-Using_OpenSSH_Certificate_Authentication]]
== Use Case: SSH Certificate Authentication
[[sec-Introduction_to_SSH_Certificates]]
=== 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, 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 [command]#ssh-keygen# utility. The format of the certificate is described in `/usr/share/doc/openssh-_version_pass:attributes[{blank}]/PROTOCOL.certkeys`.
The [command]#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.
[[sec-Creating_SSH_CA_Certificate_Signing-Keys]]
=== Creating SSH CA Certificate Signing Keys
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:
[subs="macros"]
----
ssh-keygen -s ca_user_key -I pass:quotes[_certificate_ID_] id_rsa.pub
----
Where [option]`-s` indicates the private key used to sign the certificate, [option]`-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 [option]`-h` option:
[subs="macros"]
----
ssh-keygen -s ca_host_key -I pass:quotes[_certificate_ID_] -h ssh_host_rsa_key.pub
----
Host keys are generated on the system by default, to list the keys, enter a command as follows:
----
~]# ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root 480 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root 162 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-------. 1 root root 387 May 13 16:11 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root 82 May 13 16:11 /etc/ssh/ssh_host_ed25519_key.pub
-rw-------. 1 root root 2578 May 13 16:11 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root 554 May 13 16:11 /etc/ssh/ssh_host_rsa_key.pub
----
[IMPORTANT]
====
It is recommended to create and store CA keys in a safe place just as with any other private key. In these examples the `root` user will be used. In a real production environment using an offline computer with an administrative user account is recommended. For guidance on key lengths see [citetitle]_link:++https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf++[NIST Special Publication 800-131A Revision 1]_.
====
[[proc-Generating_SSH_CA_Certificate_Signing-Keys]]
.Generating SSH CA Certificate Signing Keys
. On the server designated to be the CA, generate two keys for use in signing certificates. These are the keys that all other hosts need to trust. Choose suitable names, for example `ca_user_key` and `ca_host_key`. To generate the user certificate signing key, enter the following command as `root`:
+
----
~]# ssh-keygen -t rsa -f ~/.ssh/ca_user_key
Generating public/private rsa key pair.
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ca_user_key.
Your public key has been saved in /root/.ssh/ca_user_key.pub.
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
The key's randomart image is:
+--[ RSA 2048]----+
| .+. o|
| . o +.|
| o + . . o|
| o + . . ..|
| S . ... *|
| . . . .*.|
| = E .. |
| . o . |
| . |
+-----------------+
----
+
Generate a host certificate signing key, `ca_host_key`, as follows:
+
----
~]# ssh-keygen -t rsa -f ~/.ssh/ca_host_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/ca_host_key.
Your public key has been saved in /root/.ssh/ca_host_key.pub.
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
The key's randomart image is:
+--[ RSA 2048]----+
| .. |
| . ....|
| . . o +oo|
| o . o *o|
| S = .|
| o. .|
| *.E. |
| +o= |
| .oo. |
+-----------------+
----
+
If required, confirm the permissions are correct:
+
----
~]# ls -la ~/.ssh
total 40
drwxrwxrwx. 2 root root 4096 May 22 13:18 .
dr-xr-x---. 3 root root 4096 May 8 08:34 ..
-rw-------. 1 root root 1743 May 22 13:15 ca_host_key
-rw-r--r--. 1 root root 420 May 22 13:15 ca_host_key.pub
-rw-------. 1 root root 1743 May 22 13:14 ca_user_key
-rw-r--r--. 1 root root 420 May 22 13:14 ca_user_key.pub
-rw-r--r--. 1 root root 854 May 8 05:55 known_hosts
-r--------. 1 root root 1671 May 6 17:13 ssh_host_rsa
-rw-r--r--. 1 root root 1370 May 7 14:30 ssh_host_rsa-cert.pub
-rw-------. 1 root root 420 May 6 17:13 ssh_host_rsa.pub
----
. Create the CA server's own host certificate by signing the server's host public key together with an identification string such as the host name, the CA server's _fully qualified domain name_ (*FQDN*) but without the trailing `.`, and a validity period. The command takes the following form:
+
[subs="macros"]
----
ssh-keygen -s ~/.ssh/ca_host_key -I pass:quotes[_certificate_ID_] -h -n pass:quotes[_host_name.example.com_] -V pass:quotes[_-start:+end_] /etc/ssh/ssh_host_rsa.pub
----
+
The [option]`-n` option restricts this certificate to a specific host within the domain. The [option]`-V` option is for adding a validity period; this is highly recommend. Where the validity period is intended to be one year, fifty two weeks, consider the need for time to change the certificates and any holiday periods around the time of certificate expiry.
+
For example:
+
----
~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub
Enter passphrase:
Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2020-05-15T13:52:29 to 2021-06-08T13:52:29
----
[[sec-Distributing_and_Trusting_SSH_CA_Public_Keys]]
=== Distributing and Trusting SSH CA Public Keys
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:
[subs="macros"]
----
scp ~/.ssh/ca_user_key.pub root@pass:quotes[_host_name_].example.com:/etc/ssh/
----
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`:
----
~]# scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/
The authenticity of host 'host_name.example.com (10.34.74.56)' can't be established.
ECDSA key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'host_name.example.com,10.34.74.56' (ECDSA) to the list of known hosts.
root@host_name.example.com's password:
ca_user_key.pub 100% 420 0.4KB/s 00:00
----
For remote user authentication, CA keys can be marked as trusted per-user in the `~/.ssh/authorized_keys` file using the [command]#cert-authority# directive or for global use by means of the [command]#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.
[[proc-Trusting_the_User_Signing_Key]]
.Trusting the User Signing Key
. For user certificates which have one or more principles listed, and where the setting is to have global effect, edit the `/etc/ssh/sshd_config` file as follows:
+
----
TrustedUserCAKeys /etc/ssh/ca_user_key.pub
----
+
Restart `sshd` to make the changes take effect:
+
----
~]#{nbsp}systemctl restart sshd.service
----
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`.
[[proc-Trusting_the_Host_Signing_Key]]
.Trusting the Host Signing Key
. Extract the contents of the public key used to sign the host certificate. For example, on the CA:
+
[subs="macros"]
----
cat ~/.ssh/ca_host_key.pub
ssh-rsa pass:quotes[_AAAAB5Wm._]== root@ca-server.example.com
----
. To configure client systems to trust servers' signed host certificates, add the contents of the `ca_host_key.pub` into the global `known_hosts` file. This will automatically check a server's host advertised certificate against the CA public key for all users every time a new machine is connected to in the domain `*.example.com`. Login as `root` and configure the `/etc/ssh/ssh_known_hosts` file, as follows:
+
[subs="macros"]
----
~]# vi /etc/ssh/ssh_known_hosts
# A CA key, accepted for any host in *.example.com
@cert-authority *.example.com ssh-rsa pass:quotes[_AAAAB5Wm._]
----
+
Where `ssh-rsa _AAAAB5Wm._pass:attributes[{blank}]` is the contents of `ca_host_key.pub`. The above configures the system to trust the CA servers host public key. This enables global authentication of the certificates presented by hosts to remote users.
[[sec-Signing_SSH_Certificates]]
=== Creating SSH Certificates
A certificate 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.
[IMPORTANT]
====
Copying many keys to the CA to be signed can create confusion if they are not uniquely named. If the default name is always used then the latest key to be copied will overwrite the previously copied key, which may be an acceptable method for one administrator. In the example below the default name is used. In a production environment, consider using easily recognizable names. It is recommend to have a designated directory on the CA server owned by an administrative user for the keys to be copied into. Copying these keys to the `root` user's `/etc/ssh/` directory is not recommend. In the examples below an account named `admin` with a directory named `keys/` will be used.
====
Create an administrator account, in this example `admin`, and a directory to receive the user's keys. For example:
[subs="quotes, macros"]
----
~]$ [command]#mkdir keys#
----
Set the permissions to allow keys to be copied in:
----
~]$ chmod o+w keys
ls -la keys
total 8
drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
drwx------. 3 admin admin 4096 May 22 16:17 ..
----
[[sec-Creating_SSH_Certificates_to_Authenticate_Hosts]]
==== Creating SSH Certificates to Authenticate Hosts
The command to sign a host certificate has the following format:
[subs="macros"]
----
ssh-keygen -s ca_host_key -I pass:quotes[_host_name_] -h ssh_host_rsa_key.pub
----
The host certificate will named `ssh_host_rsa_key-cert.pub`.
[[proc-Generating_a_Host_Certificate]]
.Generating a Host Certificate
To authenticate a host to a user, a public key must be generated on the host, passed to the CA server, signed by the CA, and then passed back to be stored on the host to present to a user attempting to log into the host.
. Host keys are generated automatically on the system. To list them enter the following command:
+
----
~]# ls -l /etc/ssh/ssh_host*
-rw-------. 1 root root 480 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root 162 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-------. 1 root root 387 May 13 16:11 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root 82 May 13 16:11 /etc/ssh/ssh_host_ed25519_key.pub
-rw-------. 1 root root 2578 May 13 16:11 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root 554 May 13 16:11 /etc/ssh/ssh_host_rsa_key.pub
----
. Copy the chosen public key to the server designated as the CA. For example, from the host:
+
----
~]# scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub
The authenticity of host 'ca-server.example.com (10.34.74.58)' can't be established.
ECDSA key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
admin@ca-server.example.com's password:
ssh_host_rsa_key.pub 100% 382 0.4KB/s 00:00
----
+
Alternately, from the CA:
+
----
~]$ scp root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub
----
. On the CA server, sign the host's public key. For example, as `root`:
+
----
~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub
Enter passphrase:
Signed host key /home/admin/keys/ssh_host_rsa_key-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2020-05-26T12:21:54 to 2021-06-08T12:21:54
----
+
Where _host_name_ is the host name of the system requiring the certificate.
. Copy the certificate to the host. For example, from the CA:
+
----
~]# scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/
root@host_name.example.com's password:
ssh_host_rsa_key-cert.pub 100% 1384 1.5KB/s 00:00
----
. Configure the host to present the certificate to a user's system when a user initiates the login process. As `root`, edit the `/etc/ssh/sshd_config` file as follows:
+
----
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
----
. Restart `sshd` to make the changes take effect:
+
----
~]#{nbsp}systemctl restart sshd.service
----
. On user's systems, remove keys belonging to hosts from the `~/.ssh/known_hosts` file if the user has previously logged into the host configured above. When a user logs into the host they should no longer be presented with the warning about the hosts authenticity.
To test the host certificate, on a client system, ensure the client has set up the global `/etc/ssh/known_hosts` file, as described in xref:proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key], and that the server's public key is not in the `~/.ssh/known_hosts` file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the [option]`-v` option to the SSH command to see logging information.
[[sec-Creating_SSH_Certificates_for_Authenticating_Users]]
==== Creating SSH Certificates for Authenticating Users
To sign a user's certificate, use a command in the following format:
[subs="macros"]
----
ssh-keygen -s ca_user_key -I pass:quotes[_user_name_] -n pass:quotes[_user_name_] -V pass:quotes[_-start:+end_] id_rsa.pub
----
The resulting certificate will be named `id_rsa-cert.pub`.
The default behavior of OpenSSH is that a user is allowed to log in as a remote user if one of the principals specified in the certificate matches the remote user's name. This can be adjusted in the following ways:
* Add more user's names to the certificate during the signing process using the [option]`-n` option:
+
[subs="quotes"]
----
-n "name1[,name2,...]"
----
* On the user's system, add the public key of the CA in the `~/.ssh/authorized_keys` file using the [command]#cert-authority# directive and list the principals names as follows:
+
[subs="macros"]
----
~]# vi ~/.ssh/authorized_keys
# A CA key, accepted for any host in *.example.com
@cert-authority principals="name1,name2" *.example.com ssh-rsa pass:quotes[_AAAAB5Wm._]
----
* On the server, create an `AuthorizedPrincipalsFile` file, either per user or globally, and add the principles' names to the file for those users allowed to log in. Then in the `/etc/ssh/sshd_config` file, specify the file using the [command]#AuthorizedPrincipalsFile# directive.
[[proc-Generating_a_User_Certificate]]
.Generating a User Certificate
To authenticate a user to a remote host, a public key must be generated by the user, passed to the CA server, signed by the CA, and then passed back to be stored by the user for use when logging in to a host.
. On client systems, login as the user who requires the certificate. Check for available keys as follows:
+
[subs="quotes, macros"]
----
~]$ [command]#ls -l ~/.ssh/#
----
+
If no suitable public key exists, generate one and set the directory permissions if the directory is not the default directory. For example, enter the following command:
+
----
~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
Created directory '/home/user1/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 user1@host1.example.com
The key's randomart image is:
+--[ RSA 2048]----+
| oo++. |
| o.o.o. |
| .o o . |
| oo . o |
| . oo.S |
| o=.. |
| .Eo+ |
| .= |
| .. |
+-----------------+
----
+
By default the directory permissions for a user's keys are `drwx------.`, or octal 0700. If required, confirm the permissions are correct:
+
----
~]$ ls -la ~/.ssh
total 16
drwx------. 2 user1 user1 4096 May 7 12:37 .
drwx------. 3 user1 user1 4096 May 7 12:37 ..
-rw-------. 1 user1 user1 1679 May 7 12:37 id_rsa
-rw-r--r--. 1 user1 user1 421 May 7 12:37 id_rsa.pub
----
+
See xref:SSH-Client.adoc#s3-ssh-configuration-keypairs-generating[Generating Key Pairs] in xref:SSH-Client.adoc[OpenSSH Client Configuration] for more examples of key generation and for instructions on setting the correct directory permissions.
. The chosen public key must be copied to the server designated as the CA, in order to be signed. The secure copy command can be used to do this, the command has the following format:
+
[subs="macros"]
----
scp ~/.ssh/id_pass:quotes[_protocol_].pub pass:quotes[_admin_]@ca_server.example.com:~/keys/
----
+
Where _protocol_ is the part of the file name indicating the protocol used to generate the key, for example `rsa`, _admin_ is an account on the CA server, and _/keys/_ is a directory setup to receive the keys to be signed.
+
Copy the chosen public key to the server designated as the CA. For example:
+
----
~]$ scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/
admin@ca-server.example.com's password:
id_rsa.pub 100% 421 0.4KB/s 00:00
----
+
If you have configured the client system to trust the host signing key as described in xref:proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key] then you should not see a warning about the authenticity of the remote host.
. On the CA server, sign the user's public key. For example, as `root`:
+
----
~]# ssh-keygen -s ~/.ssh/ca_user_key -I user1 -n user1 -V -1d:+54w /home/admin/keys/id_rsa.pub
Enter passphrase:
Signed user key /home/admin/keys/id_rsa-cert.pub: id "user1" serial 0 for host_name.example.com valid from 2020-05-21T16:43:17 to 2021-06-03T16:43:17
----
. Copy the resulting certificate to the user's `~/.ssh/` directory on their system. For example:
+
----
~]# scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/
user1@host_name.example.com's password:
id_rsa-cert.pub 100% 1498 1.5KB/s 00:00
----
. If using the standard file names and location then no further configuration is required as the SSH daemon will search for user certificates ending in `-cert.pub` and use them automatically if it finds them. Note that the default location and file names for for SSH version 2 keys are: `~/.ssh/id_dsa`, `~/.ssh/id_ecdsa` and `~/.ssh/id_rsa` as explained in the `ssh_config(5)` manual page. If you use these locations and naming conventions then there is no need for editing the configuration files to enable `sshd` to present the certificate. They will be used automatically when logging in to a remote system. In this is the case then skip to step 6.
+
If required to use a non-default directory or file naming convention, then as `root`, add the following line to the `/etc/ssh/ssh_config` or `~/.ssh/config` files:
+
[subs="macros"]
----
IdentityFile pass:quotes[_~/path/key_file_]
----
+
Note that this must be the private key name, do not had `.pub` or `-cert.pub`.
Ensure the file permission are correct. For example:
+
[subs="quotes, macros, attributes"]
----
~]$ [command]#ls -la ~/.ssh/config#
-rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
[command]#chmod 700 ~/.ssh/config#
~]$ [command]#ls -la ~/.ssh/config#
-rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
----
+
This will enable the user of this system to be authenticated by a user certificate when logging into a remote system configured to trust the CA user certificate signing key.
. To test the user certificate, attempt to log into a server over SSH from the user's account. You should do this as the user listed as a principle in the certificate, if any are specified. You should not be prompted for a password. If required, add the [option]`-v` option to the SSH command to see logging information.
[[sec-SSH_Certificate_PKCS_11_Token]]
=== Signing an SSH Certificate Using a PKCS#11 Token
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 [option]`-D` and identifying the CA key by providing its public half as an argument to the [option]`-s` option:
[subs="macros"]
----
ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I pass:quotes[_certificate_ID_] host_key.pub
----
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 [option]`-n` option as follows:
[subs="macros"]
----
ssh-keygen -s ca_user_key.pub -D libpkcs11.so -I pass:quotes[_certificate_ID_] -n pass:quotes[_user1,user2_] id_rsa.pub
----
and for hosts:
[subs="macros"]
----
ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I pass:quotes[_certificate_ID_] -h -n host.domain ssh_host_rsa_key.pub
----
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 [option]`-O` option.
Certificates may be defined to be valid for a specific lifetime. The [option]`-V` option allows specifying a certificates
start and end times. For example:
[subs="macros"]
----
ssh-keygen -s ca_user_key -I pass:quotes[_certificate_ID_] -V "-1w:+54w5d" id_rsa.pub
----
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.
[[sec-Viewing_an_SSH_CA_Certificate]]
=== Viewing an SSH CA Certificate
To view a certificate, use the [option]`-L` to list the contents. For example, for a user's certificate:
----
~]$ ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub
/home/user1/.ssh/id_rsa-cert.pub:
Type: ssh-rsa-cert-v01@openssh.com user certificate
Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
Key ID: "user1"
Serial: 0
Valid: from 2020-05-27T00:09:16 to 2021-06-09T00:09:16
Principals:
user1
Critical Options: (none)
Extensions:
permit-X11-forwarding
permit-agent-forwarding
permit-port-forwarding
permit-pty
permit-user-rc
----
To view a host certificate:
----
~]# ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub
/etc/ssh/ssh_host_rsa_key-cert.pub:
Type: ssh-rsa-cert-v01@openssh.com host certificate
Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
Key ID: "host_name"
Serial: 0
Valid: from 2020-05-26T17:19:01 to 2021-06-08T17:19:01
Principals:
host_name.example.com
Critical Options: (none)
Extensions: (none)
----
[[sec-Revoking_an_SSH_CA_Certificate]]
=== Revoking an SSH CA 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:
----
RevokedKeys /etc/ssh/revoked_keys
----
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:
----
~]$ ssh-keygen -kf /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub
----
To add lines to the list, use the [option]`-u` option to update the list:
[subs="macros"]
----
ssh-keygen -ukf /etc/ssh/revoked_keys -z pass:quotes[_integer_] ~/.ssh/id_rsa.pub
----
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:
----
ssh-keygen -Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub
----
A user can revoke a CA certificate by changing the [command]#cert-authority# directive to [command]#revoke# in the `known_hosts` file.
== Use Case: X11 and Port Forwarding
A secure command line interface is just the beginning of the many ways SSH can be used. Given the proper amount of bandwidth, X11 sessions can be directed over an SSH channel. Or, by using TCP/IP forwarding, previously insecure port connections between systems can be mapped to specific SSH channels.
[[s2-ssh-beyondshell-x11]]
=== X11 Forwarding
indexterm:[SSH protocol,X11 forwarding]
To open an X11 session over an SSH connection, use a command in the following form:
[subs="quotes, macros"]
----
[command]#ssh -Y _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_pass:attributes[{blank}]#
----
For example, to log in to a remote machine named `penguin.example.com` with `USER` as a user name, type:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#ssh -Y USER@penguin.example.com#
USER@penguin.example.com's password:
----
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: For X11 forwarding to work, the SSH server must allow it. Ensure `X11Forwarding yes` is set in `/etc/ssh/sshd_config` (see xref:SSH-Server.adoc[OpenSSH Server Configuration])
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:
----
~]# dnf group install "X Window System"
----
X11 forwarding can be very useful. For example, X11 forwarding can be used to create a secure, interactive session of the [application]*Print Settings* utility. To do this, connect to the server using [application]*ssh* and type:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#system-config-printer &#
----
The [application]*Print Settings* tool will appear, allowing the remote user to safely configure printing on the remote system.
[[s2-ssh-beyondshell-tcpip]]
=== Local Port Forwarding (-L)
indexterm:[SSH protocol,port forwarding]
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.
.Using reserved port numbers
[NOTE]
====
Setting up port forwarding to listen on ports below 1024 requires `root` level access.
====
To create a TCP/IP port forwarding channel which listens for connections on the `localhost`, use a command in the following form:
[subs="quotes, macros"]
----
[command]#ssh -L _local-port_:pass:attributes[{blank}]_remote-hostname_:pass:attributes[{blank}]_remote-port_ _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_pass:attributes[{blank}]#
----
For example, to check email on a server called `mail.example.com` using `POP3` through an encrypted connection, use the following command:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#ssh -L 1100:mail.example.com:110 mail.example.com#
----
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:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#ssh -L 1100:mail.example.com:110 other.example.com#
----
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.
.A connection is only as secure as a client system
[IMPORTANT]
====
Using port forwarding to forward connections in this manner allows any user on the client system to connect to that service. If the client system becomes compromised, the attacker also has access to forwarded services.
System administrators concerned about port forwarding can disable this functionality on the server by specifying a [option]`No` parameter for the [option]`AllowTcpForwarding` line in `/etc/ssh/sshd_config` and restarting the [command]#sshd# service.
====
////
=== Remote Port Forwarding (-R)
NOTE: This section is a placeholder. It should cover `ssh -R _remote-port_:_local-host_:_local-port_ _user_@_hostname_` to expose a local (or LAN-accessible) service to the remote host, and the server-side `GatewayPorts` directive needed if the forwarded port should be reachable from other hosts on the server's network.
////
////
=== Dynamic Port Forwarding / SOCKS Proxy (-D)
NOTE: This section is a placeholder. It should cover `ssh -D _local-port_ _user_@_hostname_` to turn the SSH client into a SOCKS proxy, and how to point a browser or other application at it.
////
////
== Use Case: Passwordless Login Setup
NOTE: This section is a placeholder. It should walk through the end-to-end flow of generating a key pair and copying it to a server with `ssh-copy-id` (see xref:SSH-Client.adoc#s2-ssh-client-keypairs[Generating and Managing SSH Keys] in xref:SSH-Client.adoc[OpenSSH Client Configuration]), then disabling password authentication on the server (see xref:SSH-Server.adoc#s2-ssh-configuration-keypairs[Enforcing Key-based Authentication] in xref:SSH-Server.adoc[OpenSSH Server Configuration]).
////
////
== Use Case: Jump Hosts (ProxyJump)
NOTE: This section is a placeholder. It should cover using `ssh -J _jumphost_ _destination_` (or the `ProxyJump` directive) to reach a host via an intermediate bastion/jump host, and reference the `~/.ssh/config` gap section in xref:SSH-Client.adoc[OpenSSH Client Configuration].
////
== See Also
* xref:SSH-About.adoc[About SSH and OpenSSH] -- conceptual background on the SSH protocol.
* xref:SSH-Server.adoc[OpenSSH Server Configuration] -- full reference for `sshd` and server-side configuration.
* xref:SSH-Client.adoc[OpenSSH Client Configuration] -- full reference for `ssh`, `scp`, `sftp`, and client-side configuration.

445
modules/ROOT/pages/administration/SSH-Client.adoc Normal file
View file

@ -0,0 +1,445 @@
= OpenSSH Client Configuration
The Fedora Docs team
:revdate: 2026-06-12
:tags: SSH, Security, Access
[abstract]
This topic covers connecting to OpenSSH servers using `ssh`, `scp`, and `sftp`, plus client-side configuration files and SSH key management. For server-side configuration, see xref:SSH-Server.adoc[OpenSSH Server Configuration]. For background on the SSH protocol, see xref:SSH-About.adoc[About SSH and OpenSSH].
.Make sure you have relevant packages installed
[NOTE]
====
To connect to an OpenSSH server from a client machine, you must have the [package]*openssh-clients* package installed. See xref:package-management/DNF.adoc#sec-Installing[Installing Packages] for more information on how to install new packages in Fedora.
====
[[s2-ssh-configuration-configs-user]]
== Configuration Files
indexterm:[SSH protocol,configuration files,user-specific configuration files]
User-specific SSH configuration information is stored in `~/.ssh/` within the user's home directory, as described in xref:table-ssh-configuration-configs-user[User-specific configuration files] below. For the system-wide client configuration file, `/etc/ssh/ssh_config`, and the server's configuration files, see xref:SSH-Server.adoc#table-ssh-configuration-configs-system[System-wide configuration files] in xref:SSH-Server.adoc[OpenSSH Server Configuration].
[[table-ssh-configuration-configs-user]]
.User-specific configuration files
[options="header"]
|===
|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 [command]#ssh#.
|`~/.ssh/id_rsa.pub`|The RSA public key used by [command]#ssh#.
|`~/.ssh/id_ed25519`|The EdDSA private key used by [command]#ssh#.
|`~/.ssh/id_ed25519.pub`|The EdDSA public key used by [command]#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.
[[s2-ssh-clients-ssh]]
== Using the ssh Utility
indexterm:[ssh,OpenSSH]indexterm:[OpenSSH,client,ssh]
The [command]#ssh# utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the [command]#rlogin#, [command]#rsh#, and [command]#telnet# programs.
Similarly to the [command]#telnet# command, log in to a remote machine by using the following command:
[subs="quotes, macros"]
----
[command]#ssh# _hostname_
----
For example, to log in to a remote machine named `penguin.example.com`, type the following at a shell prompt:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#ssh penguin.example.com#
----
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:
[subs="quotes, macros"]
----
[command]#ssh# _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_
----
For example, to log in to `penguin.example.com` as `USER`, type:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#ssh USER@penguin.example.com#
----
The first time you initiate a connection, you will be presented with a message similar to this:
[subs="quotes"]
----
The authenticity of host 'penguin.example.com' can't be established.
ECDSA key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
----
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 [command]#ssh-keygen# command as follows:
[subs="attributes"]
----
~]#{nbsp}ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
256 SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c no comment (ECDSA)
----
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:
[subs="quotes"]
----
Warning: Permanently added 'penguin.example.com' (ECDSA) to the list of known hosts.
USER@penguin.example.com's password:
----
.Updating the host key of an SSH server
[IMPORTANT]
====
If the SSH server's host key changes, the client notifies the user that the connection cannot proceed until the server's host key is deleted from the `~/.ssh/known_hosts` file. Before doing this, however, contact the system administrator of the SSH server to verify the server is not compromised.
To remove a key from the `~/.ssh/known_hosts` file, issue a command as follows:
[subs="macros, attributes"]
----
~]#{nbsp}ssh-keygen -R pass:quotes[_penguin.example.com_]
# Host penguin.example.com found: line 15 type ECDSA
/home/USER/.ssh/known_hosts updated.
Original contents retained as /home/USER/.ssh/known_hosts.old
----
====
After entering the password, you will be provided with a shell prompt for the remote machine.
Alternatively, the [command]#ssh# program can be used to execute a command on the remote machine without logging in to a shell prompt:
[subs="quotes, macros"]
----
[command]#ssh# _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_ _command_
----
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:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#ssh USER@penguin.example.com cat /etc/redhat-release#
USER@penguin.example.com's password:
Fedora release 31 (Thirty One)
----
After you enter the correct password, the user name will be displayed, and you will return to your local shell prompt.
[[s2-ssh-client-keypairs]]
== Generating and Managing SSH Keys
indexterm:[OpenSSH,using key-based authentication]
To be able to use [command]#ssh#, [command]#scp#, or [command]#sftp# to connect to a server, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
Fedora uses SSH Protocol 2 and RSA keys by default (see xref:SSH-About.adoc#s2-ssh-versions[Protocol Versions] for more information).
.Do not generate key pairs as root
[IMPORTANT]
====
If you complete the steps as `root`, only `root` will be able to use the keys.
====
.Backup your ~/.ssh/ directory
[NOTE]
====
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`.
====
[[s3-ssh-configuration-keypairs-generating]]
=== Generating an RSA Key Pair
indexterm:[RSA keys,generating]indexterm:[OpenSSH,RSA keys,generating]
To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:
indexterm:[OpenSSH,ssh-keygen,RSA]
. Generate an RSA key pair by typing the following at a shell prompt:
+
[subs="attributes"]
----
~]${nbsp}ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_rsa):
----
. Press kbd:[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:
+
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][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:
+
[subs="quotes, macros"]
----
[command]#ssh-copy-id _user@hostname_pass:attributes[{blank}]#
----
+
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.
=== Generating an ECDSA Key Pair
indexterm:[ECDSA keys,generating]indexterm:[OpenSSH,ECDSA keys,generating]
To generate an ECDSA key pair for version 2 of the SSH protocol, follow these steps:
indexterm:[OpenSSH,ssh-keygen,ECDSA]
. Generate an ECDSA key pair by typing the following at a shell prompt:
+
[subs="attributes"]
----
~]${nbsp}ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_ecdsa):
----
. Press kbd:[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:
+
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][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:
+
[subs="quotes, macros"]
----
[command]#ssh-copy-id _USER@hostname_pass:attributes[{blank}]#
----
+
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.
////
=== Generating an Ed25519 Key Pair
NOTE: This section is a placeholder. Ed25519 is the current recommended default for new keys -- it produces smaller keys than RSA or ECDSA while remaining very secure and fast. This section should mirror the RSA/ECDSA steps above using `ssh-keygen -t ed25519`, including the default key location (`~/.ssh/id_ed25519`) and `ssh-copy-id` usage.
////
See xref:s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] below for information on how to set up your system to remember the passphrase.
.Never share your private key
[IMPORTANT]
====
The private key is for your personal use only, and it is important that you never give it to anyone.
====
[[s3-ssh-configuration-keypairs-agent]]
=== Configuring ssh-agent
indexterm:[OpenSSH,ssh-agent]indexterm:[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 [command]#ssh-agent# authentication agent.
To save your passphrase for a certain shell prompt, use the following command:
[subs="attributes"]
----
~]${nbsp}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.
////
[[s2-ssh-client-config-file]]
== The SSH Client Configuration File (~/.ssh/config)
NOTE: This section is a placeholder and is not covered in the original topic. It should cover the per-user `~/.ssh/config` file (and the system-wide `/etc/ssh/ssh_config`), including `Host` blocks/aliases, common per-host options such as `HostName`, `User`, `Port`, and `IdentityFile`, the `ProxyJump` directive for jump hosts, and global defaults such as `ServerAliveInterval`.
////
[[s2-ssh-clients-scp]]
== Using the [command]#scp# Utility
indexterm:[scp,OpenSSH]indexterm:[OpenSSH,client,scp]indexterm:[rcp]
[command]#scp# can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to [command]#rcp#.
To transfer a local file to a remote system, use a command in the following form:
[subs="quotes, macros"]
----
[command]#scp _localfile_ _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_:pass:attributes[{blank}]_remotefile_pass:attributes[{blank}]#
----
For example, if you want to transfer `taglist.vim` to a remote machine named `penguin.example.com`, type the following at a shell prompt:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim#
USER@penguin.example.com's password:
taglist.vim 100% 144KB 144.5KB/s 00:00
----
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:
[subs="attributes"]
----
~]${nbsp}scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/
USER@penguin.example.com's password:
closetag.vim 100% 13KB 12.6KB/s 00:00
snippetsEmu.vim 100% 33KB 33.1KB/s 00:00
taglist.vim 100% 144KB 144.5KB/s 00:00
----
To transfer a remote file to the local system, use the following syntax:
[subs="quotes, macros"]
----
[command]#scp _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_:pass:attributes[{blank}]_remotefile_ _localfile_pass:attributes[{blank}]#
----
For instance, to download the `.vimrc` configuration file from the remote machine, type:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#scp USER@penguin.example.com:.vimrc .vimrc#
USER@penguin.example.com's password:
.vimrc 100% 2233 2.2KB/s 00:00
----
[IMPORTANT]
====
The SCP protocol is not well designed and can cause unexpected results. In the past it was source of several CVEs where malicious server could override files in local filesystem when downloading files. It is recommended to use SFTP when possible. See the next section for more information.
====
[[s2-ssh-clients-sftp]]
== Using the [command]#sftp# Utility
indexterm:[sftp,OpenSSH]indexterm:[OpenSSH,client,sftp]
The [command]#sftp# utility can be used to open a secure, interactive SFTP session. In its design, it is similar to [command]#ftp# except that it uses a secure, encrypted connection.
To connect to a remote system, use a command in the following form:
[subs="quotes, macros"]
----
[command]#sftp _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_pass:attributes[{blank}]#
----
For example, to log in to a remote machine named `penguin.example.com` with `USER` as a user name, type:
[subs="quotes, macros, attributes"]
----
~]${nbsp}pass:attributes[{blank}][command]#sftp USER@penguin.example.com#
USER@penguin.example.com's password:
Connected to penguin.example.com.
sftp>
----
After you enter the correct password, you will be presented with a prompt. The [command]#sftp# utility accepts a set of commands similar to those used by [command]#ftp# (see xref:table-ssh-clients-sftp[A selection of available sftp commands]).
[[table-ssh-clients-sftp]]
.A selection of available sftp commands
[options="header"]
|===
|Command|Description
|[command]#ls# [pass:attributes[{blank}]_directory_pass:attributes[{blank}]]|List the content of a remote _directory_. If none is supplied, a current working directory is used by default.
|[command]#cd# _directory_|Change the remote working directory to _directory_.
|[command]#mkdir# _directory_|Create a remote _directory_.
|[command]#rmdir# _directory_|Remove a remote _directory_.
|[command]#put# _localfile_ [pass:attributes[{blank}]_remotefile_pass:attributes[{blank}]]|Transfer _localfile_ to a remote machine.
|[command]#get# _remotefile_ [pass:attributes[{blank}]_localfile_pass:attributes[{blank}]]|Transfer _remotefile_ from a remote machine.
|===
For a complete list of available commands, see the `sftp`(1) manual page.
== SSH Certificates
NOTE: Generating user certificates and configuring `IdentityFile` to present them is covered as part of the SSH Certificate Authentication use case in xref:SSH-Advanced-Usage.adoc[Advanced SSH Usage].
////
== Agent Forwarding
NOTE: This section is a placeholder. It should cover SSH agent forwarding (`ssh -A`, the `ForwardAgent` option), typical use cases such as jumping through a bastion host without copying private keys, and the associated security caveat of trusting the remote host with access to your agent.
////
[[s1-openssh-client-additional-resources]]
== Additional Resources
indexterm:[OpenSSH,additional resources]
For more information on how to connect to an OpenSSH server from Fedora, see the resources listed below.
* `ssh`(1) — The manual page for the [command]#ssh# client application provides a complete list of available command line options and supported configuration files and directories.
* `scp`(1) — The manual page for the [command]#scp# utility provides a more detailed description of this utility and its usage.
* `sftp`(1) — The manual page for the [command]#sftp# utility.
* `ssh-keygen`(1) — The manual page for the [command]#ssh-keygen# utility documents in detail how to use it to generate, manage, and convert authentication keys used by [command]#ssh#.
* `ssh_config`(5) — The manual page named `ssh_config` documents available SSH client configuration options.
For server-side resources and information about the SSH protocol, see xref:SSH-Server.adoc[OpenSSH Server Configuration] and xref:SSH-About.adoc[About SSH and OpenSSH].

177
modules/ROOT/pages/administration/SSH-Server.adoc Normal file
View file

@ -0,0 +1,177 @@
= OpenSSH Server Configuration
The Fedora Docs team
:revdate: 2026-06-12
:tags: SSH, Security, Access
[abstract]
This topic covers installing, starting, and configuring the OpenSSH server (`sshd`) on Fedora, including system-wide configuration files, enforcing key-based authentication, and other server-side security settings. For client-side configuration and key management, see xref:SSH-Client.adoc[OpenSSH Client Configuration]. For background on the SSH protocol, see xref:SSH-About.adoc[About SSH and OpenSSH].
In order to perform tasks described in this topic, you must have superuser privileges. To obtain them, log in as `root` by typing:
[subs="quotes, macros"]
----
[command]#su -#
----
[[s2-ssh-configuration-configs]]
== Configuration Files
indexterm:[SSH protocol,configuration files]
There are two different sets of configuration files: those for client programs (that is, [command]#ssh#, [command]#scp#, and [command]#sftp#), and those for the server (the [command]#sshd# daemon).
indexterm:[SSH protocol,configuration files,system-wide configuration files]
System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:table-ssh-configuration-configs-system[System-wide configuration files] below. For the user-specific configuration files stored in `~/.ssh/`, see xref:SSH-Client.adoc#table-ssh-configuration-configs-user[User-specific configuration files] in xref:SSH-Client.adoc[OpenSSH Client Configuration].
[[table-ssh-configuration-configs-system]]
.System-wide configuration files
[options="header"]
|===
|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 [command]#sshd# daemon.
|`/etc/ssh/ssh_host_ecdsa_key`|The ECDSA private key used by the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_ecdsa_key.pub`|The ECDSA public key used by the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_rsa_key`|The RSA private key used by the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_rsa_key.pub`|The RSA public key used by the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_ed25519_key`|The EdDSA private key used by the [command]#sshd# daemon.
|`/etc/ssh/ssh_host_ed25519_key.pub`|The EdDSA public key used by the [command]#sshd# daemon.
|`/etc/pam.d/sshd`|The PAM configuration file for the [command]#sshd# daemon.
|`/etc/sysconfig/sshd`|Configuration file for the `sshd` service.
|===
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.
[[s2-ssh-configuration-sshd]]
== Starting an OpenSSH Server
indexterm:[OpenSSH,server]
.Make sure you have relevant packages installed
[NOTE]
====
To run an OpenSSH server, you must have the [package]*openssh-server* package installed. See xref:package-management/DNF.adoc#sec-Installing[Installing Packages] for more information on how to install new packages in Fedora.
====
indexterm:[OpenSSH,server,starting]
To start the [command]#sshd# daemon in the current session, type the following at a shell prompt as `root`:
[subs="attributes"]
----
~]#{nbsp}systemctl start sshd.service
----
indexterm:[OpenSSH,server,stopping]
To stop the running [command]#sshd# daemon in the current session, use the following command as `root`:
[subs="attributes"]
----
~]#{nbsp}systemctl stop sshd.service
----
If you want the daemon to start automatically at the boot time, type as `root`:
[subs="attributes"]
----
~]#{nbsp}systemctl enable sshd.service
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'
----
See xref:infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[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:
[subs="quotes"]
----
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 xref:table-ssh-configuration-configs-system[System-wide configuration files] for a complete list), and restore them whenever you reinstall the system.
[[s2-ssh-configuration-requiring]]
== Requiring SSH for Remote Connections
indexterm:[SSH protocol,insecure protocols]indexterm:[SSH protocol,requiring for remote login]
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 [command]#telnet#, [command]#rsh#, [command]#rlogin#, and [command]#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:
[subs="quotes, macros"]
----
[command]#systemctl stop telnet.service#
[command]#systemctl stop rsh.service#
[command]#systemctl stop rlogin.service#
[command]#systemctl stop vsftpd.service#
----
To disable running these services at startup, type:
[subs="quotes, macros"]
----
[command]#systemctl disable telnet.service#
[command]#systemctl disable rsh.service#
[command]#systemctl disable rlogin.service#
[command]#systemctl disable vsftpd.service#
----
See xref:infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information on how to configure services in Fedora.
[[s2-ssh-configuration-keypairs]]
== Enforcing Key-based Authentication
indexterm:[OpenSSH,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 [application]*vi* or [application]*nano* insert the [option]`PasswordAuthentication` option as follows:
[subs="quotes"]
----
PasswordAuthentication no
----
If you are working on a system other than a new default installation, check that [command]#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 generate SSH key pairs and copy them to this server so that key-based authentication works once password authentication is disabled, see xref:SSH-Client.adoc#s3-ssh-configuration-keypairs-generating[Generating Key Pairs] in xref:SSH-Client.adoc[OpenSSH Client Configuration].
== SSH Certificates
NOTE: Configuring `HostCertificate`, `TrustedUserCAKeys`, `RevokedKeys`, and `AuthorizedPrincipalsFile` for certificate-based authentication is covered as part of the SSH Certificate Authentication use case in xref:SSH-Advanced-Usage.adoc[Advanced SSH Usage].
////
== Restricting User and Group Access
NOTE: This section is a placeholder. It should cover restricting which users and groups may log in over SSH using the `AllowUsers`, `DenyUsers`, `AllowGroups`, and `DenyGroups` directives in `sshd_config`, as well as using `Match` blocks to apply different rules to specific users, groups, or networks.
////
////
== Changing the Default SSH Port
NOTE: This section is a placeholder. It should cover changing the `Port` directive in `sshd_config`, the corresponding SELinux change needed (`semanage port -a -t ssh_port_t -p tcp _port_`), and the impact on firewall rules.
////
////
== Firewall Considerations
NOTE: This section is a placeholder. It should cover opening the `ssh` service (or a custom port) in `firewalld`. See xref:firewalld.adoc[Control of System Accessibility by firewalld] for general firewall configuration.
////
////
== Logging and Monitoring Login Attempts
NOTE: This section is a placeholder. It should cover reviewing SSH login activity with `journalctl -u sshd`, and give an overview of brute-force mitigation tools such as `fail2ban`.
////
[[s1-openssh-server-additional-resources]]
== Additional Resources
indexterm:[OpenSSH,additional resources]
For more information on how to configure an OpenSSH server on Fedora, see the resources listed below.
* `sshd`(8) — The manual page for the `sshd` daemon documents available command line options and provides a complete list of supported configuration files and directories.
* `sshd_config`(5) — The manual page named `sshd_config` provides a full description of available SSH daemon configuration options.
For client-side resources and information about the SSH protocol, see xref:SSH-Client.adoc[OpenSSH Client Configuration] and xref:SSH-About.adoc[About SSH and OpenSSH].