Operating system: Introduction to SSH protocol knowledge

Today I will share with you the knowledge related to the SSH protocol, I hope it will be helpful to everyone!

1. Introduction to SSH protocol concepts

SSH (Secure Shell) is a security protocol built on the application layer. It can provide a secure transmission environment for network services in an insecure network by encrypting and transmitting passwords for verification, and realize the connection between the SSH client and the SSH server. Therefore, SSH is based on the client-server model.

2. SSH service composition

The SSH service consists of the server software OpenSSH and the connection client (SSH, SecureCRT, xshell, etc.), and the default port is 22. SSH is a daemon process that is responsible for real-time monitoring of client requests and processing them.

3. SSH protocol framework composition

The three core protocols in the SSH protocol framework are: transport layer protocol, user authentication protocol, and connection protocol.

• The Transport Layer Protocol: provides support for server authentication, data security, information integrity and other functions.
• The User Authentication Protocol: provides the server with the identity of the client.
• The Connection Protocol: Multiplex the encrypted information tunnel into several logical channels and provide them to higher-level application protocols. Various high-level application protocols can be relatively independent of the SSH basic system, and then rely on this basic framework to use the SSH security mechanism through the connection protocol.

4. SSH workflow

4.1 Version number negotiation phase

SSH currently includes two versions: SSH1 and SSH2. Both parties determine the version to be used through version negotiation.

• The server opens port 22 and waits for the client to initiate a connection request
• The client initiates a TCP initial connection request to the server. After the connection is established, the server sends a message to the client (version mark string: SSH-<main protocol version number>.<minor protocol version number>-<software version number>>)
• After receiving the message, the client parses the data packet. If the server's protocol version number is lower than its own and the client can support the server's lower version, it will use the server's lower version protocol number. Otherwise, it will use the client's own protocol version number.
• The client responds to the server with a message containing the protocol version number that the client has decided to use. The server compares the version number sent by the client to determine whether it can work properly with the client.
• If the negotiation is successful, it will enter the key and algorithm negotiation phase, otherwise the server will disconnect the TCP connection.

Note: Messages in the version number negotiation phase are all transmitted in plain text.

4.2 Key and algorithm negotiation phase

SSH supports multiple encryption algorithms. Both parties negotiate the final algorithm to be used based on the algorithms supported by the server and the client.

• The server and the client send algorithm negotiation messages to each other respectively. The messages contain negotiation information such as the public key algorithm list, encryption algorithm list, MAC (Message Authentication Code) algorithm list, and compression algorithm list supported by each party.
• The server and client determine the final algorithm to be used based on the algorithm lists supported by the other party and themselves.
• The server and client use the DH exchange (Diffie-Hellman Exchange) algorithm, host key pair and other parameters to generate a session key and session ID, and then both parties get the same session ID and session key.
• In subsequent data communications, both ends will use the session key for encryption and decryption, thus ensuring the security of data transmission.
• During the authentication phase, both ends will use the session ID for the authentication process.

Note: Before the negotiation phase, the server has generated an RSA or DSA key pair, which is mainly used to participate in the generation of session keys.

4.3 Authentication Phase

The SSH client sends an authentication request to the server, and the server authenticates the client

• The client sends an authentication request to the server. The authentication request information includes the user name, authentication method, and content related to the authentication method (for example, in the case of password authentication, the content is the password).
• The server authenticates the client. If authentication fails, it sends an authentication failure message to the client, which also includes a list of methods that can be used to initiate authentication again.
• The client selects an authentication method from the authentication method list returned by the server and authenticates again.
• This process is repeated until the authentication is successful or the authentication limit is reached, and the server closes the connection.

4.4 Session request phase:

After authentication, the client sends a session request to the server

• The server waits for the client's request;
• After authentication, the client sends a session request to the server;
• The server processes the client's request. After the request is successfully processed, the server will respond to the client with a SSH_SMSG_SUCCESS packet, and SSH will enter the interactive session phase; otherwise, it will respond with a SSH_SMSG_FAILURE packet, indicating that the server failed to process the request or could not recognize the request.

4.5 Interactive Conversation Phase

After the session request is passed, the server and client can exchange information

• The client encrypts the command to be executed and sends it to the server;
• The server receives the message, decrypts it and executes the command, and encrypts the result and sends it back to the client;
• The client decrypts the received result and displays it on the terminal.

Note: At this stage, data can be transmitted bidirectionally.

5. SSH authentication method

5.1 Password authentication:

The client sends a password authentication request to the server, and then encrypts the username and password and sends it to the server; the server decrypts the information to obtain the plain text of the username and password, compares it with the username and password saved on its own device, and returns a message indicating whether the authentication is successful or failed.

5.2 publickey authentication:

The client is authenticated by digital signature. Currently, two public key algorithms, RSA and DSA, can be used on the device to implement digital signature. The client sends a publickey authentication request containing the user name, public key, and public key algorithm to the server. The server checks the legitimacy of the public key. If it is not legal, a failure message is sent directly; otherwise, the server authenticates the client with a digital signature and returns a message of success or failure of authentication.

5.3. Password-publickey authentication (SSH2.0)

Specifies that the authentication method for this user must be both password and publickey authentication. Note: Users whose client version is SSH1 can log in by passing either authentication method; users whose client version is SSH2 must pass both authentication methods to log in.

5.4 any authentication (SSH2.0)

Specifies that the authentication method for this user can be either password or publickey.

6. Common SSH commands

6.1 Remote Login

ssh username@remote host ip: The first login requires downloading the other party's public key. Example: ssh 192.168.1.100

6.2 Remote Upload

scp [local location of the file to be uploaded] root@remote host ip:[path to be saved on the remote host]: upload files from the local to the remote host Example: scp /root/test.sh [email protected]

6.3 Remote Replication

scp root@remote host ip:[absolute path of remote host file] [local location to be saved]: Download files from the remote host to the local machine. Example: scp [email protected]:/root/test.sh /root