SSH protocol details

Forwarded http://blog.csdn.net/macrossdzh/article/details/5691924

Very thorough, learning

1. What is SSH

 

SSH is short for the English Secure Shell. By using SSH, You can encrypt all transmitted data, so that the "man-in-the-middle" attack method is impossible, and it can also prevent DNS Spoofing and IP spoofing. Another advantage of using SSH is that the data transmitted is compressed, which can speed up transmission. SSH has many functions. It can replace telnet, provide a secure "channel" for FTP, pop, and even PPP ".

 

Ii. Basic SSH framework

 

The most important part of the SSH protocol framework is the three protocols:

 

* The transport layer protocol supports Server Authentication, data confidentiality, and information integrity;

* The User Authentication Protocol provides the client identity authentication for the server;

* The connection protocol reuses encrypted information tunnels into several logical channels for higher-level application protocols; various high-level application protocols can be relatively independent from the SSH basic system, and rely on this basic framework to use SSH security mechanisms through connection protocols.

 

In addition, the SSH protocol framework also provides extended support for many high-level network security application protocols. The hierarchical relationships between them can be expressed as follows:

Iii. Host key mechanism

 

For a protocol such as SSH that provides secure communication, a complete key mechanism is essential. Because the SSH protocol is intended for mutual access and information exchange between hosts in the Internet network, the host key becomes a basic key mechanism. In other words, the SSH protocol requires that each host using this Protocol must have at least one of its own host key pairs, and the service provider can allow connection requests only after it passes authentication on the client's host key. A host can use multiple keys and have different keys for different key algorithms. However, at least one key is required, that is, the key generated by the DSS algorithm. For the DSS algorithm, see [FIPS-186].

 

There are two management solutions for host key authentication in the SSH protocol, as shown in:

Each host must have its own host key, which can have multiple pairs. Each pair includes a public key and a private key. In actual application, how can we use these keys and rely on them to implement security features? As shown in, two solutions are proposed in the SSH protocol framework.

 

In the first scheme, the host distributes its own public key to the relevant client. When the client accesses the host, it uses the public key of the host to encrypt the data, the host uses its own private key to decrypt data, so as to implement host key authentication and determine the reliable identity of the client. In Figure 2 (a), you can see that, when you initiate an operation from host a to access host B and host C, A becomes the client, it must configure the public keys of host B and host C in advance, and find the corresponding public keys based on the host name during access. For the accessed host (that is, the server side), you only need to ensure the security of your private key.

 

In solution 2, a key authentication center exists. All Hosts that provide services in the system submit their own public keys to the authentication center, for any host that acts as a client, you only need to save the public key of the authentication center. In this mode, the client must request authentication from the key authentication center before accessing the server host. After authentication, the client can correctly connect to the target host.

 

Obviously, the first method is relatively easy to implement, but the maintenance of the client's key is troublesome, because every change must be reflected on the client; the second method perfectly solves the management and maintenance problems. However, this mode has high requirements on the certification center and must implement such centralized authentication on the Internet, confirmation by authoritative organizations alone is a big headache. Who can decide what to say? However, from a long-term development perspective, it is necessary to adopt a central authentication solution in enterprise and commercial applications.

 

In addition, the SSH protocol framework also allows a compromise on the host key, that is, the first access without authentication. The first access without authentication means that when a client accesses the host for the first time, the host does not check the host key, but issues a copy of the public key to the client, in this way, you must use this key for future access. Otherwise, the access will be denied because it is deemed illegal.

 

 

 

Iv. Ssh Work Process

 

During the entire communication process, to achieve secure SSH connection, the server and client have to go through the following five phases:

* During version negotiation, ssh currently includes SSH1 and SSH2 versions. Both parties determine the version used through version negotiation.

* In the key-algorithm negotiation phase, ssh supports multiple encryption algorithms. Both parties negotiate the final algorithm based on the algorithms supported by the local and peer end.

* In the authentication phase, the SSH client initiates an authentication request to the server, and the server authenticates the client.

* In the Session Request stage, after the authentication is passed, the client sends a session request to the server.

* In the interactive session stage, after the session request passes, the server and the client exchange information

 

 

1. Version Number negotiation stage

1. The server opens port 22 and waits for the client to connect.

2. the client initiates a TCP initial connection request to the server. After the TCP connection is established, the server sends the first packet to the client, including the version flag string in the format of "ssh-<master protocol version number>. <Protocol version>-<software version> ". The Protocol version number consists of the main version number and the minor version number. The software version number is mainly used for debugging.

3. after receiving the packet, the client parses the packet. If the Protocol version number on the server side is lower than the version number on the server side and the client can support the earlier version on the server side, the Protocol number on the server side is used, otherwise, use your protocol version.

4. The client responds to a message from the server, including the Protocol version number determined by the client. The server compares the version number sent by the client to determine whether it can work with the client.

5. If the negotiation is successful, the key-algorithm negotiation phase is entered; otherwise, the server disconnects the TCP connection.

Note: During version number negotiation, messages are transmitted in plaintext.

 

2. Key and algorithm negotiation phase

1. the server and client send the algorithm negotiation packet to the peer respectively. The packet contains the Public Key algorithm list, encryption algorithm list, and MAC (message authentication code, message Verification Code) supported by the peer) algorithm list, compression algorithm list, etc;

2. The server side and client side obtain the final algorithm used based on the list of Algorithms supported by the peer end and the local end.

3. servers and clients generate session keys and session IDs Using DH-Hellman exchange algorithms and host key-to-Peer parameters.

 

Through the preceding steps, the server and client obtain the same session key and session ID.

* For subsequent data transmission, both ends use session keys for encryption and decryption, ensuring the security of data transmission.

* In the authentication phase, the two ends use session IDs for authentication.

Note:

Before the negotiation stage, the server has generated an RSA or DSA key pair, which is mainly used to generate session keys.

 

 

3. Authentication phase

1. The client sends an authentication request to the server. The authentication request contains the user name, authentication method, and content related to the authentication method (for example, the content is a password during Password Authentication ).

2. The server authenticates the client. If the authentication fails, the server sends an authentication failure message to the client, which contains a list of methods for further authentication.

3. The client selects an authentication method from the authentication method list to authenticate again.

4. This process is performed repeatedly until the authentication succeeds or the number of authentication attempts reaches the upper limit, and the server closes the connection.

 

SSH provides two authentication methods:

1. password Authentication: the client sends a password authentication request to the server, encrypts the user name and password, and then sends it to the server. The server decrypts the information and obtains the plaintext of the user name and password, compare with the user name and password saved on the device, and return the message of successful or failed authentication.

2. publickey authentication: use the digital signature method to authenticate the client. Currently, the device can use RSA and DSA public key algorithms to implement digital signatures. The client sends a publickey authentication request containing the user name, public key, and public key algorithm to the server. The server checks the validity of the public key. If the public key is invalid, a failed message is sent directly. Otherwise, the server uses a digital signature to authenticate the client and returns a message indicating that the authentication succeeds or fails.

 

Ssh2.0 also provides password-publickey authentication and any authentication:

1. Password-publickey authentication: specify that the user's authentication method is both password and publickey authentication. Users whose client version is SSH1 can log on only after one authentication. Users whose client version is s22.

2. Any authentication: specifies that the user's authentication method can be password or publickey.

 

4. Session Request stage

1. The server waits for client requests;

2. After the authentication is passed, the client sends a session request to the server;

3. The server processes client requests. After the request is successfully processed, the server responds to the ssh_smsg_success package to the client, and SSH enters the interactive session stage. Otherwise, the server responds to the ssh_smsg_failure package, indicating that the server fails to process the request or cannot recognize the request.

 

5. interactive session stage

In this mode, data is transmitted in two directions:

1. The client encrypts the commands to be executed and sends them to the server;

2. The server receives the message, decrypts it, executes the command, and encrypts the execution result and sends it back to the client;

3. The client decrypts the received results and displays them on the terminal.

 

 

 

 

 

5. Ssh applications

　　

First, the most common application of SSH is to use it to replace traditional network applications such as telnet and FTP, and log on to a remote machine through SSH to execute the work and commands you want. In an insecure network communication environment, it provides a strong authentication mechanism and a very secure communication environment. In fact, the root intention of SSH developers is to design it to replace the RCP, rlogin, RSH, and other instruction programs on the original UNIX system. However, after proper packaging, it is found that it can completely replace traditional applications such as telnet and FTP.

Traditional BSD-style R-series commands (such as RCP, RSH, and rlogin) are often considered insecure and can be easily cracked by various network attacks, almost all books or files related to Unix security will warn system administrators over and over again to pay attention to the setting of R series commands, system Administrators are even required to disable the R-series commands.

Ssh, which is used to replace R-series commands, is greatly enhanced in terms of security. It not only provides extremely secure encryption protection for communication content, at the same time, it also strengthens the security mechanism for identity authentication. It applies several security encryption mechanisms that have been developed in cryptography, such as encryption key cryptography, asypolicric key cryptography, one-way hash function, random-number generation, and so on, to enhance the security protection for identity authentication and communication content. Data Encryption in communication includes idea, three-key Triple DES, Des, RC4-128, TSS, blowfish, and many other security encryption algorithms, the encrypted key is exchanged through RSA. Data Encryption can defend against IP spoofing. RSA, an asymmetric encryption mechanism, can defend against DNS Spoofing and IP routing spoofing. At the same time, RSA can also verify the host identity.

Second, you can set an "encrypted channel" between the local host and remote server by using SSH ", in addition, the encrypted channel can be combined with common pop applications, X applications, and linuxconf applications to provide security assurance.

SSH's "encrypted channel" is implemented through "port forwarding. You can establish an "encrypted channel" between the local port (unavailable) and the port of a service running on the remote server ". Connect to the local port. All requests to the local port are encrypted by SSH and forwarded to the remote server port. Of course, only "encrypted channels" can work when the SSH server software is running on the remote server.

 

 

 

6. Ssh Q &

 

Q1: The version and difference of SSH.

SSH2 avoids RSA patent issues and fixes CRC defects. SSH2 replaces RSA with the digital signature algorithm (DSA) and Diffie-Hellman (DH) algorithm to exchange symmetric keys and uses HMAC to replace CRC. Meanwhile, SSH2 adds AES, twofish, and other symmetric encryption algorithms.

A1: SSH (Secure Shell) has two incompatible versions so far-SSH1 and SSH2. SSH1 is further divided into two versions: 1.3 and 1.5. SSH1 uses symmetric encryption algorithms such as des, 3DES, blowfish, and RC4 to protect secure data transmission. The keys of symmetric encryption algorithms are exchanged through asymmetric encryption algorithms (RSA. SSH1 uses cyclic redundancy checksum (CRC) to ensure data integrity, but later found that this method has a defect.

For more information, see the SSHv1 protocol & the SSHv2 Protocol

Q2: What is HMAC?

A2: HMAC (Hash Message Authentication Code), hash message authentication code, and key-based hash algorithm authentication protocol. The message authentication code uses a public function and a key to generate a fixed-length value as the authentication identifier, which identifies the integrity of the message. Use a key to generate a small data block of a fixed size, that is, Mac, and add it to the message for transmission. The receiver uses the key shared with the sender for authentication.

 

Q3: What is X11 forwarding?

A3: the X11 forwarding feature of SH enables secure communication between X client and X server. After X11 forwarding is used, data from X client to X server is first sent to the SSH server. the SSH server forwards the data to the SSH client through the Secure Channel of the SSH client, the SSH client then forwards the data streams from X server to X client. Here, the SSH server and SSH client act as the data forwarder between the X client and the X server. Because the SSH server and X client, SSH client, and X Server are generally on the same machine, secure inter-process communication, while secure communication between the SSH server and the SSH client. Therefore, communication between the X client and the X server is secure.

 

Q4: What is tty?

A4: A terminal is a type of terminal device. It has multiple types and generally uses tty for short. Tty is short for teletype. Teletype is one of the earliest terminal devices. It is very similar to a telex typewriter and is produced by teletype. Put the device name in the special file directory/dev.

 

Q5: What is the process of running SSH?

A5: the process is as follows:

* The client initiates an SSH connection request to the server.

* The server initiates version negotiation to the client.

* After the negotiation ends, the server sends the host key, public key, random number, and other information. All communications are not encrypted here.

* The client returns the confirmation information, along with a random number encrypted with the public key, which is used by both parties to calculate the session key.

* Enter the authentication stage. After that, all communications are encrypted.

* After the authentication is successful, enter the interaction stage.

SSH protocol details