A Method and System for Encrypted Remote Transmission of Shell Commands

Abstract

The present invention discloses a method and system for encrypting and remotely transmitting Shell commands, which relates to the technical field of Shell command transmission. A session secret key is generated by performing an exclusive OR operation bit by bit using a random number, and at the same time, a long socket connection is established. After decrypting the encrypted Shell command of the client, the Shell command is decrypted into ciphertext, and the ciphertext is encrypted using AES with the session secret key. After receiving the encrypted Shell command named ciphertext through the socket, AES decryption is performed using the session secret key, and it is verified whether the decrypted Shell command is legal. After the verification passes, it is sent to the local to execute the Shell command. This transmission system realizes secure remote communication of Shell commands, performs secure encrypted transmission without affecting the user experience, is suitable for use by units and individuals with high requirements for information security, can effectively prevent network data attacks, data analysis, etc., and ensures the security when remotely controlling the host.

Description

Technical Field

[0001] The present invention relates to the technical field of Shell command transmission, and particularly relates to a method and system for encrypting and remotely transmitting Shell commands. Background Art

[0002] In the information age, with the rapid development of computer science and network technology, we have fully entered a convenient and globalized information age. In the process of using information systems, remotely executing Shell commands is an indispensable function. Remotely writing Shell commands and sending them to the service for execution can effectively improve management efficiency, utilization of resources, and overall management of computer room equipment, which is of great significance.

[0003] However, how to securely and effectively send from the remote management end to the host and execute is a complex task. Using the ordinary plaintext transmission method is a very insecure transmission method. Illegal elements can capture data, restore the original text of the Shell command, use techniques such as man-in-the-middle attacks, and even tamper with the functions of the Shell command, posing a great hidden danger to security.

[0004] Based on this, the present application provides a method and system for encrypting and remotely transmitting Shell commands to achieve secure remote communication of Shell commands, securely encrypting and transmitting without affecting the user experience, suitable for units and individuals with high requirements for information security, and can effectively prevent network data attacks, data analysis, etc., ensuring security when remotely controlling the host. Summary of the Invention

[0005] The object of the present invention is to provide a method and system for encrypting and remotely transmitting Shell commands to solve the deficiencies in the background art.

[0006] To achieve the above object, the present invention provides the following technical solution: A method for encrypting and remotely transmitting Shell commands, the transmission method comprising the following steps:

[0007] The client fills in the Shell command, encrypts the filled Shell command locally using AES, and transmits it to the management end through the SSL secure communication protocol. The host end and the server end perform secret key negotiation and exchange. The management end generates a random number, signs it using the public key of the host end, and sends the random number and the signature value to the host end;

[0008] Decrypt and verify using the host - side private key, then re - encrypt using the server - side public key and return to the server. The server then verifies. If they are consistent, generate a session key by performing an exclusive - OR operation bit - by - bit on a random number, and at the same time establish a long - term socket connection. Decrypt the encrypted Shell command from the client into ciphertext, encrypt the ciphertext using the session key with AES, and send it to the host - side through the socket. After the host - side receives the encrypted Shell command named ciphertext through the socket, decrypt it using the session key with AES;

[0009] Verify whether the decrypted Shell command is legal. After passing the verification, send it to the local to execute the Shell command, collect the execution results in real - time, organize them by line, and return them in the form of a set. Encrypt the return results using the session key and return them to the server. At the same time, close the socket connection and destroy the key.

[0010] In a preferred embodiment, the host - side and the server perform key negotiation and exchange. The management - side generates a random number and signs it using the host - side public key, including the following steps:

[0011] The management - side generates a random number R through a secure random number generator. The random number R is used for key negotiation, and obtains the host - side public key , encrypts and signs the random number R using the host - side public key to obtain an encrypted random number S, and analyzes whether there are any abnormalities in the encryption process during the encryption process. According to the analysis results, generate corresponding management strategies. If there are no abnormalities in the encryption process, send the encrypted random number S and the plaintext random number R to the host - side together.

[0012] In a preferred embodiment, encrypt and sign the random number R using the host - side public key to obtain an encrypted random number S, and analyze whether there are any abnormalities in the encryption process during the encryption process, including the following steps:

[0013] During the encryption process, obtain the integrity factor, encryption time factor, and resource consumption factor, and comprehensively calculate the encryption coefficient by combining the integrity factor, encryption time factor, and resource consumption factor. The expression is: , where is the encryption coefficient, is the integrity factor, is the encryption time factor, is the resource consumption factor, , , are the proportionality coefficients of the integrity factor, encryption time factor, and resource consumption factor respectively, and , , are all greater than 0;

[0014] Compare the obtained encryption coefficient with a preset coefficient threshold. The coefficient threshold is used to analyze whether there is an abnormality in the encryption process. If the encryption coefficient is greater than or equal to the coefficient threshold, it is analyzed that there is no abnormality in the encryption process. If the encryption coefficient is less than the coefficient threshold, it is analyzed that there is an abnormality in the encryption process;

[0015] When it is analyzed that there is an abnormality in the encryption process, the generated management policy is as follows: Re - encrypt and sign the random number R using the public key of the host to obtain the encrypted random number S. When the encryption coefficients of 5 consecutive re - encryption processes are all less than the coefficient threshold, send a warning signal to the administrator for handling.

[0016] In a preferred embodiment, the calculation expression of the integrity factor is: , where is the actual length of the random number, is the expected length of the random number, is the actual length of the public key, is the standard length of the public key, is the format check assignment. If there is no format error, if there is a format error, ;

[0017] The calculation logic of the encryption time factor is: Obtain the maximum allowed encryption time and the actual encryption time of the encryption process. Subtract the maximum allowed encryption time from the actual encryption time of the encryption process to obtain the time difference. Divide the time difference by the maximum allowed encryption time to obtain the encryption time factor;

[0018] The calculation logic of the resource consumption factor is: Obtain the resource amount threshold for resource usage operation and the actual resource amount used. Subtract the resource amount threshold from the actual resource amount used to obtain the resource amount difference. Divide the resource amount difference by the resource amount threshold to obtain the resource consumption factor.

[0019] In a preferred embodiment, after the host end receives the encrypted Shell command ciphertext through the socket, it uses the session key for AES decryption, verifies whether the decrypted Shell command is legal, and sends it to the local for executing the Shell command after verification, including the following steps:

[0020] The host end receives the encrypted Shell command ciphertext through the Socket connection, uses the session key to decrypt the received ciphertext by AES, and restores the original Shell command;

[0021] Check whether the syntax of the Shell command is legal, and verify whether the parameters and paths of the Shell command conform to the preset rules;

[0022] If the decrypted Shell command passes the verification, the host will pass it to the local Shell for execution. During the execution, the execution status of the Shell command is monitored and the output results are recorded.

[0023] After the Shell command is executed, the host collects the execution results and prepares to return, organizes the content of each line of output into a collection, and further encrypts it before sending it back to the server.

[0024] In a preferred implementation, the client fills in the Shell command, encrypts the filled Shell command locally with AES, and transmits it to the management end via the SSL secure communication protocol, including the following steps:

[0025] The user enters the required Shell command in the client interface. The Shell command includes starting a service, querying system status, or running a script.

[0026] The client first generates a symmetric key, which is used to encrypt Shell commands. The client then uses the generated AES key to encrypt the input Shell commands using the AES encryption algorithm.

[0027] The client and the management end establish a connection through the SSL protocol. When establishing the SSL connection, the management end's SSL certificate will be verified for abnormalities. After the verification is passed, the communication connection will be established;

[0028] The client encapsulates the AES-encrypted Shell command in an SSL communication package and sends it to the management end through the SSL security protocol. In the SSL protocol, the client and the management end use public key encryption technology to encrypt data content;

[0029] The management end decrypts the received encrypted data through the SSL protocol, extracts the encrypted Shell command ciphertext, and uses the verification mechanism provided by the SSL protocol to verify the Shell command ciphertext. If the verification passes, the received ciphertext is directly stored in the database.

[0030] In a preferred implementation, the management end uses the verification mechanism provided by the SSL protocol to verify the Shell command ciphertext, including the following steps:

[0031] The SHA-256 hash algorithm is used to calculate the hash value of the Shell command. The expression is:

[0032] , where is a shell command, is the calculated hash value;

[0033] Verification is performed by comparing the calculated hash value with the stored hash value. The calculation formula for the verification process is as follows: , where is the calculated hash value, is the Shell command, is the hash value attached to the Shell command sent by the client, represents the result of the verification, which is used to indicate whether the verification passes. True indicates that the verification passes, and False indicates that the verification fails;

[0034] If the two hash values are equal, that is , the verification passes and the data has not been tampered with. If the hash values are not equal, that is , the verification fails and the data has been tampered with or damaged. If the verification passes, the received ciphertext is directly stored in the database.

[0035] In a preferred embodiment, the client and the management end establish a connection through the SSL protocol. When establishing an SSL connection, it will verify whether there is an abnormality in the SSL certificate of the management end. After the verification passes, a communication connection is established, including the following steps:

[0036] The client sends a connection request to the management end, initiates an SSL / TLS handshake, and the client sends a ClientHello message to the management end, including the supported encryption algorithms, SSL / TLS versions, and generated random number information;

[0037] After receiving the connection request from the client, the management end responds with a ServerHello message, confirms the used SSL / TLS version and encryption algorithm, and sends a random number generated by the management end, and sends its SSL certificate to the client. The SSL certificate includes a certificate chain;

[0038] After the client receives the SSL certificate of the management end, it checks the integrity of the management end certificate chain, verifies whether the root certificate exists and is in the list of trusted certificate issuing authorities of the client, checks the validity period of the management end certificate, and verifies whether the current date is within the validity period of the certificate;

[0039] Query whether the certificate issuing authority has issued a certificate revocation list and check whether the certificate is in it. The client verifies the certificate subject field of the management end. If the host name does not match the CN or SAN in the certificate, the client will report a certificate mismatch error and reject the connection.

[0040] In a preferred embodiment, the host end and the server end perform secret key negotiation and exchange, including the following steps:

[0041] On the host side, a small service management host will be deployed, which establishes a communication connection with the host, generates a key pair for RSA asymmetric encryption, converts the key into a 512-bit format, and checks the length of the private key. If the length of the private key is not 32 bytes, the last 32 bytes will be intercepted;

[0042] Use AES to encrypt the public key of RSA and send it to the host side. The host side performs the same operation and sends back the public key of the host side. The management side generates a random number, signs it using the public key of the host side, and then sends the random number and the signature value to the host side. The host side decrypts and verifies it using the private key, re-encrypts it using the public key of the server side, and then returns it to the server side. The server side verifies again. If they are consistent, it is determined that the negotiation key is successful, generates a session key, and performs an exclusive OR operation on the random number bit by bit to generate the session key and establish a long socket connection at the same time.

[0043] A Shell command encryption remote transmission system includes an encryption module, a management module, a host module, a service module, an execution module, and a result return module;

[0044] Encryption module: The client fills in the Shell command, encrypts the filled Shell command locally using AES, and transmits it to the management module through the SSL secure communication protocol. The Shell command is sent to the service module;

[0045] Management module: Generates a random number, signs it using the public key of the host side, and sends the random number and the signature value to the host module;

[0046] Host module: Decrypts and verifies it using the private key, re-encrypts it using the public key of the service module, and returns it to the service module. After receiving the encrypted Shell command ciphertext through the socket, it decrypts it using the session key with AES;

[0047] Service module: Verifies again. If they are consistent, performs an exclusive OR operation on the random number bit by bit to generate the session key, and at the same time establishes a long socket connection. After decrypting the encrypted Shell command from the encryption module, it decrypts the Shell command into ciphertext, encrypts the ciphertext using the session key with AES, and returns it to the host module through the socket;

[0048] Execution module: Verifies whether the decrypted Shell command is legal. After passing the verification, it sends it to the local to execute the Shell command;

[0049] Result return module: Collects the execution results in real time, organizes them by line, returns them in the form of a set, encrypts the return results using the session key and returns them to the service module, and at the same time closes the socket connection and destroys the key.

[0050] In the above technical solution, the technical effects and advantages provided by the present invention are as follows:

[0051] The present invention generates a random number through the management end, signs it using the public key of the host end, sends the random number and the signature value to the host end, decrypts and verifies it using the private key of the host end, re-encrypts it using the public key of the server end and returns it to the server end. The server end then verifies it, generates a session key by performing an exclusive OR operation on the random number bit by bit, and simultaneously establishes a long socket connection. After decrypting the encrypted Shell command of the client into ciphertext, the ciphertext is encrypted using the session key by AES and sent to the host end through the socket. After receiving the encrypted Shell command named ciphertext through the socket, the host end decrypts it using the session key by AES and verifies whether the decrypted Shell command is legal. After passing the verification, it is sent to the local to execute the Shell command. This transfer system realizes the secure remote communication of Shell commands, performs secure encrypted transmission without affecting the user experience, and is suitable for units and individuals with high requirements for information security. It can effectively prevent network data attacks, data analysis, etc., and ensure the security when remotely controlling the host. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required to be used in the embodiments. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings.

[0053] Figure 1 It is a flowchart of the method of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0054] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.

[0055] Embodiment 1: Please refer to Figure 1 As shown, a method for encrypting and remotely transmitting Shell commands in this embodiment, the transmission method includes the following steps:

[0056] The client fills in the Shell command, encrypts the filled Shell command locally using AES, and transmits it to the management end through the SSL secure communication protocol. The host end and the server end conduct key negotiation and exchange. The management end generates a random number, signs it using the public key of the host end, and sends the random number and the signature value to the host end. The host end decrypts and verifies it using its private key, re-encrypts it using the public key of the server end and returns it to the server end. The server end then verifies it. If they are consistent, a session key is generated by performing an exclusive OR operation on the random number bit by bit, and at the same time, a long socket connection is established. After decrypting the encrypted Shell command of the client, the Shell command is decrypted into ciphertext, the ciphertext is encrypted using the session key by AES, and is sent to the host end through the socket. After the host end receives the encrypted Shell command named ciphertext through the socket, it decrypts it using the session key by AES, and verifies whether the decrypted Shell command is legal. After the verification passes, it is sent to the local to execute the Shell command. The execution results are collected in real time and sorted by line, and then returned in the form of a set. The return results are encrypted using the session key and returned to the server end, and at the same time, the socket connection is closed and the key is destroyed.

[0057] In this application, the management end generates a random number, signs it using the public key of the host end, sends the random number and the signature value to the host end, the host end decrypts and verifies it using its private key, re-encrypts it using the public key of the server end and returns it to the server end. The server end then verifies it, generates a session key by performing an exclusive OR operation on the random number bit by bit, and at the same time, a long socket connection is established. After decrypting the encrypted Shell command of the client, the Shell command is decrypted into ciphertext, the ciphertext is encrypted using the session key by AES, and is sent to the host end through the socket. After the host end receives the encrypted Shell command named ciphertext through the socket, it decrypts it using the session key by AES, and verifies whether the decrypted Shell command is legal. After the verification passes, it is sent to the local to execute the Shell command. This transfer system realizes the secure remote communication of Shell commands, performs secure encrypted transmission without affecting the user experience, is suitable for units and individuals with high requirements for information security, can effectively prevent network data attacks, data analysis, etc., and ensures the security when remotely controlling the host.

[0058] The client fills in the Shell command, encrypts the filled Shell command locally using AES, and transmits it to the management end using the SSL secure communication protocol. The management end saves the encrypted data in the database. Without using the Shell command, the data is not decrypted using AES. At this time, the data has been saved in the management end.

[0059] The host side and the server side conduct key negotiation and exchange. First, it should be clear that the management side is a large-scale management platform, while the host side is a host on which Shell commands are executed. A small service will be deployed on the host side to manage the host, establish a communication connection with the host, etc. In the current key exchange step, first, an RSA asymmetric encryption key pair is generated, then the key is converted into a 512-bit format, and the length of the private key is checked to ensure that the length of the private key is 32 bytes. If it is not 32 bytes, the last 32 bytes are intercepted. The second step is to use AES to encrypt the RSA public key, and send the AES-encrypted RSA public key to the host side. The host side performs the same operation and sends back the public key of the host side. At this time, both the management side and the host side have the public keys of each other. At this time, the management side generates a random number, signs it using the public key of the host side, and then sends the random number and the signature value together. After receiving it, the host side decrypts and verifies it using the private key of the host side, encrypts it again using the public key of the server side and returns it. When it is returned to the server side, the server side verifies again. If they are consistent, the key negotiation is successful, a session key is generated, and the session key is generated by performing an exclusive OR operation on the random number bit by bit, and at the same time, a long socket connection is established.

[0060] First, decrypt the encrypted Shell command passed in by the client after being encrypted using AES, and then decrypt the Shell command into ciphertext. Otherwise, the host side cannot parse it. Then, use the session key to perform AES encryption and send it to the host side through the socket.

[0061] After the host side receives the encrypted Shell command ciphertext through the socket, it performs AES decryption using the session key, verifies the decrypted Shell command, verifies whether the Shell command is legal. After verification, it is sent to the local to execute the Shell command, and the execution results are collected in real time and sorted by line, and returned in the form of a set. The returned results are encrypted using the session key and directly returned to the server side. At the same time, the socket connection is closed and the key is destroyed.

[0062] In this application:

[0063] AES (Advanced-Encryption-Standard): Advanced Encryption Standard, a symmetric encryption algorithm used for data encryption and decryption. AES is widely used to protect the transmission of sensitive data.

[0064] SSL (Secure-Sockets-Layer): Secure Sockets Layer, a security protocol used to encrypt data transmission through a computer network to ensure the confidentiality and integrity of communication.

[0065] RSA (Rivest-Shamir-Adleman): An asymmetric encryption algorithm used for encrypting and decrypting data. The RSA algorithm relies on a pair of keys: a public key and a private key.

[0066] Public-Key: In asymmetric encryption, the key used to encrypt data. The public key can be transmitted publicly, and anyone can use the public key to encrypt data.

[0067] Private-Key: In asymmetric encryption, the key used to decrypt data. The private key must be kept secret, and only the owner of the key can decrypt the data encrypted with its public key.

[0068] Session-Key: In symmetric encryption, the key used to encrypt and decrypt data during a session. The session key is usually generated during the communication between the client and the server and is used to encrypt the transmitted data.

[0069] Socket: A socket, an endpoint of network communication, is the basis for data transmission between different hosts. A socket connection can be used for real-time data exchange between the client and the server.

[0070] Key-Exchange: In secure communication, key exchange refers to the process by which two communicating parties securely exchange the keys required for encryption through a certain mechanism. Common key exchange protocols include the Diffie-Hellman protocol, etc.

[0071] Encryption: Transforms the original data into unreadable ciphertext to protect the confidentiality of the data. The encryption process usually relies on a key.

[0072] Decryption: Converts the encrypted data back into the original plaintext data. Decryption usually requires a key related to the encryption key.

[0073] Asymmetric-Encryption: An encryption method that uses a pair of keys (a public key and a private key). The public key is used for encryption, and the private key is used for decryption.

[0074] Symmetric-Encryption: An encryption method that uses the same key for both encryption and decryption.

[0075] Random-Number: In encryption protocols, random data used to generate temporary keys. Random numbers can enhance the security of the encryption process.

[0076] Signature: Data encrypted with a private key, used to verify the identity of the message sender and the integrity of the message. Usually used to prove the authenticity of a message.

[0077] Verification: Checking the received data or signature to ensure its legality and consistency.

[0078] Ciphertext: Data that has been encrypted. Compared with the original plaintext data, ciphertext is unreadable.

[0079] Plaintext: The original data that has not been encrypted.

[0080] Length-Check: Checking whether the length of the secret key or data meets the specified requirements.

[0081] Encrypted-Ciphertext: The output after encrypting the data, ensuring the security of the data during transmission.

[0082] Real-time-Execution-Results-Collection: Dynamically collect the output during the execution of a Shell command and return the results.

[0083] Check: Verifying the legality and correctness of a Shell command or data.

[0084] Example 2: The client fills in a Shell command, encrypts the filled Shell command locally using AES, and transmits it to the management end through the SSL secure communication protocol, including the following steps:

[0085] The user enters the required Shell command in the client interface. This Shell command is usually used for remotely executed tasks, such as starting a service, querying the system status, or running a specific script, etc. These Shell commands are in plaintext and directly reflect the operations that the user hopes the host end to execute. To protect the sensitivity of the Shell command, it must be encrypted before transmission.

[0086] The client first generates an independent symmetric secret key (AES secret key) for encrypting the Shell command. The client uses the generated AES secret key to encrypt the input Shell command through the AES encryption algorithm. This will convert the Shell command from plaintext to ciphertext, preventing the content of the Shell command from being stolen during transmission. The encrypted Shell command is unreadable ciphertext, and only the party holding the correct secret key can decrypt it and restore it to the original Shell command.

[0087] The client and the management end establish a secure connection through the SSL protocol. The SSL session provides an encrypted channel for communication, ensuring that data is not eavesdropped on or tampered with by a third party during transmission. When establishing an SSL connection, the client verifies the SSL certificate of the management end to ensure communication with a legitimate management end. The management end may also verify the client's certificate to ensure the identities of both communication parties.

[0088] The client encapsulates the AES-encrypted Shell command in an SSL communication packet and sends it to the management end through the SSL security protocol. In the SSL protocol, the client and the management end use public key encryption technology to further encrypt the data content. Even if an attacker intercepts the communication packet, they cannot decrypt the content without the corresponding private key. The SSL protocol also provides data integrity verification to ensure that the data has not been tampered with during transmission. If the data is modified, the SSL protocol will throw an error and terminate the communication.

[0089] The management end decrypts the received encrypted data through the SSL protocol and extracts the encrypted Shell command ciphertext. The management end will use the built-in verification mechanism of the SSL protocol to confirm whether the received data is complete and has not been tampered with. If the verification passes, it will continue with subsequent operations.

[0090] The management end does not decrypt the Shell command at this time, but directly stores the received ciphertext in the database. The purpose of this step is to ensure that the confidentiality of the Shell command is not leaked, and decryption is only performed when it is necessary to execute it later. Since the Shell command is encrypted and stored, even if the data in the database is accessed, malicious users cannot see the plaintext content of the Shell command.

[0091] The client and the management end establish a connection through the SSL protocol. When establishing an SSL connection, they will verify whether there are any abnormalities in the SSL certificate of the management end. After the verification passes, a communication connection is established, including the following steps:

[0092] The client first sends a connection request to the management end to initiate an SSL / TLS handshake. The client sends a ClientHello message to the management end, which contains information such as supported encryption algorithms, SSL / TLS versions, and generated random numbers. After receiving the client's connection request, the management end responds with a ServerHello message, confirming the used SSL / TLS version and encryption algorithm, and sending a random number generated by the management end. The management end also sends its SSL certificate to the client, which contains the certificate chain (including the server certificate and possibly intermediate certificates).

[0093] After the client receives the SSL certificate of the management end, the following verification steps are carried out:

[0094] The client checks the integrity of the management - end certificate chain, verifying whether the root certificate exists and is in the list of trusted certificate authorities (CAs) of the client. If the certificate chain is incomplete or the root certificate fails to be verified, the client will report an error and terminate the connection. The client checks the validity period of the management - end certificate, verifying whether the current date is within the validity range of the certificate (i.e., NotBefore and Not After). If the certificate has expired or is not yet effective, the client will terminate the connection.

[0095] The client checks whether the certificate has been revoked. The client can verify in two ways: query whether the certificate authority has issued a certificate revocation list and check whether the certificate is in it. OCSP (Online Certificate Status Protocol): The client checks the status of the certificate through an OCSP request to determine whether it has been revoked. If the certificate has been revoked, the client will terminate the connection.

[0096] The client verifies the Subject field of the management - end certificate, ensuring that the "Common Name" (CN) or "Subject Alternative Name" (SAN) of the certificate matches the target host name of the connection. If the host name does not match the CN or SAN in the certificate, the client will report a certificate - mismatch error and reject the connection. The client will verify the signature of the certificate using the public key of the certificate to ensure that the certificate has not been tampered with when it was issued. If the signature verification fails, the client will terminate the connection. After the certificate is verified successfully, the client and the management - end start the key - exchange process to establish an encrypted communication channel.

[0097] RSA key exchange: The client generates a pre - master secret and encrypts it using the public key in the management - end certificate, and then sends it to the management - end.

[0098] Diffie - Hellman key exchange: The client and the management - end negotiate a shared secret key through the Diffie - Hellman algorithm. Both sides generate a private key and a public key respectively, exchange the public keys, and generate a common shared secret key using the other party's public key and their own private key.

[0099] ECDHE key exchange: Similar to Diffie - Hellman, but uses elliptic - curve cryptography to improve security and efficiency.

[0100] The client and the management - end use the key - exchange protocol to generate a session key, which will be used to encrypt the subsequent communication data. Through the session key, both sides can encrypt and decrypt data to ensure the confidentiality and integrity of data transmission.

[0101] The client and the manager exchange messages and perform a final verification to confirm that the key exchange is successful. The client sends a Finished message to indicate that it has been verified and has started using the encrypted channel. After receiving the Finished message, the manager also sends a Finished message to complete the handshake. At this point, the SSL handshake is complete, and an encrypted communication connection is established between the client and the manager. After the SSL handshake is completed, the client and the manager begin to use the session key for encrypted communication, and all data is transmitted through an encrypted channel to ensure that the communication content cannot be stolen or tampered with by a third party.

[0102] After the SSL connection is established, the client and the management end can start exchanging encrypted data. At this time, the data transmission is encrypted using a symmetric encryption algorithm (such as AES) using the session key. Each data packet is verified by a message authentication code (MAC) to ensure that the data has not been tampered with during transmission.

[0103] When the communication ends, the client and the manager close the connection through the close_notify message in the SSL / TLS protocol. At this point, both parties end the encrypted communication and destroy the session key.

[0104] When establishing an SSL connection, a series of certificate verification steps are performed between the client and the management, including verifying the certificate's validity period, revocation status, signature, and subject matching. Through these verification steps, the client ensures the legitimacy and validity of the certificate. After the verification is passed, the client and the management exchange keys and establish an encrypted communication channel to ensure the security and privacy of data transmission.

[0105] The management end decrypts the received encrypted data through the SSL protocol, extracts the encrypted Shell command ciphertext, and verifies the Shell command ciphertext using the verification mechanism provided by the SSL protocol. If the verification is successful, the received ciphertext is directly stored in the database, including the following steps:

[0106] The SHA-256 hash algorithm is used to calculate the hash value of the Shell command. The expression is:

[0107] , where is a shell command, is the calculated hash value. Here, SHA-256 represents a specific hash algorithm, which can be replaced with other hash algorithms as needed (such as MD5, SHA-1, etc., but SHA-256 is generally more secure);

[0108] Once the hash value of the shell command is calculated, it can be verified by comparing the calculated hash value with the stored hash value. The calculation formula of the verification process is as follows:

[0109] , where is the calculated hash value is the Shell command is the hash value attached to the Shell command sent by the client, representing the hash digest calculated by the client for M represents the verification result, used to indicate whether the verification passes. True indicates that the verification passes, and False indicates that the verification fails;

[0110] If the two hash values are equal, that is , the verification passes and the data has not been tampered with. If the hash values are not equal, that is , the verification fails and the data has been tampered with or damaged. If the verification passes, the received ciphertext is directly stored in the database.

[0111] The host side and the server side conduct secret key negotiation and exchange. The management side generates a random number and signs it using the public key of the host side, including the following steps:

[0112] The management side generates a random number R through a secure random number generator for secret key negotiation. This is usually a random value with a sufficient length to ensure its uniqueness and security. The management side obtains the public key of the host side , encrypts and signs the random number R using the public key of the host side to obtain the encrypted random number S, and analyzes whether there are any abnormalities in the encryption process during the encryption process. According to the analysis results, corresponding management policies are generated. If there are no abnormalities in the encryption process, the encrypted random number S and the plaintext random number R are sent to the host side together.

[0113] Encrypt and sign the random number R using the public key of the host side to obtain the encrypted random number S, and analyze whether there are any abnormalities in the encryption process during the encryption process. According to the analysis results, corresponding management policies are generated, including the following steps:

[0114] During the encryption process, obtain the integrity factor, encryption time factor, and resource consumption factor, and comprehensively calculate the encryption coefficient by combining the integrity factor, encryption time factor, and resource consumption factor. The expression is: , where is the encryption coefficient is the integrity factor is the encryption time factor is the resource consumption factor , , are the proportionality coefficients of the integrity factor, encryption time factor, and resource consumption factor respectively, and , , are all greater than 0;

[0115] The larger the encryption coefficient, the less abnormal the encryption process is. Compare the obtained encryption coefficient with a preset coefficient threshold, which is used to analyze whether there is an abnormality in the encryption process. If the encryption coefficient is greater than or equal to the coefficient threshold, it is analyzed that the encryption process is normal. If the encryption coefficient is less than the coefficient threshold, it is analyzed that the encryption process is abnormal. When it is analyzed that the encryption process is abnormal, the generated management strategy is: re-encrypt and sign the random number R with the public key of the host to obtain the encrypted random number S. When the encryption coefficients of 5 consecutive re-encryption processes are all less than the coefficient threshold, send a warning signal to the administrator for handling by the administrator.

[0116] The calculation expression of the integrity factor is: , where is the actual length of the random number, is the expected length of the random number (such as 256 or 512 bits), is the actual length of the public key, is the standard length of the public key (such as 2048 or 4096 bits), is the format check assignment. If there is no format error, , if there is a format error, , the larger the integrity factor, the more complete the random number and the public key are, and the less abnormal it is.

[0117] The calculation logic of the encryption time factor is: obtain the maximum allowed encryption time and the actual encryption time of the encryption process, subtract the maximum allowed encryption time from the actual encryption time of the encryption process to obtain the time difference, and divide the time difference by the maximum allowed encryption time to obtain the encryption time factor;

[0118] When the value of the encryption time factor is less than or equal to zero, it means that the actual encryption time is within the allowed range and the encryption process is normal. When the value of the encryption time factor is greater than zero, it means that the actual encryption time exceeds the allowed range. The larger the value, the more the encryption process time exceeds, and the greater the possibility of abnormality.

[0119] The calculation logic of the resource consumption factor is: obtain the resource amount threshold for resource usage operation and the actual resource usage amount, subtract the resource amount threshold from the actual resource usage amount to obtain the resource amount difference, and divide the resource amount difference by the resource amount threshold to obtain the resource consumption factor;

[0120] When the value of the resource consumption factor is less than or equal to zero, it means that the actual resource usage amount is within the allowed range and the encryption process is normal. When the value of the resource consumption factor is greater than zero, it means that the actual resource usage amount exceeds the allowed range. The larger the value, the more the resource consumption exceeds, and the greater the possibility of abnormality.

[0121] Send the random number and the signature value to the host side, decrypt and verify them using the host side's private key, and then re-encrypt them using the server side's public key and return them to the server side, including the following steps:

[0122] The host side receives a data packet from the server side, which contains a random number and a signature value.

[0123] The host side uses the private key stored locally to decrypt the signature value, obtains the decrypted content, and verifies whether the decryption is successful: If the decryption fails, it indicates that the signature value may have been tampered with or there is a problem with data transmission. Terminate the operation and return an error response. If the decryption is successful, proceed to the next step.

[0124] The host side verifies the decrypted content to ensure that it matches the random number: Compare the received random number with the decrypted random number. If the two are inconsistent, the verification fails and an abnormal response is returned. If they are consistent, the verification passes and enters the encryption phase. The host side re-encrypts the random number. The host side encrypts the verified random number using the server side's public key to generate a new encrypted random number.

[0125] The host side returns the encrypted random number as a response to the server side through a secure communication channel. After receiving the encrypted random number returned by the host side, the server side decrypts it using its own private key and compares it with the original random number to verify the consistency: If they are consistent, the key negotiation process is successful and enters the session key generation phase. If they are inconsistent, it is considered that there is an abnormality on the host side and the negotiation is terminated.

[0126] The server side conducts another verification. If they are consistent, it generates a session key by performing an exclusive OR operation on the random numbers bit by bit and simultaneously establishes a long socket connection, including the following steps:

[0127] After receiving the encrypted random number returned by the host side, the server side decrypts it using the server side's own private key to obtain the random number re-encrypted by the host side. The server side compares the decrypted random number with the random number it originally sent: If the two are consistent, it indicates that the verification passes and the random number has not been tampered with, and proceed to the next step. If the two are inconsistent, it indicates that there may be a data transmission problem or an abnormality on the host side. Terminate the operation and return an error response.

[0128] In the case of successful verification, the server side uses its own original random number and the verified random number to generate a session key according to the following logic: Perform an exclusive OR operation on the two random numbers bit by bit to generate the final session key. The generated session key is unique and secure and is used for data encryption in subsequent communications. The server side stores the generated session key in a secure memory area to ensure the confidentiality of the key. The session key is only valid in the current connection session and is destroyed when the connection ends.

[0129] The server and the host establish a long - term Socket connection through a secure communication channel, and use the generated session secret key as the encryption basis for communication. The two parties confirm whether the Socket connection is successful through a handshake: if the connection is successful, enter the data encryption and transmission stage. If the connection fails, attempt to re - establish the connection or terminate the current session.

[0130] After the server completes the Socket connection, it sends an encrypted confirmation message to the host to confirm the validity of the session secret key. The host decrypts the confirmation message and returns a response to ensure the consistency of the session secret key between the two parties. In the case of a successful long - term Socket connection, the server and the host enter the formal encrypted communication mode, and all transmitted data is encrypted and decrypted using the session secret key.

[0131] After decrypting the encrypted Shell command of the client into ciphertext, use the session secret key to perform AES encryption on the ciphertext and send it to the host through the socket, including the following steps:

[0132] The server obtains the encrypted Shell command of the client from the database or memory. Ensure that the encrypted Shell command data is complete, error - free, and not tampered with or damaged.

[0133] The server decrypts the Shell command using the AES secret key provided by the client to obtain the original Shell command content. During the decryption process: Verify whether the decryption operation is successful. If the decryption fails, return a decryption error response and terminate the operation. If the decryption is successful, proceed to the next step. Verify the legality of the decrypted Shell command

[0134] Verify the legality of the decrypted Shell command to ensure that the Shell command complies with the system's security rules, such as: prohibited Shell commands or keyword filtering. Check the format and syntax of the Shell command. If the Shell command verification fails, record the log and return an illegal Shell command error. If the verification passes, continue with the next step. Use the session secret key negotiated with the host to re - encrypt the decrypted Shell command through the AES encryption algorithm. Ensure that the encrypted ciphertext is random and unique to prevent replay attacks.

[0135] Ensure that the long - term Socket connection has been established and the connection status is normal. If the connection has not been established, re - establish the Socket connection with the host to ensure the security and reliability of the communication channel. The server sends the encrypted Shell command ciphertext encrypted with the session secret key to the host through the Socket connection. During the sending process: Ensure that the data packet is sent completely. Check the transmission status and confirm that the host has successfully received the data.

[0136] The server listens for the response information returned by the host, and confirms that the Shell command has been successfully transmitted to the host. If the host does not respond or returns an error, the server records the exception information and attempts to resend or terminate the operation. The server records the log information of the entire data processing and transmission, including the status of each link such as reception, decryption, encryption, and transmission, which is convenient for subsequent auditing and problem troubleshooting.

[0137] After the host receives the encrypted Shell command ciphertext through the socket, it uses the session key to perform AES decryption, verifies whether the decrypted Shell command is legal, and sends it to the local to execute the Shell command after passing the verification, including the following steps:

[0138] The host receives the encrypted Shell command ciphertext through the Socket connection. The ciphertext is encrypted by the session key to ensure the security of data transmission. The host uses the session key to perform AES decryption on the received ciphertext to restore the original Shell command. This step ensures that the content of the Shell command will not be tampered with. The decrypted Shell command needs to undergo a legality verification to ensure that the Shell command format is correct and there is no malicious code. The verification steps can include:

[0139] Check whether the syntax of the Shell command is legal. Prevent disallowed Shell commands or dangerous operations (such as system destruction, data leakage, etc.). Verify whether the parameters and paths of the Shell command conform to the preset rules.

[0140] If the decrypted Shell command passes the verification, the host passes it to the local Shell for execution. During the execution process, the host will monitor the execution status of the Shell command and record the output results.

[0141] After the host finishes executing the Shell command, it collects the execution results and prepares to return. This step may involve organizing the content of each line of output into a set and further encrypting it before sending it back to the server.

[0142] Collect the execution results in real time, organize them by line, return them in the form of a set, encrypt the return results using the session key and return them to the server, and at the same time close the socket connection and destroy the key, including the following steps:

[0143] Collect the execution results: After the host executes the Shell command locally, it collects the execution results line by line in real time to ensure the integrity of the output information of each line.

[0144] Organize the execution results by line: Organize each line of the collected results to ensure that each line of data is an independent element, forming a set (such as a list or an array).

[0145] Encrypted return result: Use the session key to perform AES encryption on the organized execution result to ensure the security of data during transmission. The encrypted data is ciphertext.

[0146] Send the ciphertext through Socket: The encrypted execution result is sent to the server through the established Socket connection to ensure the confidentiality of data during transmission.

[0147] Close the Socket connection: After the result is sent, close the Socket connection in a timely manner to ensure the release of resources and prevent unnecessary security risks.

[0148] Destroy the key: After transmitting the data and closing the connection, destroy the session key to prevent the key from being leaked or misused and ensure the ultimate security of communication.

[0149] Embodiment 3: A Shell command encryption remote transmission system described in this embodiment includes an encryption module, a management module, a host module, a service module, an execution module, and a result return module;

[0150] Encryption module: The client fills in the Shell command, performs AES encryption on the filled Shell command locally, and transmits it to the management module through the SSL secure communication protocol. The Shell command is sent to the service module;

[0151] Management module: Generate a random number, sign it using the public key of the host, and send the random number and the signature value to the host module;

[0152] Host module: Use the private key for decryption verification, re-encrypt it using the public key of the service module and return it to the service module. After receiving the encrypted Shell command ciphertext through the socket, perform AES decryption using the session key;

[0153] Service module: Verify again. If they are consistent, generate a session key by performing an exclusive OR operation on the random number bit by bit, and at the same time establish a long socket connection. After decrypting the encrypted Shell command from the encryption module into ciphertext, perform AES encryption on the ciphertext using the session key, and return it to the host module through the socket;

[0154] Execution module: Verify whether the decrypted Shell command is legal. After passing the verification, send it to execute the Shell command locally;

[0155] Result return module: Collect the execution results in real time, organize them by line, return them in the form of a set, encrypt the return result using the session key and return it to the service module, and at the same time close the socket connection and destroy the key.

[0156] The above formulas are all dimensionless and only take their numerical values for calculation. The formulas are obtained by collecting a large amount of data and performing software simulations to obtain a formula that is closest to the actual situation. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0157] It should be understood that the term "and / or" in this article is merely an association relationship describing associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. Here, A and B can be singular or plural. Additionally, the character " / " in this article generally represents an "or" relationship between the associated objects before and after, but it may also represent an "and / or" relationship, which can be specifically understood by referring to the context before and after.

[0158] It should be understood that in various embodiments of the present application, the magnitudes of the sequence numbers of the above processes do not imply the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0159] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this article can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0160] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present application, and all should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for encrypting and remotely transmitting Shell commands, characterized in that: The delivery method comprises the following steps: The client fills in the Shell command, encrypts the filled-in Shell command locally with AES, and transmits it to the management end through the SSL secure communication protocol. The host and the server negotiate and exchange secret keys. The management end generates a random number, signs it with the host's public key, and sends the random number and signature value to the host. The host uses the host private key to perform decryption verification, and re-uses the server public key to encrypt and return to the server. The server then verifies. If they are consistent, a random number is used to perform bitwise XOR operations to generate a session key, and a socket long connection is established at the same time. The server decrypts the client's encrypted Shell command and then decrypts the Shell command into ciphertext, uses the session key to perform AES encryption on the ciphertext, and sends it to the host through the socket. After the host receives the encrypted Shell command named ciphertext through the socket, it uses the session key to perform AES decryption; Verify whether the decrypted Shell command is legal. If the verification is passed, send it to the local to execute the Shell command. Collect the execution results in real time and organize them by line. Return them in a collection. Use the session key to encrypt and return the results to the server. At the same time, close the socket connection and destroy the key.

2. A method for encrypting and remotely transmitting Shell commands according to claim 1, characterized in that: The host and the server negotiate and exchange secret keys. The management generates a random number and signs it with the host's public key, including the following steps: The management end generates a random number R through a secure random number generator. The random number R is used for key negotiation to obtain the public key of the host end. , use the public key of the host to encrypt and sign the random number R to obtain the encrypted random number S, and analyze whether there is an abnormality in the encryption process during the encryption process, and generate a corresponding management policy based on the analysis results. If there is no abnormality in the encryption process, the encrypted random number S and the random number R are sent to the host together.

3. A method for encrypting and remotely transmitting Shell commands according to claim 2, characterized in that: The random number R is encrypted and signed using the public key of the host to obtain the encrypted random number S, and the encryption process is analyzed to see if there is any abnormality, including the following steps: In the encryption process, the integrity factor, encryption time factor and resource consumption factor are obtained, and the integrity factor, encryption time factor and resource consumption factor are comprehensively calculated to obtain the encryption coefficient, which is expressed as follows: , where is the encryption factor, is the integrity factor, is the encryption time factor, is the resource consumption factor, , , are the proportional coefficients of integrity factor, encryption time factor and resource consumption factor respectively, and , , All are greater than 0; The obtained encryption coefficient is compared with a preset coefficient threshold, and the coefficient threshold is used to analyze whether there is an abnormality in the encryption process. If the encryption coefficient is greater than or equal to the coefficient threshold, it is analyzed that there is no abnormality in the encryption process; if the encryption coefficient is less than the coefficient threshold, it is analyzed that there is an abnormality in the encryption process; When anomalies are found in the encryption process, the generated management policy is: re-use the public key of the host to encrypt and sign the random number R to obtain the encrypted random number S. When the encryption coefficient of the re-encryption process is less than the coefficient threshold for five consecutive times, a warning signal is sent to the administrator for processing.

4. A method for encrypting and remotely transmitting Shell commands according to claim 3, characterized in that: The calculation expression of the integrity factor is: , where is the actual length of the random number, is the expected length of the random number, is the actual length of the public key, is the standard length of the public key, Assign a value to the format check. If there is no error in the format, If there is an error in the format, ; The calculation logic of the encryption time factor is as follows: obtaining the maximum encryption time allowed for encryption and the actual encryption time, subtracting the maximum encryption time allowed for encryption from the actual encryption time to obtain the time difference, and dividing the time difference by the maximum encryption time allowed for encryption to obtain the encryption time factor; The calculation logic of the resource consumption factor is: obtain the resource amount threshold of resource usage operation and the actual resource usage, subtract the resource amount threshold from the actual resource usage to obtain the resource amount difference, and divide the resource amount difference by the resource amount threshold to obtain the resource consumption factor.

5. A method for encrypting and remotely transmitting Shell commands according to claim 4, characterized in that: After the host receives the encrypted Shell command naming ciphertext through the socket, it uses the session key to perform AES decryption to verify whether the decrypted Shell command is legal. After the verification is passed, it is sent to the local to execute the Shell command, including the following steps: The host receives the encrypted Shell command ciphertext through the Socket connection, uses the session key to perform AES decryption on the received ciphertext, and restores the original Shell command; Check whether the syntax of the Shell command is legal, and verify whether the parameters and paths of the Shell command conform to the preset rules; If the decrypted Shell command passes the verification, the host will pass it to the local Shell for execution. During the execution, the execution status of the Shell command is monitored and the output results are recorded. After the Shell command is executed, the host collects the execution results and prepares to return, organizes the content of each line of output into a collection, and further encrypts it before sending it back to the server.

6. A method for encrypting and remotely transmitting Shell commands according to claim 5, characterized in that: The client fills in the Shell command, encrypts the filled Shell command locally with AES, and transmits it to the management end through the SSL secure communication protocol, including the following steps: The user enters the required Shell command in the client interface. The Shell command includes starting a service, querying system status, or running a script. The client first generates a symmetric key, which is used to encrypt Shell commands. The client then uses the generated AES key to encrypt the input Shell commands using the AES encryption algorithm. The client and the management end establish a connection through the SSL protocol. When establishing the SSL connection, the management end's SSL certificate will be verified for abnormalities. After the verification is passed, the communication connection will be established; The client encapsulates the AES-encrypted Shell command in an SSL communication package and sends it to the management end through the SSL security protocol. In the SSL protocol, the client and the management end use public key encryption technology to encrypt data content; The management end decrypts the received encrypted data through the SSL protocol, extracts the encrypted Shell command ciphertext, and uses the verification mechanism provided by the SSL protocol to verify the Shell command ciphertext. If the verification passes, the received ciphertext is directly stored in the database.

7. A method for encrypting and remotely transmitting Shell commands according to claim 6, characterized in that: The management end uses the verification mechanism of the SSL protocol to verify the Shell command ciphertext, including the following steps: The SHA-256 hash algorithm is used to calculate the hash value of the Shell command. The expression is: , where is a shell command, is the calculated hash value; Verification is performed by comparing the calculated hash value with the stored hash value. The calculation formula of the verification process is as follows: , where is the calculated hash value, is a shell command, The hash value included in the Shell command sent by the client. Indicates the result of verification, used to indicate whether the verification is passed. True indicates that the verification is passed, and False indicates that the verification fails. If the two hash values ​​are equal, , the verification is passed, the data has not been tampered with, if the hash value is not equal, that is , the verification fails and the data has been tampered with or damaged. If the verification passes, the received ciphertext is directly stored in the database.

8. A method for encrypting and remotely transmitting Shell commands according to claim 1, characterized in that: The client and the management end establish a connection through the SSL protocol. When establishing the SSL connection, the management end's SSL certificate will be verified for any abnormalities. After the verification is passed, a communication connection is established, including the following steps: The client sends a connection request to the management end, initiates an SSL / TLS handshake, and sends a ClientHello message to the management end, which contains supported encryption algorithms, SSL / TLS versions, and generated random number information; After receiving the connection request from the client, the management end responds to the ServerHello message, confirms the SSL / TLS version and encryption algorithm used, sends a random number generated by the management end, and sends its SSL certificate to the client. The SSL certificate includes a certificate chain. After the client receives the SSL certificate from the management side, check the integrity of the management side certificate chain, verify that the root certificate exists and is in the client's trusted certificate authority list, check the validity period of the management side certificate, and verify that the current date is within the validity period of the certificate; Check whether the certificate authority has published a certificate revocation list and check whether the certificate is in it. The client verifies the certificate subject field of the management end. If the host name does not match the CN or SAN in the certificate, the client will report a certificate mismatch error and refuse to connect.

9. A method for encrypting and remotely transmitting Shell commands according to claim 8, characterized in that: The host and the server negotiate and exchange keys, including the following steps: Deploy the service management host on the host side, establish a communication connection with the service management host, generate an RSA asymmetric encryption key pair, convert the key into 512-bit format, and check the length of the private key. If the length of the private key is not 32 bytes, intercept the last 32 bytes; The server uses AES to encrypt the RSA public key and sends it to the host. The host performs the same operation and sends the host's public key back. The management generates a random number, signs it with the host's public key, and then sends the random number and signature value to the host. The host uses the private key for decryption verification, and re-encrypts it with the server's public key and returns it to the server. The server verifies it again. If they are consistent, it is determined that the negotiated key is successful, and a session key is generated. The random number is used for bitwise XOR operation to generate the session key and establish a long socket connection.

10. A Shell command encryption remote transmission system, used to implement the transmission method according to any one of claims 1 to 9, characterized in that: It includes encryption module, management module, host module, service module, execution module and result return module; Encryption module: The client fills in the Shell command, which is encrypted by AES locally and transmitted to the management module via the SSL secure communication protocol. The Shell command is then sent to the service module. Management module: Generates a random number, signs it with the host's public key, and sends the random number and signature value to the host module; Host module: Use the private key to perform decryption verification, and re-use the public key of the service module to encrypt and return to the service module. After receiving the encrypted Shell command naming ciphertext through the socket, use the session key to perform AES decryption; Service module: Verify again. If they are consistent, use the random number to perform bitwise XOR operation to generate the session key, and establish a long socket connection at the same time. Decrypt the encrypted Shell command of the encryption module and then decrypt the Shell command into ciphertext. Use the session key to perform AES encryption on the ciphertext and return it to the host module through the socket. Execution module: Verify whether the decrypted Shell command is legal. If the verification is passed, send it to the local server to execute the Shell command. Result return module: collects execution results in real time and organizes them by line, returns them in a collection, encrypts the returned results with the session key and returns them to the service module, while closing the socket connection and destroying the key.

Images