SSH protocol Basics

SSH is fully known as secure shell. It is a protocol developed by the Network Working Group of the IETF (Internet Engineering Task Force, the objective is to provide secure remote logon and other security network services on a non-secure network. We can simply understand it as an alternative solution such as rlogin and telnet. See the following SSH framework for details.

 

 

SSH basic framework

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

• Transport Layer Protocol

• User Authentication Protocol
• Connection Protocol
  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:
• The Transport Layer Protocol provides server authentication, data confidentiality, and information integrity support;
• 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.

 

SSH security verification level

• Level 1 (Password-basedAs long as you know your account and password, you can log on to the remote host. All transmitted data is encrypted, but it cannot be guaranteed that the server you are connecting to is the server you want to connect. Other servers may pretend to be real servers, that is, being attacked by man-in-the-middle.
• Level 2 (Based on keysSecurity Authentication.
  • Create a pair of keys for yourselfPublic KeyPut it on the server to be accessed;
  • The client software sends a request to the server.KeyPerform security verification;
  • After receiving the request, the server searchesPublic KeyAnd then send it to you.Public Key. If the two keys are consistent, the server uses the public key to encrypt the challenge and send it to the client software;
  • After the client software receives a question, it can use private decryption to send it to the server.

In this way, you must know your key password. However, compared with the first level, the second level does not need to transmit passwords over the network. It not only encrypts all transmitted data, in addition, the "man-in-the-middle" attack method is also impossible (because he does not have your private key ). However, the entire logon process may take 10 seconds.

 

SSH Workflow

 

During the entire communication process, to achieve secure SSH connection, the server and client must go through the following steps:Five Phases:

• Version Number negotiationSSH currently includes two versions: SSH1 and SSH2. Both parties determine the version used through version negotiation.
• Key and algorithm negotiationSSH supports multiple encryption algorithms. Both parties negotiate the final algorithm based on the algorithms supported by the local and peer end.
• AuthenticationStage, the SSH client initiates an authentication request to the server, and the server authenticates the client
• Session RequestAfter the authentication is passed, the client sends a session request to the server.
• Interactive SessionsAfter the session request passes, the server and client interact with each other.

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 that the client decides to use. The server compares the version number sent by the client to determine whether it can work with the client.
5. If the negotiation succeeds, 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 side and the local side.
3. Servers and clients use the DH-Hellman exchange algorithm and host key-to-Peer parameters to generate session keys and session IDs.

   After performing the preceding steps, the server and client obtain the same session.KeyAndSession ID.

   • Sessions are used at both ends of subsequent data transmission.KeyProceedEncryption and decryptionTo ensure the security of data transmission.
   • In the authentication phase, both ends useSession IDUsedAuthentication process.

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 authentication failure message is sent to the client, which contains a list of methods that can be re-authenticated.
3. The client selects one authentication method from the authentication method list to authenticate again.
4. This process is performed repeatedly until the authentication is successful 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: uses a 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: specifies 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.

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?

A4A 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: Briefly describe the SSH running process?

 

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, 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, used by both parties to calculate the session key.
• Enter the authentication stage. After that, all communications are encrypted.
• After successful authentication, enter the interaction stage.