SSH Chinese documents

SSH Chinese documents

SSH is a security protocol created on the application layer and transport layer, which is used to replace the poor security telnet and secure login.

SSH is currently a more reliable protocol that provides security for Telnet sessions and other network services. The use of SSH protocol can effectively prevent the information leakage in the remote management process. SSH allows you to encrypt all transmitted data, as well as to prevent DNS spoofing and IP spoofing.

Another advantage of SSH is that the data it transmits can be compressed, so it can speed up the transfer. SSH has many functions, which can replace Telnet and provide a secure "channel" for FTP, POP, and even PPP. ...

This document specifies the Internet standard tracking protocol for the web community and requests discussions and recommendations for improvement. Please refer to the "Official Internet Protocol Standard" (STD1) for the current version of the standardization and status of this agreement. The release of this document is constantly updated.

Summary

The Secure Shell (SSH) protocol is a protocol that provides secure remote logins and other network services on unsecured networks, which describes the architecture of the SSH protocol and the symbols and terminology used in the SSH protocol file. It also discusses the naming system for SSH algorithms, supporting local extensions (such as user-defined algorithms, customer-defined key rules, high-level extended functional application protocols). The SSH protocol consists of three main components: 传输层协议 server Authentication, data confidentiality, information integrity, and other support. 用户认证协议provides client authentication for the server. The 连接协议 encrypted information tunnel is reused as a number of logical channels for use in higher-level application protocols. The details of these protocols are described in a separate file.

Brief introduction

SSH (Security Shell) is a protocol for secure remote logins and other secure network services on unsecured networks.
It consists of three main parts:

The 0 Transport layer Protocol [Ssh-trans] provides server authentication, confidentiality, and integrity. It is also optional to provide compression. Transmission
Layer typically runs on a TCP/IP connection, but it can also be used on any other reliable data stream.

0 authentication protocol [Ssh-userauth] authenticates the client user to the server. It runs on the Transport Layer protocol.

0 Connection protocol [Ssh-connect] the encryption tunnel is multiplexed into several logical channels. It runs on the authentication protocol.

After a secure Transport layer connection is established, the client sends a service request. After the user authentication is complete, the second service request is issued. This allows new protocols to be defined and coexist with the above protocols.

The channel provided by the Connection Agreement can be used for a wide range of purposes. Provides a standard method for establishing a secure interactive shell process and forwarding (tunneling) any TCP/IP port and X11 connection.

The customary conventions in this article

All documents related to the SSH protocol should use the keywords "must", "Forbidden (Never)", "must", "should", "not should", "recommended", "Can", "optional" to describe the requirements. The meanings of these keywords conform to the description of [RFC2119].

The keywords in this article that describe namespace allocation are "PRIVATE use", "Hierarchical ALLOCATION",
"First COME first SERVED", "EXPERT REVIEW", "Specification REQUIRED",
The meanings of "IESG APPROVAL", "IETF CONSENSUS" and "standards ACTION" conform to [RFC2434]
Description of the.

protocol domains and possible values are defined in the protocol documentation. The protocol domain is defined in the message definition. For example
Ssh_msg_channel_data is defined as follows:

    byte   SSH_MSG_CHANNEL_DATA      uint32   recipient channel      string   

In the entire protocol document, when referencing a field, the name of the field appears in single quotation marks. When referencing the values of a field, they appear in double quotation marks. For example, the possible value of ' data ' is ' foo ' and ' bar '.

Schema master key

Each server host should have a master secret key. Hosts can have multiple host keys that use different algorithms. Multiple hosts can share the same host secret key. If the host has a key, then there must be at least one key for each of the required public key algorithm (DSS).

The server host key is used in the key exchange to verify that the client is really talking to the correct server. To make it possible, the client must know in advance the public key of the server host key.

Two different trust models can be used:

0 The client has a local database that associates each host name (the same as the user input) with the corresponding host key key. This approach does not require a centrally managed infrastructure or third-party collaboration. The disadvantage is that the host name-the maintenance of the key association database can be a burden.

0 Host name-the key association is certified by a trusted certification authority (CA). The client knows only the CA root key and is able to verify the validity of all the CA-certified host keys. The second approach eliminates maintenance issues because ideally only one CA key needs to be safely saved on the client. On the other hand, each master key must be certified in the proper way by a central authority before verification. At the same time, the central infrastructure has been placed in great trust.

The protocol provides this option: the Association of the server name-host key is not checked when connecting to the host for the first time. This allows communication without prior knowledge of the host key or certificate. The connection still provides protection against passive listening (passive listening), but it is susceptible to aggressive man-in-the-middle attacks (active man-in-the-middle attacks). System implementations should not allow this connection by default, because of the potential security issues that may occur. But
Since there is no widely deployed key infrastructure on the Internet at the time of this writing, this option greatly improves the availability of the protocol during the transition period prior to this infrastructure, while still providing much higher security than older solutions such as Telnet and rlogin.

The system implementation should try to check the host key. One possible strategy is to save the key to the local database only when the first connection to a host is not checked, and then to compare this as a baseline for all future connections to that host.

The system implementation can provide an additional way to verify the correctness of the master key, for example, by generating a hexadecimal digital fingerprint from the public key by SHA-1 Hash. This digital fingerprint can be easily checked by telephone or other external communication channels.

All system implementations should provide an option: Do not accept host keys that cannot be inspected.

Members of this working group believe that "ease-of-use" is the key to end-user acceptance of a security solution, without any security improvements if the new solution is not and is adopted. Therefore, the option to provide no check of the server host key increases the overall security of the Internet, although it reduces the security of the Protocol in settings that allow this option.

Scalability

We believe that the protocol will evolve over time and some organizations will want to use their own encryption, authentication, and/or key interaction methods.

Centralized registration of all extensions is cumbersome, especially for experimental or confidential features. On the other hand, no centralized registration can cause method identifier collisions, affecting interoperability.

We choose to identify the algorithm, method, format, and extension protocol by name in a particular format. The DNS name is used to create a local namespace in which you can define pilot or confidential extensions without worrying about conflicts with other system implementations.

One design goal is to keep the underlying protocols as simple as possible and require as few algorithms as possible. However, all system implementations must support a small collection of algorithms to ensure interoperability (this does not mean that local policies on all hosts will allow these algorithms).

The mandatory algorithm is specified in the relevant protocol documentation.

Additional algorithms, methods, formats, and extension protocols can be defined in a separate document. See section 6th, algorithm naming.

Policy issues

The protocol allows for complete negotiation of encryption, integrity, key exchange, compression, and public-key algorithms and formats. The encryption, integrity, public key, and compression algorithms in the two transport directions can be different.

The following policy issues should be resolved in the configuration mechanism of the system implementation:

0 encryption, integrity, and compression algorithms for each transmission direction. The policy must specify which one is the preferred algorithm (for example, the first algorithm listed under each category).

0 host authentication uses the public key algorithm and the key exchange method. Existing trusted host keys that use different algorithms also affect this choice.

0 The authentication method that the server requires for each user. Server policies can require multiple authentication for some or all users, and the required algorithm can depend on where the user is attempting to obtain authorization.

0 The user is allowed to use the connection protocol for the operation. Some issues are related to security; For example, a policy should not allow a server to start a process or run a command on a client, and must not allow connections to the authentication agent unless it is required to forward the
Kind of connection. Other issues, such as who is able to forward that TCP/IP port, are obviously local policies. A lot
Such problems may involve traversing or bypassing firewalls and connecting to local security policies.

Safety features

The main purpose of the SSH protocol is to improve the security of the Internet. It tries to achieve this through an easy-to-deploy approach, even at the expense of absolute security.

All of the encryption, integrity, and public-key algorithms used in 0 are well-known and mature algorithms.

0 All algorithms use key lengths that appear to be reasonable in cryptography, meaning that the key length is considered to provide protection against strong key parsing attacks within a few decades.

0 All algorithms can be easily switched to other algorithms without the need to modify the underlying protocol, through negotiation, in the case of some algorithms failure.

In order to make large-scale, rapid deployment easy to implement, the agreement made a specific compromise. Specifically, the protocol allows no validation, but is not recommended, in terms of verifying that the server host key does belong to the target host. This is thought to significantly improve the availability of the protocol in the short term until there is a pervasive Internet public key infrastructure.

Localization and Character set support

In most cases, the SSH protocol does not pass the text that will be displayed to the user directly. However, in some cases this data may be passed. When applicable, the character set of the data must be explicitly specified. In most cases, the ISO-10646 UTF-8 encoding is used [RFC3629]. When applicable, a field is also used for language markers.

An important issue is the character set of the interactive process. There is no clear solution to this problem because different applications may display data in different formats. The client may also use different types of terminal emulation, and the character set to be used is actually determined by the terminal emulation. As a result, no location is provided for the character set or encoding that directly specifies the terminal process data. However, the terminal emulation type (for example, "VT100") is routed to the far end, which implicitly specifies the character set and encoding. The application software typically uses the terminal type to determine what character set to use, or the character set is determined by some external methods. Terminal emulation may also allow setting the default character set. In any case, the character set of the terminal process is considered primarily a client-local issue.

The internal name used to identify the algorithm or protocol is generally not displayed to the user, and must be us-ascii.

The client and server user names are inherently constrained by the server's acceptable name. They may sometimes appear in logs, reports, and so on. They must use ISO-10646 UTF-8 encoding, but in some cases other encodings may be required. The server determines how the user name corresponds to the accepted user name. It is recommended to use direct bit-based, binary comparisons.

In order to localize, the protocol attempts to minimize the number of text messages that are transmitted. When present, these messages are usually related to errors, debugging information, or some external configuration data. For the data to be displayed in the general case, a numeric encoding should be used to make it possible to replace the transmitted message with a localized message. Text messages should be configurable.

Data type notation used by the SSH protocol

Byte
A byte identifies any 8-bit value (8-bit byte). Fixed-length data is sometimes represented as a byte array, written
Byte[n], where n is the number of bytes in the array.

Boolean
A Boolean value is stored as a byte. 0 indicates that false,1 represents true. All nonzero values must be interpreted as
TRUE; However, the application software prohibits storing values other than 0 and 1.

UInt32
Represents a 32-bit unsigned integer. Stored as 4 bytes in descending order of importance (network byte order). For example

UInt64
Represents a 64-bit unsigned integer. Stored as 8 bytes in descending order of importance (network byte order).

String
A binary string of any length. Strings are used to mount any binary data, including null characters and 8-bit characters. Character
The string is stored as 1 UInt32 with its length (number of subsequent bytes) and 0 (= empty string) or as a character
More bytes for the value of the string. Do not use Terminator (null character).

Strings are also used to store text. In this case, the internal name uses US-ASCII, which may be displayed to the user's
The text uses ISO-10646 UTF-8. Terminator (null characters) should not normally be saved in a string. For example
The US-ASCII string "testing" is expressed as the T-e s t i n g of the xx xx. UTF-8 Mapping does not
Changes the encoding of the us-ascii character.

Mpint
A multi-precision integer representing the binary complement (two ' s complement) format, stored as a string, per byte
8 bits, from high to Low (MSB first). The first byte of the data area of the negative number (the most
Significant bit) has a value of 1. For positive numbers, if the high position is set to 1, you must precede the
A value of 0 bytes. Suppresses non-essential leading bytes with a value of 0 or 255 (leading bytes). 0 must
Must be stored as a string with 0 bytes of data.

Cases:

value (hex)          representation (hex)  -----------          ------------------- 0                    00 00 00 00  9a378f9b2e332a7      00 00 00 08 09 a3 78 f9 b2 e3 32 a7  80                   00 00 00 02 00 80  -1234                00 00 00 02 ed cc  -deadbeef            

Name-list
A string that contains a comma-delimited list of names. A list of names is represented as one containing its length (number of subsequent bytes)
UInt32, plus a list of 0 or more comma-delimited names. The length of the name is forbidden to 0, and the forbidden
Contains a comma (","). Since this is a list of names, all contained elements are names and must be used
Us-ascii. The context may have additional restrictions on the name. For example, names in a name list might have to be a series of
A valid algorithm identifier, or a series of [RFC3066] language identifiers. The order of names in the name list may or may not
Make sense. This depends on the context in which the list is used. Disables the use of the terminating character for a single name or for the entire list (empty
characters).

Cases:

value           representation (hex)  -----           ------------------- ()，空名称列表    00 00 00 00  ("zlib")        00 00 00 04 7a 6c 69 62  ("zlib,none")   00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65  

Algorithm and method naming

The SSH protocol uses names to refer to specific hashing, encryption, integrity, compression, and key exchange algorithms or methods. There are a number of standard algorithms and methods that all system implementations must support. There are also algorithms and methods that are defined in the protocol, but are optional. In addition, it is expected that some organizations will want to use their own algorithms or methods.

In this agreement, the identification of all algorithms and methods must be a non-empty string consisting of printable Us-ascii characters, with a length not greater than 64 characters. The name must be case-sensitive.

The algorithm and method names are in two forms:

0 name without the at sign ("@") in order to wait for the IETF CONSENSUS (Internet Engineering Task Force Assignment)
Keep. such as "3DES-CBC", "Sha-1", "HMAC-SHA1", and "zlib" (double quotation marks are not part of the name
Points). The name of this format must be registered with the IANA (Internet number distribution authority) before it is valid. Name of the registration
Prohibit include at sign ("@"), comma (","), Space, control character (ASCII code 32 and below) or ASCII
Code 127 (DEL). The name is case sensitive, and the length is forbidden to exceed 64 characters.

0 Anyone can define an additional algorithm or method using a name that conforms to the [email protected] format, for example,
"[Email protected]". The format of the part before the at sign is not specified, but must be printable
ASCII string, and it is forbidden to include commas (","), spaces, control characters (ASCII code 32 and below), or
ASCII Code 127 (DEL). It must have only one at sign. The part after the at sign must be a defined by the name
A valid, fully qualified domain name that is controlled by a person or organization [RFC1034]. The name is case-sensitive and long
More than 64 characters are prohibited. How the local namespace is managed depends on the individual domains. It should be stated that the name here looks
The same as email address STD one [RFC0822]. This is purely coincidental, and with STD [RFC0822]
There is no relationship.

Message number

The message number of the SSH packet is from 1 to 255. These numbers are assigned as follows:

Transport Layer Protocol:

  1 to 19    传输层通用（例如，断开连接、忽略、除错等）  20 to 29   算法协商  30 to 49   密钥交换方法规定（编号可被重用于不同的交换方法）

Authentication protocol:

  50 to 59   用户验证通用   60 to 79   用户验证方法规定（编号可被重用于不同的验证方法）

Connection protocol:

  80 to 89   连接协议通用  90 to 127  

Reserved for client protocols:

  128 to 191 保留

Local extension::

  192 to 255 本地扩展

IANA Considerations

The IANA guidelines for the SSH protocol defined for [Ssh-arch], [Ssh-trans], [Ssh-userauth], and [Ssh-connect] are described in [ssh-numbers]. The following is a simple summary, but note [ssh-numbers] contains practical guidelines for the IANA, which may be superseded by new content in the future.

In the SSH protocol, the assignment of the following types of names is specified by the IETF consensus:

0 Service Name
* Verification Method
* Connection Protocol Channel name
* Connection Agreement Global request name
* Connection Protocol Channel request name

0 Key Exchange method name

0 The specified algorithm name
* Encryption Algorithm Name
* Mac algorithm Name
* Public Key algorithm name
* Compression algorithm Name

These names must be printable us-ascii strings and are prohibited to include an at sign ("@"), a comma (","), a space, a control character (ASCII code 32 and below), or an ASCII code 127 (DEL). The name is case sensitive, and the length is forbidden to exceed 64 characters.

The name that contains the at sign ("@") is a locally defined extension that is not controlled by the IANA.

Each of the name categories listed above has a separate namespace. However, you should avoid using the same name in multiple categories to minimize confusion.

The message number in the range 0 to 191 (see 7th) is allocated through the IETF consensus, see [RFC2434]. The message number (local extension) within the range of 191 to 255 is reserved for private use, see also [RFC2434].

Security Considerations

To make all security considerations easier to understand, the security considerations for transferring, validating, and connecting documents are concentrated here.

The Transport layer protocol [Ssh-trans] provides a secret channel on an unsecured network. It performs server host authentication, key exchange, encryption, and integrity protection. It also forms a unique session ID that can be used by a higher-level protocol.

The authentication protocol [Ssh-userauth] provides a set of mechanisms that can be used to authenticate client users to the server. Each mechanism stipulated in the authentication protocol uses the session ID provided by the Transport Layer protocol and/or relies on the security and integrity assurance of the Transport Layer protocol.

The connection protocol [Ssh-connect] specifies a multiplexing mechanism for implementing multiple data streams (channels) on a confidential, authenticated transmission. It also specifies the channel that uses the interactive command interpreter (shell), the channel that implements various external protocols on the secure transport via port forwarding (including any TCP/IP protocol), and the channel that uses the security subsystem on the server host.

Pseudo-random number generation

This protocol contains random, corresponding session-specific data in the hash value used to generate the session key, thus each session key
Session binding. Special care should be taken to ensure that all random numbers have good quality. If the random data here (for example,
Diffiehellman parameter) is pseudo-random, then the pseudo-random number generator should be cryptography safe (for example, it's under
An output cannot be easily guessed, even if all previous outputs are known, and the appropriate entropy needs to be added to the pseudo-random number generator. [RFC4086] provides recommendations for random numbers and entropy sources. The implementers should note the importance of entropy and a good-natured warning of the difficulty of correctly implementing a pseudo-random number generation formula.

The entropy that can be provided to the client or server may sometimes not reach the required amount. In this case, the pseudo-random number generator must continue to be used in the case of insufficient entropy, or the protocol will be denied. The latter is a more recommendable approach.

controlling character filtering

When displaying text to the user, such as errors or error messages, the client software should replace any control characters (except tabs, carriage returns, line breaks) with a safe sequence to avoid attacks that control characters through the sending terminal.

Transport confidentiality

It is beyond the scope of this article and the Working Group to analyze or recommend specific ciphers other than those already mature and accepted by the industry. At the time of this writing, the commonly used ciphers included 3DES, Arcfour, Twofish, Serpent, and Blowfish.

AES has been published by the U.S. Federal Information Processing Standard as [FIPS-197], and cryptography has accepted AES. As usual, implementations and users should consult the current literature to ensure that new vulnerabilities are not found in the cryptographic devices used by the product. The implementation should also check which ciphers are considered relatively strong and should recommend these stronger ciphers to the user. When a weaker cipher is chosen, the product can politely and unobtrusive inform the user that a stronger algorithm is valid and should be used, which should be considered a good feature.

"None" such an encryption device is provided for debugging and should not be used for other purposes. Its cryptographic characteristics are in [RFC2410]
is fully described and shows that it does not conform to the purposes of this agreement.

The pros and cons of these and other ciphers can also be found in the current literature. [SCHNEIER] and [KAUFMAN] the two parameters
Information on this topic can be provided in the literature. Both references describe the Cipher block link pattern for a particular cipher
And the weaknesses of the model. In essence, because of the high predictability at the beginning of the data series, this model theoretically
The optional ciphertext attack (chosen Cipher-text attack) is fragile. However, this attack is considered to be difficult and
is not fully predictable, especially if the size of the data block used is relatively large.

In addition, another CBC mode attack can be mitigated using the method of inserting packets containing ssh_msg_ignore. Without using this technique, a particular attack might succeed. This attack (commonly called rogaway attack [Rogaway], [DAI], [bellare]) takes effect, and an attacker needs to know the initial vector (IV) of the next block of data that will be encrypted. In CBC mode, it is the output that encrypts the previous block of data. If an attacker does not have any way to view the packet (that is, it is in the internal buffer or even the kernel implemented by the SSH system), then this attack will not take effect. If the previous packet has been sent to the network (that is, the attacker can get it), then he is able to use the attack.

Ideally, an implementation would need to add an additional packet only if the packet was sent to the network and no other packets were waiting for delivery. The implementation may wish to check for packets that are still waiting to be sent; Unfortunately, getting that information from the kernel or buffer is not always easy. If there are no unsent packets, then a packet containing ssh_msg_ignore should be sent. If each attacker knew that the next packet assumed the IV, a new packet was added to the data stream, the attacker would not be able to guess the correct IV so that the attack would never succeed.

As an example, consider the following scenarios:

    Client                                     Server      ------                                     ------     TCP(seq=x, len=500)       ---->      contains Record 1                       [500 ms passes, no ACK]      TCP(seq=x, len=1000)      ---->      contains Records 1,2                                                    

1. The bundle optimization algorithm (Nagle algorithm) +tcp means that two records are merged into a single TCP fragment.
2. Record 2 is not at the beginning of a TCP fragment and will never be, because it obtains a reply (ACK).
3. However, the attack is possible because record 1 has been sent out.

This example indicates that there is no clear data in the TCP buffer as a condition for whether an empty packet is required
Safe, because when the second write () is executed, the buffer will contain 1 of records that have not been answered.

On the other hand, the following conditions are completely safe:

Client                                          Server  ------                                          ------ TCP(seq=x, len=500)            ----> contains SSH_MSG_IGNORE  TCP(seq=y, len=500)            

Assuming that the second SSH Record IV is fixed when the data for the packet is determined, the following steps should be performed:
Read user input (read from user)
Encrypt empty packets (encrypt null packet)
Encrypted packets (encrypt data packet)

Data integrity

This agreement does allow the data integrity mechanism to be disabled. The implementing person should be particularly cautious when using this feature for purposes other than error.
When the "none" type of mac (data check code) is enabled, you should explicitly warn users and administrators.

This agreement provides data integrity as long as the "none" type of Mac is not used.

Since the Mac uses a 32-bit ordinal number (sequence numbers), it may be 2**32 after sending a packet
Start leaking information. However, updating the key according to the recommendation should prevent this attack. The transport protocol [Ssh-trans] recommends updating the key after 1G bytes of data, and the possible small packet is 16 bytes. As a result, the key should be updated after 2**28 packets.

Replay

The use of a Mac other than "none" provides integrity and validation. In addition, the transport protocol provides a unique session ID (partially related to the pseudo-random data binding of the participating algorithm and the key exchange process), which can be used by high-level protocols to bind data to a particular session to prevent replay of previous session data. For example, the authentication protocol [Ssh-userauth] uses it to prevent the replay of a previous session's signature. Because the public key authentication interchange is a cryptographic session bound (that is, bound to the initial key exchange), it cannot be successfully replayed in other sessions. Note that the session ID can be exposed without compromising the security of the Protocol.

If two sessions have the same session ID (the hash value of the key exchange), then one of the session's packets can be used for replay attacks against another session. It should be stressed that the odds of this happening are, without a doubt, minimal when using modern cryptography methods. This is especially true when you specify a large hash function output and a DH parameter.

In [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC4120], the
In some cases, the serial number of the monocytogenes is used as the input of the Mac or HMAC to detect replay and is described. [RFC2104] discusses the underlying structure. Basically, a different sequence number in each packet guarantees that at least the sequence number in the input of the MAC function is not the same, providing a non-reproducible Mac output that the attacker cannot predict. However, if the session remains active long enough, the sequence number will start at the beginning of the Da Yu large value. This may provide an opportunity for an attacker to replay the same sequence of packets that were previously recorded, but only if the communicating parties did not update the key after the previous packet using the sequence number was transmitted. If the key is updated by the communicating parties, replay will be detected due to MAC checksum failure. To do this, it must be emphasized that the communication parties must update the key before the sequence number starts from the beginning. Naturally, if an attacker does attempt to replay a captured packet before the communicating parties update the key, the recipient of the duplicate packet will not be able to verify the legitimacy of the MAC and discard the packet. The reason for Mac failure is that the receiver calculates a Mac based on the contents of the packet, the shared secret (Gkfx secret), and the expected ordinal number. Since the replayed packet is not using the expected sequence number (the serial number of the replay packet is already over by the recipient), the computed Mac will not match the MAC received from the packet.

Middleman

The protocol does not make assumptions or provisions for the infrastructure or method of assigning the host public key. It is expected that at some point when this agreement is used, the association between the server host key and the server hostname is not checked. This usage is vulnerable to man-in-the-middle attacks. This section describes this and advises administrators and users to understand the importance of verifying this association before initializing any session.

There are three types of man-in-the-middle attacks to consider. The first is that the attacker placed a device between the client and the server before the session was initialized. In this case, the attack device attempts to impersonate a legitimate server and provides its public key to the client when the client initializes the session. If it provides the public key of the server, it will not be able to decrypt or sign the transport between the legitimate server and the client, unless it also acquires the host's private key. At the same time, the attack device will impersonate a client to initialize a session with a legitimate server. If the server's public key is securely assigned to the client before the session is initialized, the key that the attack device provides to the client does not match the key that the client saved. In this case, you should warn the user that the host key provided is inconsistent with the host key that the client is staging. As described in 4.1, the user can be allowed to accept the new key and continue the session. It is recommended that the above warnings contain sufficient information about the client device to enable the user to make informed decisions. If the user chooses to continue the session using the stored server public key (rather than the public key provided at the beginning of the session), the client-attacker session will be different from the session-specific data in the attacker-server session due to the randomness discussed above. From this point of view, since the attacker does not have a server private key, the attacker will not be able to properly sign the packets that contain session-specific data from the server, so the attack cannot succeed.

The second scenario to consider is similar to the first, but also occurs when connecting, but this situation indicates the need to secure the allocation of the server public key. If the server public key is not securely allocated, the client cannot know if it is talking to the target server. An attacker could use social engineering (social engineering) techniques to allow unsuspecting users to accept an impersonated server key and then place a man-in-the-middle attack device between legitimate servers and clients. If this happens, then the client will generate a client-to-attacker session, which will result in an attacker-server session where the attacker will be able to monitor and manipulate all transmissions between the client and the legitimate server. Server administrator good to provide a way to check the master key fingerprint, the security of this method does not depend on the integrity of the actual master key. Possible mechanisms, in addition to those discussed in 4.1, may include secure Web pages, physical paper, and so on. The implementation of such a mechanism in the implementation of the system, such as He Yixian, should be recommended. Since this agreement is extensible, future expansion of this Agreement may provide a better mechanism to address the need to know the server's host key before connecting. For example, you might provide a master key fingerprint in a secure DNS lookup (DNS lookup), or use Kerberos ([RFC4120]) on GSS-API ([RFC1964]) in a key exchange to validate the server.

In the case of a third man-in-the-middle attack, an attacker could attempt to manipulate packets transmitted between the communicating parties after the session is established. A successful attack in this way is unlikely, as 9.3.3 describes. 9.3.3 's reasoning does assume that the Mac is secure, and it is not possible to construct the input of the MAC algorithm to obtain a known specific output. This is discussed in more detail in section 6th of [RFC2104]. If the MAC algorithm is vulnerable or weak enough, an attacker could specify a specific input to produce a known Mac. By doing this, an attacker could modify the contents of a packet in transit. Alternatively, an attacker could review the Mac of the captured packet and exploit the vulnerability or weakness of the algorithm to find the shared secret. In either case, an attacker could construct one or more packets and insert an SSH data stream. In order to prevent this, the realization of the use of generally accepted Mac algorithm, Administrator Yun good attention to the current cryptography literature and discussion, to ensure that there is no use of Yun near the discovery of vulnerabilities or weaknesses of the MAC algorithm.

In summary, using this protocol without establishing a reliable binding on the host and host keys is inherently unsafe and is not recommended. However, in an environment where security is not critical, this use of this Agreement may be necessary and will still provide protection against passive attacks. This agreement and the implementation of the application running on top of this agreement should bear in mind this possibility.

Denial of Service

This protocol is designed to be based on reliable transmission. If there is a transmission error or message manipulation (msg manipulation), the connection will be disconnected. If this behavior occurs, the connection should be re-established. Such denial-of-service attacks, like wire cutter, are almost impossible to avoid.
In addition, this protocol is vulnerable to denial-of-service attacks because an attacker can force a service to perform connection-building and key-exchange tasks that consume large amounts of CPU and memory without being authenticated. The implementation should provide features that make this attack more difficult, such as allowing connections to only a subset of the clients that have legitimate users.

Covert Channel

This protocol has not been designed to eliminate covert channels. For example, padding (padding), ssh_msg_ignore messages, and several other locations in the protocol can be used to pass covert information, and the recipient does not have a reliable way to verify that this information is being sent.

Forward security

It is important to note that the Diffie-hellman key exchange can provide full forward security (PFS). In essence, PFS is
A cryptographic attribute of a key establishment protocol that indicates that the session key or long-term private key is compromised after a particular session and does not cause an earlier session to leak [ansi-t1.523-2001]. Use the Diffie-hellman in [Ssh-trans]
The key exchange section describes the Diffie-hellman method (including "Diffie-hellman-group1-sha1" and "DIFFIE-HELLMAN-GROUP14-SHA1") created by the SSH session, even if the private key/ It is still safe to verify that the data was later disclosed, but it is no longer secure if the session key is disclosed. Therefore, for the above-mentioned PFS definition, SSH does have PFS. However, this property is not passed to any application or protocol that uses SSH as a transmission (commuted to). The transport layer of SSH provides password authentication and other methods that rely on secret data.

Of course, if the DH private parameters of the client and server are disclosed, then the session key is disclosed, but the content can be discarded after the key exchange is complete. It is worth noting that these contents should not be placed in a swap space, but they should be erased from memory immediately after the key exchange is complete.

Order of key exchange methods

As stated in the algorithm negotiation section in [Ssh-trans], each device sends a list of preferred key exchange methods. The preferred method is the first one in the list. It is recommended to sort the algorithm according to the strength of cryptography, the first of which is strong. Some additional guidelines for this issue are given in [RFC3766].

Analysis of Traffic volume

Passive interception of any protocol may give an attacker information about a session, user, or protocol that cannot be collected by other means. For example, traffic analysis for an SSH session has been shown to generate information about the length of the password-[openwall] and [USENIX]. The implementation should use Ssh_msg_ignore packets and fill with random lengths to prevent attempts to analyze traffic. Other methods may also be discovered and implemented.

Authentication protocol

The purpose of this agreement is to perform client user authentication. It assumes that it is running on a secure Transport layer protocol, that the Transport layer protocol has verified the server, established an encrypted communication channel, and computed a unique session ID for the session.

Several authentication methods with different security features are allowed. For each user, the server can accept which method (or combination of methods) is determined by the server's local policy. The verification strength will not be higher than the allowable combination of weak.

The server can enter a sleep period after repeated unsuccessful verification attempts, making the keyword retrieval more difficult for attackers. Care should be taken to make this mechanism not directed to self-denial of service (selfdenial of services).

Weak connections

If the transport layer does not provide confidentiality, authentication methods that rely on secret data should be disabled. If the transport layer does not provide strong integrity protection, requests to modify the validation data (for example, modify the password) should be disabled to prevent the attacker from modifying the ciphertext without being noticed, or making the new authentication data unavailable (denial of service).

The above assumptions-the verification protocol is very important to run only in advance to verify the secure transfer of the server. Remind the person deploying SSH that if the client does not have a very strong prior (priori) association between the server and the server host key, the consequences will result in a man-in-the-middle attack. In particular, in the case of authentication protocols, the client may generate a session to a man-in-the-middle attack device and leak user credentials such as user name and password. Even in the absence of validation that the user credential is compromised, an attacker could capture keystrokes to get unwanted information, essentially the same way as a honeypot (honeypot) program.

Debug error message

Special care should be taken when designing an error-removing message. If the design is unreasonable, these messages may reveal a surprising number of information about the host. If high security is required, the error message can be disabled during the user authentication phase. Host administrators should try various methods to divide all event notification messages and protect them from unauthorized viewing. Developers should be wary of the nature of some normal events and error messages, and may want to provide administrators with guidelines on how to prevent unauthorized persons from contacting them. Developers should consider making the sensitive information available to users in the validation phase a small, local strategy. For this reason, it is recommended to disable the error message at deployment time and require the administrator to proactively enable it. At the same time, when the administrator enables the error message, it is recommended to display a message about the above content.

Local Security Policy

The provider must ensure that the provided credentials authenticate the user and must ensure that the server's local policy allows the user's access request. In particular, due to the flexibility of the SSH connection protocol, it may not be possible to determine which, if any, local security policy should be applied when validating, because the service requested by the user at this time is uncertain. For example, a local policy might allow users to access files on the server, but not allow the interactive command interpreter to start. However, in the authentication protocol, it is not known that the user will be accessing the file, attempting to use the interactive command interpreter, or both. In any event, when the server host's local security policy exists, it must be applied and enforced correctly.

The implementation is good. Provides a default local policy and informs administrators and users of its parameters. The implementation is in its sole discretion, and the default strategy is to follow the "what's anything-goes" route, without any restrictions on the user, or along the "extreme
Limit (excessively-restrictive) "route, which allows an administrator to proactively modify the initial default parameters
To meet their needs. Alternatively, you can try to provide an administrator with a practical and immediately available policy so that they don't have to work too hard to get ssh up and running. Whichever choice you make, you must apply and enforce it as per the requirements above.

Public key validation

Using public key validation assumes that the client host is not compromised. It also assumes that the server host's private key is not compromised.

This risk can be reduced by using a password sentence (passphrases) on the private key, but this is not a policy that can be enforced. It is recommended that you use smart cards or other techniques to make a password sentence a policy that can be enforced.

The server can require both password and public key authentication, but this requires the client to expose its password to the server (see password validation in the next section).

Password verification

The password mechanism, as stipulated in the authentication protocol, assumes that the server is not compromised. If the server is compromised, using password authentication will display a valid username/password combination to the attacker, which could lead to further leaks.

This vulnerability can be mitigated by the use of other authentication methods. For example, public key validation does not assume that the security of the server

Host-based authentication

Host-based validation assumes that the client is not compromised. There is no strategy to mitigate risk in addition to using a combination of another validation method.

Connection protocol End Security

The E connection protocol assumes end security. If the server is compromised, any terminal sessions, port forwarding, or system access on that host will be compromised. There is no risk reduction factor for this.

If the client is compromised, and the server fails to block the attacker in the authentication protocol, all exposed services (whether subsystem or through mapping) are vulnerable to attack. The provider should provide a mechanism for administrators to control which services are exposed to limit the vulnerability of other services. The above controls may include controlling which machines and ports can be targeted in port forwarding, which users are allowed to use interactive command interpreters, or which users are allowed to use exposed subsystems.

Agent forwarding

The SSH connection protocol allows proxy forwarding of other protocols, such as SMTP, POP3, and HTTP. This may be an issue to consider for network administrators who want to control the access of physically external users to specific applications. In essence, the forwarding of these protocols may violate the (site-specific) security policy that belongs to a specific location because they can penetrate the firewall in a way that is not detectable. The implementation provider should provide a management mechanism to control the agent forwarding function so that security policies belonging to a particular location may be maintained.

In addition, you can use the reverse proxy forwarding feature, which can also be used to bypass firewall control.

As noted above, end security is assumed in the agent forwarding operation. End-of-security failure will compromise all data transmitted by proxy

X11 forwarding

Another form of proxy forwarding provided by the SSH Connection protocol is the forwarding of the X11 protocol. If End security fails, X11 forwarding may allow an attack on the X11 server. Users and administrators should, of course, use reasonable X11 security mechanisms to prevent unauthorized use of X11 servers. To further explore the X11, administrators, and users of security mechanisms, see [Scheifler] and analyze the problem of interaction between SSH forwarding and X11 reported before CERT vu#363181 and Vu#118892[cert].

Using SSH's X11 remote display (display forwarding), on its own, is not enough to solve the well-known X11
Security issues [Venema]. However, the X11 remote display of SSH (or other security protocols), combined with the actual and virtual explicit (actual and Pseudo-display) connections that are only accepted by a license or access control List (ACL) that is authorized by the local interprocess communication (IPC) mechanism, It does solve a lot of X11 security issues, as long as you don't use the "none" Mac. It is recommended that the system implementation shown by X11 only allows the display to be turned on on the local IPC. The system implementation of the SSH server that supports X11 forwarding is enabled by default to enable display only on the local IPC. On a single-user system, it may be reasonable to allow local display to be enabled on TCP/IP by default.

The implementation of the X11 forwarding protocol should implement the anti-cookie spoofing mechanism described in [Ssh-connect] as an additional mechanism to prevent unauthorized use of proxies

SSH Chinese documents