A service-oriented robot remote operation method and system, and a storage medium

Abstract

This invention discloses a remote operation and maintenance method, system, and storage medium for service robots. The invention adopts a dual-end architecture of "gateway server-agent program." The gateway server is deployed in a network environment with public network access capabilities, providing two logical port services: a TLS-PSK listening port and a standard SSH listening port. The agent program is deployed as a lightweight background process on the embedded computing unit of each service robot. Compared with existing technologies, this invention completely solves the NAT / firewall penetration problem, possesses a multi-layered, defense-in-depth security authentication system, and offers extreme ease of use with zero client modification for operation and maintenance personnel. Furthermore, this invention features efficient single-connection multi-session multiplexing capabilities, refined session-level isolation and auditing support, adaptive high-availability connection maintenance, and a lightweight design adapted to embedded environments.

Description

Technical Field

[0001] This invention relates to service robot operation and maintenance technology, and more particularly to a remote operation and maintenance method, system and storage medium for service robots. Background Technology

[0002] With the rapid development of artificial intelligence and robotics, service robots are widely used in scenarios such as food delivery, hotel reception, medical assistance, warehousing and logistics, commercial cleaning, and security patrol. Typical deployment environments for these service robots include restaurants, hotel lobbies, hospital wards, shopping malls, and logistics warehouses. From a network environment perspective, the deployment of service robots exhibits the following significant characteristics:

[0003] (1) Complexity of the network environment: Service robots are mostly deployed in the customer's internal LAN, behind NAT devices or firewalls. Many deployment scenarios use consumer-grade broadband (no fixed public IP address, carrier-grade NAT), 4G / 5G cellular networks (dynamic IP address, no inbound connection capability) or WiFi networks. Traditional remote direct access solutions based on public IP addresses are basically not feasible in the above scenarios.

[0004] (2) Accessibility of the physical environment: Unlike data center servers, service robots are deployed in physically accessible public and semi-public places. Malicious individuals may attempt to extract the robot's storage media, network credentials, or configuration files through physical contact, posing a risk of credential leakage and unauthorized access.

[0005] (3) Multi-party operation and maintenance: A single service robot deployment project usually involves multiple operation and maintenance entities: robot manufacturers (for firmware upgrades and system updates), system integrators (for function configuration and parameter tuning), IT operation and maintenance personnel of end customers (for daily monitoring and status checks), and third-party maintenance contractors (for troubleshooting and emergency repairs). Each party needs to access different robots, has different operating permissions, and requires independent audit trails.

[0006] (4) Limited embedded computing resources: Service robots typically run on embedded Linux systems based on ARM or RISC-V architectures, which have limited CPU computing power, memory capacity, and network bandwidth. The encryption computing overhead and memory usage of traditional VPN clients (such as IPSec and OpenVPN) are a heavy burden for such embedded computing platforms.

[0007] (5) Scale of clustered deployment: Medium and large service robot deployment projects usually involve the cluster management of dozens or even hundreds of robots, which need to support session isolation and access control when multiple users access different robots concurrently.

[0008] Currently, the main technical solutions for remote operation and maintenance of service robots include the following categories, but each has obvious technical shortcomings:

[0009] Option 1: VPN-based remote access solution. This solution deploys a VPN gateway (such as IPSec VPN, OpenVPN, or WireGuard) on the network where the service robot is located. After the maintenance personnel dial in through the VPN client, they can obtain network layer access permissions to the intranet where the robot is located. The main shortcomings of this solution are: (1) It requires the robot-side network to have a public IP address or to configure complex NAT traversal rules, which is not feasible in many actual deployment scenarios; (2) The VPN grants network layer access permissions, which is too broad. Once the maintenance personnel access the VPN, they can access all devices in the entire intranet, lacking fine-grained access control for individual robots; (3) The VPN client has a large resource overhead on the embedded platform, which affects the normal operation of the robot's core business; (4) In multi-party maintenance scenarios, different VPN accounts and permission policies need to be configured for different entities, which is complex to manage.

[0010] Option 2: Remote access solution based on SSH reverse tunnel (SSH-R). This solution involves the service robot actively initiating an SSH connection and establishing a reverse tunnel (SSH-R). The operations and maintenance personnel can indirectly access the robot through the relay server where the tunnel is located. The main shortcomings of this solution are: (1) The SSH reverse tunnel is manually established and not persistent. It needs to be manually re-established after machine restart or network switch; (2) It lacks a centralized connection management and monitoring mechanism, which cannot meet the management needs of robot clusters; (3) Each reverse tunnel uses an independent SSH connection and TCP port, which does not support multi-session reuse on a single connection. The number of connections increases linearly with the number of robots; (4) The tunnel itself only has single-layer SSH authentication and lacks an application-layer independent authentication mechanism; (5) It does not support automatic routing based on username - the operations and maintenance personnel need to remember the different relay port numbers corresponding to different robots.

[0011] Option 3: Remote access solution based on jump server / bastion host. This solution deploys a jump server (Jump Server / Bastion Host) at the network boundary. The operation and maintenance personnel first log in to the jump server and then connect to the target robot from the jump server. The main shortcomings of this solution are: (1) It still requires direct network layer reachability (IP reachability) from the jump server to the target robot, which cannot solve the problem of the robot being behind NAT and having no public IP address; (2) Credentials are accumulated on the jump server. Once the jump server is breached, the entire robot cluster faces security threats; (3) It lacks a protocol-level session isolation mechanism, making concurrent access auditing difficult.

[0012] Option 4: Remote access solution based on WebRTC / P2P traversal. This solution utilizes P2P technologies such as WebRTC combined with STUN / TURN servers to achieve NAT traversal and end-to-end communication (such as the technical solution disclosed in Chinese Patent CN115022656A). The main shortcomings of this solution are: (1) It requires the deployment and maintenance of additional STUN / TURN relay infrastructure; (2) It usually requires customized client software or browser plugins, which are incompatible with standard SSH clients (such as OpenSSH, PuTTY, Xshell, etc.) used daily by maintenance personnel; (3) The protocol design is mainly geared towards audio and video streaming media transmission scenarios, and there is insufficient optimization for interactive shell operations and SFTP file transfer.

[0013] Option 5: Remote Access Solution Based on Application Layer Proxy. Some existing patents disclose remote access solutions for industrial robots or IoT devices. For example, Chinese patent CN115499328B discloses a method for hierarchical access permissions based on HTTP request header analysis, but its core mechanism relies on HTTP protocol layer analysis and does not solve the NAT traversal problem; Chinese patent CN113119124B discloses a deep packet inspection firewall deployed on the robot side, but its function focuses on traffic filtering on the robot side and does not solve the problem of initiating remote access; Chinese patent CN110893616B discloses a unified port remote control method, but it adopts a general command forwarding mode and is not a transparent proxy solution specifically designed for the SSH protocol, lacking session-level multiplexing and isolation capabilities.

[0014] In summary, existing technical solutions cannot simultaneously meet the following key technical requirements in remote operation and maintenance scenarios for service robots:

[0015] (1) NAT / firewall penetration enables secure remote access from the external network to the robot's operating system, provided that the service robot has no public IP address and no inbound port needs to be open.

[0016] (2) Each robot is independently authenticated, providing each robot in the cluster with independent security credentials and authentication mechanisms. The leakage of credentials of a single robot will not affect the entire cluster.

[0017] (3) Standard client compatibility: maintenance personnel do not need to install proprietary software or perform special configurations. They can access the specified robot using a standard SSH client.

[0018] (4) High-efficiency reuse of multiple sessions: It supports the reuse of multiple concurrent SSH sessions on a single persistent connection, reducing network overhead and the number of connections, and adapting to robot embedded platforms and cellular network scenarios.

[0019] (5) Multi-user session isolation, supporting multiple operation and maintenance personnel to access different robots through the same gateway server at the same time, and their sessions are completely isolated and do not interfere with each other;

[0020] (6) To prevent resource occupation attacks, a forced timeout disconnection mechanism is implemented for connections that have not completed authentication to prevent malicious connections from occupying server network resources for a long time. Summary of the Invention

[0021] To overcome the shortcomings of existing technologies, this invention proposes a remote operation and maintenance method, system, and storage medium for service robots. The technical solution of this invention is implemented as follows:

[0022] This invention proposes a remote operation and maintenance method for service robots, comprising the following steps:

[0023] S1: Deploy an agent program on the service robot. The agent program actively initiates an encrypted connection request to the gateway server deployed in a publicly accessible environment via the TLS-PSK protocol, and uses the hostname of the service robot as the PSK identity identifier.

[0024] S2: During the TLS handshake phase, the gateway server searches for the corresponding pre-shared key from the pre-configured client whitelist based on the identity identifier to complete the establishment of the transport layer encrypted channel;

[0025] S3: After the encrypted channel is established, the agent program sends a registration frame to the gateway server within a preset registration timeout period. The registration frame contains the hostname and a first verification hash value, which is obtained by performing a hash operation on the combination of the hostname and the pre-shared key.

[0026] S4: The gateway server receives the registration frame, extracts the hostname, retrieves the pre-shared key corresponding to the hostname in the local whitelist configuration based on the hostname, calculates a second verification hash value for the combination of the hostname and the local pre-shared key using the same hash operation, and compares the second verification hash value with the first verification hash value; if they match, the hostname is bound to the encrypted connection, the registration of the proxy program is completed, and a registration success response is returned to the proxy program; if they do not match or no valid registration frame is received within the preset registration timeout period, the encrypted connection is disconnected.

[0027] S5: The gateway server listens for connection requests from maintenance personnel on the standard SSH port and receives SSH connections initiated by maintenance personnel through a standard SSH client in the format of "username@robot hostname";

[0028] S6: The gateway server parses the target robot hostname from the username field of the SSH connection, searches for the corresponding encrypted connection of the agent program in the registered agent program connection table, sends a session channel establishment request to the agent program through the encrypted connection, and assigns a unique session stream identifier to this session;

[0029] S7: After receiving the session channel establishment request, the agent program establishes a TCP connection with the local SSH service process of the service robot according to the address information specified in the request, binds the TCP connection with the session flow identifier, and returns a successful channel establishment response to the gateway server.

[0030] S8: The gateway server transparently forwards the authentication information of the SSH client of the operation and maintenance personnel to the SSH service process on the local side of the service robot for authentication through the encrypted connection, using the session flow identifier as the identifier, and returns the authentication result to the operation and maintenance personnel;

[0031] S9: After authentication, the gateway server will forward the session channel data of the SSH client of the operation and maintenance personnel and the TCP connection data of the agent program in a two-way transparent manner through the encrypted connection. All data frames belonging to the same session carry the session stream identifier, so as to realize the remote and secure operation and maintenance of the service robot by the operation and maintenance personnel.

[0032] Furthermore, the hash operation described in steps S3 and S4 is the SHA256 hash algorithm, and the first verification hash value is calculated as SHA256(hostname || PSK), where hostname is the hostname string of the service robot, PSK is the byte sequence of the pre-shared key, and || represents a string concatenation operation.

[0033] Furthermore, the local whitelist configuration of the gateway server allocates different pre-shared keys independently to each service robot, so that the leakage of the pre-shared key of any one service robot will not affect the communication security of other service robots.

[0034] Further, in step S1, during the handshake process of the TLS-PSK protocol, the proxy program sends the hostname as the value of the PSK identity field to the gateway server; the gateway server uses the PSK identity callback function to search for the corresponding pre-shared key byte sequence from the pre-configured client whitelist using the hostname as the index, and completes the negotiation of the pre-shared key and the establishment of the encrypted channel; the pre-shared key itself is not transmitted in the network.

[0035] Furthermore, the connection lifecycle between the proxy program and the gateway server includes three stages: the unregistered stage, which is the state where the TLS encrypted channel has been established but a valid registration frame has not yet been received, and the gateway server starts a registration timeout timer; if registration is not completed within the timeout period, the connection is actively disconnected; the registered stage, which is the state where the proxy program has completed application layer identity registration and maintains connection activity through a heartbeat mechanism; and the invalidation stage, which is the state where the heartbeat timeout occurs or the connection is abnormally disconnected, and the gateway server automatically cleans up the registration information and related session resources of the proxy program.

[0036] Furthermore, during the registration phase, the agent periodically sends heartbeat frames to the gateway server, and the gateway server returns a heartbeat response frame upon receiving the heartbeat frame. If the gateway server does not receive any frame from the registered agent within the preset heartbeat timeout period, it determines that the agent connection is invalid, removes it from the registered agent connection table, and cleans up all session resources associated with the agent.

[0037] Furthermore, after detecting that the encrypted connection with the gateway server has been broken, the proxy program automatically performs a reconnection operation. The reconnection operation adopts an exponential backoff algorithm: the waiting time for the nth reconnection attempt is T(n) = min(T_initial×k^(n-1), T_max), where T_initial is the initial waiting time, k is the backoff multiplier, and T_max is the maximum waiting time limit; and random jitter is added to the waiting time calculated each time to avoid congestion caused by multiple proxy programs reconnecting at the same time.

[0038] Furthermore, after a successful reconnection, the proxy program re-executes the complete registration process of steps S1 to S4 to re-establish the encrypted connection and application layer identity binding with the gateway server.

[0039] Further, in steps S6 to S9, the allocation and usage mechanism of the session flow identifier is as follows: When the gateway server needs to establish a channel for a new SSH session, it allocates a unique identifier that is not currently in use from the session flow identifier space; the identifier is carried in the session establishment frame sent to the agent program; after the agent program establishes a TCP connection to the local SSH service, it binds the TCP connection to the identifier; thereafter, all uplink and downlink data of the SSH session are transmitted through session data frames carrying the same session flow identifier; when the session ends, the peer is notified to release the identifier and the corresponding TCP connection resources through a session close frame.

[0040] Furthermore, in step S8, the gateway server transparently forwards the authentication information of the maintenance personnel to the local SSH service process of the service robot for authentication, specifically supporting both password authentication and public key authentication. For password authentication, the gateway server forwards the username and password provided by the maintenance personnel's SSH client to the local SSH service process of the service robot for verification. For public key authentication, the gateway server transparently forwards the maintenance personnel's public key and signature data to the local SSH service process of the service robot for verification.

[0041] Furthermore, the session channel data mentioned in step S9 includes the following SSH channel types: shell session channel, used to provide an interactive command-line operation interface; exec execution channel, used to execute a single remote command; SFTP subsystem channel, used to perform secure file transfer operations; and TCP port forwarding channel, used to map the internal TCP service of the service robot's network to the local machine of the operations and maintenance personnel.

[0042] Furthermore, the configuration of the agent program is managed through a YAML-formatted configuration file, which includes at least the following configuration items: gateway server address and port, service robot hostname, pre-shared key, local SSH service address and port, minimum TLS version requirement, initial reconnection wait time, maximum wait time and backoff multiplier, heartbeat sending interval and heartbeat response timeout, and log level.

[0043] This invention also proposes a remote operation and maintenance system for service robots, comprising:

[0044] A gateway server, deployed in a publicly accessible network environment, includes:

[0045] The TLS-PSK listening module is used to receive encrypted connection requests initiated by the agent programs deployed on each service robot. During the TLS handshake phase, it searches for the corresponding pre-shared key based on the PSK identity provided by the agent program to establish a transport layer encrypted channel.

[0046] The agent management module is used to manage the connection status of registered agent programs, maintain a mapping table of hostnames to encrypted connections, and perform registration verification, heartbeat detection, and connection lifecycle management.

[0047] The SSH proxy module is used to listen for standard SSH connection requests from operations and maintenance personnel, parse the target robot hostname from the username field, and bridge the SSH authentication and session channel data to the corresponding proxy program for encrypted connection.

[0048] The frame protocol encoding / decoding module is used to encode and decode the communication data between the gateway server and the agent program according to a preset binary frame protocol.

[0049] At least one agent program is deployed on the embedded computing unit of each service robot, said agent program comprising:

[0050] The TLS-PSK connection module is used to proactively initiate an encrypted connection to the gateway server using the hostname of the service robot as the PSK identity identifier.

[0051] The registration module is used to send a registration request frame containing the hostname and verification hash value to the gateway server after the encrypted channel is established, so as to complete the application layer identity registration.

[0052] The SSH bridging module is used to receive a session channel establishment request from the gateway server, establish a TCP connection with the SSH service process on the local side of the service robot, and forward session data bidirectionally between the encrypted connection and the local TCP connection.

[0053] The heartbeat maintenance module is used to periodically send heartbeat frames to the gateway server to maintain connection activity and automatically reconnect when the connection is lost.

[0054] The gateway server and the agent program communicate via a custom binary frame protocol. The frame structure of the binary frame protocol includes a fixed header and a variable-length payload. The fixed header includes at least: a magic number field, a protocol version field, a frame type field, a session stream identifier field, and a payload length field. The session stream identifier field is used to uniquely identify and distinguish multiple concurrent independent SSH sessions on the same TLS-PSK encrypted connection.

[0055] Furthermore, the frame types of the binary frame protocol include at least the following: a registration frame (REGISTER), used by the agent to send a registration request to the gateway server; a registration response frame (REGISTER_ACK), used by the gateway server to return the registration result; a heartbeat frame (HEARTBEAT), used by the agent to maintain connection activity; a heartbeat response frame (HEARTBEAT_ACK), used by the gateway server to acknowledge the heartbeat; a session establishment frame (SSH_OPEN), used by the gateway server to request the agent to establish a connection to the local SSH service; a session establishment response frame (SSH_OPEN_ACK), used by the agent to acknowledge successful session channel establishment; a session data frame (SSH_DATA), used for bidirectional transmission of SSH session channel data; a session close frame (SSH_CLOSE), used to notify the peer to close the specified session stream; and an error frame (ERROR), used to transmit structured error information.

[0056] Furthermore, the fixed header length of the binary frame protocol is 14 bytes, specifically including: a 4-byte magic number field, with a fixed identifier string encoded in ASCII, used for frame boundary identification and protocol validity verification; a 1-byte version field, used to identify the protocol version to support backward compatibility; a 1-byte frame type field, used to distinguish different frame types; a 4-byte session stream identifier field, used to identify the SSH session to which the frame belongs, wherein the session stream identifier field value of the control frame is zero; and a 4-byte payload length field, representing the number of bytes of the subsequent variable-length payload in unsigned big-endian integer form.

[0057] Furthermore, the gateway server and the agent program transmit structured error information via error frames. The payload of each error frame includes predefined error codes and error description text. The error codes include at least: unregistered error, indicating that a non-registered frame was sent before registration was completed; registration timeout error, indicating that registration was not completed within a preset time; unknown client error, indicating that the hostname provided by the agent program is not in the whitelist configuration of the gateway server; PSK verification failure error, indicating that the hostname matches but the verification hash value is inconsistent; protocol version incompatibility error, indicating that the protocol version used by the agent program is not supported by the gateway server; SSH connection failure error, indicating that the agent program cannot connect to the local SSH service process; and session stream non-existent error, indicating that the referenced session stream identifier is invalid or closed.

[0058] Furthermore, the proxy management module of the gateway server maintains a thread-safe mapping table of registered proxy programs, with hostnames as keys and proxy connection objects as values; the proxy connection object contains at least the following information: a network socket reference for the underlying TLS-PSK encrypted connection, the hostname of the proxy program, a registration completion timestamp, a timestamp of the last received frame, a mapping table from the currently active session stream identifier to the session context, and a mutex lock for concurrency control.

[0059] The present invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor of the remote operation and maintenance method for service robots.

[0060] Compared with the prior art, the present invention has the following beneficial effects:

[0061] (1) Completely solves the NAT / firewall penetration problem: Through the "reverse tunnel" architecture that actively initiates outbound connections via the agent program, the service robot only needs outbound TCP access capability (usually not restricted by firewalls), without the need for public IP address, inbound port mapping, or additional NAT penetration infrastructure (such as STUN / TURN servers), greatly reducing the network deployment threshold. The robot can achieve secure remote access in any network environment with internet access (broadband, 4G / 5G, WiFi);

[0062] (2) A multi-layered, defense-in-depth security authentication system: A two-layer authentication mechanism of TLS-PSK encryption and identity association at the transport layer + SHA256 hash challenge response at the application layer, combined with a whitelist management strategy for each robot's independent PSK, constructs a defense-in-depth authentication system. The leakage of a single robot's PSK does not affect the security of other robots in the cluster; the plaintext PSK does not appear in any network transmission; and a registration timeout mechanism prevents unauthorized connections from consuming resources.

[0063] (3) Extreme ease of use for operation and maintenance personnel with zero client modification: Operation and maintenance personnel can use their familiar standard SSH clients (OpenSSH, PuTTY, Xshell, Termius, etc.) to access the target robot in the intuitive "username@robot name" format. There is no need to install proprietary software, browser plugins or configure complex agent commands, which greatly reduces the training cost and deployment resistance of the operation and maintenance team.

[0064] (4) Highly efficient single-connection multi-session multiplexing capability: By customizing the StreamID field in the binary frame protocol, a single TLS-PSK long connection can carry multiple concurrent SSH sessions. Compared with traditional solutions where each SSH tunnel or VPN connection carries only a single session, this invention reduces the number of network connections and TLS handshake overhead by several to tens of times, significantly saving CPU resources of embedded platforms and data traffic of cellular networks;

[0065] (5) Fine-grained session-level isolation and auditing support: All SSH session data between maintenance personnel and the robot passes through the gateway server, and each session has a globally unique StreamID identifier. This provides a natural technical foundation for session-level access control, operation auditing, and logging, enabling centralized security auditing without increasing the computational overhead on the robot side;

[0066] (6) Adaptive high availability connection maintenance: The agent program’s exponential backoff automatic reconnection mechanism (initial interval starts from 1 second, the waiting time doubles after each failure, with a maximum of 60 seconds, plus random jitter) ensures that the connection is automatically restored in common scenarios such as network interruption, robot roaming across WiFi APs, and cellular signal switching, without manual intervention, ensuring the continuous availability of the operation and maintenance channel.

[0067] (7) Lightweight design adapted to embedded environment: The agent program is designed to be simple, requiring only a single TLS connection and a small amount of memory data structure (StreamID mapping table), resulting in very low CPU and memory usage on the robot embedded computing platform. The fixed 14-byte header overhead of the binary frame protocol is minimal, and the protocol parsing logic is simple and efficient, making it suitable for resource-constrained environments. Attached Figure Description

[0068] Figure 1 This is a system structure diagram of a remote operation and maintenance system for service robots according to the present invention;

[0069] Figure 2 This is a schematic diagram of the frame structure of a binary frame protocol in one embodiment of the present invention;

[0070] Figure 3 This is a timing diagram of the agent program registration process in one embodiment of the present invention;

[0071] Figure 4 This is a timing diagram of the SSH proxy session establishment and bidirectional data forwarding process in one embodiment of the present invention;

[0072] Figure 5 This is a schematic diagram of single-connection multi-session multiplexing based on StreamID in one embodiment of the present invention;

[0073] Figure 6 This is a state machine diagram of the agent program connection lifecycle in one embodiment of the present invention;

[0074] Figure 7 This is a diagram of a multi-robot cluster management architecture in one embodiment of the present invention. Detailed Implementation

[0075] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0076] Please see Figure 1The present invention provides a remote operation and maintenance system for service robots, which consists of three logical layers:

[0077] Operations and Maintenance Terminal Layer: This layer consists of terminal devices used by operations and maintenance personnel, running standard SSH client software (such as OpenSSH, PuTTY, Xshell, etc.). Personnel connect to the gateway server via the internet or a dedicated network line. No proprietary software, certificates, or special network configurations are required on these terminal devices.

[0078] Gateway server layer: Deployed in an environment with a public IP address or network accessibility for maintenance personnel. The gateway server is the core scheduling and proxy node of this system, and mainly includes the following functional modules:

[0079] TLS-PSK Listening Module: Listens for TLS-PSK connection requests from various service robot agents on the configured TCP port. During the TLS handshake phase, it uses the PSK identity callback mechanism to look up the corresponding PSK from the local whitelist configuration to complete the establishment of the encrypted channel.

[0080] The agent management module maintains a thread-safe mapping table with hostnames as keys and AgentConn objects as values. Each AgentConn object contains: an underlying network connection reference, hostname, registration completion timestamp, timestamp of the last received frame, and a mapping table from StreamID to session context. The agent management module is responsible for: handling agent registration requests (verifying the hash value in the REGISTER frame), starting the registration timeout timer, periodically checking heartbeat timeouts, and cleaning up failed connections and their associated resources.

[0081] SSH Proxy Module: Listens for standard SSH connections from operations and maintenance personnel on the configured TCP port. This module integrates the SSH server protocol stack and is responsible for: SSH handshake and key exchange, resolving the target robot hostname from the username field, finding the corresponding Agent connection through the proxy management module, creating a transparent proxy channel to the robot's local SSHD, and bridging authentication requests and session channel data;

[0082] Frame protocol encoding / decoding module: Implements the encoding / decoding logic of a custom binary frame protocol, including: frame serialization (encoding into a byte stream), frame deserialization (decoding from a byte stream into a frame structure), reading complete frames from a TCP stream according to frame boundaries, and writing frames into a TCP stream.

[0083] Service robot layer: An agent is deployed on the embedded computing unit of each service robot. The agent contains the following functional modules:

[0084] TLS-PSK connection module: Using the hostname of the robot as the PSK identity, it actively initiates a TLS-PSK connection to the gateway server using a pre-configured PSK;

[0085] Registration module: After the encrypted channel is established, it constructs and sends a REGISTER frame and processes the REGISTER_ACK response;

[0086] SSH bridging module: Receives SSH_OPEN frames, establishes a TCP connection with the local SSHD (listening on 127.0.0.1:22), binds the StreamID to the TCP connection, and performs bidirectional data forwarding between SSH_DATA frames and the local TCP connection;

[0087] Heartbeat maintenance module: Sends HEARTBEAT frames at preset intervals, detects connection loss events, and drives exponential backoff reconnection logic.

[0088] Please see Figure 2 In this invention, all communication between the gateway server and the agent program adopts a custom binary frame protocol. The reasons for choosing a custom binary protocol instead of a text-based protocol (such as HTTP / 1.1 or JSON stream) are: (1) Fixed header parsing efficiency is high and it is suitable for embedded platforms; (2) The payload length field of binary encoding eliminates the frame boundary ambiguity problem in the text protocol; (3) The fixed position of the StreamID field facilitates fast demultiplexing of routes; (4) The protocol overhead is extremely small (only 14 bytes of header per frame).

[0089] Frame structure definition:

[0090] Each frame consists of a 14-byte fixed header and a variable-length payload. The fields in the fixed header are encoded in network byte order (big-endian), as defined below:

[0091] The Magic Number (offset 0, length 4 bytes): A fixed value of the ASCII-encoded string "SGHW", i.e., the byte sequence {0x53, 0x47, 0x48, 0x57}. It is used for frame boundary identification—the receiver scans this Magic Number in the TCP byte stream to determine the start position of the frame. Simultaneously, the existence of the Magic Number provides the first layer of protocol validity verification; if the first 4 received bytes do not match the Magic Number, a protocol error is immediately determined.

[0092] Version field (Version, offset 4, length 1 byte): Identifies the version number of the frame protocol; the current version value is 0x01. This field is reserved to provide backward compatibility for subsequent protocol upgrades. The gateway server can use different frame parsing logic for different versions of the proxy program based on the version number.

[0093] Type field (Type, offset 5, length 1 byte): Identifies the type of frame, determining the semantics and processing method of the payload. The currently defined frame types are shown in Table 1 below:

[0094] Table 1 Currently Defined Frame Types .

[0095] The Session Stream Identifier field (StreamID, offset 6, length 4 bytes) is used to distinguish multiple concurrent independent SSH sessions over the same TLS-PSK encrypted connection. For control frames (REGISTER, REGISTER_ACK, HEARTBEAT, HEARTBEAT_ACK, ERROR), this field has a value of 0. For session frames (SSH_OPEN, SSH_OPEN_ACK, SSH_DATA, SSH_CLOSE), this field has a unique session identifier assigned by the gateway server. StreamID is a 32-bit unsigned integer, theoretically supporting over 4 billion concurrent sessions, far exceeding the concurrency requirements of actual deployments.

[0096] The payload length field (Length, offset 10, length 4 bytes): represents the number of bytes of the subsequent payload as an unsigned 32-bit big-endian integer. A value of 0 indicates that the frame has no payload (such as heartbeat frames and heartbeat response frames). In this embodiment, the maximum payload length is limited to 65536 bytes (64KB). SSH session data exceeding this limit is fragmented at the sending end and sent as multiple SSH_DATA frames, which are then reassembled sequentially at the receiving end.

[0097] The pseudocode for frame encoding (serialization) and decoding (deserialization) of the binary frames used in this invention is as follows:

[0098] Frame encoding algorithm (serializing the frame structure into a byte stream):

[0099] Algorithm: EncodeFrame(frame) → []byte Input: frame, containing Version, Type, StreamID, and Payload fields. Output: Complete frame byte sequence.

[0100] Steps: 1. payloadLen ← len(frame.Payload) 2. buffer ← Allocate a byte array of 14 + payloadLen bytes. 3. / / Write the magic number (big-endian) 4. buffer[0] ← 0x53 / / 'S' 5. buffer[1] ← 0x47 / / 'G' 6. buffer[2] ← 0x48 / / 'H' 7. buffer[3] ← 0x57 / / 'W' 8. / / Write the version number 9. buffer[4] ← frame.Version 10. / / Write frame type 11. buffer[5] ← frame.Type 12. / / Write StreamID (big-endian, 4 bytes) 13. buffer[6] ← byte((frame.StreamID >> 24) & 0xFF) 14. buffer[7] ← byte((frame.StreamID >> 16) & 0xFF) 15. buffer[8] ← byte((frame.StreamID >> 8) & 0xFF) 16. buffer[9] ← byte(frame.StreamID & 0xFF) 17. / / Write payload length (big-endian, 4 bytes) 18. buffer

[10] ← byte((payloadLen >> 24) & 0xFF) 19. buffer

[11] ← byte((payloadLen >> 16) & 0xFF) 20. buffer

[12] ← byte((payloadLen >> 8) & 0xFF) 21. buffer

[13] ← byte(payloadLen & 0xFF) 22. / / Write payload 23. Copy frame.Payload to buffer[14..14+payloadLen] 24. return buffer

[0101] Frame decoding algorithm (reading and parsing a complete frame from a TCP byte stream):

[0102] Algorithm: DecodeFrame(reader) → (Frame, error) Input: reader, a readable byte stream (such as a TCP connection). Output: The parsed Frame structure, or error message. step: 1. header ← Reads 14 bytes from the reader 2. If the number of bytes read is less than 14: 3. Return error("Incomplete frame header") 4. / / Verify the magic number 5. if header[0] != 0x53 OR header[1] != 0x47 OR header[2] != 0x48 ORheader[3] != 0x57: 6. Return error("Magic number check failed: not a valid start of frame") 7. / / Parse each field 8. version ← header[4] 9. If version != 0x01: 10. Return error("Unsupported protocol version") 11. frameType ← header[5] 12.streamID←(uint32(header[6])<<24)| (uint32(header[7]) << 16) |(uint32(header[8]) << 8) | uint32(header[9]) 13.payloadLen←(uint32(header

[10] )<<24)|(uint32(header

[11] )<<16) |(uint32(header

[12] ) << 8) | uint32(header

[13] ) 14. / / Verify load length 15. If payloadLen > 65536: 16. Return error("Load length exceeds maximum limit") 17. / / Read payload 18. if payloadLen > 0: 19. payload ← Read payloadLen bytes from reader 20. else: 21. payload ← empty byte array 22. / / Construct and return a Frame 23. return Frame{Version: version, Type: frameType, StreamID:streamID, Payload: payload}

[0103] Frame boundary detection and incremental parsing:

[0104] Since TCP is a byte-stream oriented protocol and does not preserve application-layer message boundaries, the receiver needs to implement a frame boundary detection mechanism. This embodiment employs the following approach: the receiver maintains a receive buffer and a parsing state machine. The parsing state machine includes the following states: WAIT_MAGIC (waiting for the magic number, scanning the 0x53 0x47 0x48 0x57 sequence in the byte stream), WAIT_HEADER (magic number found, waiting to receive the complete 14-byte header), and WAIT_PAYLOAD (header parsed, waiting to receive the specified payload length). The state transitions are as follows:

[0105] 1. The initial state is WAIT_MAGIC. The receiver scans byte by byte, and when it matches a 4-byte magic number consecutively, it transitions to the WAIT_HEADER state.

[0106] 2. In the WAIT_HEADER state, the receiver continues to read the next 10 bytes (version 1 + type 1 + StreamID4 + Length 4) to form a complete 14-byte header. After parsing out the version number, frame type, StreamID, and payload length, it transitions to the WAIT_PAYLOAD state.

[0107] 3. In the WAIT_PAYLOAD state, the receiver reads the specified number of payload data according to the parsed payload length. After all payloads have been read, a complete Frame structure is generated and delivered to the upper layer for processing. The state machine then returns to the WAIT_MAGIC state to prepare for parsing the next frame.

[0108] The above mechanism ensures that when byte packets are joined together or incomplete (a common phenomenon in TCP) during network transmission, the receiver can correctly segment and parse each frame.

[0109] The detailed design of the TLS-PSK transport layer of this invention is as follows:

[0110] In one embodiment of the present invention, the transport layer security between the gateway server and the agent program is guaranteed by the TLS-PSK (Pre-Shared Key) protocol. The reasons for choosing TLS-PSK instead of standard TLS certificate authentication are: (1) Service robots usually do not have a complete PKI infrastructure (no CA server, certificate update mechanism), and the management of PSK (pre-set in the configuration file) is more suitable for robot deployment scenarios; (2) The computational overhead of PSK authentication is lower than that of certificate chain verification, which is suitable for embedded platforms; (3) PSK itself is not transmitted in the network, so its security is guaranteed.

[0111] This embodiment supports the following TLS-PSK cipher suites:

[0112] - TLS_PSK_WITH_AES_128_GCM_SHA256 (Recommended for resource-constrained platforms, 128-bit security)

[0113] - TLS_PSK_WITH_AES_256_GCM_SHA384 (Recommended for high-security scenarios, 256-bit security)

[0114] All of the above suites use the AEAD (Authenticated Encryption with Associated Data) encryption mode, which provides both encryption and integrity protection in a single cryptographic operation.

[0115] PSK Identity Mapping Mechanism:

[0116] During the TLS-PSK handshake, the client (agent) sends a ClientHello message carrying the PSKidentity extension. In this embodiment, the agent uses the hostname string of the service robot it is using as the value of the PSK identity. Upon receiving the ClientHello, the server (gateway server) calls the PSK identity callback function to look up the corresponding PSK. The pseudocode for the callback function is as follows:

[0117] Algorithm: PSKLookupCallback(identity) → (PSK, error) Input: identity, a PSK identity string (i.e., hostname) provided by the agent. Output: The corresponding PSK byte sequence, or a lookup failure error. step: 1. hostname ← identity / / identity is the hostname 2. Search for entries with matching hostnames in the whitelist configuration of clients on the gateway server. 3. If no matching entry is found: 4. Return error("Unknown client: " + hostname) 5. psk ← Retrieves the pre-shared key string from the matched entries. 6. if len(psk) < 16: 7. Return error("PSK length is insufficient, at least 16 bytes are required") 8. return []byte(psk)

[0118] If the PSK lookup fails (hostname not configured), the TLS handshake will fail, and the proxy's connection will be rejected. This constitutes the first layer of authentication, namely transport layer authentication.

[0119] Degradation solutions when the standard library is restricted:

[0120] For cases where TLS-PSK multi-identity support is incomplete in some programming language standard libraries (e.g., some languages' standard TLS libraries only support a single PSK configuration), this embodiment provides a downgraded solution: Standard TLS certificate authentication (using a self-signed certificate or a certificate issued by an internal CA) is used to establish the transport layer encrypted channel, while identity authentication and PSK verification are entirely handled by the application layer's REGISTER frame mechanism. Under this downgraded solution, the transport layer is only responsible for encryption and no longer undertakes identity authentication; the application layer's two-layer authentication degenerates into single-layer authentication, but the overall security and functionality of the system remain unchanged.

[0121] Please see Figure 3 The registration process of the proxy program in this invention is one of the core security mechanisms of this invention. The gateway server maintains a client whitelist (clients) in the configuration file, in the format `<hostname, PSK> A list of pairs. Each hostname uniquely identifies a service robot, and each PSK is a unique pre-shared key string assigned independently to that robot. Generally, the length should be no less than 16 bytes, and 32 bytes or more is recommended.

[0122] The normal registration process is as follows:

[0123] (1) After the proxy program starts, it reads the local YAML configuration file to obtain the gateway server address, local hostname and PSK. The proxy program uses the hostname as the PSK identity and the PSK byte sequence as the pre-shared key, and calls the TLS-PSK Dial function to initiate a connection to the gateway server.

[0124] (2) The gateway server's TLS-PSK listening module accepts the TCP connection and searches for the PSK through the PSKidentity callback function during the TLS handshake phase to complete the TLS handshake. At this time, the encrypted channel has been established, but the connection is in an "unregistered" state. The gateway server's proxy management module starts a registration timeout timer (e.g., 30 seconds) for this connection.

[0125] (3) The agent program constructs a REGISTER frame. The REGISTER frame's type field is 0x01, the StreamID field is 0 (control frame), and the payload is registration information in JSON format:

[0126] { "hostname": "kitchen-robot-03", "psk_hash": "a1b2c3d4e5f6..." }

[0127] The psk_hash is calculated using SHA256(hostname || PSK), which means that the SHA256 hash value is calculated from the concatenation result of the hostname string and the PSK byte sequence. The PSK plaintext does not appear in the REGISTER frame, nor in any network transmission.

[0128] (4) After receiving the REGISTER frame, the gateway server executes the following verification logic:

[0129] - Parse the JSON payload and extract the hostname and psk_hash;

[0130] - Search for the corresponding PSK using the hostname as the key in the local whitelist configuration;

[0131] - If the hostname is not in the whitelist, return REGISTER_ACK {success: false, message:"unknown client"} and disconnect;

[0132] - Calculate SHA256(hostname || PSK in the local whitelist) using the same hash algorithm;

[0133] - Compare the calculation results byte by byte with the psk_hash in the REGISTER frame;

[0134] - If they match, bind the hostname to the TLS connection, store it in the mapping table of the proxy management module, unregister the timeout timer, and return REGISTER_ACK {success: true};

[0135] - If there is a discrepancy, return REGISTER_ACK {success: false, message: "PSKverification failed"} and disconnect.

[0136] (5) After receiving REGISTER_ACK {success: true}, the agent program enters the "registered" state, starts the heartbeat cycle, and begins normal service.

[0137] The paths that cause registration errors include:

[0138] (A) Registration Timeout -- If the proxy does not send a REGISTER frame within the registration timeout period (e.g., 30 seconds) after the TLS handshake is completed, the gateway server will proactively disconnect the connection and release resources. This mechanism prevents malicious or faulty proxies from occupying TLS session resources for an extended period.

[0139] (B) Unknown Client -- If the hostname in the REGISTER frame is not in the gateway server's whitelist, it means that the proxy program is not authorized to access this gateway server.

[0140] (C) PSK verification failed -- If the hostname matches but the psk_hash does not match, it means that the PSK held by the agent is inconsistent with the configuration on the server side (which may be due to configuration error or an attacker trying to forge an identity).

[0141] Regarding the security of the dual-layer authentication in this invention:

[0142] In this invention, the TLS-PSK handshake authentication and the REGISTER frame hash verification are two independent security layers:

[0143] - The TLS-PSK layer ensures: encrypted communication, server authentication (the proxy verifies that it has indeed connected to a legitimate server with the correct PSK), and initial client authentication (only clients with the correct PSK can complete the TLS handshake).

[0144] - The REGISTER frame layer ensures: cryptographic binding verification of the hostname and PSK, and prevents unauthorized registration attempts via legitimate TLS channels.

[0145] The two layers are independent of each other—even if an attacker completes the TLS handshake in some way (e.g., by exploiting a TLS implementation vulnerability), registration can still be completed by verifying the hash of the REGISTER frame. Conversely, even if an attacker intercepts the psk_hash in the REGISTER frame (which is not feasible within a TLS encrypted channel and is only for analysis purposes), this hash value can only be used for verification and cannot be used to deduce the PSK.

[0146] Please see Figure 4 Once the agent program completes registration, operations and maintenance personnel can remotely perform SSH operations and maintenance on the service robot through the gateway server.

[0147] Step 1: Establishing an SSH connection and resolving usernames

[0148] Maintenance personnel use a standard SSH client to connect to the gateway server's SSH listening port (e.g., port 2222). The SSH login username format is "real username@robot hostname". For example, if maintenance engineer Alice needs to access the food delivery robot with the hostname "kitchen-robot-03", the SSH command would be:

[0149] ssh alice@kitchen-robot-03-p 2222

[0150] After receiving the SSH connection, the gateway server's SSH proxy module extracts the username field during the SSH protocol's user authentication phase (SSH_MSG_USERAUTH_REQUEST). The parsing logic is as follows:

[0151] - Find the position of the last '@' character in the username string;

[0152] - The part before '@' is the "real username" (realUser, in this example, "alice");

[0153] - The part after '@' is the "target robot hostname" (in this example, "kitchen-robot-03").

[0154] - If the username does not contain '@', it is considered an incorrect format and authentication is rejected.

[0155] Step 2: Agent connection lookup and session channel establishment

[0156] The gateway server's SSH proxy module uses targetHostname as the key to look up the corresponding AgentConn object in the registered agent mapping table of the proxy management module.

[0157] If the agent program corresponding to targetHostname is not registered or is offline, return an authentication failure message of "target robot unreachable" to the operations and maintenance personnel.

[0158] If the corresponding AgentConn object is found, the SSH proxy module performs the following operations:

[0159] - Allocate a unique session stream identifier from the StreamID space (e.g., using an atomic incrementing counter, starting from 1);

[0160] - Construct an SSH_OPEN frame (type 0x05, StreamID is the identifier just assigned), with a payload in JSON format:

[0161] { "stream_id": 1, "addr": "127.0.0.1:22" }

[0162] - Send the frame via the target robot's TLS-PSK encrypted connection;

[0163] - Temporarily store the context of this SSH session (including the SSH connection reference of the operations and maintenance personnel, StreamID, target hostname, realUser, etc.) and wait for the SSH_OPEN_ACK response.

[0164] Step 3: The agent establishes a connection to the local SSHD.

[0165] After receiving the SSH_OPEN frame, the agent parses the addr field in the payload (formatted as "IP:Port") and initiates a TCP connection to the specified target address (usually 127.0.0.1:22, i.e., the local SSH service port).

[0166] If the TCP connection is successfully established, the proxy program performs the following operations:

[0167] - Record the mapping relationship between the StreamID and the TCP connection in the local StreamID mapping table;

[0168] - Construct an SSH_OPEN_ACK frame (type 0x06, carrying the same StreamID) and send it back to the gateway server;

[0169] - Start a data forwarding coroutine / thread for this StreamID, which is responsible for reading data from this TCP connection and encapsulating it into SSH_DATA frames to send to the gateway server.

[0170] If the TCP connection fails to be established (e.g., the local SSHD is not running), the agent constructs an SSH_OPEN_ACK frame with the failure information in the payload, or sends an ERROR frame (error code 2001, SSH connection failed).

[0171] Step 4: Transparent forwarding of authentication information

[0172] After receiving the SSH_OPEN_ACK confirmation, the gateway server knows that the local SSHD channel on the robot has been established. At this point, the gateway server performs transparent authentication bridging according to the SSH authentication method used by the operations and maintenance personnel:

[0173] (A) Password authentication mode:

[0174] - The gateway server has received the SSH_MSG_USERAUTH_REQUEST (password method) sent by the operations and maintenance personnel's SSH client, which contains realUser and password;

[0175] - The gateway server initiates a new SSH client connection to the robot's local SSHD through the previously established channel to the robot's local SSHD (a virtual connection identified by StreamID);

[0176] - On this client connection, the gateway server sends a password authentication request to the robot's local SSHD using realUser as the username and the password provided by the operations and maintenance personnel as the password;

[0177] - The robot's local SSHD verifies usernames and passwords based on its local user database ( / etc / shadow, PAM, etc.);

[0178] - The gateway server returns the authentication result (success or failure) returned by the robot's local SSHD to the operations and maintenance personnel via their SSH connection.

[0179] (B) Public Key Authentication Mode:

[0180] - The gateway server will forward the public key and signature data provided by the operations and maintenance personnel as is through the SSH client connection to the robot's local SSHD;

[0181] - The robot's local SSHD verifies the public key and signature based on its local authorized_keys file;

[0182] - The gateway server transparently sends the authentication result back to the operations and maintenance personnel.

[0183] After successful authentication, an SSH client-server session is established between the gateway server and the robot's local SSHD.

[0184] Step 5: Bidirectional forwarding of session channel data

[0185] After successful authentication, the SSH client of the operations and maintenance personnel can request to open various types of SSH channels. The SSH proxy module of the gateway server transparently bridges the channel requests and channel data between the "SSH connection of the operations and maintenance personnel" and the "SSH client connection for the robot's local SSHD".

[0186] Taking a shell session channel as an example, the data forwarding process is as follows:

[0187] - When maintenance personnel enter commands in the SSH client, the SSH client encapsulates the command data in an SSH_MSG_CHANNEL_DATA message and sends it to the gateway server;

[0188] - The gateway server extracts the payload of SSH_MSG_CHANNEL_DATA, encapsulates it into an SSH_DATA frame (type 0x07, StreamID is the identifier of this session), and sends it to the proxy program via a TLS-PSK encrypted connection;

[0189] - The agent receives SSH_DATA frames, looks up the corresponding local TCP connection (connected to the local SSHD) based on the StreamID, and writes the payload data to the TCP connection as is.

[0190] - The robot processes SSHD commands locally, generates output data, and returns it to the agent program via a TCP connection;

[0191] - The agent encapsulates the output data into SSH_DATA frames (type 0x07, same StreamID) and sends them to the gateway server via a TLS-PSK encrypted connection;

[0192] - The gateway server encapsulates the output data into an SSH_MSG_CHANNEL_DATA message and sends it to the SSH client of the operations and maintenance personnel;

[0193] - The terminal interface of the operations and maintenance personnel displays the output results of the commands.

[0194] The bidirectional forwarding process described above is routed using the StreamID mapping table in the proxy program. The data structure maintained by the proxy program is as follows:

[0195] streams: map[uint32]net.Conn / / StreamID → TCP connection (pointing to local 127.0.0.1:22)

[0196] Pseudocode for the proxy program's frame distribution logic:

[0197] Algorithm: AgentHandleFrame(frame) Input: frame, a frame received from a TLS-PSK connection. step: 1. switch frame.Type: 2. case SSH_OPEN: 3. addr ← parses the target address in frame.Payload 4. tcpConn ← DialTCP(addr) 5. if tcpConn == error: 6. Send an ERROR frame (error code 2001) 7. return 8. streams[frame.StreamID] ← tcpConn 9. Send an SSH_OPEN_ACK frame (carrying frame.StreamID) 10. Start the forwarding coroutine ForwardTCPToServer(frame.StreamID, tcpConn) 11. Case SSH_DATA: 12. tcpConn ← streams[frame.StreamID] 13. if tcpConn == nil: 14. Send an ERROR frame (Error code 2002, stream ID does not exist). 15. return 16. tcpConn.Write(frame.Payload) 17. case SSH_CLOSE: 18. tcpConn ← streams[frame.StreamID] 19. if tcpConn != nil: 20. tcpConn.Close() 21. delete(streams, frame.StreamID) 22. case HEARTBEAT_ACK: 23. Update heartbeat status (record the time of the last received frame) 24. Case Error: 25. Log errors.

[0198] Step Six: Close the Session

[0199] When maintenance personnel actively disconnect the SSH connection, or when the robot's local SSHD closes the session, the session closure process is as follows:

[0200] - Disable the initiator from sending SSH_CLOSE frames (type 0x08, carrying the corresponding StreamID);

[0201] - After receiving the SSH_CLOSE frame, the other end closes the corresponding TCP connection or SSH channel and deletes the StreamID entry from the mapping table;

[0202] - The gateway server reclaims the StreamID so that it can be reused in subsequent new sessions.

[0203] Supported channel types:

[0204] The SSH proxy module in this embodiment supports transparent proxying for the following SSH tunnel types:

[0205] - Session channel: SSH standard session channel, supporting shell (interactive command line), exec (remote command execution), and subsystem (subsystem, such as SFTP) request types;

[0206] - direct-tcpip channel: TCP port forwarding channel, allowing operations and maintenance personnel to access other TCP services (such as robot debugging ports, database service ports, etc.) within the local area network where the service robot is located via SSH sessions.

[0207] Please see Figure 5One of the key technologies of this invention is session multiplexing. The multiplexing principle is as follows: When the gateway server needs to establish a channel to the same robot for multiple maintenance personnel or multiple SSH sessions, it assigns a different StreamID to each session. All SSH_OPEN, SSH_DATA, and SSH_CLOSE frames carry the StreamID of their respective sessions. After receiving the frames, the agent program routes the data to the corresponding local TCP connection based on the StreamID, achieving session-level demultiplexing.

[0208] Specific example: Suppose three operations and maintenance personnel simultaneously access the same service robot "kitchen-robot-03" through the gateway server:

[0209] - Alice, the operations and maintenance personnel, executed a shell command: assigning StreamID = 1.

[0210] - System administrator Bob performs an SFTP file transfer: assigns StreamID = 2

[0211] - Operations engineer Charlie executes a remote command: Assign StreamID = 3

[0212] The SSH_DATA frames from the three sessions are transmitted alternately over the same TLS-PSK connection:

[0213] Frame 1: [Magic Number: SGHW] [Type: SSH_DATA] [StreamID: 1] [Payload: Alice's command data...] Frame 2: [Magic Number: SGHW] [Type: SSH_DATA] [StreamID: 2] [Payload: Bob's file data...] Frame 3: [Magic Number: SGHW] [Type: SSH_DATA] [StreamID: 1] [Payload: Response to Alice command...] Frame 4: [Magic Number: SGHW] [Type: SSH_DATA] [StreamID: 3] [Payload: Charlie command response...]

[0214] The receiving end of the proxy program routes frame 2 to Bob's SFTP connection (TCP connection B) based on the StreamID, routes frames 1 and 3 to Alice's shell connection (TCP connection A), and routes frame 4 to Charlie's connection (TCP connection C). Data from each session does not interfere with each other.

[0215] Reuse Efficiency Analysis: Assume a service robot has N active SSH sessions simultaneously. Traditional SSH reverse tunneling schemes require N independent TCP connections and N TLS handshakes. This invention requires only 1 TCP connection and 1 TLS handshake, resulting in a connection count of O(1). For robots deployed on cellular networks (4G / 5G), the reduced number of connections directly translates to: fewer TCP slow start processes, fewer Radio Resource Control (RRC) state transitions, lower signaling overhead, and greater power savings.

[0216] Please see Figure 6 The connection between the agent and the gateway server follows a strictly defined state machine model.

[0217] Status includes:

[0218] - DISCONNECTED: There is no network connection between the agent and the gateway server. This is the initial state.

[0219] - CONNECTING: The agent is performing a TCP connection and TLS-PSK handshake.

[0220] - TLS_ESTABLISHED (TLS established): The TLS handshake has been completed and the encrypted channel has been established, but application layer registration has not yet been completed. The gateway server has started a registration timeout timer for this connection.

[0221] - REGISTERING: The agent has sent a REGISTER frame and is waiting for a REGISTER_ACK response.

[0222] - REGISTERED: The agent has been registered and is functioning normally. It can receive and respond to SSH session requests. It periodically sends heartbeat frames.

[0223] - HEARTBEAT_WAIT: The agent has sent a HEARTBEAT frame and is waiting for a HEARTBEAT_ACK response.

[0224] - STALE (Failed): The gateway server has determined that the proxy connection has failed (heartbeat timeout) and is performing a cleanup operation.

[0225] The state transition rules are shown in Table 2 below:

[0226] Table 2 State Transition Rules .

[0227] Heartbeat Mechanism: In the REGISTERED state, the agent periodically sends HEARTBEAT frames (type 0x03, empty payload) at the configured heartbeat interval (heartbeat.interval, e.g., 30 seconds), and then enters the HEARTBEAT_WAIT state. Upon receiving the HEARTBEAT frame, the gateway server updates the agent's "last received frame timestamp" and returns a HEARTBEAT_ACK frame (type 0x04, empty payload). The agent returns to the REGISTERED state upon receiving the HEARTBEAT_ACK. If the agent does not receive a HEARTBEAT_ACK within the heartbeat response timeout period (heartbeat.timeout, e.g., 10 seconds), it determines the connection is abnormal, enters the DISCONNECTED state, and initiates a reconnection.

[0228] On the gateway server side, the agent management module starts a background periodic check task (the check interval is equal to the heartbeat timeout, e.g., 90 seconds), iterating through all registered AgentConn objects. For connections whose last received frame timestamp is more than heartbeat_timeout from the current time, they are determined to be invalid, enter the STALE state, and perform cleanup operations (closing the underlying TCP connection, removing it from the mapping table, and reclaiming all StreamID resources associated with the agent).

[0229] The independence of registration timeout and heartbeat timeout: Registration timeout and heartbeat timeout are two independent time parameters. Registration timeout only applies to the TLS_ESTABLISHED and REGISTERING states, and is relatively short (e.g., 30 seconds), aiming to quickly release connections that have not yet completed registration. Heartbeat timeout applies to the REGISTERED state, and is longer (e.g., 90 seconds), aiming to tolerate temporary network fluctuations without frequently triggering reconnections. This separation allows the system to quickly reject unauthorized connections without frequently interrupting registered connections due to momentary network fluctuations.

[0230] The index backoff and reconnection mechanism is as follows:

[0231] When the agent detects that the connection with the gateway server has been lost (whether due to network interruption, server restart, or heartbeat timeout), it automatically initiates an exponential backoff reconnection process, which is described in detail below.

[0232] Reconnection algorithm:

[0233] Algorithm: ReconnectLoop() step: 1. attempt ← 1 2. while true: 3. Wait for ReconnectDelay(attempt) seconds. 4. conn ← Attempts to connect to the gateway server (TLS-PSK Dial) 5. If conn succeeds: 6. attempt ← 1 / / Reset the attempt count 7. Perform the registration process (see Section 5.4) 8. If registration is successful: 9. Enter the normal operating cycle (frame reception → distribution → heartbeat) 10. else: 11. / / Registration failed (e.g., PSK error), do not retry, log the error and exit. 12. break 13. else: 14. attempt ← attempt + 1 15. Log reconnection failures. Function: ReconnectDelay(attempt) → Number of seconds 1. rawDelay ← initial_interval × multiplier^(attempt - 1) 2. cappedDelay ← min(rawDelay, max_interval) 3. jitter ← cappedDelay × random(0, 0.5) / / 0 to 50% random jitter 4. finalDelay ← cappedDelay - jitter 5. return max(finalDelay, 0)

[0234] Example of parameter configuration:

[0235] - initial_interval (initial wait time): 1 second

[0236] - Multiplier (backoff multiplier): 2.0

[0237] - max_interval (maximum wait time): 60 seconds

[0238] Under this configuration, the waiting time (rounded) for each reconnection attempt is as follows:

[0239] - First retry: approximately 0.5 to 1.0 seconds

[0240] - Second retry: approximately 1.0 ~ 2.0 seconds

[0241] - 3rd retry: approximately 2.0 ~ 4.0 seconds

[0242] - 4th retry: approximately 4.0 ~ 8.0 seconds

[0243] - 5th retry: approximately 8.0 ~ 16.0 seconds

[0244] - 6th retry: Approximately 16.0 ~ 32.0 seconds

[0245] - Retry 7th time and beyond: approximately 30.0 ~ 60.0 seconds

[0246] The significance of random jitter: In robot cluster deployment scenarios, when the gateway server briefly restarts, all agents detect the connection loss almost simultaneously. Without random jitter, all agents will initiate reconnection simultaneously according to the same backoff schedule, causing the "Thundering Herd Problem," which may overwhelm the gateway server or intermediate network devices. Random jitter calculated independently by each agent (0-50% latency reduction) naturally disperses the reconnection times of each robot, evenly distributing them within the backoff window.

[0247] State synchronization after reconnection: After a successful reconnection, the agent re-executes the complete registration process using a new TLS-PSK connection. All active SSH sessions (StreamID mappings) prior to the reconnection were cleaned up during the disconnection. If operations personnel still need to access the bot, they must re-initiate the SSH connection. This ensures state simplicity and consistency, eliminating "orphan" session states across connections.

[0248] The main security threats faced by this invention and the corresponding protection mechanisms are as follows:

[0249] Threat 1: Network eavesdropping and man-in-the-middle attacks

[0250] - Threat Description: Attackers intercept or tamper with communication data on the network path between the agent and the gateway server.

[0251] - Protection Mechanism: All communication between the agent and the gateway server is conducted through a TLS-PSK encrypted channel. The TLS-PSK uses the AEAD cipher suite (AES-GCM) to provide both encryption and integrity protection. Attackers cannot decrypt the communication content, and any tampering will be detected by integrity verification, leading to connection termination. The PSK itself is not transmitted over the network during the TLS handshake process, preventing attackers from obtaining the PSK through eavesdropping.

[0252] Threat 2: Unauthorized proxy registration

[0253] - Threat Description: Attackers attempt to register their malicious proxies with the gateway server to hijack or impersonate legitimate bots.

[0254] - Protection mechanisms: (1) During the TLS-PSK handshake phase, the attacker must have the correct PSK corresponding to the legitimate hostname to complete the handshake; (2) Even if the TLS handshake is successful, the attacker still needs to provide the correct SHA256 (hostname || PSK) verification hash value in the REGISTER frame; (3) Even if the attacker intercepts the REGISTER frame of the legitimate proxy program (which is not feasible under TLS encryption), psk_hash is a one-way hash value and the PSK cannot be derived in reverse; (4) The registration timeout mechanism prevents the attacker from occupying the connection for a long time through brute-force attempts.

[0255] Threat 3: Leakage of credentials due to physical contact

[0256] - Threat Description: Attackers physically contact service bots to extract the PSK from their agent configuration files on their storage media.

[0257] - Protection mechanism: (1) Each service robot uses an independent PSK. The leakage of a single robot's PSK only affects the robot itself and does not affect other robots in the cluster; (2) The whitelist management of the gateway server allows maintenance personnel to quickly revoke the leaked robot's PSK - simply delete or modify the entry of the hostname in the configuration file and restart or hot-load the gateway server; (3) PSK can be stored in conjunction with hardware security modules (such as TPM, TrustZone) to increase the difficulty of physical extraction - this enhancement scheme is a reasonable extension of the technical solution of this invention.

[0258] Threat 4: Resource exhaustion attack (Denial of Service)

[0259] - Threat Description: Attackers initiate a large number of TCP connection or TLS handshake requests to the gateway server's TLS-PSK listening port, intending to exhaust the server's file descriptors, memory, or CPU resources.

[0260] - Protection mechanisms: (1) Registration timeout mechanism - Connections that have completed the TLS handshake but have not completed registration within the preset time are forcibly disconnected, limiting the upper limit of resource occupation time for a single connection attempt; (2) Standard SYN cookie and connection rate limiting mechanism can be deployed in front of the gateway server; (3) The computational overhead of the TLS-PSK handshake itself is much lower than that of the asymmetric cryptography TLS certificate handshake (without RSA / ECDSA signature verification), which improves the resilience against denial-of-service attacks.

[0261] Threat 5: Session hijacking of registered connections

[0262] - Threat Description: Attackers attempt to inject forged frames into legitimate proxy TLS connections to manipulate or eavesdrop on SSH sessions.

[0263] - Protection mechanisms: (1) The AEAD encryption of the TLS protocol provides an independent sequence number and integrity label for each TLS record, so attackers cannot inject or replay data at the TLS layer; (2) At the application layer, each SSH session has an independent StreamID, and the StreamID is assigned by the gateway server when the session is established and transmitted through an encrypted channel, so attackers cannot predict or forge a valid StreamID.

[0264] Threat 6: Lateral Movement After Gateway Server is Breached

[0265] - Threat Description: The attackers have gained control of the gateway server and are attempting to further penetrate the various service bots through it.

[0266] - Protection mechanism: (1) The channel from the gateway server to the robot is an SSH client (not an SSH server) connection. The gateway server does not store the login credentials of the robot's local SSHD. The password / key of the maintenance personnel is transmitted transparently during the authentication phase. The gateway server cannot obtain the plaintext (the gateway server can never obtain the private key under the public key authentication mode); (2) Each maintenance personnel's SSH session to the robot is an independent SSH client connection. The sessions are completely isolated. Attackers who compromise the gateway server cannot access the data of another session through one session; (3) It is recommended to implement additional system hardening measures for the gateway server in production deployment (such as the principle of least privilege, mandatory access control, audit logs, etc.).

[0267] In one embodiment of the present invention, both the agent program and the gateway server use YAML format configuration files for parameter management. YAML format has advantages such as good human readability, support for hierarchical structures, and mature parsing libraries available for most programming languages.

[0268] Example of agent configuration (agent.yaml):

[0269] # Agent Configuration server: address: "gateway.example.com:8443" # Gateway server address and port connect_timeout: 10s # TCP connection timeout tls_min_version: "1.2" # Minimum TLS version requirement client: hostname: "kitchen-robot-03" # The hostname of this service robot (must be configured in the server-side whitelist) psk: "a3f8b2c1d4e5f6a7b8c9d0e1f2a3b4c5" # The bot's pre-shared key (recommended to be at least 32 bytes) ssh_address: "127.0.0.1" # Local SSH service listening address ssh_port: 22 # Local SSH service listening port reconnect: enabled: true initial_interval: 1s # Initial reconnection wait time max_interval: 60s # Maximum reconnection wait time limit multiplier: 2.0 # Backoff multiplier heartbeat: interval: 30s # Heartbeat sending interval timeout: 10s # Heartbeat response timeout (if no ACK is received within the timeout period, the connection is considered lost) log: level: "info" # Log levels: debug / info / warn / error file: "" # Log file path (an empty string indicates output to standard output)

[0270] Gateway server configuration example (server.yaml):

[0271] # Server Configuration gateway: listen: "0.0.0.0:8443" # Agent TLS-PSK connection listening address register_timeout: 30s # Registration timeout (REGISTER must be completed within this time limit after the TLS handshake is finished) heartbeat_timeout: 90s # Heartbeat timeout (If no frame is received within the timeout period, the Agent is considered offline) tls_min_version: "1.2" # Minimum TLS version requirement # Whitelist of allowed client connections, each client has a unique hostname and pre-shared key. clients: - hostname: "kitchen-robot-01" psk: "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6" - hostname: "kitchen-robot-02" psk: "d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9" - hostname: "kitchen-robot-03" psk: "a3f8b2c1d4e5f6a7b8c9d0e1f2a3b4c5" - hostname: "cleaning-robot-01" psk: "f7e8d9c0b1a2f3e4d5c6b7a8f9e0d1c2" ssh: listen: "0.0.0.0:2222" # SSH connection listening address for system administrators host_key_file: "ssh_host_key" # Path to the SSH host private key file (automatically generated on first run) log: level: "info" file: " / var / log / ssh-gateway / server.log"

[0272] The configuration file embodies the key security design principles of this invention: (1) Each service robot is assigned an independent hostname and PSK, and each record in the whitelist corresponds to a robot that is different from each other; (2) The PSK is stored in plaintext in the configuration file on the server side, which requires the configuration file on the server side to be strictly protected by the operating system file permissions (e.g., set to 0600 permissions under Linux, which can only be read by root); (3) Registration timeout and heartbeat timeout are configured independently, with the former being shorter (30s) to quickly release unauthorized connections and the latter being longer (90s) to tolerate network jitter.

[0273] In one embodiment of the present invention, the key technical parameters obtained in actual deployment testing are as follows:

[0274] Frame protocol overhead: Each frame has a fixed header of only 14 bytes. Taking a typical interactive command scenario in an SSH session (each key press generates an SSH data packet, approximately 40-100 bytes) as an example, the 14-byte frame header overhead accounts for approximately 12%-26%. For SFTP large file transfer scenarios (data packets can reach 32KB), the frame header overhead can be reduced to below 0.04%.

[0275] Agent program resource usage (measured on an embedded platform with ARM Cortex-A53 1.2GHz / 512MB RAM):

[0276] - In idle state (TLS connection maintenance + heartbeat): memory usage is approximately 8-12MB, CPU utilization is <0.5%.

[0277] - Single active SSH shell session: Memory usage approximately 15-20MB, CPU utilization 1-3%

[0278] - 5 concurrent active sessions (shell + SFTP): Memory usage approximately 25-35MB, CPU utilization 5-10%

[0279] The resource consumption mentioned above is far lower than that of typical VPN client solutions (OpenVPN typically uses a baseline of 30-50MB of memory), making it suitable for long-term operation on resource-constrained embedded computing platforms.

[0280] Concurrent session capacity: On a single TLS-PSK connection, the number of concurrent SSH sessions supported in this embodiment is theoretically limited by the 32-bit space of StreamID (approximately 4.2 billion), and practically limited by the number of file descriptors on the platform where the agent program resides (each session occupies one file descriptor for a TCP connection). In a typical embedded Linux system (default file descriptor limit of 1024), the theoretical maximum number of concurrent sessions is approximately 1000.

[0281] Reconnection recovery time: In scenarios of momentary network interruption (such as WiFi AP switching, with an interruption duration of 3-5 seconds), the agent program typically completes reconnection and re-registration within approximately 1-2 seconds after the disconnection (corresponding to a first retry waiting time of approximately 0.5-1 seconds). In scenarios of network recovery after a prolonged interruption (such as cellular signal loss for several minutes), the waiting time gradually increases to a maximum of 60 seconds, and the agent program restores the connection within 30-60 seconds after the signal is restored.

[0282] Please see Figure 7 The following three typical application scenarios further illustrate the practical application of this invention.

[0283] Scenario 1: Operation and maintenance of a chain restaurant's food delivery robot cluster

[0284] A chain restaurant has deployed 3 food delivery robots in each of its 20 stores (60 robots in total). Each store uses an independent broadband network, and the robots have no public IP address within the store's intranet. The robot manufacturer's technical support team, the restaurant company's IT department, and a third-party maintenance company all need to perform maintenance on the robots separately.

[0285] Deployment plan: Deploy a gateway server in the cloud (public cloud virtual server) and configure 60 client entries (each robot has a unique hostname and PSK). Each of the three robots in each store runs an agent program, connecting to the gateway server via the store's broadband (outbound TCP to the cloud port 8443).

[0286] Operation and maintenance methods:

[0287] - Manufacturer engineer performs firmware upgrade: `ssh firmware@store05-robot02 -p 2222`

[0288] - The headquarters IT administrator checks the robot's status: `ssh monitor@store12-robot01 -p 2222`

[0289] - Third-party maintenance personnel urgently troubleshooting: `ssh repair@store18-robot03 -p 2222`

[0290] Each operations and maintenance (O&M) personnel uses their familiar SSH client to simultaneously connect to different robots in different stores. All sessions are multiplexed and transmitted over their respective single TLS connections via StreamID, without interference. The gateway server can centrally record the login time, source IP, target robot, and operation duration of all O&M sessions, enabling complete audit trails.

[0291] Scenario 2: Remote Safety Maintenance of Hospital Ward Disinfection Robots

[0292] A hospital deployed 10 ultraviolet disinfection robots to automatically circulate and disinfect between wards and operating rooms. Due to strict network security policies controlling the hospital network (only outbound HTTPS traffic is allowed), the traditional inbound VPN solution was rejected by the hospital's IT department.

[0293] Deployment Scheme: The gateway server's agent program listens on port 443 (instead of 8443). When the agent program connects via TLS-PSK, it presents standard TLS traffic (port 443), indistinguishable from HTTPS traffic at the network layer. The robot agent program connects to the gateway server's port 443 via the hospital's WiFi network, bypassing hospital firewall restrictions. Technicians from the robot manufacturer can access any robot remotely for diagnostics, log collection, and software updates via the gateway server's SSH port (2222). The entire session is encrypted, and the hospital's IT department does not need to open any inbound ports.

[0294] Scenario 3: Centralized Management of Warehouse Logistics Robots Across Multiple Locations

[0295] A logistics company has deployed 50 autonomous mobile robots (AMRs) in each of three different city warehousing centers, totaling 150 robots. Each warehousing center uses independent network infrastructure and an ISP. The logistics company has a centralized robot operation and maintenance center to manage all 150 robots.

[0296] Deployment Plan: Deploy a gateway server (configured with a public IP address) in the operations center's data center, and whitelist all 150 robots. Each warehouse's robot agent program connects to this gateway server via its respective ISP network. Operations center engineers can directly SSH into port 2222 of the gateway server from within the local area network, specifying the target robot using the format `user@city-warehouse-robotNN`. A single gateway server can manage all robots distributed across multiple cities, eliminating the need to deploy jump servers or VPN gateways in each warehouse.

[0297] The above description represents a preferred embodiment of the present invention. It should be noted that any modifications, equivalent substitutions, or improvements made by those skilled in the art within the spirit and principles of the present invention should be included within the scope of protection of the present invention. For example:

[0298] - The magic number "SGHW" in the frame protocol can be replaced by different fixed identifier strings;

[0299] - The registration verification hash algorithm is not limited to SHA256; other cryptographic hash functions such as SHA-3 and BLAKE2 can be used.

[0300] - TLS-PSK can be replaced with the External PSK mode of TLS 1.3 or the Raw Public Key (RPK) authentication mode;

[0301] - The connection between the agent and the local SSH service is not limited to TCP connections; it can also use the Unix DomainSocket method.

[0302] - The configuration file format is not limited to YAML; TOML, JSON, or other structured configuration formats can also be used.

[0303] - The gateway server can be horizontally scaled to a multi-instance cluster deployment, working with a load balancer to distribute agent connections and SSH connections for operations and maintenance personnel.

Claims

1. A remote operation and maintenance method for service robots, characterized in that, Including the following steps: S1: Deploy an agent program on the service robot. The agent program actively initiates an encrypted connection request to the gateway server deployed in a publicly accessible environment via the TLS-PSK protocol, and uses the hostname of the service robot as the PSK identity identifier. S2: During the TLS handshake phase, the gateway server searches for the corresponding pre-shared key from the pre-configured client whitelist based on the identity identifier to complete the establishment of the transport layer encrypted channel; S3: After the encrypted channel is established, the agent program sends a registration frame to the gateway server within a preset registration timeout period. The registration frame contains the hostname and a first verification hash value, which is obtained by performing a hash operation on the combination of the hostname and the pre-shared key. S4: The gateway server receives the registration frame, extracts the hostname, retrieves the pre-shared key corresponding to the hostname in the local whitelist configuration based on the hostname, calculates a second verification hash value for the combination of the hostname and the local pre-shared key using the same hash operation, and compares the second verification hash value with the first verification hash value; if they match, the hostname is bound to the encrypted connection, the registration of the proxy program is completed, and a registration success response is returned to the proxy program; if they do not match or no valid registration frame is received within the preset registration timeout period, the encrypted connection is disconnected. S5: The gateway server listens for connection requests from maintenance personnel on the standard SSH port and receives SSH connections initiated by maintenance personnel through a standard SSH client in the format of "username@robot hostname"; S6: The gateway server parses the target robot hostname from the username field of the SSH connection, searches for the corresponding encrypted connection of the agent program in the registered agent program connection table, sends a session channel establishment request to the agent program through the encrypted connection, and assigns a unique session stream identifier to this session; S7: After receiving the session channel establishment request, the agent program establishes a TCP connection with the local SSH service process of the service robot according to the address information specified in the request, binds the TCP connection with the session flow identifier, and returns a successful channel establishment response to the gateway server. S8: The gateway server transparently forwards the authentication information of the SSH client of the operation and maintenance personnel to the SSH service process on the local side of the service robot for authentication through the encrypted connection, using the session flow identifier as the identifier, and returns the authentication result to the operation and maintenance personnel; S9: After authentication, the gateway server will forward the session channel data of the SSH client of the operation and maintenance personnel and the TCP connection data of the agent program in a two-way transparent manner through the encrypted connection. All data frames belonging to the same session carry the session stream identifier, so as to realize the remote and secure operation and maintenance of the service robot by the operation and maintenance personnel.

2. The remote operation and maintenance method for service robots as described in claim 1, characterized in that, The hash operation described in steps S3 and S4 is the SHA256 hash algorithm. The first verification hash value is calculated as SHA256(hostname ||PSK), where hostname is the hostname string of the service robot, PSK is the byte sequence of the pre-shared key, and || represents string concatenation operation.

3. The remote operation and maintenance method for service robots as described in claim 1, characterized in that, In step S1, during the handshake process of the TLS-PSK protocol, the proxy program sends the hostname as the value of the PSK identity field to the gateway server; The gateway server uses the PSK identity callback function to search for the corresponding pre-shared key byte sequence from the pre-configured client whitelist using the hostname as an index, thereby completing the negotiation of the pre-shared key and the establishment of the encrypted channel; the pre-shared key itself is not transmitted in the network.

4. The remote operation and maintenance method for service robots as described in claim 1, characterized in that, The connection lifecycle between the proxy program and the gateway server includes three phases: the unregistered phase, which is the state where the TLS encrypted channel has been established but a valid registration frame has not yet been received, and the gateway server starts a registration timeout timer; if registration is not completed within the timeout period, the connection is actively disconnected; the registered phase, which is the state where the proxy program has completed application layer identity registration and maintains connection activity through a heartbeat mechanism; and the invalid phase, which is the state where the heartbeat timeout occurs or the connection is abnormally disconnected, and the gateway server automatically cleans up the registration information and related session resources of the proxy program.

5. The remote operation and maintenance method for service robots as described in claim 1, characterized in that, After detecting that the encrypted connection with the gateway server has been broken, the proxy program automatically performs a reconnection operation. The reconnection operation adopts an exponential backoff algorithm: the waiting time for the nth reconnection attempt is T(n) = min(T_initial×k^(n-1), T_max), where T_initial is the initial waiting time, k is the backoff multiplier, and T_max is the maximum waiting time limit. Random jitter is added to the waiting time calculated each time to avoid congestion caused by multiple agent programs reconnecting at the same time.

6. The remote operation and maintenance method for service robots as described in claim 1, characterized in that, In steps S6 to S9, the allocation and usage mechanism of the session flow identifier is as follows: when the gateway server needs to establish a channel for a new SSH session, it allocates a unique identifier that is not currently in use from the session flow identifier space; the identifier is carried in the session establishment frame sent to the agent program; after the agent program establishes a TCP connection to the local SSH service, it binds the TCP connection to the identifier. Subsequently, all uplink and downlink data in this SSH session are transmitted via session data frames carrying the same session stream identifier; when the session ends, the peer is notified to release the identifier and the corresponding TCP connection resources via a session close frame.

7. A remote operation and maintenance system for service robots, characterized in that, include: A gateway server, deployed in a publicly accessible network environment, includes: The TLS-PSK listening module is used to receive encrypted connection requests initiated by the agent programs deployed on each service robot. During the TLS handshake phase, it searches for the corresponding pre-shared key based on the PSK identity provided by the agent program to establish a transport layer encrypted channel. The agent management module is used to manage the connection status of registered agent programs, maintain a mapping table of hostnames to encrypted connections, and perform registration verification, heartbeat detection, and connection lifecycle management. The SSH proxy module is used to listen for standard SSH connection requests from operations and maintenance personnel, parse the target robot hostname from the username field, and bridge the SSH authentication and session channel data to the corresponding proxy program for encrypted connection. The frame protocol encoding / decoding module is used to encode and decode the communication data between the gateway server and the agent program according to a preset binary frame protocol. At least one agent program is deployed on the embedded computing unit of each service robot, said agent program comprising: The TLS-PSK connection module is used to proactively initiate an encrypted connection to the gateway server using the hostname of the service robot as the PSK identity identifier. The registration module is used to send a registration request frame containing the hostname and verification hash value to the gateway server after the encrypted channel is established, so as to complete the application layer identity registration. The SSH bridging module is used to receive a session channel establishment request from the gateway server, establish a TCP connection with the SSH service process on the local side of the service robot, and forward session data bidirectionally between the encrypted connection and the local TCP connection. The heartbeat maintenance module is used to periodically send heartbeat frames to the gateway server to maintain connection activity and automatically reconnect when the connection is lost. The gateway server and the agent program communicate via a custom binary frame protocol. The frame structure of the binary frame protocol includes a fixed header and a variable-length payload. The fixed header includes at least: a magic number field, a protocol version field, a frame type field, a session stream identifier field, and a payload length field. The session stream identifier field is used to uniquely identify and distinguish multiple concurrent independent SSH sessions on the same TLS-PSK encrypted connection.

8. The remote operation and maintenance system for service robots as described in claim 7, characterized in that, The frame types of the binary frame protocol include at least the following: a registration frame, used by the agent to send a registration request to the gateway server; a registration response frame, used by the gateway server to return a registration result; a heartbeat frame, used by the agent to maintain connection activity; a heartbeat response frame, used by the gateway server to confirm the heartbeat; a session establishment frame, used by the gateway server to request the agent to establish a connection to the local SSH service; a session establishment response frame, used by the agent to confirm that the session channel has been successfully established; a session data frame, used for bidirectional transmission of SSH session channel data; a session close frame, used to notify the peer to close a specified session stream; and an error frame, used to transmit structured error information.

9. The remote operation and maintenance system for service robots as described in claim 8, characterized in that, The fixed header length of the binary frame protocol is 14 bytes, specifically including: a 4-byte magic number field, with a fixed identifier string encoded in ASCII, used for frame boundary identification and protocol validity verification; a 1-byte version field, used to identify the protocol version to support backward compatibility; a 1-byte frame type field, used to distinguish different frame types; a 4-byte session stream identifier field, used to identify the SSH session to which the frame belongs, wherein the session stream identifier field value of the control frame is zero; and a 4-byte payload length field, representing the number of bytes of the subsequent variable-length payload in unsigned big-endian integer form.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is executed by a processor as the remote operation and maintenance method for service robots as described in claim 1.

Images