[deployment-guide/comm-rel: 16/41] Changed the order of sections.
dsilas
dsilas at fedoraproject.org
Fri Jul 16 08:53:13 UTC 2010
commit e3efd830c80aab37272f432fcf6d539fc1bed2bc
Author: Jaromir Hradilek <jhradile at redhat.com>
Date: Fri Jul 9 15:43:29 2010 +0200
Changed the order of sections.
This is to make the structure of the chapter more logical, and thus
easier to read. I have also corrected the Why Use SSH section.
en-US/OpenSSH.xml | 347 +++++++++++++++++++++++++++--------------------------
1 files changed, 176 insertions(+), 171 deletions(-)
---
diff --git a/en-US/OpenSSH.xml b/en-US/OpenSSH.xml
index ffda38b..55a136e 100644
--- a/en-US/OpenSSH.xml
+++ b/en-US/OpenSSH.xml
@@ -12,227 +12,232 @@
<para>
The <application>ssh</application> program is designed to replace older, less secure terminal applications used to log into remote hosts, such as <command>telnet</command> or <command>rsh</command>. A related program called <command>scp</command> replaces older programs designed to copy files between hosts, such as <command>rcp</command>. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.
</para>
- <section id="s1-ssh-intro">
- <title>Features of SSH</title>
- <indexterm>
- <primary>SSH protocol</primary>
- <secondary>features of</secondary>
- </indexterm>
- <indexterm>
- <primary>OpenSSH</primary>
- <seealso>SSH</seealso>
- </indexterm>
- <para>
- The SSH protocol provides the following safeguards:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- After an initial connection, the client can verify that it is connecting to the same server it had connected to previously.
- </para>
- </listitem>
- <listitem>
- <para>
- The client transmits its authentication information to the server using strong, 128-bit encryption.
- </para>
- </listitem>
- <listitem>
- <para>
- All data sent and received during a session is transferred using 128-bit encryption, making intercepted transmissions extremely difficult to decrypt and read.
- </para>
- </listitem>
- <listitem>
- <para>
- The client can forward X11<footnote><para>X11 refers to the X11R7 windowing display system, traditionally referred to as the X Window System or X. &MAJOROS; includes X11R7, an open source X Window System.</para></footnote> applications from the server. This technique, called <firstterm>X11 forwarding</firstterm>, provides a secure means to use graphical applications over a network.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- Because the SSH protocol encrypts everything it sends and receives, it can be used to secure otherwise insecure protocols. Using a technique called <firstterm>port forwarding</firstterm>, an SSH server can become a conduit to securing otherwise insecure protocols, like POP, and increasing overall system and data security.
- </para>
- <para>
- The OpenSSH server and client can also be configured to create a tunnel similar to a virtual private network for traffic between server and client machines.
- </para>
- <para lang="en-US,as-IN,bn-IN,gu-IN,hi-IN,kn-IN,ml-IN,mr-IN,or-IN,pa-IN,si-LK,ta-IN,te-IN,pt-BR">
- Finally, OpenSSH servers and clients can be configured to authenticate using the GSSAPI implementation of the Kerberos network authentication protocol. For more information on configuring Kerberos authentication services, refer to <!-- TBD6: <xref linkend="ch-kerberos" /> -->.
- </para>
- <para>
- &MAJOROS; includes the general OpenSSH package (<filename>openssh</filename>) as well as the OpenSSH server (<filename>openssh-server</filename>) and client (<filename>openssh-clients</filename>) packages. Note, the OpenSSH packages require the OpenSSL package (<filename>openssl</filename>) which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
- </para>
- <section id="s2-ssh-intro-why">
+ <section id="s1-ssh-protocol">
+ <title>The SSH Protocol</title>
+ <section id="s2-ssh-why">
<title>Why Use SSH?</title>
<indexterm>
<primary>SSH protocol</primary>
<secondary>security risks</secondary>
</indexterm>
<para>
- Nefarious computer users have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:
+ Potential intruders have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>Interception of communication between two systems</term>
+ <listitem>
+ <para>
+ The attacker can be somewhere on the network between the communicating parties, copying any information passed between them. He may intercept and keep the information, or alter the information and send it on to the intended recipient.
+ </para>
+ <para>
+ This attack is usually performed using a <firstterm>packet sniffer</firstterm>, a rather common network utility that captures each packet flowing through the network, and analyzes its content.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Impersonation of a particular host</term>
+ <listitem>
+ <para>
+ Attacker's system is configured to pose as the intended recipient of a transmission. If this strategy works, the user's system remains unaware that it is communicating with the wrong host.
+ </para>
+ <para>
+ This attack can be performed using a technique known as <firstterm>DNS poisoning</firstterm>, or via so-called <firstterm>IP spoofing</firstterm>. In the first case, the intruder uses a cracked DNS server to point client systems to a maliciously duplicated host. In the second case, the intruder sends falsified network packets that appear to be from a trusted host.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous. If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.
+ </para>
+ </section>
+ <section id="s2-ssh-goals">
+ <title>SSH Design Goals</title>
+ <indexterm>
+ <primary>SSH protocol</primary>
+ <secondary>features of</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>OpenSSH</primary>
+ <seealso>SSH</seealso>
+ </indexterm>
+ <para>
+ The SSH protocol provides the following safeguards:
</para>
<itemizedlist>
<listitem>
<para>
- <emphasis>Interception of communication between two systems</emphasis> — In this scenario, the attacker can be somewhere on the network between the communicating parties, copying any information passed between them. The attacker may intercept and keep the information, or alter the information and send it on to the intended recipient.
+ After an initial connection, the client can verify that it is connecting to the same server it had connected to previously.
</para>
+ </listitem>
+ <listitem>
<para>
- This attack can be mounted through the use of a packet sniffer — a common network utility.
+ The client transmits its authentication information to the server using strong, 128-bit encryption.
</para>
</listitem>
<listitem>
<para>
- <emphasis>Impersonation of a particular host</emphasis> — Using this strategy, an attacker's system is configured to pose as the intended recipient of a transmission. If this strategy works, the user's system remains unaware that it is communicating with the wrong host.
+ All data sent and received during a session is transferred using 128-bit encryption, making intercepted transmissions extremely difficult to decrypt and read.
</para>
+ </listitem>
+ <listitem>
<para>
- This attack can be mounted through techniques known as DNS poisoning<footnote><para>DNS poisoning occurs when an intruder cracks a DNS server, pointing client systems to a maliciously duplicated host.</para></footnote> or IP spoofing<footnote><para>IP spoofing occurs when an intruder sends network packets which falsely appear to be from a trusted host on the network.</para></footnote>.
+ The client can forward X11<footnote><para>X11 refers to the X11R7 windowing display system, traditionally referred to as the X Window System or X. &MAJOROS; includes X11R7, an open source X Window System.</para></footnote> applications from the server. This technique, called <firstterm>X11 forwarding</firstterm>, provides a secure means to use graphical applications over a network.
</para>
</listitem>
</itemizedlist>
<para>
- Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous.
+ Because the SSH protocol encrypts everything it sends and receives, it can be used to secure otherwise insecure protocols. Using a technique called <firstterm>port forwarding</firstterm>, an SSH server can become a conduit to securing otherwise insecure protocols, like POP, and increasing overall system and data security.
+ </para>
+ <para>
+ The OpenSSH server and client can also be configured to create a tunnel similar to a virtual private network for traffic between server and client machines.
+ </para>
+ <para lang="en-US,as-IN,bn-IN,gu-IN,hi-IN,kn-IN,ml-IN,mr-IN,or-IN,pa-IN,si-LK,ta-IN,te-IN,pt-BR">
+ Finally, OpenSSH servers and clients can be configured to authenticate using the GSSAPI implementation of the Kerberos network authentication protocol. For more information on configuring Kerberos authentication services, refer to <!-- TBD6: <xref linkend="ch-kerberos" /> -->.
</para>
<para>
- If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.
+ &MAJOROS; includes the general OpenSSH package (<filename>openssh</filename>) as well as the OpenSSH server (<filename>openssh-server</filename>) and client (<filename>openssh-clients</filename>) packages. Note, the OpenSSH packages require the OpenSSL package (<filename>openssl</filename>) which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
</para>
</section>
- </section>
- <section id="s1-ssh-version">
- <title>SSH Protocol Versions</title>
- <indexterm
- significance="normal">
- <primary>SSH protocol</primary>
- <secondary>version 1</secondary>
- </indexterm>
- <indexterm
- significance="normal">
- <primary>SSH protocol</primary>
- <secondary>version 2</secondary>
- </indexterm>
- <para>The SSH protocol allows any client and server programs built to the protocol's specifications to communicate securely and to be used interchangeably.</para>
- <para>Two varieties of SSH (version 1 and version 2) currently exist. The OpenSSH suite under &MAJOROS; uses SSH version 2 which has an enhanced key exchange algorithm not vulnerable to the exploit in version 1. However, the OpenSSH suite does support version 1 connections.</para>
- <important>
- <title>Important</title>
- <para>It is recommended that only SSH version 2-compatible servers and clients are used whenever possible.</para>
- </important>
- </section>
- <section
- id="s1-ssh-conn">
- <title>Event Sequence of an SSH Connection</title>
- <indexterm>
- <primary>SSH protocol</primary>
- <secondary>connection sequence</secondary>
- </indexterm>
- <para>
- The following series of events help protect the integrity of SSH communication between two hosts.
- </para>
- <orderedlist>
- <listitem>
- <para>
- A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
- </para>
- </listitem>
- <listitem>
- <para>
- The transport layer of the connection between the client and remote host is encrypted using a symmetric cipher.
- </para>
- </listitem>
- <listitem>
- <para>
- The client authenticates itself to the server.
- </para>
- </listitem>
- <listitem>
- <para>
- The remote client interacts with the remote host over the encrypted connection.
- </para>
- </listitem>
- </orderedlist>
- <section id="s2-ssh-protocol-conn-transport">
- <title>Transport Layer</title>
+ <section id="s2-ssh-versions">
+ <title>SSH Protocol Versions</title>
+ <indexterm
+ significance="normal">
+ <primary>SSH protocol</primary>
+ <secondary>version 1</secondary>
+ </indexterm>
+ <indexterm
+ significance="normal">
+ <primary>SSH protocol</primary>
+ <secondary>version 2</secondary>
+ </indexterm>
+ <para>The SSH protocol allows any client and server programs built to the protocol's specifications to communicate securely and to be used interchangeably.</para>
+ <para>Two varieties of SSH (version 1 and version 2) currently exist. The OpenSSH suite under &MAJOROS; uses SSH version 2 which has an enhanced key exchange algorithm not vulnerable to the exploit in version 1. However, the OpenSSH suite does support version 1 connections.</para>
+ <important>
+ <title>Important</title>
+ <para>It is recommended that only SSH version 2-compatible servers and clients are used whenever possible.</para>
+ </important>
+ </section>
+ <section id="s2-ssh-conn">
+ <title>Event Sequence of an SSH Connection</title>
<indexterm>
<primary>SSH protocol</primary>
- <secondary>layers of</secondary>
- <tertiary>transport layer</tertiary>
+ <secondary>connection sequence</secondary>
</indexterm>
<para>
- The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.
- </para>
- <para>
- 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:
- </para>
- <itemizedlist>
+ The following series of events help protect the integrity of SSH communication between two hosts.
+ </para>
+ <orderedlist>
<listitem>
<para>
- Keys are exchanged
+ A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
</para>
</listitem>
<listitem>
<para>
- The public key encryption algorithm is determined
+ The transport layer of the connection between the client and remote host is encrypted using a symmetric cipher.
</para>
</listitem>
<listitem>
<para>
- The symmetric encryption algorithm is determined
+ The client authenticates itself to the server.
</para>
</listitem>
<listitem>
<para>
- The message authentication algorithm is determined
+ The remote client interacts with the remote host over the encrypted connection.
</para>
</listitem>
- <listitem>
+ </orderedlist>
+ <section id="s2-ssh-protocol-conn-transport">
+ <title>Transport Layer</title>
+ <indexterm>
+ <primary>SSH protocol</primary>
+ <secondary>layers of</secondary>
+ <tertiary>transport layer</tertiary>
+ </indexterm>
+ <para>
+ The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.
+ </para>
+ <para>
+ 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:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Keys are exchanged
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The public key encryption algorithm is determined
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The symmetric encryption algorithm is determined
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The message authentication algorithm is determined
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The hash algorithm is determined
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ During the key exchange, the server identifies itself to the client with a unique <firstterm>host key</firstterm>. 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 gets around this problem by accepting the server's host key. This is done after the user is notified and has both accepted and verified the new host key. 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.
+ </para>
+ <warning>
+ <title>Caution</title>
<para>
- The hash algorithm is determined
+ It is possible for an attacker to masquerade as an SSH server during the initial contact since the local system does not know the difference between the intended server and a false one set up by an attacker. To help prevent this, verify the integrity of a new SSH server by contacting the server administrator before connecting for the first time or in the event of a host key mismatch.
</para>
- </listitem>
- </itemizedlist>
- <para>
- During the key exchange, the server identifies itself to the client with a unique <firstterm>host key</firstterm>. 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 gets around this problem by accepting the server's host key. This is done after the user is notified and has both accepted and verified the new host key. 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.
- </para>
- <warning>
- <title>Caution</title>
+ </warning>
<para>
- It is possible for an attacker to masquerade as an SSH server during the initial contact since the local system does not know the difference between the intended server and a false one set up by an attacker. To help prevent this, verify the integrity of a new SSH server by contacting the server administrator before connecting for the first time or in the event of a host key mismatch.
+ SSH is designed to work with almost any kind of public key algorithm or encoding format. After an initial key exchange creates a hash value used for exchanges and a shared secret value, the two systems immediately begin calculating new keys and algorithms to protect authentication and future data sent over the connection.
</para>
- </warning>
- <para>
- 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.
- </para>
- <para>
- 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.
- </para>
- </section>
- <section id="s2-ssh-protocol-authentication">
- <title>Authentication</title>
- <indexterm>
- <primary>SSH protocol</primary>
- <secondary>authentication</secondary>
- </indexterm>
- <para>
- Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.
- </para>
- <para>
- SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.
- </para>
- </section>
- <section id="s2-ssh-protocol-connection">
- <title>Channels</title>
- <indexterm>
- <primary>SSH protocol</primary>
- <secondary>layers of</secondary>
- <tertiary>channels</tertiary>
- </indexterm>
- <para>
- After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called <firstterm>multiplexing</firstterm><footnote><para>A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.</para></footnote>. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
- </para>
- <para>
- Both clients and servers can create a new channel. Each channel is then assigned a different number on each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions do not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection.
- </para>
- <para>
- Channels also support <firstterm>flow-control</firstterm>, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the client receives a message that the channel is open.
- </para>
- <para>
- The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.
- </para>
+ <para>
+ 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.
+ </para>
+ </section>
+ <section id="s2-ssh-protocol-authentication">
+ <title>Authentication</title>
+ <indexterm>
+ <primary>SSH protocol</primary>
+ <secondary>authentication</secondary>
+ </indexterm>
+ <para>
+ Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.
+ </para>
+ <para>
+ SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.
+ </para>
+ </section>
+ <section id="s2-ssh-protocol-connection">
+ <title>Channels</title>
+ <indexterm>
+ <primary>SSH protocol</primary>
+ <secondary>layers of</secondary>
+ <tertiary>channels</tertiary>
+ </indexterm>
+ <para>
+ After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called <firstterm>multiplexing</firstterm><footnote><para>A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.</para></footnote>. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
+ </para>
+ <para>
+ Both clients and servers can create a new channel. Each channel is then assigned a different number on each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions do not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection.
+ </para>
+ <para>
+ Channels also support <firstterm>flow-control</firstterm>, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the client receives a message that the channel is open.
+ </para>
+ <para>
+ The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.
+ </para>
+ </section>
</section>
</section>
<section id="s1-openssh-server-config">
More information about the docs-commits
mailing list