A tunnel-based edge device ssh operation and maintenance implementation system and method

By deploying tunneling technology and a Kubernetes cluster controller in the edge cloud environment, the difficulties of remote connection for SSH operation and maintenance of edge devices are solved, enabling secure and efficient SSH operation and maintenance, and reducing operation and maintenance costs and complexity.

CN117835453BActive Publication Date: 2026-05-08CHINA TELECOM CLOUD TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
CHINA TELECOM CLOUD TECH CO LTD
Filing Date
2023-12-14
Publication Date
2026-05-08

AI Technical Summary

Technical Problem

In the maintenance of edge cloud devices, remote SSH connections are difficult, and the scarcity of public IP resources leads to high maintenance costs and low efficiency. Existing methods such as command forwarding and binding to public IPs have limitations and cost issues.

Method used

By deploying an nps server on the public network and the server side, and deploying an npc module and an SSHd module on edge devices, SSH connections are achieved using tunneling technology. Combined with the Master node controller of the Kubernetes cluster to manage tunnel connections, cross-network SSH operation and maintenance can be realized.

Benefits of technology

It enables secure and convenient remote SSH connections, reduces operational complexity and costs, improves the management efficiency of edge devices and the controllability of the system, and supports flexible tunnel connection management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117835453B_ABST
    Figure CN117835453B_ABST
Patent Text Reader

Abstract

The present application relates to the technical field of IT and software development, in particular to a tunnel-based edge device SSH operation and maintenance implementation system and method, the system comprising: a first device for receiving an SSH connection request sent by a second device; the second device is configured to send an SSH connection request to the first device, and further configured 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 configured to send an SSH connection request to the second device through the tunnel connection established by the first device when connecting the public IP and port of the first device; and a control device is configured to issue start and stop tasks to the second device, and further configured to control the establishment and destruction of the tunnel connection established by the first device and the second device. Through the cooperative operation of the devices, SSH login is realized in the scenario where the cloud and the edge are located in different network planes and have no Internet port, thereby solving the problem of uncontrollable cost.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the fields of IT and software development technology, and in particular to a system and method for implementing SSH operation and maintenance of edge devices based on tunnels. Background Technology

[0002] In recent years, with the rapid development of edge computing and the Internet of Things (IoT), scenarios using edge embedded boxes as computing nodes have become increasingly diverse, and extending cloud-native capabilities to the edge has become a trend. Cloud-native edge architectures such as KubeEdge, with their comprehensive "cloud, edge, and device integration" capabilities, have been widely applied in typical edge computing scenarios such as IoT, edge cloud, and distributed cloud, covering many industries including logistics, energy, transportation, manufacturing, retail, healthcare, and CDN.

[0003] Currently, conventional Kubernetes deployments typically take place within a local area network (LAN) server cluster, allowing for easy SSH login to any server for maintenance. However, in edge cloud device maintenance, there's also a need to remotely SSH into edge devices for troubleshooting. Due to the scarcity of public IP addresses, edge devices are usually located within a LAN subnet, preventing the server from initiating communication requests. Maintenance in such scenarios typically involves dispatching personnel to the site or sending remote commands to retrieve logs, but these methods are often unsatisfactory. Either the maintenance manpower costs are high, or the log information is insufficient for troubleshooting, leading to a poor user experience due to delayed responses.

[0004] To address this pain point, the main methods currently used are command forwarding and binding to a public IP address. Command forwarding uses a client / server mechanism, sending the command to be executed from the network to the client, which then executes it and returns the result to the server. However, this method typically cannot handle interactive commands like `top` and `vi`, resulting in significant limitations. While binding to a public IP address fully implements SSH, public IP addresses are scarce and expensive, hindering cost control. Summary of the Invention

[0005] The purpose of this invention is to provide a system and method for implementing SSH operation and maintenance of edge devices based on tunnels. By deploying NPCs as pod containers and embedding them into the cloud-native system, SSH and cloud-native technologies are integrated. This enables SSH login in scenarios where the cloud and edge are located on different network planes and have no internet ports, thereby solving the problem of uncontrollable costs in the aforementioned background technologies.

[0006] On one hand, embodiments of the present invention provide an implementation system for SSH operation and maintenance of edge devices based on tunnels, comprising: a first device, a second device, a third device, and a control device, wherein,

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

[0008] The second device is set in the edge environment of the target device. The second device is used to send an SSH connection request to the first device. 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.

[0009] A third device is installed in an external device and / or a management device. When the third device is used to connect to the public IP address and port of the first device, it sends an SSH connection request to the second device through the tunnel connection established between the first device and the second device.

[0010] A control device is installed on the Master node of the Kubernetes cluster. The control device is used to issue and start / 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.

[0011] Furthermore, the first device is an NPS server, set up on the public network and / or on the server side, and the NPS server is used to accept and process SSH connection requests from the public network and / or the server side.

[0012] Furthermore, the second device includes:

[0013] An NPC module is set up in the edge environment of the target device. The NPC module is used to send SSH connection requests to the NPS server. 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.

[0014] The Sshd module, installed on the target device, is used to receive SSH connection requests from nps and npc.

[0015] Furthermore, the third device is an SSH-client module, which is installed in the external device and / or 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.

[0016] Furthermore, the nps server is also used to send an 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 it receives the SSH connection request.

[0017] Furthermore, the Sshd module is also used to receive an SSH connection request sent by the Ssh-client module through the tunnel established between the nps server and the npc module, and then establish a communication connection with the Ssh-client module.

[0018] 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 manage the start and stop of the Pods of the NPC module. 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 Pods of the NPC module.

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

[0020] On the other hand, embodiments of the present invention also provide a method for implementing a tunnel-based SSH operation and maintenance system for edge devices based on the above embodiments, comprising:

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

[0022] Configure port forwarding rules on the NPS server and ensure that the port of the configured NPS server is port 22;

[0023] The Kubernetes controller is controlled to send the Pod of the NPC module to the edge environment of the target device, and a long connection is established with the nps server through the public IP of the Kubernetes Master node;

[0024] The nps server is controlled to send SSH connection requests to the npc module of the target node through the corresponding long connection, and the npc module is controlled to forward them to the SSH-client module.

[0025] Furthermore, when installing and starting the nps server on the Kubernetes Master node, and ensuring that the nps server is running on the Kubernetes Master node and listening on a specific port, the process also includes:

[0026] Configure the firewall policy to allow public network users to access the IP address and port of the NPS server.

[0027] Compared with existing technologies, the SSH operation and maintenance system for edge devices based on tunneling, as described in this embodiment of the invention, offers the following advantages: Firstly, a first device acts 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, thus achieving 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. Secondly, a third device, acting as an external or management device, can easily send SSH connection requests to the second device by connecting to the first device. This provides maintenance personnel with a convenient remote maintenance method, eliminating the need for direct communication with the target device, thereby reducing maintenance complexity and error risks. Most importantly, the control device resides on the Master node of the Kubernetes cluster. It has the ability to issue and start / stop tasks for the second device and manage the establishment and destruction 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 SSH operation and maintenance of edge devices anytime, anywhere. This improves the efficiency and convenience of operation and maintenance, facilitating rapid problem response and maintaining the stability of edge devices. Attached Figure Description

[0028] Figure 1 This is a structural block diagram of an implementation system for SSH operation and maintenance of edge devices based on tunnels, according to an embodiment of the present invention.

[0029] Figure 2 This is a schematic diagram of the framework of an implementation system for SSH operation and maintenance of edge devices based on tunnels, according to an embodiment of the present invention.

[0030] Figure 3 This is a flowchart of an implementation method for an edge device SSH operation and maintenance system based on tunneling, according to an embodiment of the present invention. Detailed Implementation

[0031] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0032] like Figure 1 and Figure 2 As shown in the figure, an implementation system for SSH operation and maintenance of edge devices based on tunneling according to an embodiment of the present invention includes: a first device, a second device, a third device, and a control device. The first device is located on a public network and / or a server, and is used to accept SSH connection requests sent by the second device. The second device is located in the edge environment of the target device, and is used to send SSH connection requests to the first device. 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 located in an external device and / or a management device. When the third device connects to the public IP address and port of the first device, it sends SSH connection requests to the second device through the tunnel connection established between the first device and the second device. The control device is located on the Master node of the Kubernetes cluster, and is used to issue and start / 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.

[0033] As can be seen, the system operates by having the first device, located on the public network or a server, act as the receiver of SSH connection requests, accepting requests from the second device. The second device, situated in the edge environment of the target device, is responsible for sending SSH connection requests to the first device and establishing a tunnel connection for secure communication. The third device, located in an external or management device, connects to the public IP address and port of the first device and can send SSH connection requests to the second device through the established tunnel connection. The control device, located on the Master node of the Kubernetes cluster, is responsible for issuing and starting / stopping tasks to the second device, and managing the establishment and destruction of the tunnel connection between the first and second devices. This system provides a secure and efficient solution for SSH operation and maintenance of edge devices, allowing remote management and maintenance of the target device without direct access, increasing convenience and system controllability.

[0034] Understandably, the first device acts as the receiving end of the SSH connection, accepting connection requests from the second device, thus enabling remote SSH connections. The second device, located in the edge environment of the target device, can establish a tunnel connection with the first device, ensuring the secure transmission of SSH requests. The third device can connect to the first device from external or management devices, sending SSH requests to the second device through the established tunnel connection, enabling remote operation and maintenance. The control device resides on the Master node of the Kubernetes cluster, controlling the task assignment and startup / shutdown of the second device, while simultaneously managing the tunnel connection between the first and second devices, achieving centralized control of the entire system. This system improves the efficiency of remote management of edge devices, strengthens the monitoring and management of tunnel connections, and makes SSH operation and maintenance more convenient and controllable.

[0035] Specifically, in some embodiments of the present invention, the first device is an NPS server, which is set up 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.

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

[0037] Understandably, the first device, acting as an NPS server located on the public network and / or a server, serves as a relay station for receiving and processing SSH connection requests. This allows users or servers to securely establish SSH connections with the target device over the public network, thereby enabling remote operation and management. This provides a convenient remote access method, enhances system reachability, and also increases system security and management efficiency.

[0038] Specifically, in some embodiments of the present invention, the second device includes an npc module and an SSHd module. The npc module is installed in the edge environment of the target device and is used to send SSH connection requests to the nps server. 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. The SSHd module is installed on the target device and is used to receive SSH connection requests from both the nps and npc.

[0039] As can be seen, the second device consists of an npc module and an SSHd module. The npc module is located in the edge environment of the target device and is responsible for establishing a tunnel connection with the nps server and sending SSH connection requests to the nps server. The SSHd module is set up on the target device and is specifically used to receive SSH connection requests from the nps server and the npc module, acting as the SSH server of the target device. This technical solution realizes the proxying and tunneling of SSH connections, providing a convenient way for remote operation and maintenance, while also effectively managing the processing of SSH connection requests.

[0040] Understandably, the SSH tunneling proxy function for edge device maintenance is achieved through the collaborative work of the npc and SSHd modules in the second device. The npc module, located in the edge environment, is responsible for establishing a tunnel connection with the nps server, forwarding SSH connection requests from the target device to the nps server, thus allowing remote access to the target device. Simultaneously, the SSHd module, located on the target device, receives SSH connection requests from both the nps server and the npc module, providing a flexible and secure remote maintenance method for the target device.

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

[0042] As can be seen, the SSH-client module in the third device acts as an SSH client, located in the external or management device, and is used to establish SSH connection requests with the nps server. It seamlessly transmits the SSH connection request to the SSHd module in the target device through a tunnel connection established between the nps server and the npc module. This technical solution enables SSH connection transmission in different network environments, providing greater flexibility and accessibility for SSH operation and maintenance of edge devices, allowing administrators to easily manage and maintain the target devices.

[0043] Understandably, the SSH client module in the third-party device plays a crucial role, enabling external and management devices to easily communicate with edge devices via SSH. By establishing an SSH connection with the nps server, it transmits SSH connection requests to the target device's SSHd module through the established tunnel, thus achieving seamless remote operation and maintenance. Furthermore, it provides a more flexible and efficient way for administrators to easily manage remote devices, reducing the complexity and cost of operation and maintenance.

[0044] Specifically, in some embodiments of the present invention, the nps server is also used to send an 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 it receives the SSH connection request sent by the SSH client module.

[0045] Specifically, in some embodiments of the present invention, the Sshd module is also used to receive an SSH connection request sent by the Ssh-client module through the tunnel established between the nps server and the npc module, and then establish a communication connection with the Ssh-client module.

[0046] As can be seen, the nps server acts as a relay station, assisting in forwarding SSH connection requests from the SSH-client module to the SSHd module on the target device through a tunnel. Simultaneously, the SSHd module on the target device receives and processes SSH connection requests, thus effectively ensuring the communication connection between the SSH-client module and the target device.

[0047] Understandably, the nps server, acting as a core relay station, plays a crucial role as a connection hub. By receiving SSH connection requests from the SSH client module and forwarding them to the SSHd module on the target device through a tunnel established with the npc module, it enables remote operation via SSH. This distributed architecture facilitates the transfer of remote maintenance operations from external devices to the target device, improving network security and ease of operation. Simultaneously, the SSHd module on the target device ensures the reception and processing of SSH connection requests, enabling efficient communication, providing users with a better user experience, and reducing the complexity of maintenance.

[0048] 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 manage the start and stop of the Pods of the NPC module. 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 Pods of the NPC module.

[0049] As can be seen, by setting the Kubernetes controller on the Master node of the Kubernetes cluster, it is responsible for managing the Pods of the NPC module, including starting and stopping tasks. This means that it can dynamically manage containerized applications related to the NPC module, ensuring the normal operation of the NPC module. In addition, the Kubernetes controller also plays a role in controlling the establishment and destruction status of the tunnel between the NPS server and the NPC module. By determining whether to establish or terminate the tunnel based on the Pod status of the NPC module, it achieves flexible control and effective resource management of the entire system connection.

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

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

[0052] Understandably, the SSH-client module encompasses various SSH connection request initiators, such as MobaXterm, PuTTY, and Xshell. This means the SSH-client module has broad compatibility, meeting the needs of diverse end-users. Regardless of the SSH client used, users can easily connect to the target device, thereby improving system flexibility and user-friendliness. This diversity helps cover a wider user base, making the system more universally applicable while reducing user training and adaptation costs.

[0053] In summary, this invention provides a tunnel-based SSH operation and maintenance system for edge devices. A first device acts as the receiver of SSH connection requests, while a second device in the edge environment sends a request to the first device, subsequently establishing a tunnel connection. This achieves 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. Secondly, a third device, acting as an external or management device, can easily send SSH connection requests to the second device by connecting to the first device. This provides maintenance personnel with a convenient remote maintenance method, eliminating the need for direct communication with the target device and reducing maintenance complexity and error risks. Most importantly, the control device resides on the Master node of the Kubernetes cluster. It has the ability to issue and start / stop tasks for the second device and manage the establishment and destruction 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 SSH operation and maintenance of edge devices anytime, anywhere. This improves the efficiency and convenience of operation and maintenance, facilitating rapid problem response and maintaining the stability of edge devices.

[0054] like Figure 3 As shown, some embodiments of the present invention also provide a method for implementing a tunnel-based SSH edge device operation and maintenance system based on the above embodiments, including:

[0055] Step S100: 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.

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

[0057] Step S300: Control the Kubernetes controller to send Pods of the NPC module to the edge environment of the target device, and establish a long connection with the NPC server through the public IP of the Kubernetes Master node.

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

[0059] As can be seen, firstly, in step S100, the nps server is installed and started on the Kubernetes Master node to ensure its normal operation and listening on a specific port, thus providing an entry point for SSH connections. Then, in step S200, port forwarding rules are configured to redirect SSH connection requests to port 22 of the target device, ensuring SSH communication with the target device. In step S300, the Kubernetes controller sends the pod of the npc module to the edge environment of the target device and establishes a long-lived connection through the public IP address of the Kubernetes Master node, ensuring the availability of remote access. Finally, in step S400, the nps server routes the SSH connection request through the established long-lived connection to the npc module of the target node, which then forwards it to the SSH-client module, thus realizing the forwarding of SSH connection requests and the establishment of the actual SSH session. This technical solution enables remote SSH operation and maintenance while ensuring connection security and availability.

[0060] Understandably, step S100 ensures that the nps server runs on the Kubernetes Master node, providing a central entry point for external SSH connections by listening on a specific port. 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 can be smoothly directed to the target device's SSH port, enabling remote access. Control device SSH client modules, such as MobaXterm, PuTTY, and Xshell, initiate SSH connection requests and establish secure communication with the nps server, enabling external devices to access edge devices without opening additional ports on the firewall, thus improving system security. Furthermore, in step S300, the Kubernetes controller is responsible for distributing Pods to the npc module and establishing persistent connections. This allows system administrators to easily control the connection lifecycle, while the establishment of persistent connections ensures efficient remote access. Additionally, using public IP addresses to establish connections means that operators can easily access edge devices from the outside, without geographical limitations. Finally, the nps server in step S400 ensures the routing and forwarding of SSH requests. This step ensures the smooth transmission of SSH connections while providing additional control and security for the connection, protecting the privacy and integrity of remote operations.

[0061] Specifically, in some embodiments of the present invention, when installing and starting the nps server on the Kubernetes Master node and ensuring that the nps server is running on the Kubernetes Master node and listening on a specific port, the method further includes: setting the firewall policy to allow public network users to access the IP address and port of the nps server.

[0062] Understandably, installing and starting the nps server on the Kubernetes Master node ensures that the server is protected by Kubernetes' security mechanisms, thereby enhancing system security. Secondly, configuring firewall policies to allow public network users to access the nps server's IP address and port improves system performance, as external users can more easily access the server, reducing latency and increasing response speed. Finally, this approach offers flexibility, as firewall policies can be adjusted as needed to allow or deny access to specific users.

[0063] The above is only one embodiment of the present invention, but it cannot be used to limit the scope of the present invention. Any structural changes made based on the present invention, as long as they do not lose the essence of the present invention, should be considered to fall within the protection scope of the present invention and be subject to its restrictions.

[0064] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the system described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0065] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical 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 embodiments can be merged 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 various modules or steps and are not considered as an improper limitation of the present invention.

[0066] Those skilled in the art will recognize that the modules and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. The programs corresponding to the software modules and method steps can be placed in random access memory (RAM), main 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. To clearly illustrate the interchangeability of electronic hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented 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 beyond the scope of the invention.

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

[0068] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will all fall within the scope of protection of the present invention.

[0069] The above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention.

Claims

1. A system for the operation and maintenance of edge devices via SSH based on tunnels, characterized in that, include: The equipment includes a first device, a second device, a third device, and a control device, wherein... The first device is set up on the public network and / or on the server side, and the first device is used to accept SSH (Secure Shell) connection requests sent by the second device; The second device is set in the edge environment of the target device. The second device is used to send an SSH connection request to the first device. 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. A third device is installed in an external device and / or a management device. When the third device is used to connect to the public IP (Internet Protocol) and port of the first device, it 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 set on the Master node of the Kubernetes cluster. The control device is used to issue and start / 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. The first device is an NPS (Network Penetration Proxy Server) server, which is set up on the public network and / or the server. The NPS server is used to accept and process SSH connection requests from the public network and / or the server. The second device includes: An NPC (internal network penetration proxy client) module is set up in the edge environment of the target device. The NPC module is used to send SSH connection requests to the NPS server. 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. The Sshd (SSH service daemon) module is installed on the target device. The Sshd module is used to receive SSH connection requests from nps and npc. The control device is a k8s (short for Kubernetes, a container orchestration system) controller. The k8s controller is set on the Master node of the Kubernetes cluster. The k8s controller is used to manage the start and stop of the Pods (container groups) of the NPC module. 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 Pods of the NPC module.

2. The implementation system for SSH operation and maintenance of edge devices based on tunnels as described in claim 1, characterized in that, The third device is an SSH-client (Secure Shell Protocol Client) module, which is installed in an external device and / or 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.

3. The system for SSH operation and maintenance of edge devices based on tunnels as described in claim 2, characterized in that, The nps server 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 when it receives the SSH connection request sent by the SSH-client module.

4. The implementation system for SSH operation and maintenance of edge devices based on tunnels as described in claim 3, characterized in that, The SSHd module is also used to accept SSH connection requests sent by the SSH-client module through the tunnel established between the nps server and the npc module, and then establish a communication connection with the SSH-client module.

5. The implementation system for SSH operation and maintenance of edge devices based on tunnels as described in claim 4, characterized in that, The SSH-client module is an SSH connection request initiator composed of one or more of the following: MobaXterm, PuTTY, Xshel, etc.

6. The implementation method of the tunnel-based edge device SSH operation and maintenance system as described in any one of claims 1-5, characterized in that, include: 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; Configure port forwarding rules on the NPS server and ensure that the port of the configured NPS server is port 22; The Kubernetes controller is controlled to send the Pod of the NPC module to the edge environment of the target device, and a long connection is established with the nps server through the public IP of the Kubernetes Master node; The nps server is controlled to send SSH connection requests to the npc module of the target node through the corresponding long connection, and the npc module is controlled to forward them to the SSH-client module.

7. The implementation method as described in claim 6, characterized in that, When installing and starting the nps server on the Kubernetes Master node, and ensuring that the nps server is running on the Kubernetes Master node and listening on a specific port, the process also includes: Configure the firewall policy to allow public network users to access the IP address and port of the NPS server.

Citation Information

Patent Citations

  • Remote access method and device, electronic equipment and storage medium

    CN113259344A

  • Software deployment method and device based on Kubernetes platform

    CN114138754A