Shell command encryption remote transmission method and system

Abstract

The invention discloses a Shell command encryption remote transmission method and system, and relates to the technical field of Shell command transmission, a random number is used to carry out XOR operation bit by bit to generate a session key, a socket long connection is established at the same time, an encrypted Shell command of a client is decrypted, then the Shell command is decrypted into a ciphertext, the session key is used to carry out AES encryption on the ciphertext, and the encrypted Shell command is transmitted to the client. And after the encrypted Shell command named ciphertext is received through the socket, AES decryption is carried out by using the session key, whether the decrypted Shell command is legal is verified, and the decrypted Shell command is sent to the local to execute the Shell command after the verification is passed. The transmission system realizes secure remote communication of Shell commands, performs secure encrypted transmission under the condition of not influencing the user experience, is suitable for units and individuals with high information security requirements, can effectively prevent network data attack, data analysis and the like, and ensures the security when a host is remotely controlled.

Description

Technical Field

[0001] The present invention relates to the technical field of Shell command transmission, and in particular 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, remote execution of Shell commands is an indispensable function. Remotely writing Shell commands and sending them to services for execution can effectively improve management efficiency, resource utilization, and the overall management of computer room equipment, which are of great significance.

[0003] However, how to send and execute commands safely and effectively from the remote management terminal to the host is a complex task. Ordinary plain text transmission is a very unsafe transmission method. Illegal elements can capture data, restore the original text of Shell commands, use man-in-the-middle attacks and other technologies, and even tamper with the functions of Shell commands, posing a huge hidden danger to security.

[0004] Based on this, the present application provides a Shell command encrypted remote transmission method and system to realize secure remote communication of Shell commands, and securely encrypt transmission without affecting the user experience. It is suitable for use by units and individuals with high information security requirements, and can effectively prevent network data attacks, data analysis, etc., to ensure the security of remote control of the host. Summary of the invention

[0005] The purpose of the present invention is to provide a method and system for encrypting and remotely transmitting Shell commands to solve the shortcomings of the background technology.

[0006] In order to achieve the above object, the present invention provides the following technical solution: a method for remotely transmitting encrypted Shell commands, the method comprising the following steps:

[0007] 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.

[0008] Use the host private key for decryption verification, and re-use the server public key to encrypt and return to the server. The server verifies again. If they are consistent, use the random number to perform bitwise XOR operation to generate the session key, and establish a socket long connection at the same time. Decrypt the client's encrypted Shell command and then decrypt the Shell command into ciphertext. Use the session key to encrypt the ciphertext with AES and send 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.

[0009] 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 the return result and return it to the server. At the same time, close the socket connection and destroy the key.

[0010] In a preferred embodiment, the host and the server negotiate and exchange keys, the management generates a random number, and signs it using the public key of the host, including the following steps:

[0011] 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 plaintext random number R are sent to the host together.

[0012] In a preferred embodiment, the public key of the host is used to encrypt and sign the random number R to obtain the encrypted random number S, and the encryption process is analyzed to determine whether there is an abnormality, including the following steps:

[0013] 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;

[0014] 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;

[0015] 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.

[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, Assign a value to the format check. If there is no error in the format, If there is an error in the format, ;

[0017] 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;

[0018] 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.

[0019] In a preferred embodiment, after receiving the encrypted Shell command naming ciphertext through the socket, the host 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 verification, including the following steps:

[0020] 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;

[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-in 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 verifies the Shell command ciphertext using the verification mechanism provided by the SSL protocol. 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 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.

[0034] 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.

[0035] In a preferred embodiment, the client and the management end establish a connection through the SSL protocol. When establishing the SSL connection, it verifies whether there is an abnormality in the SSL certificate of the management end. After the verification is passed, 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 sends a ClientHello message to the management end, which contains supported encryption algorithms, SSL / TLS versions, and generated random number information;

[0037] 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.

[0038] 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;

[0039] 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.

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

[0041] A small service management host will be deployed on the host side, and a communication connection will be established with the host to generate an RSA asymmetric encryption key pair, convert the key into a 512-bit format, and check 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 RSA public key and send 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 to decrypt and verify, 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 a session key and establish a long socket connection.

[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, 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.

[0045] 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;

[0046] 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;

[0047] 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.

[0048] 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.

[0049] 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.

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

[0051] The present invention generates a random number through the management end, uses the public key of the host end to sign, sends the random number and the signature value to the host end, uses the private key of the host end to decrypt and verify, and re-uses the public key of the server end to encrypt and return to the server end, the server end verifies again, uses the random number to perform bitwise XOR operation to generate a session key, and simultaneously establishes a socket long connection, decrypts the encrypted Shell command of the client 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 end through the socket, after the host end receives the encrypted Shell command naming ciphertext through the socket, uses the session key to perform AES decryption, verifies whether the decrypted Shell command is legal, and sends it to the local execution Shell command after verification. The transmission system realizes secure remote communication of Shell commands, securely encrypts and transmits without affecting the user experience, is suitable for units and individuals with high information security requirements, can effectively prevent network data attacks, data analysis, etc., and ensures the security of remote control of the host. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0053] Figure 1 The present invention is a flow chart of the method. DETAILED DESCRIPTION

[0054] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

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

[0056] 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 keys. The management end generates a random number, signs it with the host's public key, sends the random number and signature value to the host, uses the host's 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, use the random number to perform bitwise XOR operation to generate a session key, and establish a long socket connection at the same time. After decrypting the client's encrypted Shell command, decrypt the Shell command into ciphertext, use the session key to encrypt the ciphertext with AES, and send 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 to verify whether the decrypted Shell command is legal. After verification, it is sent to the local to execute the Shell command. The execution results are collected in real time and sorted according to the line, and then returned in a collection. The return result is encrypted with the session key and returned to the server, and the socket connection is closed and the key is destroyed.

[0057] This application generates a random number through the management end, signs it with the public key of the host end, sends the random number and signature value to the host end, uses the private key of the host end for decryption verification, and re-encrypts it with the public key of the server end and returns it to the server end, which then verifies it again, uses the random number to perform bitwise XOR operation to generate a session key, and simultaneously establishes a long socket connection, 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 end through the socket. After the host end receives the encrypted Shell command named 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 verification. This transmission system realizes secure remote communication of Shell commands, securely encrypts and transmits without affecting the user experience, and is suitable for units and individuals with high information security requirements. It can effectively prevent network data attacks, data analysis, etc., and ensure the security of remote control of the host.

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

[0059] The host and the server negotiate and exchange keys. First of all, it should be clear that the management end is a large management platform, and the host end is a host end where Shell commands are executed. A small service will be deployed on the host end to manage the host and establish a communication connection with the host. In the current key exchange step, first generate an RSA asymmetric encrypted key pair, then convert the key into 512-bit format, and check the length of the private key to ensure that the length of the private key is 32 bytes. If it is not 32 bytes, intercept the last 32 bytes. The second step is to use AES to encrypt the RSA public key. The SA public key is sent to the host side, and the host side performs the same operation and sends its public key back. At this point, the management side and the host side both have each other's public keys. At this time, the management side generates a random number, signs it with the host side's public key, and then sends the random number and signature value together. After receiving it, the host side uses the host side's private key for decryption verification, and re-encrypts it with the server's public key and returns it. After returning to the server, the server verifies it again. If they are consistent, the negotiated key is successful, and the session key is generated. The random number is used for bitwise XOR operation to generate the session key, and a long socket connection is established at the same time.

[0060] First, the encrypted Shell command encrypted with AES passed by the decryption client is decrypted, and then the Shell command is decrypted into ciphertext, otherwise the host side cannot parse it. Then, the session key is used for AES encryption and sent to the host side through the socket.

[0061] After the host receives the encrypted Shell command naming ciphertext through the socket, it uses the session key to perform AES decryption, verifies the decrypted Shell command to verify whether it is legal, and sends it to the local to execute the Shell command after verification. The execution results are collected in real time and sorted by line, and returned in a collection. The returned results are encrypted with the session key and returned directly to the server. 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 over computer networks to ensure the confidentiality and integrity of communications.

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

[0066] Public-Key: In asymmetric encryption, a secret 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 secret key used to decrypt data. The private key must be kept secret, and only the owner of the private key can decrypt data encrypted with the public key.

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

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

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

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

[0072] Decryption: Converting encrypted data back to 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 (public key and 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 secret key for 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 sender's identity 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 legitimacy and consistency.

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

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

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

[0081] Encrypted-Ciphertext: Encrypted data output to ensure data security during transmission.

[0082] Real-time-Execution-Results-Collection: Dynamically collects the output of Shell commands during execution and returns the results.

[0083] Verification (Check): Verify the legality and correctness of Shell commands or data.

[0084] Embodiment 2: 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:

[0085] The user enters the required Shell command in the client interface. The Shell command is usually used for remote execution tasks, such as starting a service, querying system status, or running a specific script. These Shell commands are in plain text and directly reflect the operations that the user wants the host to perform. In order to protect the sensitivity of the Shell command, it must be encrypted before transmission.

[0086] The client first generates an independent symmetric key (AES key) to encrypt the Shell command. The client uses the generated AES key to encrypt the input Shell command through the AES encryption algorithm. This will convert the Shell command from plain text to cipher text, preventing the Shell command content from being stolen during transmission. The encrypted Shell command is a cipher text that cannot be directly understood. Only the party holding the correct key can decrypt 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 or tampered with by a third party during transmission. When the client establishes an SSL connection, it verifies the SSL certificate of the management end to ensure that it is communicating with the legitimate management end. The management end may also verify the client's certificate to ensure the identity of both parties in the communication.

[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 the attacker intercepts the communication packet, he cannot decrypt the content because he does not have 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 uses the verification mechanism of the SSL protocol to confirm whether the received data is complete and has not been tampered with. If the verification is successful, the subsequent operation will continue.

[0090] The management end will not decrypt the Shell command at this time, but will directly store 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 the decryption operation is only performed when it is needed in the future. Because the Shell command is stored in encrypted form, even if the data in the database is accessed, malicious users cannot see the plaintext Shell command content.

[0091] 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:

[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 SSL / TLS version and encryption algorithm used, and sending the random number generated by the management end. The management end also sends its SSL certificate to the client, including the certificate chain (including the server certificate and possible intermediate certificates).

[0093] After the client receives the SSL certificate from the management client, it performs the following verification steps:

[0094] The client checks the integrity of the management certificate chain and verifies that the root certificate exists and is in the client's trusted certificate authority (CA) list. If the certificate chain is incomplete or the root certificate cannot be verified, the client reports an error and terminates the connection. The client checks the validity period of the management certificate and verifies that the current date is within the certificate's validity period (i.e., NotBefore and NotAfter). If the certificate has expired or has not yet taken effect, the client terminates 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 published a certificate revocation list and check whether the certificate is on 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 is revoked, the client terminates the connection.

[0096] The client verifies the subject field of the management certificate to ensure that the certificate's "Common Name" (CN) or "Subject Alternative Name" (SAN) matches the target host name of the connection. If the host name does not match the CN or SAN in the certificate, the client reports a certificate mismatch error and refuses to connect. The client verifies the signature of the certificate using the certificate's public key to ensure that the certificate has not been tampered with when it was issued. If the signature verification fails, the client terminates the connection. After the certificate is verified, the client and management begin the key exchange process to establish an encrypted communication channel.

[0097] RSA key exchange: The client generates a pre-master secret, encrypts it with the public key in the manager's certificate, and then sends it to the manager.

[0098] Diffie-Hellman key exchange: The client and the manager negotiate a shared key using the Diffie-Hellman algorithm. Each party generates a private key and a public key, and then generates a common shared key by exchanging public keys and 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 for increased 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 subsequent communication data. Through the session key, both parties 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 a shell command, The hash value included in the Shell command sent by the client indicates the hash digest calculated by the client for M. 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.

[0110] 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.

[0111] 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:

[0112] The management end generates a random number R through a secure random number generator for key negotiation. This is usually a random value long enough to ensure its uniqueness and security. The management end obtains the public key of the host. , 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 plaintext random number R are sent to the host together.

[0113] The random number R is encrypted and signed using the public key of the host to obtain the encrypted random number S. During the encryption process, the encryption process is analyzed to see if there is an abnormality. According to the analysis result, a corresponding management policy is generated, including the following steps:

[0114] 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;

[0115] The larger the encryption coefficient, the less abnormal the encryption process is. The obtained encryption coefficient is compared with the 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, the encryption process is normal. If the encryption coefficient is less than the coefficient threshold, the encryption process is abnormal. When the encryption process is abnormal, 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 coefficients of five consecutive re-encryption processes are less than the coefficient threshold, a warning signal is sent to the administrator for processing.

[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), Assign a value to the format check. If there is no error in the format, If there is an error in the format, The larger the integrity factor, the more complete the random number and the public key are, and the less abnormalities there are.

[0117] The calculation logic of the encryption time factor is as follows: obtain the maximum encryption time allowed and the actual encryption time, subtract the maximum encryption time allowed from the actual encryption time to obtain the time difference, and divide the time difference by the maximum encryption time allowed 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 allowable 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 allowable range. The larger the value, the more the encryption process time exceeds the allowable range, and the greater the possibility of abnormality.

[0119] The calculation logic of the resource consumption factor is as follows: obtain the resource amount threshold of resource usage operation and the actual resource amount used, subtract the resource amount threshold from the actual resource 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 is within the allowable 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 exceeds the allowable range. The larger the value, the more the resource consumption exceeds the allowable range, and the greater the possibility of abnormality.

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

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

[0123] The host uses the locally stored private key to decrypt the signature value, obtain the decrypted content, and verify 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 the data transmission. The operation is terminated and an error response is returned. If the decryption is successful, proceed to the next step.

[0124] The host verifies the decrypted content to ensure that it matches the random number: the received random number is compared 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 the encryption phase begins. Re-encrypt the random number The host encrypts the verified random number with the server's public key to generate a new encrypted random number.

[0125] The host responds with the encrypted random number and returns it to the server through a secure communication channel. After receiving the encrypted random number returned by the host, the server uses its own private key to decrypt it and compares it with the original random number to verify consistency: if they are consistent, the key negotiation process is successful and the session key generation phase begins. If they are inconsistent, the host is considered abnormal and the negotiation is terminated.

[0126] The server then verifies the session key. If the two are the same, it uses the random number to perform bitwise XOR operations to generate a session key and establishes a persistent socket connection, including the following steps:

[0127] After receiving the encrypted random number returned by the host, the server uses its own private key to decrypt it and obtains the random number re-encrypted by the host. The server compares the decrypted random number with the random number it originally sent: if the two are consistent, it means that the verification is successful 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, and the operation is terminated and an error response is returned.

[0128] If the verification is successful, the server uses its own original random number and the verified random number to generate a session key according to the following logic: perform an XOR 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 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 Socket connection through a secure communication channel, using the generated session key as the encryption basis for communication. Both parties confirm whether the Socket connection is successful through a handshake: if the connection is successful, enter the data encryption transmission stage. If the connection fails, try 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 key. The host decrypts the confirmation message and returns a response to ensure that both parties have the same session key. When the Socket long connection is successful, the server and the host enter the formal encrypted communication mode, and all transmitted data is encrypted and decrypted using the session key.

[0131] After decrypting the client's encrypted Shell command, decrypt the Shell command into ciphertext, use the session 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 client's encrypted Shell command from the database or memory to ensure that the encrypted Shell command data is complete and has not been tampered with or damaged.

[0133] The server uses the AES key provided by the client to decrypt the Shell command and 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 legitimacy of the decrypted Shell command

[0134] Verify the legitimacy 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, log it and return an illegal Shell command error. If the verification passes, proceed to the next step. Use the session key negotiated with the host to re-encrypt the decrypted Shell command using the AES encryption algorithm. Ensure that the encrypted ciphertext is random and unique to prevent replay attacks.

[0135] Ensure that the Socket persistent connection has been established and the connection status is normal. If the connection is not established, re-establish the Socket persistent connection with the host to ensure that the communication channel is secure and reliable. The server will use the session key to encrypt the Shell command ciphertext and send it to the host through the Socket connection. During the sending process: Ensure that the data packet is sent completely. Check the transmission status to confirm that the host successfully receives the data.

[0136] The server monitors the response information returned by the host to confirm that the Shell command has been successfully delivered to the host. If the host does not respond or returns an error, the server records the abnormal information and tries 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, to facilitate subsequent auditing and troubleshooting.

[0137] 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:

[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 and 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 be verified for legitimacy to ensure that the Shell command format is correct and contains no malicious code. The verification steps may include:

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

[0140] If the decrypted Shell command passes the verification, the host will pass 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 Shell command is executed, the host collects the execution results and prepares to return. This step may involve collating the content of each line of output into a collection, further encrypting it and sending it back to the server.

[0142] After collecting the execution results in real time and organizing them by line, they are returned in a collection, encrypted with the session key and returned to the server. At the same time, the socket connection is closed and the key is destroyed. The following steps are included:

[0143] Collect execution results: After the host executes the Shell command locally, the execution results are collected line by line in real time to ensure that the output information of each line is complete and correct.

[0144] Arrange execution results by row: Arrange each row of collected results to ensure that each row of data is treated as an independent element to form a collection (such as a list or array).

[0145] Encrypted return results: Use the session key to encrypt the collated execution results using AES to ensure data security during transmission. The encrypted data is ciphertext.

[0146] Send 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 results are sent, close the Socket connection in time to ensure that resources are released and prevent unnecessary security risks.

[0148] Destroy the key: After the data is transmitted and the connection is closed, the session key is destroyed to prevent the key from being leaked or abused, ensuring the ultimate security of the 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, 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.

[0151] 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;

[0152] 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;

[0153] 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.

[0154] 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.

[0155] 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.

[0156] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0157] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

[0158] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0159] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0160] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on 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. Use the host private key for decryption verification, and re-use the server public key to encrypt and return to the server. The server verifies again. If they are consistent, use the random number to perform bitwise XOR operation to generate the session key, and establish a socket long connection at the same time. Decrypt the client's encrypted Shell command and then decrypt the Shell command into ciphertext. Use the session key to encrypt the ciphertext with AES and send 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 plaintext 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 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. Use AES to encrypt the RSA public key and send 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 to decrypt and verify, 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 a 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