Tunneling-based edge device SSH operation and maintenance implementation system and method

Abstract

The present application relates to a tunneling-based edge device ssh operation and maintenance implementation system and a method. The system comprises: a first device used for receiving an SSH connection request sent by a second device; the second device used for sending the SSH connection request to the first device, and further used for establishing a tunnel connection with the first device after the first device receives the SSH connection request sent by the second device; a third device used for send the SSH connection request to the second device by means of the tunnel connection established between the first device and the second device when the third device is connected to a public network Ip and a port of the first device; and a control device used for issuing a task to the second device and starting / stopping the task, and further used for controlling establishment and destruction of the tunnel connection established between the first device and the second device. By means of cooperative operation of different devices, ssh login in scenarios where the cloud and the edge are in different network planes and there is no Internet port is implemented, and then the problem of uncontrollable costs is solved.

Description

A system and method for implementing SSH operation and maintenance of edge devices based on tunnels

[0001] Related applications

[0002] This application claims priority to Chinese patent application number 2023117182881, filed on December 14, 2023, entitled “A system and method for implementing SSH operation and maintenance of edge devices based on tunnels,” the entire text of which is hereby incorporated by reference. Technical Field

[0003] The present invention relates to the technical field of software development, and more specifically, to a system and method for implementing SSH operation and maintenance of an edge device based on a tunnel. Background Art

[0004] Currently, conventional Kubernetes (k8s for short) deployments are usually carried out in a server cluster within a local area network (LAN), and operations and maintenance personnel can easily log in to any server through SSH for operation and maintenance. However, in edge cloud device maintenance, there is also a need to remotely log in to edge devices through SSH (Secure Shell) to troubleshoot faults. However, due to the scarcity of public IP (Internet Protocol) resources, edge devices are all located within a LAN subnet segment, and the server cannot actively initiate communication requests. Operation and maintenance in this scenario usually involves dispatching operations and maintenance personnel to perform on-site operations or sending remote commands to obtain operation logs, but the results are not satisfactory. Either the operation and maintenance labor costs are high, or the location cannot be determined due to the lack of detailed log information. At the same time, the inability to respond in a timely manner will also lead to a very poor user experience.

[0005] To address this pain point, the main methods currently used are command forwarding and binding a public IP address. Command forwarding uses a client-server mechanism to send the command to be executed from the network to the client, which then executes the command and returns the result to the server. However, this method is generally unable to handle interactive commands such as top and vi, and has significant limitations. Summary of the Invention

[0006] In order to overcome the above-mentioned defects of the prior art, the present invention provides a system and method for implementing SSH operation and maintenance of edge devices based on tunnels.

[0007] On the one hand, an embodiment of the present invention provides a tunnel-based edge device SSH operation and maintenance implementation system, including: a first device, a second device, a third device and a control device, wherein:

[0008] The first device is set on the public network and / or the server, and is used to accept the SSH connection request sent by the second device;

[0009] The second device is provided in an edge environment of the target device, the second device is used to send an SSH connection request to the first device, and the second device is further used to establish a tunnel connection with the first device after the first device accepts the SSH connection request sent by the second device;

[0010] a third device, provided in the external device and / or the management device, configured to send an SSH connection request to the second device through the tunnel connection established between the first device and the second device when the third device is connected to the public network IP and port of the first device;

[0011] A control device is set on the Master node of the Kubernetes cluster. The control device is used to issue and start and stop tasks to the second device. The control device is also used to control the establishment and destruction of the tunnel connection established between the first device and the second device.

[0012] Furthermore, the first device is an nps server, which is set on the public network and / or the server, and the nps server is used to accept and process SSH connection requests from the public network and / or the server.

[0013] Furthermore, the second device includes:

[0014] An npc module is provided in the edge environment of the target device, and is used to send an SSH connection request to the nps server;

[0015] The SSHD module is set on the target device and is used to receive SSH connection requests from the NPS and NPC.

[0016] Furthermore, the npc module is further configured to establish a tunnel connection with the nps server after the nps server accepts the SSH connection request sent by the npc module.

[0017] Furthermore, the third device is an SSH-client module, which is set in the external device and / or the management device, and the SSH-client module is used to initiate an SSH connection request to the nps server.

[0018] Furthermore, the nps server is further configured to, upon receiving an SSH connection request sent by the SSH-client module, send the request to the SSHd module in the target device through the tunnel established between the nps server and the npc module.

[0019] Furthermore, the SSH-client module is also used to send an SSH connection request to the SSHd module in the target device through the tunnel established between the nps server and the npc module.

[0020] Furthermore, the Sshd module is further configured to establish a communication connection with the Ssh-client module after receiving an SSH connection request sent by the Ssh-client module through the tunnel established between the nps server and the npc module.

[0021] Furthermore, the control device is a k8s controller, which is set on the Master node of the Kubernetes cluster. The k8s controller is used to start and stop the Pod of the npc module. The k8s controller is also used to control the establishment or damage status of the tunnel between the nps server and the npc module according to the Pod of the npc module.

[0022] Furthermore, the Ssh-client module is an SSH connection request initiator composed of one or more combinations of MobaXterm, PuTTY, Xshell, etc.

[0023] On the other hand, an embodiment of the present invention further provides a method for implementing a tunnel-based edge device SSH operation and maintenance system based on the above-mentioned embodiments of the invention, including:

[0024] Install and start the nps server on the Kubernetes Master node, and ensure that the nps server is running on the Kubernetes Master node and listening on a specific port;

[0025] Configure the port forwarding rules on the NPS server and ensure that the port of the NPS server after configuration is port 22;

[0026] Control the k8s controller to send the Pod of the npc module to the edge environment of the target device, and establish a long connection with the nps server through the public network IP of the Kubernetes Master node;

[0027] Control the nps server to send the SSH connection request to the npc module of the target node through the corresponding long connection, and control the npc module to forward it to the SSH-client module.

[0028] Furthermore, when performing the installation and startup of the nps server on the Master node of the Kubernetes and ensuring that the nps server is running on the Master node of the Kubernetes and listening to a specific port, it also includes: setting a firewall policy to allow public network users to access the IP address and port of the nps server. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the conventional technology, the following briefly introduces the drawings required for use in the embodiments or the conventional technology descriptions. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the disclosed drawings without any creative work.

[0030] FIG1 is a structural block diagram of a system for implementing SSH operation and maintenance of an edge device based on a tunnel according to an embodiment of the present invention.

[0031] FIG2 is a schematic diagram of a framework of a system for implementing SSH operation and maintenance of an edge device based on a tunnel according to an embodiment of the present invention.

[0032] FIG3 is a flowchart of an implementation method of a tunnel-based edge device SSH operation and maintenance implementation system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0034] As shown in Figures 1 and 2, an embodiment of the present invention provides an implementation system for SSH operation and maintenance of edge devices based on a tunnel, including: a first device, a second device, a third device and a control device, wherein the first device is set in a public network and / or a server end, and the first device is used to accept an SSH connection request sent by the second device; the second device is set in an edge environment of the target device, and the second device is used to send an SSH connection request to the first device, and the second device is also used to establish a tunnel connection with the first device after the first device accepts the SSH connection request sent by the second device; the third device is set in an external device and / or a management device, and when the third device is connected to the public network IP and port of the first device, the third device sends an SSH connection request to the second device through the tunnel connection established between the first device and the second device; the control device is set on the Master node of the Kubernetes cluster, and the control device is used to issue and start and stop tasks to the second device, and the control device is also used to control the establishment and destruction of the tunnel connection established between the first device and the second device.

[0035] It can be seen that by placing the first device on the public network or server side, it acts as the receiver of the SSH connection request and accepts the request sent by the second device. The second device is located in the edge environment of the target device, and is responsible for sending SSH connection requests to the first device and establishing a tunnel connection with the first device to achieve secure communication. The third device is located in an external device or a management device, and by connecting to the public IP and port of the first device, it can send an SSH connection request to the second device through the established tunnel connection. The control device is located on the Master node of the Kubernetes cluster, and is responsible for issuing and starting and stopping tasks to the second device, while managing the establishment and destruction of the tunnel connection between the first device and the second device. This system provides a safe and efficient solution for SSH operation and maintenance of edge devices, allowing remote management and maintenance of target devices without direct access to the target devices, which increases convenience and controllability of the system.

[0036] It is understandable that the first device acts as the receiving end of the SSH connection, accepting the connection request of the second device, making the remote SSH connection feasible. The second device is located in the edge environment of the target device and can establish a tunnel connection with the first device, thereby ensuring the secure transmission of the SSH request. The third device can connect to the first device from an external device or a management device, and send an SSH request to the second device through the established tunnel connection to achieve remote operation and maintenance. The control device is located on the Master node of the Kubernetes cluster. By controlling the task distribution and start and stop of the second device, and managing the tunnel connection between the first device and the second device, centralized control of the entire system is achieved. This system improves the remote management efficiency of edge devices, strengthens the monitoring and management of tunnel connections, and makes SSH operation and maintenance more convenient and controllable.

[0037] Specifically, in some embodiments of the present invention, the first device is an nps server, which is set on the public network and / or the server. The nps server is used to receive and process SSH connection requests from the public network and / or the server.

[0038] As can be seen, the first device is the NPS server, located on the public network and / or server. Its primary function is to accept and process SSH connection requests from the public network and / or server. This device acts as a relay station, allowing external users or servers to establish connections to the target device via the SSH protocol, enabling remote access and management. This technical solution provides an entry point and relay function for remote SSH operation and maintenance, enhancing system accessibility and manageability.

[0039] It is understood that the first device, acting as an NPS server located on the public network and / or server side, acts as a relay station for receiving and processing SSH connection requests, enabling users or servers to securely establish an SSH connection with the target device via the public network, thereby enabling remote operation, maintenance, and management. This provides a convenient remote access path, enhances system accessibility, and also increases system security and management efficiency.

[0040] Specifically, in some embodiments of the present invention, the second device includes an NPC module and an SSHd module. The NPC module is located in the edge environment of the target device and is configured to send an SSH connection request to an NPS server. After the NPS server accepts the SSH connection request sent by the NPC module, the NPC module is further configured to establish a tunnel connection with the NPS server. The SSHd module is located on the target device and is configured to receive SSH connection requests from the NPS and NPC.

[0041] It can be seen that the second device consists of an npc module and an SSHd module. The npc module, located at the edge of the target device, is responsible for establishing a tunnel connection with the nps server and sending SSH connection requests to the nps server. The SSHd module, located on the target device, is specifically responsible for receiving SSH connection requests from the nps server and the npc module, acting as the target device's SSH server. This technical solution implements SSH connection proxying and tunneling, providing a convenient method for remote operation and maintenance, while also effectively managing the processing of SSH connection requests.

[0042] It can be understood that the collaborative work of the npc module and the sshd module in the second device enables the tunnel proxy function for SSH operation and maintenance on the edge device. The npc module, located in the edge environment, is responsible for establishing a tunnel connection with the nps server, passing SSH connection requests from the target device to the nps server, thereby enabling remote access to the target device. Simultaneously, the sshd module, located on the target device, is capable of receiving SSH connection requests from the nps server and the npc module, providing a flexible and secure remote operation and maintenance method for the target device.

[0043] Specifically, in some embodiments of the present invention, the third device is an Ssh-client module, which is set in an external device and / or a management device. The Ssh-client module is used to initiate an SSH connection request to the nps server. The Ssh-client module is also used to send an SSH connection request to the Sshd module in the target device after establishing a tunnel between the nps server and the npc module.

[0044] As can be seen, the SSH-client module in the third device acts as an SSH client. Located in an external device or management device, it establishes an SSH connection request with the NPS server. Through the tunnel established between the NPS server and the NPC module, it seamlessly transmits the SSH connection request to the SSHd module in the target device. This technical solution enables SSH connection transmission in various network environments, providing greater flexibility and accessibility for SSH operations and maintenance on edge devices, making it easier for administrators to manage and maintain target devices.

[0045] As you can see, the SSH-client module in the third device plays a key role, enabling external devices and management devices to easily communicate with edge devices via SSH. By establishing an SSH connection with the NPS server, it tunnels the SSH connection request to the SSHd module on the target device, enabling seamless remote operation and maintenance. This provides a more flexible and efficient way for administrators to easily manage remote devices, reducing operational complexity and costs.

[0046] Specifically, in some embodiments of the present invention, the nps server is further configured to, upon receiving an SSH connection request sent by the SSH-client module, send the request to the SSHd module in the target device through the tunnel established between the nps server and the npc module.

[0047] Specifically, in some embodiments of the present invention, the Sshd module is further configured to establish a communication connection with the Ssh-client module after receiving an SSH connection request sent by the Ssh-client module through a tunnel established between the nps server and the npc module.

[0048] It can be seen that the nps server acts as a relay station, helping to forward SSH connection requests from the SSH-client module to the SSHd module of the target device through the tunnel. Simultaneously, the SSHd module receives and processes SSH connection requests on the target device, effectively ensuring communication between the SSH-client module and the target device.

[0049] Understandably, the nps server, as a core transit station, plays a crucial role as a connection hub. It receives SSH connection requests from the ssh-client module and forwards them to the sshd module on the target device through a tunnel established with the npc module, enabling remote operation of the SSH connection. This distributed architecture facilitates the transfer of remote O&M operations from external devices to the target device, improving network security and operational convenience. At the same time, the sshd module ensures the receipt and processing of SSH connection requests on the target device, enabling efficient communication connections, providing users with a better operational experience, and reducing the difficulty of O&M.

[0050] Specifically, in some embodiments of the present invention, the control device is a k8s controller, which is set on the Master node of the Kubernetes cluster. The k8s controller is used to start and stop the Pod of the npc module. The k8s controller is also used to control the establishment or damage status of the tunnel between the nps server and the npc module according to the Pod of the npc module.

[0051] It can be seen that by setting the k8s controller on the Master node in the Kubernetes cluster, it is responsible for managing the Pod of the npc module, including starting and stopping tasks. This means that it can dynamically manage containerized applications related to the npc module to ensure the normal operation of the npc module. In addition, the k8s controller also controls the establishment and damage status of the tunnel between the nps server and the npc module. By determining the establishment or termination of the tunnel based on the Pod status of the npc module, flexible control of the entire system connection and effective resource management are achieved.

[0052] Understandably, the Kubernetes controller plays a key role in the system. By managing the NPC module's Pods, it enables the start and stop management of containerized applications, thereby achieving system automation and dynamic expansion. Furthermore, the Kubernetes controller can control the establishment or removal of tunnels between the NPS server and the NPC module based on the NPC module's Pod status, providing intelligent management of tunnel connections. This control approach, combined with Kubernetes' powerful container orchestration capabilities, makes the system more flexible and efficient, adapting to the SSH operation and maintenance requirements of edge devices under varying loads and network conditions, further improving the system's scalability, stability, and maintainability.

[0053] Specifically, in some embodiments of the present invention, the Ssh-client module is an SSH connection request initiator composed of one or more combinations of MobaXterm, PuTTY, Xshell, etc.

[0054] The SSH-client module, understandably, covers a wide range of SSH connection request initiators, such as MobaXterm, PuTTY, and Xshell. This means it offers broad compatibility, meeting the needs of a wide range of end users. Regardless of which SSH client a user uses, they can easily connect to the target device, enhancing the system's flexibility and user-friendliness. This diversity helps reach a wider user base, making the system more universally applicable while reducing user training and adaptation costs.

[0055] In summary, the embodiments of the present invention provide a tunnel-based SSH operation and maintenance system for edge devices. This system uses a first device as the receiver of SSH connection requests. A second device in the edge environment sends a request to the first device, subsequently establishing a tunnel connection. This system implements a secure SSH connection from the public network or server to the target device. This simplifies remote maintenance of edge devices and improves system security. Furthermore, a third device, acting as an external device or management device, can easily send SSH connection requests to the second device by connecting to the first device. This provides a convenient remote maintenance method for operators, eliminating the need for direct communication with the target device, thereby reducing maintenance complexity and the risk of errors. Most importantly, the control device, located on the Master node of the Kubernetes cluster, has the ability to issue and start / stop tasks to the second device and manage the establishment and termination of the tunnel connection between the first and second devices. This makes the entire system dynamic, allowing for flexible establishment and termination of tunnel connections as needed, enabling anytime, anywhere SSH operation and maintenance of edge devices. This improves the efficiency and convenience of operation and maintenance, facilitating rapid response to issues and maintaining the stability of edge devices.

[0056] As shown in FIG3 , some embodiments of the present invention further provide a method for implementing a tunnel-based edge device SSH operation and maintenance system based on the above embodiments, including:

[0057] Step S100: Install and start the nps server on the Master node of Kubernetes, and ensure that the nps server is running on the Master node of Kubernetes and listening on a specific port.

[0058] Step S200: Configure port forwarding rules on the nps server and ensure that the configured port of the nps server is port 22.

[0059] Step S300: Control the k8s controller to send the Pod of the npc module to the edge environment of the target device, and establish a long connection with the nps server through the public network IP of the Kubernetes Master node.

[0060] Step S400: Control the nps server to send the SSH connection request to the npc module of the target node through the corresponding long connection, and control the npc module to forward it to the SSH-client module.

[0061] It can be seen that, first, in step S100, by installing and starting the nps server on the Master node of Kubernetes, it is ensured that it runs normally and listens to a specific port, thereby providing an entry for the SSH connection. Then, in step S200, the port forwarding rule is configured to direct the SSH connection request to port 22 of the target device to ensure SSH communication with the target device. In step S300, the k8s controller ensures the availability of remote access by sending the Pod of the npc module to the edge environment of the target device and establishing a long connection through the public network IP of the Master node of Kubernetes. Finally, in step S400, the nps server routes the SSH connection request to the npc module of the target node through the established long connection, and the npc module forwards it to the Ssh-client module, thereby realizing the forwarding of the SSH connection request and the actual establishment of the SSH session. This technical solution enables remote SSH operation and maintenance operations while ensuring the security and availability of the connection.

[0062] As you can understand, step S100 ensures that the nps server runs on the Kubernetes Master node and, by listening on a specific port, provides a central entry point for external SSH connections. This reduces direct SSH exposure to target devices, increases overall system security, and allows control and monitoring of all inbound connections. Secondly, the port forwarding rule configuration in step S200 ensures that public network traffic is smoothly directed to the target device's SSH port, enabling remote access. The control device's SSH client module, such as MobaXterm, PuTTY, or Xshell, initiates SSH connection requests and establishes secure communication with the nps server. This enables external devices to access edge devices without opening additional ports on the firewall, thereby improving system security. Furthermore, in step S300, the Kubernetes controller is responsible for issuing the npc module's pod and establishing a persistent connection. This allows system administrators to easily control the connection lifecycle, while establishing a persistent connection ensures efficient remote access. Furthermore, using a public IP address to establish the connection means that operators can easily access edge devices from the outside, regardless of geographic location. Finally, the nps server in step S400 ensures the routing and forwarding of SSH requests. This step ensures the smooth transmission of the SSH connection while providing additional control and security for the connection, protecting the privacy and integrity of remote operation and maintenance operations.

[0063] Specifically, in some embodiments of the present invention, when performing the installation and startup of the nps server on the Master node of Kubernetes and ensuring that the nps server is running on the Master node of Kubernetes and listening to a specific port, it also includes: setting the firewall policy to allow public network users to access the IP address and port of the nps server.

[0064] As you can see, by installing and starting the nps server on the Kubernetes Master node, you ensure that the server is protected by Kubernetes' security mechanisms, thereby enhancing system security. Secondly, by setting a firewall policy to allow public users to access the nps server's IP address and port, you can improve system performance because external users can more easily access the server, reducing latency and improving response speed. Finally, this approach provides flexibility, as firewall policies can be adjusted as needed to allow or deny access to specific users.

[0065] Compared with the prior art, the tunnel-based edge device SSH operation and maintenance implementation system of the present application has the following advantages: with the first device acting as the receiving end of the SSH connection request, the second device sends a request to the first device in the edge environment, and then establishes a tunnel connection, thereby realizing a secure SSH connection from the public network or server to the target device. This simplifies the remote maintenance of edge devices and improves system security. Secondly, the third device, as an external device or management device, can easily send an SSH connection request to the second device by connecting to the first device. This provides a convenient remote maintenance method for operation and maintenance personnel without the need to communicate directly with the target device, thereby reducing the complexity and error risk of maintenance. Most importantly, the control device is located on the Master node of the Kubernetes cluster. It has the ability to issue and start and stop tasks to the second device, and can also manage the establishment and destruction of the tunnel connection between the first device and the second device. This makes the entire system dynamic and can flexibly establish and terminate tunnel connections as needed, realizing edge device SSH operation and maintenance anytime and anywhere. This improves the efficiency and convenience of operation and maintenance, helps to quickly respond to problems and maintain the stability of edge devices.

[0066] The above is only an embodiment of the present invention, but it cannot be used to limit the scope of the present invention. Any structural changes made according to the present invention should be deemed to fall within the scope of protection of the present invention and be subject to restrictions as long as they do not lose the essence of the present invention.

[0067] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process and related instructions of the system described above can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0068] It should be noted that the system provided in the above embodiment is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiment can be combined into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the modules or steps and are not to be regarded as improper limitations of the present invention.

[0069] Those skilled in the art should be able to appreciate that, in conjunction with the modules and method steps of each example described in the embodiments disclosed herein, it is possible to implement them with electronic hardware, computer software, or a combination of the two, and the programs corresponding to the software modules and method steps can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. In order to clearly illustrate the interchangeability of electronic hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in electronic hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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 invention.

[0070] The term "comprise" or any other similar term is intended to cover non-exclusive inclusion such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0071] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0072] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A tunnel-based edge device SSH operation and maintenance implementation system, wherein: include: A first device, a second device, a third device and a control device, wherein: The first device is arranged on a public network and / or a server, and is used to accept an SSH connection request sent by the second device; The second device is arranged in an edge environment of the target device, the second device is used to send an SSH connection request to the first device, and the second device is further used to establish a tunnel connection with the first device after the first device accepts the SSH connection request sent by the second device; A third device is arranged in the external device and / or the management device, and when the third device is used to connect to the public network IP and port of the first device, sends an SSH connection request to the second device through the tunnel connection established between the first device and the second device; A control device is arranged on the Master node of the Kubernetes cluster, and is used to issue and start and stop tasks to the second device. The control device is also used to control the establishment and destruction of the tunnel connection established between the first device and the second device.

2. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 1, wherein: The first device is an nps server, which is arranged on a public network and / or a server. The nps server is used to accept and process SSH connection requests from the public network and / or the server.

3. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 2, wherein: The second device comprises: An npc module is provided in the edge environment of the target device, and is used to send an SSH connection request to the nps server; The Sshd module is set on the target device, and is used to receive SSH connection requests from the nps and npc.

4. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 3, wherein: The npc module is also used to establish a tunnel connection with the nps server after the nps server accepts the SSH connection request sent by the npc module.

5. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 4, wherein: The third device is an Ssh-client module, which is arranged in the external device and / or the management device. The Ssh-client module is used to initiate an SSH connection request to the nps server.

6. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 5, wherein: The Ssh-client module is also used to send an SSH connection request to the Sshd module in the target device through the tunnel established between the nps server and the npc module.

7. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 5, wherein: The nps server is also used to send the SSH connection request sent by the Ssh-client module to the Sshd module in the target device through the tunnel established between the nps server and the npc module when receiving the SSH connection request sent by the Ssh-client module.

8. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 7, wherein: The Sshd module is also used to communicate with the Ssh-client module after receiving the SSH connection request sent by the Ssh-client module through the tunnel established between the nps server and the npc module.

9. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 8, wherein: The control device is a k8s controller, which is arranged on the Master node of the Kubernetes cluster, and is used to start and stop the Pod of the npc module.

10. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 9, wherein: The k8s controller is also used to control the establishment or destruction status of the tunnel between the nps server and the npc module according to the Pod of the npc module.

11. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 9, wherein: The Ssh-client module is the SSH connection request initiator of MobaXterm.

12. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 9, wherein: The Ssh-client module is an SSH connection request initiator of MobaXterm, PuTTY or Xshell.

13. The implementation system of SSH operation and maintenance of edge devices based on tunnels as claimed in claim 9, wherein: The Ssh-client module is an SSH connection request initiator composed of at least two of MobaXterm, PuTTY, and Xshell.

14. The method for implementing the tunnel-based edge device SSH operation and maintenance implementation system according to any one of claims 1 to 13, wherein: include: Install and start the nps server on the Master node of Kubernetes, and ensure that the nps server is running on the Master node of Kubernetes and listening to a specific port; Configure port forwarding rules on the nps server, and ensure that the port of the nps server after configuration is port 22; Control the k8s controller to send the Pod of the npc module to the edge environment of the target device, and establish a long connection with the nps server through the public network IP of the Master node of the Kubernetes; Control the nps server to send the SSH connection request to the npc module of the target node through the corresponding long connection, and control the npc module to forward it to the SSH-client module.

15. The implementation method according to claim 14, wherein: When the nps server is installed and started on the master node of the Kubernetes, and it is ensured that the nps server is running on the master node of the Kubernetes and listening to a specific port, the process further includes: Set the firewall policy to allow public network users to access the IP address and port of the nps server.

Images