[release-notes/f22] Update revhistory
by Petr Kovář
commit 0495493129b3a22ece09320855ae1aa85c4267d6
Author: Petr Kovar <pkovar(a)redhat.com>
Date: Thu May 28 22:26:20 2015 +0200
Update revhistory
en-US/Revision_History.xml | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
---
diff --git a/en-US/Revision_History.xml b/en-US/Revision_History.xml
index eaf46f9..f0d0e76 100644
--- a/en-US/Revision_History.xml
+++ b/en-US/Revision_History.xml
@@ -8,6 +8,22 @@
<simpara>
<revhistory>
<revision>
+ <revnumber>22-03</revnumber>
+ <date>Thursday, May 28 2015</date>
+ <author>
+ <firstname>Fedora</firstname>
+ <surname>Docs</surname>
+ <email>docs AT lists.fedoraproject.org</email>
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>
+ Corrections to the GNOME & Git beats
+ </member>
+ </simplelist>
+ </revdescription>
+ </revision>
+ <revision>
<revnumber>22-02</revnumber>
<date>Monday, May 25 2015</date>
<author>
8 years, 11 months
[release-notes] Fix relnumber for GNOME
by Petr Kovář
commit 05d080e52976403b9e3ba540b7be4761de1c226f
Author: Petr Kovar <pkovar(a)redhat.com>
Date: Thu May 28 22:17:51 2015 +0200
Fix relnumber for GNOME
en-US/Desktop.xml | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/en-US/Desktop.xml b/en-US/Desktop.xml
index 1041df2..a4f438f 100644
--- a/en-US/Desktop.xml
+++ b/en-US/Desktop.xml
@@ -27,7 +27,7 @@ WaylandEnable=false</screen>
<para>GNOME has been updated to the latest upstream release 3.16. This release comes with a number of feature improvements, some of which are listed below.</para>
<itemizedlist>
<listitem>
- <para>The GNOME 3 notification system has been completely redesigned for 3.14. The message tray, used in previous versions of GNOME, was replaced with a new message list that the user can access from the GNOME Shell top bar.</para>
+ <para>The GNOME 3 notification system has been completely redesigned for 3.16. The message tray, used in previous versions of GNOME, was replaced with a new message list that the user can access from the GNOME Shell top bar.</para>
<para>GNOME Shell's calendar drop down has also been substantially changed to improve the overall user experience.</para>
</listitem>
<listitem>
@@ -37,10 +37,10 @@ WaylandEnable=false</screen>
<para>The Activities overview, login screen and other parts of the GNOME Desktop come with an updated look.</para>
</listitem>
<listitem>
- <para>The 3.14 release introduces a new style of scrollbars that are only shown when the pointer is moved. They change size when the user clicks on them.</para>
+ <para>The 3.16 release introduces a new style of scrollbars that are only shown when the pointer is moved. They change size when the user clicks on them.</para>
</listitem>
<listitem>
- <para>The 3.14 release includes new games, <application>gnome-2048</application> and <application>gnome-taquin</application>.</para>
+ <para>The 3.16 release includes new games, <application>gnome-2048</application> and <application>gnome-taquin</application>.</para>
</listitem>
<listitem>
<para>Support for codec, font, and MIME handler installation has been moved from <application>gnome-packagekit</application> to <application>gnome-software</application>. A new UI has been added to support these features.</para>
8 years, 11 months
[release-notes/f22] Fix relnumber for GNOME
by Petr Kovář
commit 6ca2ef5a4c597985ab9ee40ccb848a7e5fd72395
Author: Petr Kovar <pkovar(a)redhat.com>
Date: Thu May 28 22:17:51 2015 +0200
Fix relnumber for GNOME
en-US/Desktop.xml | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/en-US/Desktop.xml b/en-US/Desktop.xml
index 1041df2..a4f438f 100644
--- a/en-US/Desktop.xml
+++ b/en-US/Desktop.xml
@@ -27,7 +27,7 @@ WaylandEnable=false</screen>
<para>GNOME has been updated to the latest upstream release 3.16. This release comes with a number of feature improvements, some of which are listed below.</para>
<itemizedlist>
<listitem>
- <para>The GNOME 3 notification system has been completely redesigned for 3.14. The message tray, used in previous versions of GNOME, was replaced with a new message list that the user can access from the GNOME Shell top bar.</para>
+ <para>The GNOME 3 notification system has been completely redesigned for 3.16. The message tray, used in previous versions of GNOME, was replaced with a new message list that the user can access from the GNOME Shell top bar.</para>
<para>GNOME Shell's calendar drop down has also been substantially changed to improve the overall user experience.</para>
</listitem>
<listitem>
@@ -37,10 +37,10 @@ WaylandEnable=false</screen>
<para>The Activities overview, login screen and other parts of the GNOME Desktop come with an updated look.</para>
</listitem>
<listitem>
- <para>The 3.14 release introduces a new style of scrollbars that are only shown when the pointer is moved. They change size when the user clicks on them.</para>
+ <para>The 3.16 release introduces a new style of scrollbars that are only shown when the pointer is moved. They change size when the user clicks on them.</para>
</listitem>
<listitem>
- <para>The 3.14 release includes new games, <application>gnome-2048</application> and <application>gnome-taquin</application>.</para>
+ <para>The 3.16 release includes new games, <application>gnome-2048</application> and <application>gnome-taquin</application>.</para>
</listitem>
<listitem>
<para>Support for codec, font, and MIME handler installation has been moved from <application>gnome-packagekit</application> to <application>gnome-software</application>. A new UI has been added to support these features.</para>
8 years, 11 months
[system-administrators-guide] Using OpenSSH Certificate Authentication
by stephenw
commit 56c73ab24905918ad2883fb7c9c6fb2fa8d5b8df
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Thu May 28 21:26:55 2015 +0200
Using OpenSSH Certificate Authentication
en-US/OpenSSH.xml | 531 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 530 insertions(+), 1 deletions(-)
---
diff --git a/en-US/OpenSSH.xml b/en-US/OpenSSH.xml
index 53ed1e6..1b8e0b2 100644
--- a/en-US/OpenSSH.xml
+++ b/en-US/OpenSSH.xml
@@ -858,7 +858,536 @@ Enter passphrase for /home/USER/.ssh/id_rsa:</screen>
</para>
</section>
</section>
- </section>
+ </section>
+
+ <section id="sec-Using_OpenSSH_Certificate_Authentication">
+ <title>Using OpenSSH Certificate Authentication</title>
+
+ <section id="sec-Introduction_to_SSH_Certificates">
+ <title>Introduction to SSH Certificates</title>
+ <para>
+ 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 <firstterm>certificate authority</firstterm> (<acronym>CA</acronym>) 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.
+ </para>
+ <para>
+ 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</command> utility. The format of the certificate is described in <filename class="directory">/usr/share/doc/openssh-<replaceable>version</replaceable>/PROTOCOL.certkeys</filename>.
+</para>
+<para>
+The <command>ssh-keygen</command> 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, <systemitem class="daemon">sshd</systemitem> must be configured to trust the CA public key.
+</para>
+</section>
+
+ <section id="sec-Support_for_OpenSSH_Certificates">
+ <title>Support for SSH Certificates</title>
+ <para>
+ Support for certificate authentication of users and hosts using the new OpenSSH certificate format was introduced in Red Hat Enterprise Linux 6.5, in the <package>openssh-5.3p1-94.el6</package> package. If required, to ensure the latest OpenSSH package is installed, enter the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>yum install openssh</command>
+Package openssh-5.3p1-104.el6_6.1.i686 already installed and latest version
+Nothing to do</screen>
+ </para>
+</section>
+
+<section id="sec-Creating_SSH_CA_Certificate_Signing-Keys">
+<title>Creating SSH CA Certificate Signing Keys</title>
+<para>
+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 <literal>ca_user_key</literal> and <literal>ca_host_key</literal>, 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.
+</para>
+<para>
+ The basic format of the command to sign user's public key to create a user certificate is as follows:
+ <synopsis>ssh-keygen -s ca_user_key -I <replaceable>certificate_ID</replaceable> id_rsa.pub</synopsis>
+ Where <option>-s</option> indicates the private key used to sign the certificate, <option>-I</option> indicates an identity string, the <replaceable>certificate_ID</replaceable>, which can be any alpha numeric value. It is stored as a zero terminated string in the certificate. The <replaceable>certificate_ID</replaceable> 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.</para>
+ <para>
+ To sign a host's public key to create a host certificate, add the <option>-h</option> option:
+ <synopsis>ssh-keygen -s ca_host_key -I <replaceable>certificate_ID</replaceable> -h ssh_host_rsa_key.pub</synopsis>
+</para>
+<para>
+ Host keys are generated on the system by default, to list the keys, enter a command as follows:
+ <screen>~]# <command>ls -l /etc/ssh/ssh_host*</command>
+-rw-------. 1 root root 668 Jul 9 2014 /etc/ssh/ssh_host_dsa_key
+-rw-r--r--. 1 root root 590 Jul 9 2014 /etc/ssh/ssh_host_dsa_key.pub
+-rw-------. 1 root root 963 Jul 9 2014 /etc/ssh/ssh_host_key
+-rw-r--r--. 1 root root 627 Jul 9 2014 /etc/ssh/ssh_host_key.pub
+-rw-------. 1 root root 1671 Jul 9 2014 /etc/ssh/ssh_host_rsa_key
+-rw-r--r--. 1 root root 382 Jul 9 2014 /etc/ssh/ssh_host_rsa_key.pub</screen>
+</para>
+<important>
+ <para>
+ It is recommended to create and store CA keys in a safe place just as with any other private key. In these examples the <systemitem class="username">root</systemitem> 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 <ulink url="http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf"><citetitle pubwork="book">NIST Special Publication 800-131A</citetitle></ulink>.
+ </para>
+</important>
+<procedure id="proc-Generating_an_SSH_CA_Certificate">
+<title>Generating an SSH CA Certificate</title>
+ <step>
+<para>
+ 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 <filename>ca_user_key</filename> and <filename>ca_host_key</filename>. To generate the user certificate signing key, enter the following command as <systemitem class="username">root</systemitem>:
+<screen>~]# <command>ssh-keygen -t rsa -f ~/.ssh/ca_user_key</command>
+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:
+11:14:2f:32:fd:5d:f5:e4:7a:5a:d6:b6:a0:62:c9:1f root(a)host_name.example.com
+The key's randomart image is:
++--[ RSA 2048]----+
+| .+. o|
+| . o +.|
+| o + . . o|
+| o + . . ..|
+| S . ... *|
+| . . . .*.|
+| = E .. |
+| . o . |
+| . |
++-----------------+</screen>
+Generate a host certificate signing key, <filename>ca_host_key</filename>, as follows:
+<screen>~]# <command>ssh-keygen -t rsa -f ~/.ssh/ca_host_key</command>
+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:
+e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a root(a)host_name.example.com
+The key's randomart image is:
++--[ RSA 2048]----+
+| .. |
+| . ....|
+| . . o +oo|
+| o . o *o|
+| S = .|
+| o. .|
+| *.E. |
+| +o= |
+| .oo. |
++-----------------+</screen>
+If required, confirm the permissions are correct:
+<screen>~]# <command>ls -la ~/.ssh</command>
+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</screen>
+ </para>
+</step>
+<step>
+<para>
+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 <firstterm>fully qualified domain name</firstterm> (<acronym>FQDN)</acronym>, and a validity period. The command takes the following form:
+<synopsis>ssh-keygen -s ~/.ssh/ca_host_key -I <replaceable>certificate_ID</replaceable> -h -Z <replaceable>host_name.example.com.</replaceable> -V <replaceable>-start:+end</replaceable> ~/.ssh/ssh_host_rsa.pub</synopsis>
+The <option>-Z</option> option restricts this certificate to a specific host within the domain. The <option>-V</option> 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.
+</para>
+<para>
+For example:
+<screen>~]# <command>ssh-keygen -s ~/.ssh/ca_host_key -I <replaceable>host_name</replaceable> -h -Z host_name.example.com. -V -1w:+54w5d ~/.ssh/ssh_host_rsa.pub</command>
+Enter passphrase:
+Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "<replaceable>host_name</replaceable>" serial 0 for host_name.example.com. valid from 2015-05-15T13:52:29 to 2016-06-08T13:52:29</screen>
+</para>
+</step>
+</procedure>
+</section>
+
+<section id="sec-Distributing_and_Trusting_SSH_CA_Public_Keys">
+<title>Distributing and Trusting SSH CA Public Keys</title>
+<para>
+ 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 <literal>ca_user_key.pub</literal>.
+</para>
+<para>
+Publish the <literal>ca_user_key.pub</literal> 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:
+<synopsis>scp ~/.ssh/ca_user_key.pub root@<replaceable>host_name</replaceable>.example.com:/etc/ssh/</synopsis>
+Where <replaceable>host_name</replaceable> 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 <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/</command>
+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.
+root(a)host_name.example.com's password:
+ca_user_key.pub 100% 420 0.4KB/s 00:00</screen>
+</para>
+
+ <para>
+CA keys can be marked as trusted in the <filename>~/.ssh/authorized_keys</filename> file or by means of the <command>TrustedUserCAKeys</command> directive in the <filename>/etc/ssh/sshd_config</filename> file for user authentication, or in the <filename>/etc/ssh/known_hosts</filename> or <filename>~/.ssh/ssh_known_hosts</filename> file for host authentication.
+</para>
+<para>
+To configure a host to permit logging in by a remote user listed in a certificate's list of principals, edit the <filename>/etc/ssh/sshd_config</filename> file as follows:
+<synopsis>TrustedUserCAKeys /etc/ssh/ca_user_key.pub</synopsis>
+ Restart <systemitem class="daemon">sshd</systemitem> to make the changes take effect:
+ <screen>~]# <command>service sshd restart</command></screen>
+ </para>
+ <para>
+To configure a host to permit logging in to any user account from any remote user with a certificate, add the key to the <filename>/etc/ssh/ssh_known_hosts</filename> file using the <command>cert-authority</command> directive. For example:
+<screen># A CA key, accepted for any host in *.example.com
+@cert-authority *.example.com ssh-rsa <replaceable>AAAAB5Wm.</replaceable></screen>
+ The <filename>sshd(8)</filename> manual page has more examples.
+ </para>
+
+ <para>
+ To avoid being presented with the warning about an unknown host, user's systems must be configured to trust the CA's public key that was used to sign the host certificates. In this example that is <literal>ca_host_key.pub</literal>.
+</para>
+</section>
+
+<section id="sec-Signing_SSH_Certificates">
+<title>Signing SSH Certificates</title>
+
+<important>
+<para>
+ 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 <systemitem class="username">root</systemitem> user's <filename class="directory">/etc/ssh/</filename> directory is not recommend. In the examples below an account named <systemitem class="username">admin</systemitem> with a directory named <filename class="directory">keys/</filename> will be used.
+ </para>
+</important>
+ <para>
+ Create an administrator account, in this example <systemitem class="username">admin</systemitem>, and a directory to receive the user's keys. For example:
+ <screen>~]$ <command>mkdir keys</command></screen>
+ Set the permissions to allow keys to be copied in:
+ <screen>~]$ <command>chmod o+w keys</command>
+<command>ls -la keys</command>
+total 8
+drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
+drwx------. 3 admin admin 4096 May 22 16:17 ..</screen>
+ </para>
+
+</section>
+
+<section id="sec-Creating_SSH_Certificates_for_Authenticating_Users">
+<title>Creating SSH Certificates for Authenticating Users</title>
+<para>
+To sign a user's certificate, use a command in the following format:
+ <synopsis>ssh-keygen -s ca_user_key -I <replaceable>user_name</replaceable> -Z <replaceable>user_name</replaceable> -V <replaceable>-start:+end</replaceable> id_rsa.pub</synopsis>
+The resulting certificate will be named <filename>id_rsa-cert.pub</filename>.
+</para>
+<para>
+ The default behavior of OpenSSH is that a certificate must include the user's name in order to be accepted for authentication. There are two alternatives:
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the user's names to the certificate during the signing process using the <option>-Z</option>:
+ <synopsis>-Z "name1[,name2,...]"</synopsis>
+ and add the public key of the CA in the <filename>~/.ssh/authorized_keys</filename> file.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the principles names in a per-user file. In the <filename>/etc/ssh/sshd_config</filename> file, specify the file using the <command>AuthorizedPrincipalsFile</command> directive, and specify the CA's public key using the <command>TrustedCAKeys</command> directive.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+<procedure id="proc-Generating_a_User_Certificate">
+<title>Generating a User Certificate</title>
+<para>
+ 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.
+</para>
+
+<step>
+<para>
+ On client systems, login as the user who requires the certificate. Check for available keys as follows:
+ <screen>~]$ <command>ls -l ~/.ssh/</command></screen>
+ 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:
+ <screen>~]$ <command>ssh-keygen -t rsa</command>
+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:
+b1:f8:26:a7:46:87:c3:60:54:a3:6d:85:0d:60:fe:ce user1(a)host1.example.com
+The key's randomart image is:
++--[ RSA 2048]----+
+| oo++. |
+| o.o.o. |
+| .o o . |
+| oo . o |
+| . oo.S |
+| o=.. |
+| .Eo+ |
+| .= |
+| .. |
++-----------------+</screen>
+By default the directory permissions for a user's keys are <filename class="directory">drwx------.</filename>, or octal 0700. If required, confirm the permissions are correct:
+<screen>~]$ <command>ls -la ~/.ssh</command>
+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</screen>
+ See <xref linkend="s2-ssh-configuration-keypairs" /> for more examples of key generation and for instructions on setting the correct directory permissions.
+</para>
+</step>
+<step>
+<para>
+ 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:
+<synopsis>scp ~/.ssh/id_<replaceable>protocol</replaceable>.pub <replaceable>admin</replaceable>@ca_server.example.com:~/keys/</synopsis>
+Where <replaceable>protocol</replaceable> is the part of the file name indicating the protocol used to generate the key, for example <literal>rsa</literal>, <replaceable>admin</replaceable> is an account on the CA server, and <replaceable>/keys/</replaceable> is a directory setup to receive the keys to be signed.
+</para>
+ <para>
+ Copy the chosen public key to the server designated as the CA. For example:
+ <screen>~]$ <command>scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/</command>
+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
+Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
+admin(a)ca-server.example.com's password:
+id_rsa.pub 100% 421 0.4KB/s 00:00</screen>
+ </para>
+</step>
+<step>
+<para>
+ On the CA server, sign the user's public key. For example, as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>ssh-keygen -s ~/.ssh/ca_user_key -I user1 -Z user1 -V -1d:+54w /home/admin/keys/id_rsa.pub</command>
+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</screen>
+</para>
+</step>
+<step>
+ <para>
+ Copy the resulting certificate to the user's <filename class="directory">~/.ssh/</filename> directory on their system. For example:
+ <screen>~]# <command>scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/</command>
+user1(a)host_name.example.com's password:
+id_rsa-cert.pub 100% 1498 1.5KB/s 00:00</screen>
+ </para>
+</step>
+
+<step>
+<para>
+ 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 <literal>-cert.pub</literal> and use them automatically if it finds them. Note that the default location and file names for for SSH version 2 keys are: <filename>~/.ssh/id_dsa</filename>, <filename>~/.ssh/id_ecdsa</filename> and <filename>~/.ssh/id_rsa</filename> as explained in the <filename>ssh_config(5)</filename> manual page. If you use these locations and naming conventions then there is no need for editing the configuration files to enable <systemitem class="daemon">sshd</systemitem> to present the certificate. They will be used automatically when logging in to a remote system. There is also no need to restart <systemitem class="daemon">sshd</systemitem> in this case and you can skip to step 6.</para>
+ <para>
+ If required to use a non-default directory or file naming convention, then as <systemitem class="username">root</systemitem>, add the following line to the <filename>/etc/ssh/sshd_config</filename> or <filename>~/.ssh/config</filename> files:
+ <screen>IdentityFile <replaceable>~/path/key_file</replaceable></screen>
+ Note that this must be the private key name, do not had <literal>.pub</literal> or <literal>-cert.pub</literal>.
+ Ensure the file permission are correct. For example:
+ <screen>~]$ <command>ls -la ~/.ssh/config</command>
+-rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
+<command>chmod 700 ~/.ssh/config</command>
+~]$ <command>ls -la ~/.ssh/config</command>
+-rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config</screen>
+ 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.
+ </para>
+</step>
+<step>
+ <para>
+ 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> option to the SSH command to see logging information.
+ </para>
+</step>
+
+</procedure>
+
+</section>
+
+<section id="sec-Creating_SSH_Certificates_to_Authenticate_Hosts">
+<title>Creating SSH Certificates to Authenticate Hosts</title>
+<para>
+The command to sign a host certificate has the following format:
+ <synopsis>ssh-keygen -s ca_host_key -I <replaceable>host_name</replaceable> -h ssh_host_rsa_key.pub</synopsis>
+The host certificate will named <filename>ssh_host_rsa_key-cert.pub</filename>.
+</para>
+
+<procedure id="proc-Generating_a_Host_Certificate">
+<title>Generating a Host Certificate</title>
+
+<para>
+ 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.
+</para>
+<step>
+<para>
+Host keys are generated automatically on the system. To list them enter the following command:
+ <screen>~]# <command>ls -l /etc/ssh/ssh_host*</command>-rw-------. 1 root root 668 May 6 14:38 /etc/ssh/ssh_host_dsa_key
+-rw-r--r--. 1 root root 590 May 6 14:38 /etc/ssh/ssh_host_dsa_key.pub
+-rw-------. 1 root root 963 May 6 14:38 /etc/ssh/ssh_host_key
+-rw-r--r--. 1 root root 627 May 6 14:38 /etc/ssh/ssh_host_key.pub
+-rw-------. 1 root root 1679 May 6 14:38 /etc/ssh/ssh_host_rsa_key
+-rw-r--r--. 1 root root 382 May 6 14:38 /etc/ssh/ssh_host_rsa_key.pub</screen>
+</para>
+</step>
+<step>
+ <para>
+ Copy the chosen public key to the server designated as the CA. For example, from the host:
+ <screen>~]# <command>scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub</command>
+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
+Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
+admin(a)ca-server.example.com's password:
+ssh_host_rsa_key.pub 100% 382 0.4KB/s 00:00</screen>
+ </para>
+ <para>
+ Alternately, from the CA:
+ <screen>~]$ <command>scp root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub</command></screen>
+ </para>
+
+</step>
+<step>
+<para>
+ On the CA server, sign the host's public key. For example, as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -Z host_name.example.com. -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub</command>
+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</screen>
+ Where <replaceable>host_name</replaceable> is the host name of the system requiring the certificate.
+</para>
+</step>
+<step>
+ <para>
+ Copy the certificate to the host. For example, from the CA:
+ <screen>~]# <command>scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/</command>
+root(a)host_name.example.com's password:
+ssh_host_rsa_key-cert.pub 100% 1384 1.5KB/s 00:00</screen>
+ </para>
+</step>
+<step>
+ <para>
+Configure the host to present the certificate to a user's system when a user initiates the login process. As <systemitem class="username">root</systemitem>, edit the <filename>/etc/ssh/sshd_config</filename> file as follows:
+ <synopsis>HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub</synopsis>
+ </para>
+</step>
+<step>
+ <para>
+ Restart <systemitem class="daemon">sshd</systemitem> to make the changes take effect:
+ <screen>~]# <command>service sshd restart</command></screen>
+ </para>
+</step>
+
+<step>
+<para>
+ Extract the contents of the public key. For example, on the CA:
+ <screen><command>cat ~/.ssh/ca_host_key.pub</command>
+ssh-rsa <replaceable>AAAAB5Wm.</replaceable>== root(a)ca-server.example.com</screen>
+</para>
+<para>
+To configure the users' systems to enable authentication of hosts certificates for all users on the system, login as <systemitem class="username">root</systemitem> and configure the <filename>/etc/ssh/ssh_known_hosts</filename> file, creating it if it does not yet exist, as follows:
+<screen># A CA key, accepted for any host in *.example.com
+@cert-authority *.example.com ssh-rsa <replaceable>AAAAB5Wm.</replaceable></screen>
+ The above configures the system to trust the CA servers host public key. This enables global authentication of the certificates presented by remote hosts to users.
+ </para>
+
+ <para>
+ For host certificates that do not include host identifying information, or for certificates that are <emphasis role="bold">not</emphasis> for global use, place the contents of the host certificate signing key file in the user's <filename>~/.ssh/known_hosts</filename> file. Create the file if it does not yet exist.
+ Edit the <filename>~/.ssh/known_hosts</filename> file to include a line as follows:
+<screen># A CA key, accepted for any host in *.example.com
+@cert-authority *.example.com ssh-rsa <replaceable>AAAAB5Wm.</replaceable></screen>
+ The <filename>sshd(8)</filename> manual page has more examples.
+</para>
+</step>
+<step>
+ <para>
+ Remove keys belonging to hosts from the <filename>~/.ssh/known_hosts</filename> 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.</para>
+</step>
+<step>
+ <para>
+ To test the host certificate, ensure the server's public key is not in the <filename>~/.ssh/known_hosts</filename> file and 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> option to the SSH command to see logging information.</para>
+</step>
+
+</procedure>
+
+</section>
+
+<section id="sec-SSH_Certificate_PKCS_11_Token">
+<title>Signing an SSH Certificate Using a PKCS#11 Token</title>
+<para>
+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</option> and identifying the CA key by providing its public half as an argument to the <option>-s</option> option:
+ <synopsis>ssh-keygen -s ca_key.pub -D libpkcs11.so -I <replaceable>certificate_ID</replaceable> host_key.pub</synopsis>
+ In all cases, <replaceable>certificate_ID</replaceable> is a <quote>key identifier</quote> that is logged by the server when the certificate is used for authentication.
+ </para>
+<para>
+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>-Z</option> option as follows:</para>
+<screen>ssh-keygen -s ca_user_key -I <replaceable>certificate_ID</replaceable> -Z <replaceable>user1,user2</replaceable> id_rsa.pub</screen>
+<para>
+and for hosts:
+<screen>ssh-keygen -s ca_host_key -I <replaceable>certificate_ID</replaceable> -h -Z host.domain ssh_host_rsa_key.pub</screen>
+</para>
+<para>
+ 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
+ <filename>ssh-keygen(1)</filename> manual page for the <option>-O</option> option.
+ </para>
+ <para>
+ Certificates may be defined to be valid for a specific lifetime. The <option>-V</option> option allows specifying a certificates
+ start and end times. For example:
+ <synopsis>ssh-keygen -s ca_user_key -I <replaceable>certificate_ID</replaceable> id_rsa.pub -V "-1w:+54w5d"</synopsis>
+ 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.
+</para>
+</section>
+
+<section id="sec-Viewing_an_SSH_CA_Certificate">
+<title>Viewing an SSH CA Certificate</title>
+
+<para>
+To view a certificate, use the <option>-L</option> to list the contents. For example, for a user's certificate:
+<screen>~]$ <command>ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub</command>
+/home/user1/.ssh/id_rsa-cert.pub:
+ Type: ssh-rsa-cert-v01(a)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
+ Key ID: "user1"
+ Serial: 0
+ Valid: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16
+ Principals:
+ user1
+ Critical Options: (none)
+ Extensions:
+ permit-X11-forwarding UNKNOWN OPTION (len 0)
+ permit-agent-forwarding UNKNOWN OPTION (len 0)
+ permit-port-forwarding UNKNOWN OPTION (len 0)
+ permit-pty UNKNOWN OPTION (len 0)
+ permit-user-rc UNKNOWN OPTION (len 0)</screen>
+</para>
+<para>
+ To vew a host certificate:
+ <screen>~]# <command>ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub</command>
+/etc/ssh/ssh_host_rsa_key-cert.pub:
+ Type: ssh-rsa-cert-v01(a)openssh.com user 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
+ Key ID: "host_name"
+ Serial: 0
+ Valid: from 2015-05-26T12:21:54 to 2016-06-08T12:21:54
+ Principals:
+ host_name.example.com.
+ Critical Options: (none)
+ Extensions:
+ permit-X11-forwarding UNKNOWN OPTION (len 0)
+ permit-agent-forwarding UNKNOWN OPTION (len 0)
+ permit-port-forwarding UNKNOWN OPTION (len 0)
+ permit-pty UNKNOWN OPTION (len 0)
+ permit-user-rc UNKNOWN OPTION (len 0)</screen>
+</para>
+</section>
+
+<section id="sec-Revoking_an_SSH_CA_Certificate">
+<title>Revoking an SSH CA Certificate</title>
+
+<para>
+ 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 CAN and all host and user certificates previously created and distributed.
+</para>
+<para>
+ Keys can be revoked by adding them to the <filename>revoked_keys</filename> file and specifying the file name in the <filename>sshd_config</filename> file as follows:
+ <synopsis>RevokedKeys /etc/ssh/revoked_keys</synopsis>
+</para>
+<para>
+ A new key revocation list can be generated as follows:
+ <screen>~]$ ssh-keygen -kf /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub</screen>
+ To add lines to the list, use the <option>-u</option> option to update the list:
+<synopsis>ssh-keygen -ukf /etc/ssh/revoked_keys -z <replaceable>integer</replaceable> ~/.ssh/id_rsa.pub</synopsis>
+where <replaceable>integer</replaceable> is the line number.
+</para>
+<para>
+ To test if a key has been revoked, query the revocation list for the presence of the key. Use a command as follows:
+ <synopsis>ssh-keygen -Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub</synopsis>
+</para>
+<para>
+ Where the <command>@cert-authority</command> directive has been used, certificates can be revoke by changing the directive to <command>@revoke</command>.
+</para>
+
+ </section>
+ </section>
+
<section id="s1-ssh-clients">
<title>OpenSSH Clients</title>
<indexterm>
8 years, 11 months
[system-administrators-guide/22] Using OpenSSH Certificate Authentication
by stephenw
commit 79e961177635f9fefad09e663a907c60c1697a52
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Thu May 28 21:26:55 2015 +0200
Using OpenSSH Certificate Authentication
en-US/OpenSSH.xml | 531 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 530 insertions(+), 1 deletions(-)
---
diff --git a/en-US/OpenSSH.xml b/en-US/OpenSSH.xml
index 53ed1e6..1b8e0b2 100644
--- a/en-US/OpenSSH.xml
+++ b/en-US/OpenSSH.xml
@@ -858,7 +858,536 @@ Enter passphrase for /home/USER/.ssh/id_rsa:</screen>
</para>
</section>
</section>
- </section>
+ </section>
+
+ <section id="sec-Using_OpenSSH_Certificate_Authentication">
+ <title>Using OpenSSH Certificate Authentication</title>
+
+ <section id="sec-Introduction_to_SSH_Certificates">
+ <title>Introduction to SSH Certificates</title>
+ <para>
+ 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 <firstterm>certificate authority</firstterm> (<acronym>CA</acronym>) 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.
+ </para>
+ <para>
+ 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</command> utility. The format of the certificate is described in <filename class="directory">/usr/share/doc/openssh-<replaceable>version</replaceable>/PROTOCOL.certkeys</filename>.
+</para>
+<para>
+The <command>ssh-keygen</command> 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, <systemitem class="daemon">sshd</systemitem> must be configured to trust the CA public key.
+</para>
+</section>
+
+ <section id="sec-Support_for_OpenSSH_Certificates">
+ <title>Support for SSH Certificates</title>
+ <para>
+ Support for certificate authentication of users and hosts using the new OpenSSH certificate format was introduced in Red Hat Enterprise Linux 6.5, in the <package>openssh-5.3p1-94.el6</package> package. If required, to ensure the latest OpenSSH package is installed, enter the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>yum install openssh</command>
+Package openssh-5.3p1-104.el6_6.1.i686 already installed and latest version
+Nothing to do</screen>
+ </para>
+</section>
+
+<section id="sec-Creating_SSH_CA_Certificate_Signing-Keys">
+<title>Creating SSH CA Certificate Signing Keys</title>
+<para>
+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 <literal>ca_user_key</literal> and <literal>ca_host_key</literal>, 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.
+</para>
+<para>
+ The basic format of the command to sign user's public key to create a user certificate is as follows:
+ <synopsis>ssh-keygen -s ca_user_key -I <replaceable>certificate_ID</replaceable> id_rsa.pub</synopsis>
+ Where <option>-s</option> indicates the private key used to sign the certificate, <option>-I</option> indicates an identity string, the <replaceable>certificate_ID</replaceable>, which can be any alpha numeric value. It is stored as a zero terminated string in the certificate. The <replaceable>certificate_ID</replaceable> 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.</para>
+ <para>
+ To sign a host's public key to create a host certificate, add the <option>-h</option> option:
+ <synopsis>ssh-keygen -s ca_host_key -I <replaceable>certificate_ID</replaceable> -h ssh_host_rsa_key.pub</synopsis>
+</para>
+<para>
+ Host keys are generated on the system by default, to list the keys, enter a command as follows:
+ <screen>~]# <command>ls -l /etc/ssh/ssh_host*</command>
+-rw-------. 1 root root 668 Jul 9 2014 /etc/ssh/ssh_host_dsa_key
+-rw-r--r--. 1 root root 590 Jul 9 2014 /etc/ssh/ssh_host_dsa_key.pub
+-rw-------. 1 root root 963 Jul 9 2014 /etc/ssh/ssh_host_key
+-rw-r--r--. 1 root root 627 Jul 9 2014 /etc/ssh/ssh_host_key.pub
+-rw-------. 1 root root 1671 Jul 9 2014 /etc/ssh/ssh_host_rsa_key
+-rw-r--r--. 1 root root 382 Jul 9 2014 /etc/ssh/ssh_host_rsa_key.pub</screen>
+</para>
+<important>
+ <para>
+ It is recommended to create and store CA keys in a safe place just as with any other private key. In these examples the <systemitem class="username">root</systemitem> 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 <ulink url="http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf"><citetitle pubwork="book">NIST Special Publication 800-131A</citetitle></ulink>.
+ </para>
+</important>
+<procedure id="proc-Generating_an_SSH_CA_Certificate">
+<title>Generating an SSH CA Certificate</title>
+ <step>
+<para>
+ 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 <filename>ca_user_key</filename> and <filename>ca_host_key</filename>. To generate the user certificate signing key, enter the following command as <systemitem class="username">root</systemitem>:
+<screen>~]# <command>ssh-keygen -t rsa -f ~/.ssh/ca_user_key</command>
+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:
+11:14:2f:32:fd:5d:f5:e4:7a:5a:d6:b6:a0:62:c9:1f root(a)host_name.example.com
+The key's randomart image is:
++--[ RSA 2048]----+
+| .+. o|
+| . o +.|
+| o + . . o|
+| o + . . ..|
+| S . ... *|
+| . . . .*.|
+| = E .. |
+| . o . |
+| . |
++-----------------+</screen>
+Generate a host certificate signing key, <filename>ca_host_key</filename>, as follows:
+<screen>~]# <command>ssh-keygen -t rsa -f ~/.ssh/ca_host_key</command>
+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:
+e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a root(a)host_name.example.com
+The key's randomart image is:
++--[ RSA 2048]----+
+| .. |
+| . ....|
+| . . o +oo|
+| o . o *o|
+| S = .|
+| o. .|
+| *.E. |
+| +o= |
+| .oo. |
++-----------------+</screen>
+If required, confirm the permissions are correct:
+<screen>~]# <command>ls -la ~/.ssh</command>
+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</screen>
+ </para>
+</step>
+<step>
+<para>
+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 <firstterm>fully qualified domain name</firstterm> (<acronym>FQDN)</acronym>, and a validity period. The command takes the following form:
+<synopsis>ssh-keygen -s ~/.ssh/ca_host_key -I <replaceable>certificate_ID</replaceable> -h -Z <replaceable>host_name.example.com.</replaceable> -V <replaceable>-start:+end</replaceable> ~/.ssh/ssh_host_rsa.pub</synopsis>
+The <option>-Z</option> option restricts this certificate to a specific host within the domain. The <option>-V</option> 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.
+</para>
+<para>
+For example:
+<screen>~]# <command>ssh-keygen -s ~/.ssh/ca_host_key -I <replaceable>host_name</replaceable> -h -Z host_name.example.com. -V -1w:+54w5d ~/.ssh/ssh_host_rsa.pub</command>
+Enter passphrase:
+Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "<replaceable>host_name</replaceable>" serial 0 for host_name.example.com. valid from 2015-05-15T13:52:29 to 2016-06-08T13:52:29</screen>
+</para>
+</step>
+</procedure>
+</section>
+
+<section id="sec-Distributing_and_Trusting_SSH_CA_Public_Keys">
+<title>Distributing and Trusting SSH CA Public Keys</title>
+<para>
+ 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 <literal>ca_user_key.pub</literal>.
+</para>
+<para>
+Publish the <literal>ca_user_key.pub</literal> 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:
+<synopsis>scp ~/.ssh/ca_user_key.pub root@<replaceable>host_name</replaceable>.example.com:/etc/ssh/</synopsis>
+Where <replaceable>host_name</replaceable> 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 <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/</command>
+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.
+root(a)host_name.example.com's password:
+ca_user_key.pub 100% 420 0.4KB/s 00:00</screen>
+</para>
+
+ <para>
+CA keys can be marked as trusted in the <filename>~/.ssh/authorized_keys</filename> file or by means of the <command>TrustedUserCAKeys</command> directive in the <filename>/etc/ssh/sshd_config</filename> file for user authentication, or in the <filename>/etc/ssh/known_hosts</filename> or <filename>~/.ssh/ssh_known_hosts</filename> file for host authentication.
+</para>
+<para>
+To configure a host to permit logging in by a remote user listed in a certificate's list of principals, edit the <filename>/etc/ssh/sshd_config</filename> file as follows:
+<synopsis>TrustedUserCAKeys /etc/ssh/ca_user_key.pub</synopsis>
+ Restart <systemitem class="daemon">sshd</systemitem> to make the changes take effect:
+ <screen>~]# <command>service sshd restart</command></screen>
+ </para>
+ <para>
+To configure a host to permit logging in to any user account from any remote user with a certificate, add the key to the <filename>/etc/ssh/ssh_known_hosts</filename> file using the <command>cert-authority</command> directive. For example:
+<screen># A CA key, accepted for any host in *.example.com
+@cert-authority *.example.com ssh-rsa <replaceable>AAAAB5Wm.</replaceable></screen>
+ The <filename>sshd(8)</filename> manual page has more examples.
+ </para>
+
+ <para>
+ To avoid being presented with the warning about an unknown host, user's systems must be configured to trust the CA's public key that was used to sign the host certificates. In this example that is <literal>ca_host_key.pub</literal>.
+</para>
+</section>
+
+<section id="sec-Signing_SSH_Certificates">
+<title>Signing SSH Certificates</title>
+
+<important>
+<para>
+ 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 <systemitem class="username">root</systemitem> user's <filename class="directory">/etc/ssh/</filename> directory is not recommend. In the examples below an account named <systemitem class="username">admin</systemitem> with a directory named <filename class="directory">keys/</filename> will be used.
+ </para>
+</important>
+ <para>
+ Create an administrator account, in this example <systemitem class="username">admin</systemitem>, and a directory to receive the user's keys. For example:
+ <screen>~]$ <command>mkdir keys</command></screen>
+ Set the permissions to allow keys to be copied in:
+ <screen>~]$ <command>chmod o+w keys</command>
+<command>ls -la keys</command>
+total 8
+drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
+drwx------. 3 admin admin 4096 May 22 16:17 ..</screen>
+ </para>
+
+</section>
+
+<section id="sec-Creating_SSH_Certificates_for_Authenticating_Users">
+<title>Creating SSH Certificates for Authenticating Users</title>
+<para>
+To sign a user's certificate, use a command in the following format:
+ <synopsis>ssh-keygen -s ca_user_key -I <replaceable>user_name</replaceable> -Z <replaceable>user_name</replaceable> -V <replaceable>-start:+end</replaceable> id_rsa.pub</synopsis>
+The resulting certificate will be named <filename>id_rsa-cert.pub</filename>.
+</para>
+<para>
+ The default behavior of OpenSSH is that a certificate must include the user's name in order to be accepted for authentication. There are two alternatives:
+ <itemizedlist>
+ <listitem>
+ <para>
+ Add the user's names to the certificate during the signing process using the <option>-Z</option>:
+ <synopsis>-Z "name1[,name2,...]"</synopsis>
+ and add the public key of the CA in the <filename>~/.ssh/authorized_keys</filename> file.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Add the principles names in a per-user file. In the <filename>/etc/ssh/sshd_config</filename> file, specify the file using the <command>AuthorizedPrincipalsFile</command> directive, and specify the CA's public key using the <command>TrustedCAKeys</command> directive.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
+
+<procedure id="proc-Generating_a_User_Certificate">
+<title>Generating a User Certificate</title>
+<para>
+ 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.
+</para>
+
+<step>
+<para>
+ On client systems, login as the user who requires the certificate. Check for available keys as follows:
+ <screen>~]$ <command>ls -l ~/.ssh/</command></screen>
+ 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:
+ <screen>~]$ <command>ssh-keygen -t rsa</command>
+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:
+b1:f8:26:a7:46:87:c3:60:54:a3:6d:85:0d:60:fe:ce user1(a)host1.example.com
+The key's randomart image is:
++--[ RSA 2048]----+
+| oo++. |
+| o.o.o. |
+| .o o . |
+| oo . o |
+| . oo.S |
+| o=.. |
+| .Eo+ |
+| .= |
+| .. |
++-----------------+</screen>
+By default the directory permissions for a user's keys are <filename class="directory">drwx------.</filename>, or octal 0700. If required, confirm the permissions are correct:
+<screen>~]$ <command>ls -la ~/.ssh</command>
+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</screen>
+ See <xref linkend="s2-ssh-configuration-keypairs" /> for more examples of key generation and for instructions on setting the correct directory permissions.
+</para>
+</step>
+<step>
+<para>
+ 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:
+<synopsis>scp ~/.ssh/id_<replaceable>protocol</replaceable>.pub <replaceable>admin</replaceable>@ca_server.example.com:~/keys/</synopsis>
+Where <replaceable>protocol</replaceable> is the part of the file name indicating the protocol used to generate the key, for example <literal>rsa</literal>, <replaceable>admin</replaceable> is an account on the CA server, and <replaceable>/keys/</replaceable> is a directory setup to receive the keys to be signed.
+</para>
+ <para>
+ Copy the chosen public key to the server designated as the CA. For example:
+ <screen>~]$ <command>scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/</command>
+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
+Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
+admin(a)ca-server.example.com's password:
+id_rsa.pub 100% 421 0.4KB/s 00:00</screen>
+ </para>
+</step>
+<step>
+<para>
+ On the CA server, sign the user's public key. For example, as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>ssh-keygen -s ~/.ssh/ca_user_key -I user1 -Z user1 -V -1d:+54w /home/admin/keys/id_rsa.pub</command>
+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</screen>
+</para>
+</step>
+<step>
+ <para>
+ Copy the resulting certificate to the user's <filename class="directory">~/.ssh/</filename> directory on their system. For example:
+ <screen>~]# <command>scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/</command>
+user1(a)host_name.example.com's password:
+id_rsa-cert.pub 100% 1498 1.5KB/s 00:00</screen>
+ </para>
+</step>
+
+<step>
+<para>
+ 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 <literal>-cert.pub</literal> and use them automatically if it finds them. Note that the default location and file names for for SSH version 2 keys are: <filename>~/.ssh/id_dsa</filename>, <filename>~/.ssh/id_ecdsa</filename> and <filename>~/.ssh/id_rsa</filename> as explained in the <filename>ssh_config(5)</filename> manual page. If you use these locations and naming conventions then there is no need for editing the configuration files to enable <systemitem class="daemon">sshd</systemitem> to present the certificate. They will be used automatically when logging in to a remote system. There is also no need to restart <systemitem class="daemon">sshd</systemitem> in this case and you can skip to step 6.</para>
+ <para>
+ If required to use a non-default directory or file naming convention, then as <systemitem class="username">root</systemitem>, add the following line to the <filename>/etc/ssh/sshd_config</filename> or <filename>~/.ssh/config</filename> files:
+ <screen>IdentityFile <replaceable>~/path/key_file</replaceable></screen>
+ Note that this must be the private key name, do not had <literal>.pub</literal> or <literal>-cert.pub</literal>.
+ Ensure the file permission are correct. For example:
+ <screen>~]$ <command>ls -la ~/.ssh/config</command>
+-rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
+<command>chmod 700 ~/.ssh/config</command>
+~]$ <command>ls -la ~/.ssh/config</command>
+-rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config</screen>
+ 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.
+ </para>
+</step>
+<step>
+ <para>
+ 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> option to the SSH command to see logging information.
+ </para>
+</step>
+
+</procedure>
+
+</section>
+
+<section id="sec-Creating_SSH_Certificates_to_Authenticate_Hosts">
+<title>Creating SSH Certificates to Authenticate Hosts</title>
+<para>
+The command to sign a host certificate has the following format:
+ <synopsis>ssh-keygen -s ca_host_key -I <replaceable>host_name</replaceable> -h ssh_host_rsa_key.pub</synopsis>
+The host certificate will named <filename>ssh_host_rsa_key-cert.pub</filename>.
+</para>
+
+<procedure id="proc-Generating_a_Host_Certificate">
+<title>Generating a Host Certificate</title>
+
+<para>
+ 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.
+</para>
+<step>
+<para>
+Host keys are generated automatically on the system. To list them enter the following command:
+ <screen>~]# <command>ls -l /etc/ssh/ssh_host*</command>-rw-------. 1 root root 668 May 6 14:38 /etc/ssh/ssh_host_dsa_key
+-rw-r--r--. 1 root root 590 May 6 14:38 /etc/ssh/ssh_host_dsa_key.pub
+-rw-------. 1 root root 963 May 6 14:38 /etc/ssh/ssh_host_key
+-rw-r--r--. 1 root root 627 May 6 14:38 /etc/ssh/ssh_host_key.pub
+-rw-------. 1 root root 1679 May 6 14:38 /etc/ssh/ssh_host_rsa_key
+-rw-r--r--. 1 root root 382 May 6 14:38 /etc/ssh/ssh_host_rsa_key.pub</screen>
+</para>
+</step>
+<step>
+ <para>
+ Copy the chosen public key to the server designated as the CA. For example, from the host:
+ <screen>~]# <command>scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub</command>
+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
+Warning: Permanently added 'ca-server.example.com,10.34.74.58' (RSA) to the list of known hosts.
+admin(a)ca-server.example.com's password:
+ssh_host_rsa_key.pub 100% 382 0.4KB/s 00:00</screen>
+ </para>
+ <para>
+ Alternately, from the CA:
+ <screen>~]$ <command>scp root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub</command></screen>
+ </para>
+
+</step>
+<step>
+<para>
+ On the CA server, sign the host's public key. For example, as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -Z host_name.example.com. -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub</command>
+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</screen>
+ Where <replaceable>host_name</replaceable> is the host name of the system requiring the certificate.
+</para>
+</step>
+<step>
+ <para>
+ Copy the certificate to the host. For example, from the CA:
+ <screen>~]# <command>scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/</command>
+root(a)host_name.example.com's password:
+ssh_host_rsa_key-cert.pub 100% 1384 1.5KB/s 00:00</screen>
+ </para>
+</step>
+<step>
+ <para>
+Configure the host to present the certificate to a user's system when a user initiates the login process. As <systemitem class="username">root</systemitem>, edit the <filename>/etc/ssh/sshd_config</filename> file as follows:
+ <synopsis>HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub</synopsis>
+ </para>
+</step>
+<step>
+ <para>
+ Restart <systemitem class="daemon">sshd</systemitem> to make the changes take effect:
+ <screen>~]# <command>service sshd restart</command></screen>
+ </para>
+</step>
+
+<step>
+<para>
+ Extract the contents of the public key. For example, on the CA:
+ <screen><command>cat ~/.ssh/ca_host_key.pub</command>
+ssh-rsa <replaceable>AAAAB5Wm.</replaceable>== root(a)ca-server.example.com</screen>
+</para>
+<para>
+To configure the users' systems to enable authentication of hosts certificates for all users on the system, login as <systemitem class="username">root</systemitem> and configure the <filename>/etc/ssh/ssh_known_hosts</filename> file, creating it if it does not yet exist, as follows:
+<screen># A CA key, accepted for any host in *.example.com
+@cert-authority *.example.com ssh-rsa <replaceable>AAAAB5Wm.</replaceable></screen>
+ The above configures the system to trust the CA servers host public key. This enables global authentication of the certificates presented by remote hosts to users.
+ </para>
+
+ <para>
+ For host certificates that do not include host identifying information, or for certificates that are <emphasis role="bold">not</emphasis> for global use, place the contents of the host certificate signing key file in the user's <filename>~/.ssh/known_hosts</filename> file. Create the file if it does not yet exist.
+ Edit the <filename>~/.ssh/known_hosts</filename> file to include a line as follows:
+<screen># A CA key, accepted for any host in *.example.com
+@cert-authority *.example.com ssh-rsa <replaceable>AAAAB5Wm.</replaceable></screen>
+ The <filename>sshd(8)</filename> manual page has more examples.
+</para>
+</step>
+<step>
+ <para>
+ Remove keys belonging to hosts from the <filename>~/.ssh/known_hosts</filename> 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.</para>
+</step>
+<step>
+ <para>
+ To test the host certificate, ensure the server's public key is not in the <filename>~/.ssh/known_hosts</filename> file and 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> option to the SSH command to see logging information.</para>
+</step>
+
+</procedure>
+
+</section>
+
+<section id="sec-SSH_Certificate_PKCS_11_Token">
+<title>Signing an SSH Certificate Using a PKCS#11 Token</title>
+<para>
+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</option> and identifying the CA key by providing its public half as an argument to the <option>-s</option> option:
+ <synopsis>ssh-keygen -s ca_key.pub -D libpkcs11.so -I <replaceable>certificate_ID</replaceable> host_key.pub</synopsis>
+ In all cases, <replaceable>certificate_ID</replaceable> is a <quote>key identifier</quote> that is logged by the server when the certificate is used for authentication.
+ </para>
+<para>
+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>-Z</option> option as follows:</para>
+<screen>ssh-keygen -s ca_user_key -I <replaceable>certificate_ID</replaceable> -Z <replaceable>user1,user2</replaceable> id_rsa.pub</screen>
+<para>
+and for hosts:
+<screen>ssh-keygen -s ca_host_key -I <replaceable>certificate_ID</replaceable> -h -Z host.domain ssh_host_rsa_key.pub</screen>
+</para>
+<para>
+ 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
+ <filename>ssh-keygen(1)</filename> manual page for the <option>-O</option> option.
+ </para>
+ <para>
+ Certificates may be defined to be valid for a specific lifetime. The <option>-V</option> option allows specifying a certificates
+ start and end times. For example:
+ <synopsis>ssh-keygen -s ca_user_key -I <replaceable>certificate_ID</replaceable> id_rsa.pub -V "-1w:+54w5d"</synopsis>
+ 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.
+</para>
+</section>
+
+<section id="sec-Viewing_an_SSH_CA_Certificate">
+<title>Viewing an SSH CA Certificate</title>
+
+<para>
+To view a certificate, use the <option>-L</option> to list the contents. For example, for a user's certificate:
+<screen>~]$ <command>ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub</command>
+/home/user1/.ssh/id_rsa-cert.pub:
+ Type: ssh-rsa-cert-v01(a)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
+ Key ID: "user1"
+ Serial: 0
+ Valid: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16
+ Principals:
+ user1
+ Critical Options: (none)
+ Extensions:
+ permit-X11-forwarding UNKNOWN OPTION (len 0)
+ permit-agent-forwarding UNKNOWN OPTION (len 0)
+ permit-port-forwarding UNKNOWN OPTION (len 0)
+ permit-pty UNKNOWN OPTION (len 0)
+ permit-user-rc UNKNOWN OPTION (len 0)</screen>
+</para>
+<para>
+ To vew a host certificate:
+ <screen>~]# <command>ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub</command>
+/etc/ssh/ssh_host_rsa_key-cert.pub:
+ Type: ssh-rsa-cert-v01(a)openssh.com user 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
+ Key ID: "host_name"
+ Serial: 0
+ Valid: from 2015-05-26T12:21:54 to 2016-06-08T12:21:54
+ Principals:
+ host_name.example.com.
+ Critical Options: (none)
+ Extensions:
+ permit-X11-forwarding UNKNOWN OPTION (len 0)
+ permit-agent-forwarding UNKNOWN OPTION (len 0)
+ permit-port-forwarding UNKNOWN OPTION (len 0)
+ permit-pty UNKNOWN OPTION (len 0)
+ permit-user-rc UNKNOWN OPTION (len 0)</screen>
+</para>
+</section>
+
+<section id="sec-Revoking_an_SSH_CA_Certificate">
+<title>Revoking an SSH CA Certificate</title>
+
+<para>
+ 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 CAN and all host and user certificates previously created and distributed.
+</para>
+<para>
+ Keys can be revoked by adding them to the <filename>revoked_keys</filename> file and specifying the file name in the <filename>sshd_config</filename> file as follows:
+ <synopsis>RevokedKeys /etc/ssh/revoked_keys</synopsis>
+</para>
+<para>
+ A new key revocation list can be generated as follows:
+ <screen>~]$ ssh-keygen -kf /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub</screen>
+ To add lines to the list, use the <option>-u</option> option to update the list:
+<synopsis>ssh-keygen -ukf /etc/ssh/revoked_keys -z <replaceable>integer</replaceable> ~/.ssh/id_rsa.pub</synopsis>
+where <replaceable>integer</replaceable> is the line number.
+</para>
+<para>
+ To test if a key has been revoked, query the revocation list for the presence of the key. Use a command as follows:
+ <synopsis>ssh-keygen -Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub</synopsis>
+</para>
+<para>
+ Where the <command>@cert-authority</command> directive has been used, certificates can be revoke by changing the directive to <command>@revoke</command>.
+</para>
+
+ </section>
+ </section>
+
<section id="s1-ssh-clients">
<title>OpenSSH Clients</title>
<indexterm>
8 years, 11 months
[web] fedmenu!
by Pete Travis
commit 51ca5010f3bbc9910a9e11ccb00f82ffe6898408
Author: Pete Travis <immanetize(a)fedoraproject.org>
Date: Thu May 28 12:21:30 2015 -0600
fedmenu!
fedmenu-patch.patch | 58 ++++++++++++++++++++
fedmenu.patch | 150 ++++++++++++++++++++++++++++++---------------------
public_html/toc.js | 58 ++++++++++++++++++++
3 files changed, 204 insertions(+), 62 deletions(-)
---
diff --git a/fedmenu-patch.patch b/fedmenu-patch.patch
new file mode 100644
index 0000000..474d20e
--- /dev/null
+++ b/fedmenu-patch.patch
@@ -0,0 +1,58 @@
+
+/* fedmenu integration */
+
+function install_fedmenu() {
+ var jquery_src = document.createElement('script');
+ jquery_src.type = 'text/javascript';
+ jquery_src.src = 'https://apps.fedoraproject.org/fedmenu/js/jquery-1.11.2.min.js';
+ var done = false;
+ jquery_src.onload = jquery_src.onreadystatechange = function() {
+ if (!done && (
+ !this.readyState ||
+ this.readyState == 'loaded' ||
+ this.readyState == 'complete'
+ )) {
+ done = true;
+ set_fedmenu(); // Do the callback
+ jquery_src.onload = jquery_src.onreadystatechange = null;
+ document.body.removeChild(jquery_src);
+ };
+ };
+ document.body.appendChild(jquery_src);
+}
+
+function set_fedmenu() {
+ var fedmenu_src = document.createElement('script');
+ fedmenu_src.type = 'text/javascript';
+ fedmenu_src.src = 'https://apps.fedoraproject.org/fedmenu/js/fedmenu.js';
+ var done = false;
+ fedmenu_src.onload = fedmenu_src.onreadystatechange = function() {
+ if (!done && (
+ !this.readyState ||
+ this.readyState == 'loaded' ||
+ this.readyState == 'complete'
+ )) {
+ done = true;
+ run_fedmenu(); // Do the callback
+ fedmenu_src.onload = fedmenu_src.onreadystatechange = null;
+ document.body.removeChild(fedmenu_src);
+ };
+ };
+ document.body.appendChild(fedmenu_src);
+}
+
+function run_fedmenu() {
+ var fedmenu_spt = document.createElement('script');
+ fedmenu_spt.type = 'text/javascript';
+ fedmenu_spt.text = 'fedmenu({'
+ + '"url": "https://apps.fedoraproject.org/js/data.js", '
+ + '"mimetype": "application/javascript", '
+ + '"position": "bottom-right", '
+ + '"context": parent.document'
+ + '});';
+ document.body.appendChild(fedmenu_spt);
+}
+
+window.addEventListener("load", function(){
+ install_fedmenu();
+});
diff --git a/fedmenu.patch b/fedmenu.patch
index d5b21cc..48a5afc 100644
--- a/fedmenu.patch
+++ b/fedmenu.patch
@@ -1,62 +1,88 @@
---- toc.js.1 2015-05-06 18:00:20.000000000 +0200
-+++ toc.js 2015-05-07 09:23:33.652727936 +0200
-@@ -337,3 +337,59 @@
- setCookie(name_menu, 'open', expDate, '/', false, false);
- }
-
-+/* fedmenu integration */
-+
-+function install_fedmenu() {
-+ var jquery_src = document.createElement('script');
-+ jquery_src.type = 'text/javascript';
-+ jquery_src.src = 'https://apps.fedoraproject.org/fedmenu/js/jquery-1.11.2.min.js';
-+ var done = false;
-+ jquery_src.onload = jquery_src.onreadystatechange = function() {
-+ if (!done && (
-+ !this.readyState ||
-+ this.readyState == 'loaded' ||
-+ this.readyState == 'complete'
-+ )) {
-+ done = true;
-+ set_fedmenu(); // Do the callback
-+ jquery_src.onload = jquery_src.onreadystatechange = null;
-+ document.body.removeChild(jquery_src);
-+ };
-+ };
-+ document.body.appendChild(jquery_src);
-+}
-+
-+function set_fedmenu() {
-+ var fedmenu_src = document.createElement('script');
-+ fedmenu_src.type = 'text/javascript';
-+ fedmenu_src.src = 'https://apps.fedoraproject.org/fedmenu/js/fedmenu.js';
-+ var done = false;
-+ fedmenu_src.onload = fedmenu_src.onreadystatechange = function() {
-+ if (!done && (
-+ !this.readyState ||
-+ this.readyState == 'loaded' ||
-+ this.readyState == 'complete'
-+ )) {
-+ done = true;
-+ run_fedmenu(); // Do the callback
-+ fedmenu_src.onload = fedmenu_src.onreadystatechange = null;
-+ document.body.removeChild(fedmenu_src);
-+ };
-+ };
-+ document.body.appendChild(fedmenu_src);
-+}
-+
-+function run_fedmenu() {
-+ var fedmenu_spt = document.createElement('script');
-+ fedmenu_spt.type = 'text/javascript';
-+ fedmenu_spt.text = 'fedmenu({'
-+ + '"url": "https://apps.fedoraproject.org/js/data.js", '
-+ + '"mimetype": "application/javascript", '
-+ + '"position": "bottom-left", '
-+ + '});';
-+ document.body.appendChild(fedmenu_spt);
-+}
-+
-+window.addEventListener("load", function(){
-+ install_fedmenu();
-+});
+From 23e9e1f56a48322fa229257305b092385d035fdd Mon Sep 17 00:00:00 2001
+From: Pierre-Yves Chibon <pingou(a)pingoured.fr>
+Date: Tue, 19 May 2015 15:45:13 -0400
+Subject: [PATCH] Add fedmenu to docs.fp.o.
+
+This is done by modifying ``toc.js`` to pull in the fedmenu resources
+which in turn write the fedmenu elements to the DOM. We run into
+trouble though, because toc.js executes in the context of an iframe
+child and fedmenu gets confused -- where should it write!?
+
+This required a patch to fedmenu that allows it to accept a `context`
+argument: https://github.com/fedora-infra/fedmenu/pull/12
+
+In this patch, we pass ``parent.document`` as the context, which gets
+fedmenu to write to the correct location.
+
+Signed-off-by: Ralph Bean <rbean(a)redhat.com>
+---
+ public_html/toc.js | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 57 insertions(+)
+
+diff --git a/public_html/toc.js b/public_html/toc.js
+index 501b27a..a57d564 100644
+--- a/public_html/toc.js
++++ b/public_html/toc.js
+@@ -337,3 +337,60 @@ function showMenu() {
+ setCookie(name_menu, 'open', expDate, '/', false, false);
+ }
+
++/* fedmenu integration */
++
++function install_fedmenu() {
++ var jquery_src = document.createElement('script');
++ jquery_src.type = 'text/javascript';
++ jquery_src.src = 'https://apps.fedoraproject.org/fedmenu/js/jquery-1.11.2.min.js';
++ var done = false;
++ jquery_src.onload = jquery_src.onreadystatechange = function() {
++ if (!done && (
++ !this.readyState ||
++ this.readyState == 'loaded' ||
++ this.readyState == 'complete'
++ )) {
++ done = true;
++ set_fedmenu(); // Do the callback
++ jquery_src.onload = jquery_src.onreadystatechange = null;
++ document.body.removeChild(jquery_src);
++ };
++ };
++ document.body.appendChild(jquery_src);
++}
++
++function set_fedmenu() {
++ var fedmenu_src = document.createElement('script');
++ fedmenu_src.type = 'text/javascript';
++ fedmenu_src.src = 'https://apps.fedoraproject.org/fedmenu/js/fedmenu.js';
++ var done = false;
++ fedmenu_src.onload = fedmenu_src.onreadystatechange = function() {
++ if (!done && (
++ !this.readyState ||
++ this.readyState == 'loaded' ||
++ this.readyState == 'complete'
++ )) {
++ done = true;
++ run_fedmenu(); // Do the callback
++ fedmenu_src.onload = fedmenu_src.onreadystatechange = null;
++ document.body.removeChild(fedmenu_src);
++ };
++ };
++ document.body.appendChild(fedmenu_src);
++}
++
++function run_fedmenu() {
++ var fedmenu_spt = document.createElement('script');
++ fedmenu_spt.type = 'text/javascript';
++ fedmenu_spt.text = 'fedmenu({'
++ + '"url": "https://apps.fedoraproject.org/js/data.js", '
++ + '"mimetype": "application/javascript", '
++ + '"position": "bottom-right", '
++ + '"context": parent.document'
++ + '});';
++ document.body.appendChild(fedmenu_spt);
++}
++
++window.addEventListener("load", function(){
++ install_fedmenu();
++});
+--
+2.4.1
diff --git a/public_html/toc.js b/public_html/toc.js
index 501b27a..5588a70 100644
--- a/public_html/toc.js
+++ b/public_html/toc.js
@@ -337,3 +337,61 @@ function showMenu() {
setCookie(name_menu, 'open', expDate, '/', false, false);
}
+
+/* fedmenu integration */
+
+function install_fedmenu() {
+ var jquery_src = document.createElement('script');
+ jquery_src.type = 'text/javascript';
+ jquery_src.src = 'https://apps.fedoraproject.org/fedmenu/js/jquery-1.11.2.min.js';
+ var done = false;
+ jquery_src.onload = jquery_src.onreadystatechange = function() {
+ if (!done && (
+ !this.readyState ||
+ this.readyState == 'loaded' ||
+ this.readyState == 'complete'
+ )) {
+ done = true;
+ set_fedmenu(); // Do the callback
+ jquery_src.onload = jquery_src.onreadystatechange = null;
+ document.body.removeChild(jquery_src);
+ };
+ };
+ document.body.appendChild(jquery_src);
+}
+
+function set_fedmenu() {
+ var fedmenu_src = document.createElement('script');
+ fedmenu_src.type = 'text/javascript';
+ fedmenu_src.src = 'https://apps.fedoraproject.org/fedmenu/js/fedmenu.js';
+ var done = false;
+ fedmenu_src.onload = fedmenu_src.onreadystatechange = function() {
+ if (!done && (
+ !this.readyState ||
+ this.readyState == 'loaded' ||
+ this.readyState == 'complete'
+ )) {
+ done = true;
+ run_fedmenu(); // Do the callback
+ fedmenu_src.onload = fedmenu_src.onreadystatechange = null;
+ document.body.removeChild(fedmenu_src);
+ };
+ };
+ document.body.appendChild(fedmenu_src);
+}
+
+function run_fedmenu() {
+ var fedmenu_spt = document.createElement('script');
+ fedmenu_spt.type = 'text/javascript';
+ fedmenu_spt.text = 'fedmenu({'
+ + '"url": "https://apps.fedoraproject.org/js/data.js", '
+ + '"mimetype": "application/javascript", '
+ + '"position": "bottom-right", '
+ + '"context": parent.document'
+ + '});';
+ document.body.appendChild(fedmenu_spt);
+}
+
+window.addEventListener("load", function(){
+ install_fedmenu();
+});
8 years, 11 months
[networking-guide] f22: Remove draft from book tag (5bf018e)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : f22
>---------------------------------------------------------------
commit 5bf018e41ee38bc75c2cb268c11e19086b134d5f
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Thu May 28 16:21:04 2015 +0200
Remove draft from book tag
>---------------------------------------------------------------
en-US/Networking_Guide.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Networking_Guide.xml b/en-US/Networking_Guide.xml
index dfa3edc..617c1fb 100644
--- a/en-US/Networking_Guide.xml
+++ b/en-US/Networking_Guide.xml
@@ -3,7 +3,7 @@
<!ENTITY % BOOK_ENTITIES SYSTEM "Networking_Guide.ent">
%BOOK_ENTITIES;
]>
-<book status="draft">
+<book>
<!-- TITLE PAGE -->
<xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<!-- FRONT MATTER -->
8 years, 11 months
[system-administrators-guide] Add link to RHEL7 Security Guide
by stephenw
commit 650f50e8a4911b2db706c10accbc616457d82ed1
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Thu May 28 09:36:27 2015 +0200
Add link to RHEL7 Security Guide
en-US/FTP.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/FTP.xml b/en-US/FTP.xml
index 0d4f2b7..52ae2b2 100644
--- a/en-US/FTP.xml
+++ b/en-US/FTP.xml
@@ -366,7 +366,7 @@
<para>For a complete list of all directives available, refer to the man page for <filename>vsftpd.conf</filename>.</para>
<important>
<title>Securing the vsftpd service</title>
- <para>For an overview of ways to secure <command>vsftpd</command>, refer to the &MAJOROSVER; <citetitle>Security Guide</citetitle><!-- TBD6: link to the Security Guide -->.</para>
+ <para>For an overview of ways to secure <command>vsftpd</command>, see the <ulink url="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...">Red Hat Enterprise Linux 7 Security Guide</ulink>.</para>
</important>
<para>The following is a list of some of the more important directives within <filename>/etc/vsftpd/vsftpd.conf</filename>. All directives not explicitly found or commented out within <command>vsftpd</command>'s configuration file are set to their default value.</para>
<section
8 years, 11 months
[system-administrators-guide] Add links to RHEL7 Security Guide
by stephenw
commit 1c70c6bce3a47cdf60317db0ec74ad9204579948
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Thu May 28 09:33:01 2015 +0200
Add links to RHEL7 Security Guide
en-US/Gaining_Privileges.xml | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/en-US/Gaining_Privileges.xml b/en-US/Gaining_Privileges.xml
index cde4151..7b6c519 100644
--- a/en-US/Gaining_Privileges.xml
+++ b/en-US/Gaining_Privileges.xml
@@ -7,7 +7,7 @@
System administrators, and in some cases users, need to perform certain tasks with administrative access. Accessing the system as the <systemitem class="username">root</systemitem> user is potentially dangerous and can lead to widespread damage to the system and data. This chapter covers ways to gain administrative privileges using setuid programs such as <command>su</command> and <command>sudo</command>. These programs allow specific users to perform tasks which would normally be available only to the <systemitem class="username">root</systemitem> user while maintaining a higher level of control and system security.
</para>
<para>
- See the <citetitle>&MAJOROS; Security Guide</citetitle> for more information on administrative controls, potential dangers and ways to prevent data loss resulting from improper use of privileged access.
+ See the <ulink url="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...">Red Hat Enterprise Linux 7 Security Guide</ulink> for more information on administrative controls, potential dangers, and ways to prevent data loss resulting from improper use of privileged access.
</para>
<section id="sect-Gaining_Privileges-The_su_Command">
@@ -83,7 +83,7 @@
In the above example, <replaceable>command</replaceable> would be replaced by a command normally reserved for the <systemitem class="username">root</systemitem> user, such as <command>mount</command>.
</para>
<para>
- The <command>sudo</command> command allows for a high degree of flexibility. For instance, only users listed in the <filename>/etc/sudoers</filename> configuration file are allowed to use the <command>sudo</command> command and the command is executed in <emphasis>the user's</emphasis> shell, not a <systemitem class="username">root</systemitem> shell. This means the <systemitem class="username">root</systemitem> shell can be completely disabled as shown in the <citetitle>&MAJOROS; Security Guide</citetitle>.
+ The <command>sudo</command> command allows for a high degree of flexibility. For instance, only users listed in the <filename>/etc/sudoers</filename> configuration file are allowed to use the <command>sudo</command> command and the command is executed in <emphasis>the user's</emphasis> shell, not a <systemitem class="username">root</systemitem> shell. This means the <systemitem class="username">root</systemitem> shell can be completely disabled as shown in the <ulink url="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...">Red Hat Enterprise Linux 7 Security Guide</ulink>.
</para>
<para>
Each successful authentication using the <command>sudo</command> command is logged to the file <filename>/var/log/messages</filename> and the command issued along with the issuer's user name is logged to the file <filename>/var/log/secure</filename>. If additional logging is required, use the <systemitem>pam_tty_audit</systemitem> module to enable TTY auditing for specified users by adding the following line to your <filename>/etc/pam.d/system-auth</filename> file:
@@ -172,7 +172,7 @@
<itemizedlist>
<listitem>
<para>
- The <citetitle>&MAJOROS; Security Guide</citetitle> provides a more in-depth look at potential security issues pertaining to setuid programs as well as techniques used to alleviate these risks.
+ The <ulink url="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...">Red Hat Enterprise Linux 7 Security Guide</ulink> provides a more in-depth look at potential security issues pertaining to setuid programs as well as techniques used to alleviate these risks.
</para>
</listitem>
</itemizedlist>
8 years, 11 months
[system-administrators-guide] Fix name of link, RHEL7 Security Guide
by stephenw
commit ddce088582386d1b6f9542f53278d3e15a726c99
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Thu May 28 09:25:11 2015 +0200
Fix name of link, RHEL7 Security Guide
en-US/Managing_Users_and_Groups.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Managing_Users_and_Groups.xml b/en-US/Managing_Users_and_Groups.xml
index 02a432a..26bb02c 100644
--- a/en-US/Managing_Users_and_Groups.xml
+++ b/en-US/Managing_Users_and_Groups.xml
@@ -100,7 +100,7 @@
<itemizedlist>
<listitem>
<para>
- The <command>chage</command> utility for setting password-aging parameters. For details, see the <ulink url="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...">Password Security</ulink> section in the <citetitle pubwork="book">&MAJOROSVER; Security Guide</citetitle>.
+ The <command>chage</command> utility for setting password-aging parameters. For details, see the <ulink url="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...">Password Security</ulink> section in the <citetitle pubwork="book">Red Hat Enterprise Linux 7 Security Guide</citetitle>.
</para>
</listitem>
<listitem>
8 years, 11 months