From cf3dd11c02191e13ac00f11ace02b146bb68374f Mon Sep 17 00:00:00 2001 From: Petr Bokoc Date: Oct 26 2020 21:46:28 +0000 Subject: [PATCH 1/3] Add ToC and fix broken xrefs --- diff --git a/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc b/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc index a553e20..b27e48a 100644 --- a/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc +++ b/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc @@ -4,6 +4,8 @@ include::{partialsdir}/entities.adoc[] [[ch-OpenSSH]] = OpenSSH +:toc: + indexterm:[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 [command]#rlogin#, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords. @@ -132,7 +134,7 @@ In order to perform tasks described in this section, you must have superuser pri 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]indexterm:[SSH protocol,configuration files,user-specific configuration files] -System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files]. User-specific SSH configuration information is stored in `~/.ssh/` within the user's home directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-user[User-specific 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]. 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]. [[table-ssh-configuration-configs-system]] .System-wide configuration files @@ -219,7 +221,7 @@ 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:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files] for a complete list), and restore them whenever you reinstall the system. +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 @@ -262,7 +264,7 @@ If you are working on a system other than a new default installation, check that To be able to use [command]#ssh#, [command]#scp#, or [command]#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. -{MAJOROSVER} uses SSH Protocol 2 and RSA keys by default (see xref:OpenSSH.adoc#s2-ssh-versions[Protocol Versions] for more information). +{MAJOROSVER} uses SSH Protocol 2 and RSA keys by default (see xref:s2-ssh-versions[Protocol Versions] for more information). .Do not generate key pairs as root [IMPORTANT] @@ -405,7 +407,7 @@ 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 xref:OpenSSH.adoc#s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] for information on how to set up your system to remember the passphrase. +See xref:s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] for information on how to set up your system to remember the passphrase. .Never share your private key [IMPORTANT] @@ -750,7 +752,7 @@ HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub . 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:OpenSSH.adoc#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. +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 @@ -833,7 +835,7 @@ drwx------. 3 user1 user1 4096 May 7 12:37 .. -rw-r--r--. 1 user1 user1 421 May 7 12:37 id_rsa.pub ---- + -See xref:OpenSSH.adoc#s2-ssh-configuration-keypairs[Using Key-based Authentication] for more examples of key generation and for instructions on setting the correct directory permissions. +See xref:s2-ssh-configuration-keypairs[Using Key-based Authentication] 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: + @@ -852,7 +854,7 @@ 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:OpenSSH.adoc#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. +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`: + From 565ec22597736956ea23653eaa43a385fbe97489 Mon Sep 17 00:00:00 2001 From: Petr Bokoc Date: Oct 26 2020 21:47:04 +0000 Subject: [PATCH 2/3] Merge branch 'pr54' into f33 --- diff --git a/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc b/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc index c3821c3..b27e48a 100644 --- a/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc +++ b/modules/system-administrators-guide/pages/infrastructure-services/OpenSSH.adoc @@ -4,6 +4,8 @@ include::{partialsdir}/entities.adoc[] [[ch-OpenSSH]] = OpenSSH +:toc: + indexterm:[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 [command]#rlogin#, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords. @@ -36,9 +38,9 @@ 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, 128-bit encryption. +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 128-bit encryption, making intercepted transmissions extremely difficult to decrypt and read. +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: @@ -53,15 +55,7 @@ It supports Kerberos authentication:: OpenSSH servers and clients can be config [[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 {MAJOROS} uses SSH version 2, which has an enhanced key exchange algorithm not vulnerable to the known exploit in version 1. However, for compatibility reasons, the OpenSSH suite does support version 1 connections as well, although version 1 is disabled by default and needs to be enabled in the configuration files. - -.Avoid using SSH version 1 -[IMPORTANT] -==== - -To ensure maximum security for your connection, it is recommended that only SSH version 2-compatible servers and clients are used whenever possible. - -==== +Two varieties of SSH currently exist: version 1 and version 2. The OpenSSH suite under {MAJOROS} 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 @@ -83,15 +77,15 @@ The primary role of the transport layer is to facilitate safe and secure communi 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: -* Keys are exchanged +* The key exchange algorithm is determined -* The public key encryption algorithm is determined +* The public key signature algorithm is determined * The symmetric encryption algorithm is determined * The message authentication algorithm is determined -* The hash 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. @@ -105,7 +99,7 @@ It is possible for an attacker to masquerade as an SSH server during the initial 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), 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. +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 @@ -140,7 +134,7 @@ In order to perform tasks described in this section, you must have superuser pri 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]indexterm:[SSH protocol,configuration files,user-specific configuration files] -System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files]. User-specific SSH configuration information is stored in `~/.ssh/` within the user's home directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-user[User-specific 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]. 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]. [[table-ssh-configuration-configs-system]] .System-wide configuration files @@ -148,15 +142,15 @@ System-wide SSH configuration information is stored in the `/etc/ssh/` directory [options="header"] |=== |File|Description -|`/etc/ssh/moduli`|Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange 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. This value is then used to provide host authentication. +|`/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_key`|The RSA private key used by the [command]#sshd# daemon for version 1 of the SSH protocol. -|`/etc/ssh/ssh_host_key.pub`|The RSA public key used by the [command]#sshd# daemon for version 1 of the SSH protocol. -|`/etc/ssh/ssh_host_rsa_key`|The RSA private key used by the [command]#sshd# daemon for version 2 of the SSH protocol. -|`/etc/ssh/ssh_host_rsa_key.pub`|The RSA public key used by the [command]#sshd# daemon for version 2 of the SSH protocol. +|`/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. |=== @@ -170,10 +164,10 @@ System-wide SSH configuration information is stored in the `/etc/ssh/` directory |`~/.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# for version 2 of the SSH protocol. -|`~/.ssh/id_rsa.pub`|The RSA public key used by [command]#ssh# for version 2 of the SSH protocol. -|`~/.ssh/identity`|The RSA private key used by [command]#ssh# for version 1 of the SSH protocol. -|`~/.ssh/identity.pub`|The RSA public key used by [command]#ssh# for version 1 of the SSH protocol. +|`~/.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. |=== @@ -227,7 +221,7 @@ 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:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files] for a complete list), and restore them whenever you reinstall the system. +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 @@ -259,18 +253,18 @@ See xref:infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemo [[s2-ssh-configuration-keypairs]] === Using 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, open the `/etc/ssh/sshd_config` configuration file in a text editor such as [application]*vi* or [application]*nano*, and change the [option]`PasswordAuthentication` option as follows: +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. If connected remotely, not using console or out-of-band access, testing the key-based log in process before disabling password authentication is advised. +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 be able to use [command]#ssh#, [command]#scp#, or [command]#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. -{MAJOROSVER} uses SSH Protocol 2 and RSA keys by default (see xref:OpenSSH.adoc#s2-ssh-versions[Protocol Versions] for more information). +{MAJOROSVER} uses SSH Protocol 2 and RSA keys by default (see xref:s2-ssh-versions[Protocol Versions] for more information). .Do not generate key pairs as root [IMPORTANT] @@ -313,7 +307,7 @@ 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: -e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 USER@penguin.example.com +SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com The key's randomart image is: +--[ RSA 2048]----+ | E. | @@ -374,7 +368,7 @@ 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: -fd:1d:ca:10:52:96:21:43:7e:bd:4c:fc:5b:35:6b:63 USER@penguin.example.com +SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com The key's randomart image is: +--[ECDSA 256]---+ | .+ +o | @@ -413,7 +407,7 @@ 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 xref:OpenSSH.adoc#s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] for information on how to set up your system to remember the passphrase. +See xref:s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] for information on how to set up your system to remember the passphrase. .Never share your private key [IMPORTANT] @@ -457,7 +451,7 @@ Support for certificate authentication of users and hosts using the new OpenSSH ---- ~]# dnf install openssh -Last metadata expiration check performed 0:58:01 ago on Sun Sep 6 16:07:22 2015. +Last metadata expiration check performed 0:58:01 ago on Sun Sep 6 16:07:22 2020. Package openssh-7.1p1-1.fc23.x86_64 is already installed, skipping. ---- @@ -514,7 +508,7 @@ 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: -11:14:2f:32:fd:5d:f5:e4:7a:5a:d6:b6:a0:62:c9:1f root@host_name.example.com +SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com The key's randomart image is: +--[ RSA 2048]----+ | .+. o| @@ -539,7 +533,7 @@ 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: -e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a root@host_name.example.com +SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com The key's randomart image is: +--[ RSA 2048]----+ | .. | @@ -585,7 +579,7 @@ 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 2015-05-15T13:52:29 to 2016-06-08T13:52:29 +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]] @@ -605,9 +599,9 @@ Where _host_name_ is the host name of a server the is required to authenticate u ---- ~]# 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. -RSA key fingerprint is fc:23:ad:ae:10:6f:d1:a1:67:ee:b1:d5:37:d4:b0:2f. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added 'host_name.example.com,10.34.74.56' (RSA) to the list of known hosts. +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 ---- @@ -625,7 +619,7 @@ TrustedUserCAKeys /etc/ssh/ca_user_key.pub Restart `sshd` to make the changes take effect: + ---- -~]# service sshd restart +~]#{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`. @@ -713,8 +707,8 @@ To authenticate a host to a user, a public key must be generated on the host, pa ---- ~]# 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. -RSA key fingerprint is b0:e5:ea:b8:75:e2:f0:b1:fe:5b:07:39:7f:58:64:d9. -Are you sure you want to continue connecting (yes/no)? yes +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 @@ -731,7 +725,7 @@ Alternately, from the CA: ---- ~]# 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 2015-05-26T12:21:54 to 2016-06-08T12:21:54 +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. @@ -753,12 +747,12 @@ HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub . Restart `sshd` to make the changes take effect: + ---- -~]# service sshd restart +~]#{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:OpenSSH.adoc#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. +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 @@ -815,7 +809,7 @@ 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: -b1:f8:26:a7:46:87:c3:60:54:a3:6d:85:0d:60:fe:ce user1@host1.example.com +SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 user1@host1.example.com The key's randomart image is: +--[ RSA 2048]----+ | oo++. | @@ -841,7 +835,7 @@ drwx------. 3 user1 user1 4096 May 7 12:37 .. -rw-r--r--. 1 user1 user1 421 May 7 12:37 id_rsa.pub ---- + -See xref:OpenSSH.adoc#s2-ssh-configuration-keypairs[Using Key-based Authentication] for more examples of key generation and for instructions on setting the correct directory permissions. +See xref:s2-ssh-configuration-keypairs[Using Key-based Authentication] 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: + @@ -860,14 +854,14 @@ 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:OpenSSH.adoc#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. +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 2015-05-21T16:43:17 to 2016-06-03T16:43:17 +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: @@ -939,7 +933,7 @@ start and end times. For example: [subs="macros"] ---- -ssh-keygen -s ca_user_key -I pass:quotes[_certificate_ID_] id_rsa.pub -V "-1w:+54w5d" +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. @@ -954,11 +948,11 @@ To view a certificate, use the [option]`-L` to list the contents. For example, f ~]$ 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 3c:9d:42:ed:65:b6:0f:18:bf:52:77:c6:02:0e:e5:86 - Signing CA: RSA b1:8e:0b:ce:fe:1b:67:59:f1:74:cd:32:af:5f:c6:e8 + Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 + Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 Key ID: "user1" Serial: 0 - Valid: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16 + Valid: from 2020-05-27T00:09:16 to 2021-06-09T00:09:16 Principals: user1 Critical Options: (none) @@ -976,11 +970,11 @@ To vew 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 1d:71:61:50:05:9b:ec:64:34:27:a5:cc:67:24:03:23 - Signing CA: RSA e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a + Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 + Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 Key ID: "host_name" Serial: 0 - Valid: from 2015-05-26T17:19:01 to 2016-06-08T17:19:01 + Valid: from 2020-05-26T17:19:01 to 2021-06-08T17:19:01 Principals: host_name.example.com Critical Options: (none) @@ -1073,8 +1067,8 @@ The first time you initiate a connection, you will be presented with a message s [subs="quotes"] ---- The authenticity of host 'penguin.example.com' can't be established. -ECDSA key fingerprint is 256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff. -Are you sure you want to continue connecting (yes/no)? +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: @@ -1082,7 +1076,7 @@ Users should always check if the fingerprint is correct before answering the que [subs="attributes"] ---- ~]#{nbsp}ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub -256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff (ECDSA) +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: @@ -1126,7 +1120,7 @@ For example, the `/etc/redhat-release` file provides information about the {MAJO ---- ~]${nbsp}pass:attributes[{blank}][command]#ssh USER@penguin.example.com cat /etc/redhat-release# USER@penguin.example.com's password: -Fedora release 20 (Heisenbug) +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. @@ -1179,10 +1173,16 @@ 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 FTP session. In its design, it is similar to [command]#ftp# except that it uses a secure, encrypted connection. +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: @@ -1212,7 +1212,7 @@ After you enter the correct password, you will be presented with a prompt. The [ |[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# _path_|Remove 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. |=== From 20bd98281cb52e9b9a57a7987aca0e577dded533 Mon Sep 17 00:00:00 2001 From: Rostislav Krasny Date: Dec 20 2020 16:52:30 +0000 Subject: [PATCH 3/3] Fix wrong command example in modules/system-administrators-guide/pages/package-management/DNF.adoc --- diff --git a/modules/system-administrators-guide/pages/package-management/DNF.adoc b/modules/system-administrators-guide/pages/package-management/DNF.adoc index 7ac95cc..5836d91 100644 --- a/modules/system-administrators-guide/pages/package-management/DNF.adoc +++ b/modules/system-administrators-guide/pages/package-management/DNF.adoc @@ -1,4 +1,3 @@ - :experimental: include::{partialsdir}/entities.adoc[] @@ -198,7 +197,7 @@ Be careful to escape the glob expressions when passing them as arguments to a [c DNF searches only package names when using glob expressions. To search for a version of a package, include a dash and part of the version number as follows: ---- -~]# dnf search kernel*-4* +~]# dnf list kernel*-4* Last metadata expiration check performed 2:46:09 ago on Thu May 14 23:23:51 2015. Installed Packages kernel.x86_64 4.0.0-1.fc22 @System