A method and system for implementing server operation and maintenance management based on an SSH protocol

Abstract

The application discloses a method and system for realizing server operation and maintenance management based on an SSH protocol, and the method comprises the following steps: establishing a communication connection with N target servers respectively through the SSH protocol; wherein N is greater than or equal to 1 and is a natural number, the target servers are only pre-installed with a standard SSH server program and do not install any client software related to operation and maintenance monitoring; sending a standard operation and maintenance data collection command to the target servers through the established SSH session, obtaining a standard output stream of the command; analyzing the standard output stream to obtain structured operation and maintenance data; and sending corresponding operation and maintenance operation commands to the target servers according to the structured operation and maintenance data and executing the commands. The application establishes a connection and sends a command by using the SSH protocol, does not need to install any operation and maintenance monitoring client software on the target servers, effectively avoids the complexity and security risks of special Agent deployment, realizes non-intrusive server operation and maintenance management, and simultaneously supports a heterogeneous environment and batch processing.

Description

Technical Field

[0001] This application relates to the field of telecommunications technology, and in particular to a method, system and related equipment for server operation and maintenance management based on the SSH protocol. Background Technology

[0002] Currently, server operation and maintenance management is usually achieved by installing a dedicated agent program on the target server, or by having operation and maintenance personnel remotely log in to each server to perform operations, so as to achieve unified operation and maintenance management of multiple servers.

[0003] Server operation and maintenance management is usually achieved by installing a dedicated agent, relying on out-of-band management or vendor consoles, or manual SSH login. However, these operation and maintenance management methods either require the installation of corresponding clients or servers, are tied to specific hardware or cloud vendors, or are inefficient and untraceable. Summary of the Invention

[0004] The purpose of this application is to provide a method, system, and related equipment for server operation and maintenance management based on the SSH protocol. It can establish a connection and send commands by using the SSH protocol without installing any operation and maintenance monitoring client software on the target server or deploying any external script files. This effectively avoids the complexity and security risks of deploying a dedicated agent, achieves non-intrusive server operation and maintenance management, and supports heterogeneous environments and batch processing.

[0005] Firstly, this application provides a server operation and maintenance management method based on the SSH protocol, including the following steps: Communication connections are established with N target servers via the SSH protocol; where N≥1 and N is a natural number, the target servers are pre-installed with only the standard SSH server program, and no operation and maintenance monitoring related client software or external script files are installed; Send a standard operation and maintenance data collection command to the target server through the established SSH session, and obtain the standard output stream of the command; The standard output stream is parsed to obtain structured operation and maintenance data; Based on the structured operation and maintenance data, execute the corresponding operation and maintenance command on the target server.

[0006] Furthermore, establishing communication connections with N target servers via the SSH protocol includes: Perform transport layer reachability detection on the target server's address and SSH port, and distinguish the port status type, which includes port unreachable, port reachable but authentication failed, and port reachable and authentication successful; Based on the port status type, an SSH client connection to the target server is established using a unified timeout policy. The SSH client connection is used to perform metric collection, connectivity verification, container operations, and storage and network configuration operations.

[0007] Furthermore, the step of sending a standard operation and maintenance data collection command to the target server and obtaining the standard output stream of the command includes: Send a standard operation and maintenance data collection command sequence and output multiple segments of content in an agreed order, with each segment separated by a unique delimiter. Obtain the complete standard output stream containing multiple segments and delimiters; The standard output stream is divided into several segments based on the delimiter to be parsed and structured operation and maintenance data is obtained.

[0008] Furthermore, the sequence of sending standard operation and maintenance data collection commands outputs multiple segments of content in a pre-defined order, including: Read the cumulative CPU count in / proc / stat at the first point in time and output the first CPU segment; Read network statistics from / proc / net / dev at the first time point and output the first network segment; Perform a fixed-duration sleep; At the second time point, read the cumulative CPU count in / proc / stat and output the second CPU segment; At the second time point, read network statistics from / proc / net / dev and output the second network segment; The first CPU segment, the first network segment, the second CPU segment, and the second network segment are separated by a unique delimiter, so that the local system can calculate the CPU utilization based on the count difference between the first CPU segment and the second CPU segment, and calculate the network throughput rate based on the statistical difference between the first network segment and the second network segment.

[0009] Furthermore, the step of sending the standard operation and maintenance data collection command sequence and outputting multiple segments of content in a pre-defined order also includes: Read data from / proc / meminfo and output memory segments; The JSON output mode for executing the ip command outputs the network interface card and address range. Execute the df command to output the disk usage segments; Detect the existence of the dedicated hardware command-line tool; if it exists, output the dedicated hardware segment; otherwise, output an empty identifier. The memory segment, network card and address segment, disk usage segment, dedicated hardware segment or empty identifier are all defined by a unique separator to be parsed locally as structured operation and maintenance data.

[0010] Furthermore, the step of sending a standard operation and maintenance data collection command to the target server and obtaining the standard output stream of the command also includes: The full collection command set is divided into multiple independent sub-command modules, including a system resource collection sub-command module, a disk usage collection sub-command module, and a dedicated hardware detection sub-command module. Configure multiple API endpoints, each of which triggers a corresponding sub-command module to execute on the target server via an SSH session and returns the standard output stream of the sub-command module; By calling the corresponding API endpoint through the operation terminal, multiple sub-command modules are triggered to execute in parallel, and the execution task of each sub-command module is configured with an independent timeout. The operation terminal is configured with an integrated program packaged and generated based on the Tauri framework.

[0011] Further, a standard operation and maintenance data collection command is sent to the target server, and the standard output stream of the command is obtained, including: Send a container runtime probe command to the target server; Probe the availability of the Docker container runtime and the podman container runtime in turn; Select an available container runtime based on the detection results; Send a command to the target server, causing the target server to output a list of containers in JSON line format using the selected container runtime; Insert runtime identifier rows and list body boundary markers into the output stream so that the container data can be segmented and parsed locally based on the boundary markers.

[0012] Furthermore, the parsing of the standard output stream to obtain structured operation and maintenance data includes: The output stream is segmented based on the runtime identifier row and the list body boundary marker; Perform line-by-line JSON deserialization on the container list data; Implement custom deserialization for port mapping fields, compatible with both string and object array formats; The various JSON formats are unified into a single display structure for subsequent operation and maintenance.

[0013] Furthermore, the step of executing maintenance operation commands on the target server based on the structured maintenance data includes: Receive container operation instructions, wherein the container operation instructions include runtime name, container ID, and operation type; Construct a remote command protected by command line escape sequences based on the runtime name and the container ID; The remote commands are executed on the target server via the SSH session, wherein the remote commands include container start commands, container stop commands, and container delete commands; Return command output and exit status information.

[0014] Further, a standard operation and maintenance data collection command is sent to the target server, and the standard output stream of the command is obtained, including: Send the lsblk command to the target server to obtain the block device tree data in JSON output mode; The block device tree data is deserialized locally. Recursively check the mount point field of block devices to filter out unmounted block device nodes; Based on the unmounted block device nodes, partition identifiers and formatting identifiers are generated for subsequent operation and maintenance.

[0015] Furthermore, the step of executing maintenance operation commands on the target server based on the structured maintenance data includes: Verify the device path parameters; The partitioning operation command is executed on the target server via the SSH session. Execute formatting commands on the target server via the SSH session; The mount operation command is executed on the target server via the SSH session; Returns the operation results and the newly generated device path information.

[0016] Furthermore, the step of executing maintenance operation commands on the target server based on the structured maintenance data also includes: The network configuration parameters submitted by the operator are received, including network interface card name, working mode, static address, gateway, and DNS list. The network configuration parameters are locally validated, including network card naming character set validation, loopback interface operation prohibition validation, and address format validation. The verified network configuration parameters are Base64 encoded. The Base64 encoded network configuration parameters are used as command parameters and assembled into a directly executable configuration command. The network configuration parameters are configured on the target server via the SSH session. The network configuration is applied by invoking network management stack commands through the configuration command.

[0017] Secondly, this application also provides a management terminal device for operation and maintenance based on the SSH protocol, including: The first unit is used to establish communication connections with N target servers via the SSH protocol; where N≥1 and N is a natural number, the target servers are pre-installed with only standard SSH server programs and have not installed any operation and maintenance monitoring related client software or deployed any external script files; The second unit is used to send standard operation and maintenance data collection commands to the target server via an SSH session and obtain the standard output stream of the commands. The third unit is used to parse the standard output stream to obtain structured operation and maintenance data; The fourth unit is used to execute operation and maintenance commands on the target server based on the structured operation and maintenance data.

[0018] Furthermore, the first unit is also used for: Perform transport layer reachability detection on the target server's address and SSH port, and distinguish the port status type, which includes port unreachable, port reachable but authentication failed, and port reachable and authentication successful; Based on the port status type, an SSH client connection to the target server is established using a unified timeout policy. The SSH client connection is used to perform metric collection, connectivity verification, container operations, and storage and network configuration operations.

[0019] Furthermore, the second unit is also used for: The full collection command set is divided into multiple independent sub-command modules, including a system resource collection sub-command module, a disk usage collection sub-command module, and a dedicated hardware detection sub-command module. Configure multiple API endpoints, each of which triggers a corresponding sub-command module to execute on the target server via an SSH session and returns the standard output stream of the sub-command module; By calling the corresponding API endpoint through the operation terminal, multiple sub-command modules are triggered to execute in parallel, and the execution task of each sub-command module is configured with an independent timeout. The operation terminal is configured with an integrated program packaged and generated based on the Tauri framework.

[0020] Thirdly, this application also provides a server operation and maintenance management system based on the SSH protocol, used to execute the aforementioned server operation and maintenance management method based on the SSH protocol, including: The management service module provides a RESTful API interface, maintains a list of target servers and connection parameters, establishes SSH sessions with target servers through an SSH client library, sends operation and maintenance data collection commands to the target servers and parses the standard output stream of the commands, and executes operation and maintenance operations according to the operation instructions. The target server runs a Unix-like operating system, provides SSH service, and comes pre-installed with a general toolchain including lsblk, ip, and df. It receives and executes operation and maintenance data collection commands and operation and maintenance operation commands issued by the management service module. The target server only comes pre-installed with a standard SSH server program and does not have any operation and maintenance monitoring related client software installed or any external script files deployed. The operation terminal is used to call the RESTful API interface of the management terminal service module through an integrated program packaged based on the Tauri framework, display operation and maintenance data, and receive operation instructions input by the operator.

[0021] Furthermore, the management service module includes: The SSH access unit is used to perform transport layer reachability detection on the target server's address and SSH port, and establish an SSH client connection with the target server using a unified timeout policy. The indicator acquisition unit is used to connect to the target server via the SSH client and send an indicator acquisition command sequence, segment the standard output stream of the command according to the delimiter, perform double sampling difference calculation, and parse to obtain structured indicator data. The container management unit is used to connect to the adaptive detection container runtime via the SSH client, parse the container list data in JSON line format, and perform container lifecycle operations; The network configuration unit is used to perform local validity verification of network configuration parameters, and uses Base64 encoded network configuration parameters as command parameters to assemble them into directly executable configuration commands to call the network management stack to apply the configuration. The storage operation and maintenance unit is used to connect and parse block device tree data through the SSH client, identify unmounted devices, and perform partitioning, formatting, and mounting operations.

[0022] Furthermore, the management service module also includes: An embedded relational database is used to store the target server identifier, connection address, port, username, and authentication information. The RESTful API interface unit provides interfaces for server CRUD operations, connectivity testing, metric collection, container operation, storage maintenance, and network configuration.

[0023] Fourthly, this application also provides a computer-readable storage medium storing computer-readable instructions thereon, which are executed by a processor to implement server operation and maintenance management based on the SSH protocol as described above.

[0024] Fifthly, this application also provides an apparatus, the apparatus comprising: One or more processors; and A memory storing computer-readable instructions, which, when executed, cause the processor to perform server operation and maintenance management operations as described above based on the SSH protocol.

[0025] Compared with the prior art, this application has the following advantages: This application provides a server operation and maintenance management method and system. The method includes: establishing a communication connection with a target server via the SSH protocol, sending a standard operation and maintenance data collection command to the target server and obtaining the standard output stream of the command, parsing it into structured data and performing operation and maintenance operations. By using the SSH protocol to establish a connection and send commands, it is not necessary to install any operation and maintenance monitoring client software on the target server or deploy any external script files, effectively avoiding the complexity and security risks of deploying a dedicated agent, realizing non-intrusive server operation and maintenance management, and supporting heterogeneous environments and batch processing. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a server operation and maintenance management method based on the SSH protocol, provided as an embodiment of this application.

[0027] Figure 2 This is a schematic diagram of the structure of a server operation and maintenance management device based on the SSH protocol, provided as an embodiment of this application.

[0028] Figure 3 This is a schematic diagram of the structure of a server operation and maintenance management system based on the SSH protocol, provided as an embodiment of this application.

[0029] Figure 4 This is a schematic diagram of the structure of a server operation and maintenance management system based on the SSH protocol, provided as an embodiment of this application. Detailed Implementation

[0030] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0031] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] For ease of understanding, the following explains some key terms in the embodiments of this application: SSH (Secure Shell Protocol) is an encrypted network transmission protocol used to securely execute network services in insecure networks. It establishes a secure, encrypted channel between the client and server to enable remote command-line operations, file transfers, and other functions, ensuring the confidentiality and integrity of data transmission.

[0033] The target server refers to a remote computer or virtual machine that requires operation and maintenance management. In this embodiment, the target server is pre-installed with only the standard SSH server program, without the need to install any additional operation and maintenance monitoring-related client software, thereby reducing deployment complexity and resource consumption.

[0034] An SSH session refers to an interactive or non-interactive communication connection established between a client and a target server via the SSH protocol. This session provides a secure channel that allows the client to send commands to the server and receive the results of their execution.

[0035] Traditional server operation and maintenance management methods typically rely on installing dedicated agent programs on the target servers or manually logging in remotely to operate each server individually. These methods have limitations such as intrusive client software deployment, dependence on specific hardware or cloud vendors, low operational efficiency, and difficulty in traceability, failing to achieve unified, efficient, and non-intrusive operation and maintenance management of multiple servers.

[0036] Based on this, such as Figure 1 As shown, this application proposes a server operation and maintenance management method based on the SSH protocol.

[0037] S100. Establish communication connections with N target servers via the SSH protocol. Where N ≥ 1, and N is a natural number. Each target server is pre-installed with a standard SSH server program and has no client software related to operation and maintenance monitoring installed, nor any external script files deployed.

[0038] One approach is for the management console to directly attempt to establish an SSH connection with the target server using a pre-defined IP address, port, and authentication information (such as username, password, or key). For example, a list of servers can be maintained, and the console can iterate through the list, attempting to initiate an SSH connection request for each server. Another approach is to pre-configure a connection pool, retrieving an available SSH connection from the pool when communication with the target server is needed.

[0039] S200: Through the established SSH session, send a standard operation and maintenance data collection command to the target server and obtain the standard output stream of the command.

[0040] One implementation approach is for the management device to send a single command string containing all the data to be collected to the target server via an SSH session. For example, this command string could execute commands such as `top -bn1`, `free -m`, and `df -h` sequentially, writing the output of all commands continuously to the standard output stream. Another approach is for the management device to send multiple independent standard operational data collection commands to the target server sequentially, sending one command at a time, waiting for its execution to complete and its standard output stream to be retrieved, before sending the next command. For example, it could first send `cat / proc / meminfo` to retrieve memory information, wait for its output, and then send `ip -json a` to retrieve network interface information.

[0041] S300: Parse the standard output stream to obtain structured operation and maintenance data.

[0042] One implementation approach is for the management device to parse the acquired standard output stream using a fixed pattern matching method. For example, it can extract data from specific rows or fields of the output stream using preset regular expressions or string searches. Another implementation approach is for the management device to read the standard output stream line by line and perform basic checks and data extraction based on the content of each line.

[0043] S400. Based on the structured operation and maintenance data, execute the corresponding operation and maintenance command on the target server.

[0044] As one implementation method, after acquiring and parsing structured operation and maintenance data, the management device can directly construct and send corresponding operation and maintenance commands to the target server for execution based on preset rules or operator input. For example, if the structured data indicates that a certain service is not running, it can directly send `systemctl start`.<service_name> Order.

[0045] This embodiment simplifies the deployment process and reduces operational costs by utilizing the existing standard SSH server program and general toolchain on the target server, thus avoiding the need to install dedicated agent programs or client software on the target server.

[0046] In some implementations, establishing communication connections with N target servers via the SSH protocol includes: Perform transport layer reachability detection on the target server's address and SSH port, and distinguish the port status type, which includes port unreachable, port reachable but authentication failed, and port reachable and authentication successful; Based on the port status type, an SSH client connection to the target server is established using a unified timeout policy. The SSH client connection is used to perform metric collection, connectivity verification, container operations, and storage and network configuration operations.

[0047] As one implementation method, when establishing communication connections with N target servers via the SSH protocol, a transport layer reachability check is first performed on the target server's address and SSH port. This check aims to confirm whether the target server's network address and SSH service port are accessible at the network transport layer. For example, reachability can be determined by sending a TCP SYN packet to the target server's SSH port and listening for a SYN-ACK response. Based on the check results, the system can distinguish between various port status types, including port unreachable, port reachable but authentication failed, and port reachable and authentication successful. Port unreachable typically indicates a network outage or that the SSH service on the target server is not running; port reachable but authentication failed indicates a normal network connection but incorrect authentication information (such as username, password, or key); and port reachable and authentication successful means a valid SSH session can be established. Based on these clearly defined port status types, the system uses a unified timeout policy to establish SSH client connections with the target server. This unified timeout policy ensures a preset maximum waiting time at each stage of the connection attempt (such as TCP handshake, SSH protocol negotiation, user authentication, etc.), avoiding indefinite waiting due to network latency or slow server response, thereby improving the efficiency and stability of connection establishment. Once the SSH client connection is successfully established, it will serve as the foundational channel for all subsequent operational and maintenance operations, used to perform various management tasks such as metric collection, connectivity verification, container operations, storage and network configuration operations.

[0048] In some implementations, sending a standard operation and maintenance data collection command to the target server and obtaining the standard output stream of the command includes: Send a standard operation and maintenance data collection command sequence and output multiple segments of content in an agreed order, with each segment separated by a unique delimiter. Obtain the complete standard output stream containing multiple segments and delimiters; The standard output stream is divided into several segments based on the delimiter to be parsed and structured operation and maintenance data is obtained.

[0049] As one implementation method, to ensure that the operational data obtained from the target server can be clearly identified and effectively distinguished, the management end can construct a sequence containing multiple standard operational data collection commands. When this command sequence is executed on the target server, it will output different types or different time points of operational data in a preset order. After each piece of content is output, or between different types of data, a pre-agreed string that rarely appears in normal command output will be inserted as a unique delimiter.

[0050] Once the management console sends the constructed command sequence to the target server via an SSH session, the SSH client continuously listens for and collects all standard output returned by the target server. This output stream will be a continuous text data stream, containing not only the actual operational data generated by the various standard operational data collection commands, but also all unique delimiters inserted by the management console into the command sequence. The SSH client is responsible for completely capturing all output from the start to the end of command execution and returning it to the management console as a single, unprocessed, raw standard output stream.

[0051] Based on this, after receiving the complete standard output stream, the management end uses a pre-agreed unique delimiter as the segmentation basis. Through string processing functions or regular expressions, the entire standard output stream is decomposed into multiple independent text segments. Each segment corresponds to specific operational data generated by one or a group of commands in the command sequence. For example, one segment might contain CPU statistics, while another might contain memory information.

[0052] In some implementations, the sequence of sending standard operation and maintenance data collection commands outputs multiple segments of content in a pre-defined order, including: Read the cumulative CPU count in / proc / stat at the first point in time and output the first CPU segment; Read network statistics from / proc / net / dev at the first time point and output the first network segment; Perform a fixed-duration sleep; At the second time point, read the cumulative CPU count in / proc / stat and output the second CPU segment; At the second time point, read network statistics from / proc / net / dev and output the second network segment; The first CPU segment, the first network segment, the second CPU segment, and the second network segment are separated by a unique delimiter, so that the local system can calculate the CPU utilization based on the count difference between the first CPU segment and the second CPU segment, and calculate the network throughput rate based on the statistical difference between the first network segment and the second network segment.

[0053] As one implementation, the first CPU segment is output by reading the cumulative CPU count from ` / proc / stat` at the first point in time. ` / proc / stat` is a virtual file in Linux that provides statistics about system and process activity, including cumulative CPU usage time (e.g., user mode, system mode, idle mode). These counts are accumulated values ​​since system startup. Reading these cumulative counts at the first point in time aims to obtain a baseline snapshot as the starting point for subsequent differential calculations. The first CPU segment output is the raw CPU statistics obtained from the ` / proc / stat` file at that moment.

[0054] Simultaneously, network statistics are read from ` / proc / net / dev` at the first point in time, and the first network segment is output. ` / proc / net / dev` is another virtual file in the Linux system that provides statistical information about network devices (such as network interface cards), including the number of bytes received and sent, the number of packets, and the number of errors. These statistics are also cumulative values ​​since system startup. Reading this data at the first point in time aims to obtain a baseline snapshot of network activity. The first network segment output is the raw network statistics obtained from the ` / proc / net / dev` file at this moment.

[0055] After the initial data acquisition, the system will execute a pre-defined, fixed-duration sleep period. The purpose of this sleep is to create a defined time interval between two data acquisitions, thus providing a known time reference for subsequent differential calculations. For example, the sleep period can be 1 second, 2 seconds, or 5 seconds, depending on the required sampling accuracy and system load.

[0056] After a fixed-duration sleep period, the system reads the cumulative CPU count from ` / proc / stat` again at a second time point and outputs the second CPU segment. The count obtained at this time is the cumulative value after a period of operation. The output second CPU segment is the raw CPU statistics obtained from the ` / proc / stat` file at this moment.

[0057] Similarly, at the second time point, network statistics are read from ` / proc / net / dev`, and the second network segment is output. The statistics obtained at this time are the cumulative values ​​after a period of operation. The output second network segment is the raw network statistics obtained from the ` / proc / net / dev` file at this moment.

[0058] To ensure accurate differentiation and extraction of raw data from different time points and of different types within a single standard output stream, the first CPU segment, the first network segment, the second CPU segment, and the second network segment are delimited by unique delimiters. A pre-agreed, unique delimiter that does not appear in the data content is inserted between each data segment. For example, a specific string can be used as the delimiter so that the local parser can reliably segment the entire output stream into independent segments.

[0059] On the local management end, after receiving the output stream containing the cumulative CPU counts at two time points, the parsing program extracts the relevant counts from the first and second CPU segments. By calculating the difference between the count at the second time point and the count at the first time point, and combining this with the known fixed sleep duration between the two data collections, the CPU utilization rate within that time period can be accurately calculated.

[0060] Similarly, the local parsing program extracts network statistics (such as the number of bytes received / sent) from the first and second network segments. By calculating the difference between the statistics at the second time point and the statistics at the first time point, and combining this with the known fixed sleep duration between the two collections, the network throughput rate (e.g., the number of bytes received / sent per second) during that time period can be accurately calculated.

[0061] In some implementations, the step of sending a standard operation and maintenance data collection command sequence and outputting multiple segments of content in a predetermined order further includes: Read data from / proc / meminfo and output memory segments; The JSON output mode for executing the ip command outputs the network interface card and address range. Execute the df command to output the disk usage segments; Detect the existence of the dedicated hardware command-line tool; if it exists, output the dedicated hardware segment; otherwise, output an empty identifier. The memory segment, network card and address segment, disk usage segment, dedicated hardware segment or empty identifier are all defined by a unique separator to be parsed locally as structured operation and maintenance data.

[0062] As one implementation, reading data from ` / proc / meminfo` and outputting memory segments aims to obtain information about the target server's memory usage. ` / proc / meminfo` is a virtual file in Linux systems that provides memory usage information, containing detailed data such as total system memory, available memory, cache, and swap space. It is one of the key indicators for evaluating server performance and health. The management console can execute the `cat / proc / meminfo` command on the target server via an SSH session, capturing the standard output stream of this command and treating it as a memory segment. To ensure the accuracy of subsequent parsing, this memory segment should be delimited from other data segments using a unique, predefined delimiter.

[0063] Executing the `ip` command with JSON output mode and displaying the network interface and address range is crucial for gaining a comprehensive understanding of the target server's network configuration and interface status. The `ip` command is a powerful tool in Linux systems for displaying and configuring network parameters such as network devices, routes, policy-based routing, and tunnels. By specifying the JSON output mode, such as `ip -json addr show`, structured network interface information can be obtained, including network interface name, MAC address, IP address (IPv4 and IPv6), subnet mask, broadcast address, and interface status. The management end executes such commands on the target server via an SSH session, capturing the standard JSON output stream and using it as the network interface and address range. This range also needs to be uniquely separated from other data ranges using a predefined delimiter for local structured parsing.

[0064] Executing the `df` command and outputting disk usage segments aims to monitor the storage resource usage of a target server and promptly identify potential problems such as insufficient disk space. The `df` command (disk free) displays the disk space usage of a Linux file system, including the file system name, total capacity, used space, available space, percentage of usage, and mount point. The management console executes the `df -P` command on the target server via an SSH session, capturing its standard output stream and using it as a disk usage segment. For ease of subsequent parsing, this segment should also be delimited by a unique predefined delimiter.

[0065] This function detects the existence of dedicated hardware command-line tools. If a dedicated hardware segment exists, it outputs the dedicated hardware section; otherwise, it outputs an empty identifier. The aim is to dynamically collect relevant dedicated hardware information based on the target server's hardware configuration, improving the comprehensiveness and relevance of operational data. Dedicated hardware (such as RAID cards, GPUs, BMCs, etc.) typically has specific command-line tools (such as `megacli`, `nvidia-smi`, `ipmitool`, etc.) to query its status, configuration, or logs. The management side can execute a series of `which` or `command -v` commands on the target server via an SSH session to detect the existence of specific dedicated hardware command-line tools. If a tool exists, its corresponding command is executed, and its standard output stream is used as the dedicated hardware segment. If all preset dedicated hardware tools are not found, a predefined "empty identifier," such as a specific string or a blank line, is output. Each dedicated hardware segment or empty identifier must also be delimited by a unique preset separator.

[0066] Using a unique, pre-defined delimiter to define memory segments, network interface card (NIC) and address segments, disk usage segments, dedicated hardware segments, or empty identifiers is a key mechanism to ensure that the local management terminal can accurately and efficiently segment the raw standard output stream obtained from the target server into independent, parsable data blocks. This allows different types of data to be clearly identified and extracted, and then converted into structured operational data. When constructing the sequence of operational data collection commands to be sent to the target server, a predefined string that does not appear in the normal command output is inserted after or before the output of each command as a delimiter, such as `echo "---SECTION_DELIMITER---"`. After receiving the complete standard output stream, the local management terminal segments the entire output stream into multiple independent segments according to these delimiters, each segment corresponding to a type of operational data, and then performs targeted parsing on each segment.

[0067] In some implementations, sending a standard operation and maintenance data collection command to the target server and obtaining the standard output stream of the command further includes: The full collection command set is divided into multiple independent sub-command modules, including a system resource collection sub-command module, a disk usage collection sub-command module, and a dedicated hardware detection sub-command module. Configure multiple API endpoints, each of which triggers a corresponding sub-command module to execute on the target server via an SSH session and returns the standard output stream of the sub-command module; By calling the corresponding API endpoint through the operation terminal, multiple sub-command modules are triggered to execute in parallel, and the execution task of each sub-command module is configured with an independent timeout. The operation terminal is configured with an integrated program packaged and generated based on the Tauri framework.

[0068] As an implementation approach, to address the complex and diverse needs of operational data collection, this application decomposes the traditional single, massive full-data collection command set into several sub-command modules with single functions and clearly defined responsibilities. For example, it may include a system resource collection sub-command module specifically for collecting system performance indicators such as CPU, memory, and load; a disk usage collection sub-command module for obtaining information such as file system usage and disk I / O; and a dedicated hardware detection sub-command module for querying the status of hardware from specific vendors (such as RAID cards, GPUs, etc.).

[0069] Building upon this, the management service module configures one or more API endpoints for each independent sub-command module. These API endpoints serve as interfaces between external systems (such as operating terminals) and internal data acquisition logic, allowing specific sub-command modules to be triggered via standardized requests (such as RESTful API calls). Upon receiving an API request, the management service module executes the corresponding sub-command module on the target server through an established SSH session, captures the standard output stream of the executed module, and then returns this output stream as part of the API response to the caller.

[0070] Furthermore, the operating terminal itself is an integrated program configured with a packaged version based on the Tauri framework, serving as the interface for users to interact with the operation and maintenance management system. This terminal can simultaneously call multiple API endpoints provided by the management service module according to user needs, thereby triggering multiple sub-command modules to execute in parallel on the target server. To ensure the stability and efficiency of the overall data collection task, each sub-command module's execution task is independently configured with a timeout period. This means that even if a sub-command module remains unresponsive for an extended period due to network latency, high server load, or slow command execution, its execution task will be terminated after the preset timeout period without affecting other parallel executing sub-command modules, thus avoiding overall blockage caused by a single point of failure.

[0071] By breaking down the full data collection command set into multiple independent sub-command modules and configuring an independent API endpoint for each module, this application enables fine-grained management and scheduling of operational data collection tasks. The operation terminal can flexibly select and invoke the corresponding API endpoints according to actual needs, thereby triggering multiple sub-command modules to execute in parallel on the target server. Simultaneously, configuring independent timeouts for each sub-command module's execution task effectively isolates the influence between different collection tasks. Even if a module malfunctions or takes too long, it will not cause the interruption of the entire collection process, thus enhancing the system's robustness and stability. The operation terminal uses an integrated program packaged based on the Tauri framework, providing users with a unified, efficient, and user-friendly interface, further improving the convenience of operational management.

[0072] In some implementations, a standard operation and maintenance data collection command is sent to the target server, and the standard output stream of the command is obtained, including: Send a container runtime probe command to the target server; Probe the availability of the Docker container runtime and the podman container runtime in turn; Select an available container runtime based on the detection results; Send a command to the target server, causing the target server to output a list of containers in JSON line format using the selected container runtime; Insert runtime identifier rows and list body boundary markers into the output stream so that the container data can be segmented and parsed locally based on the boundary markers.

[0073] As one implementation method, to accurately identify the container environment on the target server without pre-installing any client software or external script files, the management console sends specific commands to the target server to detect whether a container runtime is installed. These commands can check the existence of a specific executable file (e.g., `which docker` or `which podman`), or they can attempt to execute diagnostic commands provided by the container runtime (e.g., `docker info` or `podman info`) and analyze the returned results.

[0074] When probing container runtimes, the management console performs availability checks on common container runtimes (such as the Docker container runtime and the Podman container runtime) in a pre-defined priority or order. For example, it might first attempt to probe the Docker container runtime; if it's found to be available, it's used first; if Docker is unavailable, it continues probing the Podman container runtime. Availability checks are typically performed by executing the corresponding runtime commands and checking their exit status codes or standard output.

[0075] After sequentially probing different container runtimes, the management console intelligently selects an available container runtime based on the probing results. For example, if the Docker container runtime is detected as available, Docker is selected; if Docker is unavailable but the Podman container runtime is available, Podman is selected.

[0076] To ensure that the acquired container data has a consistent and easily parsable format, the management system sends a crafted command to the target server. This command instructs the selected container runtime (such as Docker or podman) to output its container list data in JSON line-by-line format. For example, for Docker, the command could be `docker ps --all --format '{{json .}}'`; for podman, the command could be `podman ps --all --format '{{json.}}'`. This JSON line-by-line format ensures that each line is a separate JSON object, simplifying the data parsing process for the management system.

[0077] To further improve the robustness and accuracy of data parsing, the management system instructs the target server to insert specific runtime identifier lines and list body boundary markers into the output stream before or after the container list data is output to the standard output stream. The runtime identifier line explicitly indicates which container runtime generated the currently output container data (e.g., `---RUNTIME:DOCKER---`), while the list body boundary markers (e.g., `---CONTAINER_LIST_START---` and `---CONTAINER_LIST_END---`) clearly define the start and end positions of the container list data.

[0078] In some implementations, parsing the standard output stream to obtain structured operation and maintenance data includes: The output stream is segmented based on the runtime identifier row and the list body boundary marker; Perform line-by-line JSON deserialization on the container list data; Implement custom deserialization for port mapping fields, compatible with both string and object array formats; The various JSON formats are unified into a single display structure for subsequent operation and maintenance.

[0079] As an implementation, runtime identifier lines and list body boundary markers are pre-inserted into the target server's output stream. These markers serve as explicit delimiters, enabling the local management end to accurately identify data segments from different container runtimes (e.g., docker or podman) and precisely extract the actual container list data. This segmentation mechanism ensures reliable data separation and processing even in mixed output or multi-runtime scenarios, avoiding parsing errors caused by output format uncertainties. For example, these markers can be located by searching for predefined string patterns (such as `---RUNTIME_IDENTIFIER:docker---` and `---LIST_BOUNDARY_START---` / `---LIST_BOUNDARY_END---`), and then the original standard output stream is divided into multiple logical segments based on the marker positions, each segment containing data of a specific runtime or a specific type.

[0080] The container list data is deserialized line by line into JSON. Specifically, the container list data is output in JSON line format, meaning each line is an independent JSON object representing detailed information about a container. Line-by-line JSON deserialization involves converting these JSON strings into a data structure that the program can manipulate internally, such as an object, dictionary, or struct. This approach fully leverages the self-descriptive and easily parsed nature of the JSON format, allowing various container attributes (such as ID, name, status, image, port mapping, etc.) to be clearly extracted and accessed. After receiving the segmented container list data, each line can be traversed, and a standard JSON parsing library can be used to convert it into a data object that the program can recognize.

[0081] To further enhance the robustness of parsing, a custom deserialization is implemented for the port mapping field to ensure compatibility with both string and object array formats. Container port mapping information may be represented in different JSON structures depending on the container runtime version or configuration. For example, sometimes it might be a simple string (e.g., 80:8080), and sometimes it might be an array containing multiple port mapping objects. To ensure parsing accuracy and compatibility, a custom deserialization logic needs to be implemented to recognize and correctly handle these two or more formats of port mapping data. During line-by-line JSON deserialization, the data type of the port mapping field can be checked first. If it is a string, the host port and container port are extracted according to the preset string parsing rules; if it is an object array, each object in the array is traversed to extract the corresponding port information.

[0082] Multiple JSON formats are unified into a single display structure for subsequent operational tasks. Even with custom deserialization of various port mapping fields, subtle structural differences may still exist in the original JSON for the entire container list data. To facilitate unified display, filtering, searching, and subsequent operational operations (such as starting, stopping, and deleting containers) on the management side, all parsed container data needs to be mapped to a predefined, standardized internal data structure. This unified display structure shields the differences in the underlying data source, providing a stable and consistent data interface for upper-layer applications. For example, a generic container data model can be defined, containing attributes such as `id`, `name`, `image`, `status`, and `ports` (where the `ports` field itself is a standardized array of port mapping objects). After line-by-line JSON deserialization and custom port mapping processing, the parsed data is populated into this unified data model instance.

[0083] In some implementations, executing maintenance operation commands on the target server based on the structured maintenance data includes: Receive container operation instructions, wherein the container operation instructions include runtime name, container ID, and operation type; Construct a remote command protected by command line escape sequences based on the runtime name and the container ID; The remote commands are executed on the target server via the SSH session, wherein the remote commands include container start commands, container stop commands, and container delete commands; Return command output and exit status information.

[0084] As one implementation approach, the management console first receives container operation instructions from the operator or automation system. These instructions are a digital representation of the user's intent, and their core content includes explicitly specifying the runtime name of the container to be operated (e.g., whether it's Docker or a container runtime environment like Podman), the unique identifier of the target container (Container ID), and the type of operation desired to be performed on the container (e.g., start, stop, or delete). This information forms the basis for executing subsequent container management operations.

[0085] Upon receiving a container operation command, the management system dynamically constructs a remote shell command to be executed on the target server based on the runtime name, container ID, and operation type provided in the command. To ensure this remote command is correctly parsed and executed within the target server's shell environment, especially when parameters such as the container ID may contain spaces, quotation marks, or other special characters, strict command-line escaping protection must be applied to these parameters. For example, adding a backslash (`\`) before special characters or enclosing the entire parameter in single quotes (`'`) can prevent the remote shell from misinterpreting them as command separators or options, effectively avoiding command injection risks and execution errors.

[0086] The management console uses the previously established SSH session with the target server to send remote commands, protected by command-line escape sequences, to the target server for execution. The specific form of the remote command varies depending on the operation type. For example, if the operation type is to start, the remote command might be `docker start [container ID]` or `podman start [container ID]`; if it is to stop, it might be `docker stop [container ID]` or `podman stop [container ID]`; and if it is to delete, it might be `docker rm [container ID]` or `podman rm [container ID]`.

[0087] After a remote command is executed, the management console receives and sends back the command's standard output stream, standard error stream, and exit status information. The standard output and standard error streams contain any logs, warnings, or errors generated during command execution, while the exit status information (usually an integer, 0 for success and non-zero for failure) directly indicates the command's execution result. This feedback information is crucial for the management console to determine whether the operation was successful, diagnose errors, and provide timely feedback to the operator.

[0088] In some implementations, a standard operation and maintenance data collection command is sent to the target server, and the standard output stream of the command is obtained, including: Send the lsblk command to the target server to obtain the block device tree data in JSON output mode; The block device tree data is deserialized locally. Recursively check the mount point field of block devices to filter out unmounted block device nodes; Based on the unmounted block device nodes, partition identifiers and formatting identifiers are generated for subsequent operation and maintenance.

[0089] As one implementation method, the operations and maintenance management end sends the `lsblk` command to the target server through an established SSH session. The `lsblk` command is a standard tool in Linux systems for listing block device information. It can display all available block devices and their relationships, such as physical hard drives, partitions, and logical volumes. The JSON output mode outputs block device information in a structured JSON format, rather than the traditional plain text format.

[0090] Local deserialization of the block device tree data refers to the process by which the operation and maintenance management terminal, after receiving the JSON-formatted block device tree data (usually in string form) returned from the target server, uses the JSON parsing library of the local programming language to convert it into a data structure that can be manipulated internally by the program, such as a nested structure of objects, dictionaries, or lists.

[0091] Recursively checking the mount point field of block devices to filter unmounted block device nodes means that in the deserialized data structure, the program traverses all block device nodes and their child nodes (such as partitions), checking the mount point field of each node. If this field is empty or null, it indicates that the block device or partition is not currently mounted by the operating system. Through recursive checking, all unmounted devices that can be used for new storage configurations can be accurately identified.

[0092] Generating partitioning and formatting flags based on unmounted block device nodes for subsequent maintenance operations means that for selected unmounted block device nodes, the system automatically generates corresponding operation suggestions or flags based on their current status and type. For example, for a brand new, unpartitioned, and unformatted physical disk, the system can generate partitioning and formatting flags; for a partitioned partition but with an unknown or empty file system type, a formatting flag is generated.

[0093] In some implementations, executing maintenance operation commands on the target server based on the structured maintenance data includes: Verify the device path parameters; The partitioning operation command is executed on the target server via the SSH session. Execute formatting commands on the target server via the SSH session; The mount operation command is executed on the target server via the SSH session; Returns the operation results and the newly generated device path information.

[0094] As an implementation method, validating device path parameters aims to ensure that the provided device path is valid and secure before performing any storage operations. Specifically, validation may include, but is not limited to: checking if the device path exists on the target server; verifying that the path indeed points to a block device and not another type of file or directory; confirming that the block device is currently unmounted (unless the operation intends to remount or modify an already mounted device); and verifying that the device is not a critical system partition (such as the root partition) to prevent accidental system crashes. This validation can be performed locally on the management end to avoid unnecessary remote operations, or it can be performed a secondary confirmation on the target server by pre-executing probe commands.

[0095] The partitioning operation commands are executed on the target server via the established SSH session. This step involves remotely executing commands on the target server to create, modify, or delete disk partitions. Common partitioning tools include `fdisk`, `parted`, or `gdisk`. During execution, the management end constructs corresponding command-line parameters based on the preset partitioning scheme (e.g., partition type, starting sector, size, file system type, etc.) and sends them to the target server for execution via the SSH tunnel. During execution, it is necessary to ensure the correctness of the commands and capture their standard output and error output for subsequent evaluation of the operation results.

[0096] The formatting operation command is executed on the target server via the SSH session. This step remotely executes commands on the target server to create a file system on a specified partition or block device. Different tools can be used depending on the required file system type, such as `mkfs.ext4`, `mkfs.xfs`, and `mkfs.btrfs`. The formatting command must be constructed including parameters such as the target device path and file system type. Because the formatting operation erases all data on the device, strict device path verification and user confirmation are required before execution to prevent data loss.

[0097] The mount operation command is executed on the target server via the SSH session. This step remotely executes commands on the target server via the SSH session to attach the file system to a specified mount point in the file system tree. The `mount` command is typically used, and its parameters include the path to the device to be mounted, the target mount point directory, and optional file system types and mount options. After successful mounting, the contents of the file system can be accessed through the mount point. To ensure that the mount remains effective after a system reboot, it is usually necessary to update the ` / etc / fstab` file on the target server.

[0098] The system returns the operation results and newly generated device path information. After performing storage operations such as partitioning, formatting, and mounting, the target server will send the execution results of these operations (including success or failure status, standard output, error output, and exit codes) back to the management end via an SSH session. Furthermore, if the operation (such as partitioning) results in the generation of new device paths (e.g., generating ` / dev / sdb1` from ` / dev / sdb`), this newly generated device path information will also be returned. This allows the management end to understand the progress and results of the operations in real time and update its internal device status records.

[0099] In some implementations, executing maintenance operation commands on the target server based on the structured maintenance data further includes: The network configuration parameters submitted by the operator are received, including network interface card name, working mode, static address, gateway, and DNS list. The network configuration parameters are locally validated, including network card naming character set validation, loopback interface operation prohibition validation, and address format validation. The verified network configuration parameters are Base64 encoded. The Base64 encoded network configuration parameters are used as command parameters and assembled into a directly executable configuration command. The network configuration parameters are configured on the target server via the SSH session. The network configuration is applied by invoking network management stack commands through the configuration command.

[0100] As one implementation method, the management terminal receives network configuration parameters submitted by the operator. These parameters are the specific configuration information that the user expects to apply to the target server's network interface, typically including the network interface name (e.g., eth0, enp0s3, etc.), operating mode (e.g., static IP, DHCP, etc.), static address (including IP address, subnet mask, etc.), gateway, and DNS server list. These parameters are fundamental to implementing the server's network functions.

[0101] Local validation of network configuration parameters involves pre-checking the received parameters on the management end before sending them to the target server. Network interface card (NIC) naming character set validation ensures that the NIC name conforms to the operating system's device naming conventions, preventing command execution failures due to illegal characters. Loopback interface operation disabling validation prevents operator errors or malicious attempts to modify or disable the loopback interface (e.g., "lo"), as the loopback interface is crucial for internal system communication, and incorrect configuration can lead to system malfunctions. Address format validation verifies that the IP address, subnet mask, gateway, and DNS server address conform to the standard IPv4 or IPv6 format; for example, ensuring the IP address consists of four sets of numbers and dots, with each set of numbers between 0 and 255. Strict local validation effectively prevents invalid or dangerous configurations from being sent to the remote server, reducing the risk of remote execution failures and improving operational security and stability.

[0102] Base64 encoding is a method of converting arbitrary binary data into printable ASCII characters. In this step, network configuration parameters that have undergone local validation are converted into Base64 strings. Its main purpose is to resolve command-line parsing errors or injection attacks that may occur during SSH remote command execution due to special characters (such as spaces, quotation marks, pipes, etc.). Through Base64 encoding, all parameters are uniformly represented as safe ASCII characters, avoiding complex command-line escaping processes, simplifying the command construction process, and enhancing the robustness and security of remote command execution.

[0103] The Base64-encoded network configuration parameters are used as command parameters and assembled into a directly executable configuration command. The Base64-encoded network configuration parameters are embedded within a predefined command template to form a complete configuration command that can be directly executed on the target server. This configuration command typically includes the logic on the target server that decodes the Base64 parameters and calls network management tools (such as the `ip` command, `nmcli`, `netplan`, etc.).

[0104] The network configuration parameters are configured on the target server via the SSH session. Using the established SSH session, the executable configuration commands assembled in the previous step are sent to the target server and their execution is triggered. The SSH session provides a secure channel, ensuring that commands are not eavesdropped on or tampered with during transmission. On the target server, the command is interpreted and executed by the shell, thus initiating the network configuration process.

[0105] The configuration commands invoke network management stack commands to apply network configurations. The configuration commands executed on the target server internally call network management stack commands provided by the operating system to actually apply the network configurations. Network management stack commands are core tools used by the operating system to manage network interfaces, IP addresses, routing, DNS, etc. For example, in Linux systems, this might include the `ip` command (used to configure IP addresses and routing), `nmcli` (NetworkManager command-line tool), `netplan apply` (Netplan configuration tool), or directly modifying configuration files such as ` / etc / network / interfaces` and restarting network services.

[0106] It should be noted that the above description describes some embodiments of the present invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0107] Based on the same inventive concept, corresponding to any of the above embodiments, such as Figure 2 As shown, this application also provides a management terminal device for operation and maintenance based on the SSH protocol, including: The first unit is used to establish communication connections with N target servers via the SSH protocol; where N≥1 and N is a natural number, the target servers are pre-installed with only the standard SSH server program and have not installed any operation and maintenance monitoring related client software; The second unit is used to send standard operation and maintenance data collection commands to the target server via an SSH session and obtain the standard output stream of the commands. The third unit is used to parse the standard output stream to obtain structured operation and maintenance data; The fourth unit is used to execute operation and maintenance commands on the target server based on the structured operation and maintenance data.

[0108] Furthermore, the first unit is also used for: Perform transport layer reachability detection on the target server's address and SSH port, and distinguish the port status type, which includes port unreachable, port reachable but authentication failed, and port reachable and authentication successful; Based on the port status type, an SSH client connection to the target server is established using a unified timeout policy. The SSH client connection is used to perform metric collection, connectivity verification, container operations, and storage and network configuration operations.

[0109] Furthermore, the second unit is also used for: The full collection command set is divided into multiple independent sub-command modules, including a system resource collection sub-command module, a disk usage collection sub-command module, and a dedicated hardware detection sub-command module. Configure multiple API endpoints, each of which triggers a corresponding sub-command module to execute on the target server via an SSH session and returns the standard output stream of the sub-command module; By calling the corresponding API endpoint through the operation terminal, multiple sub-command modules are triggered to execute in parallel, and the execution task of each sub-command module is configured with an independent timeout. The operation terminal is configured with an integrated program packaged and generated based on the Tauri framework.

[0110] The apparatus described above is used to implement the corresponding methods in the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0111] Based on the same inventive concept, corresponding to any of the above embodiments, such as Figures 3-4 As shown, this application also provides a server operation and maintenance management system based on the SSH protocol, used to execute the above-described server operation and maintenance management method based on the SSH protocol, including: The management service module provides a RESTful API interface, maintains a list of target servers and connection parameters, establishes SSH sessions with target servers through an SSH client library, sends operation and maintenance data collection commands to the target servers and parses the standard output stream of the commands, and executes operation and maintenance operations according to the operation instructions. The target server is used to run a Unix-like operating system, provides SSH service, and comes pre-installed with a general toolchain including lsblk, ip, and df. It receives and executes operation and maintenance data collection commands and operation and maintenance operation commands issued by the management service module. The target server only comes pre-installed with a standard SSH server program and does not have any operation and maintenance monitoring related client software installed. The operation terminal is used to call the RESTful API interface of the management terminal service module through an integrated program packaged based on the Tauri framework, display operation and maintenance data, and receive operation instructions input by the operator.

[0112] Furthermore, the management service module includes: The SSH access unit is used to perform transport layer reachability detection on the target server's address and SSH port, and establish an SSH client connection with the target server using a unified timeout policy. The indicator acquisition unit is used to connect to the target server via the SSH client and send an indicator acquisition command sequence, segment the standard output stream of the command according to the delimiter, perform double sampling difference calculation, and parse to obtain structured indicator data. The container management unit is used to connect to the adaptive detection container runtime via the SSH client, parse the container list data in JSON line format, and perform container lifecycle operations; The network configuration unit is used to perform local validity verification of network configuration parameters, and uses Base64 encoded network configuration parameters as command parameters to assemble them into directly executable configuration commands to call the network management stack to apply the configuration. The storage operation and maintenance unit is used to connect and parse block device tree data through the SSH client, identify unmounted devices, and perform partitioning, formatting, and mounting operations.

[0113] Furthermore, the management service module also includes: An embedded relational database is used to store the target server identifier, connection address, port, username, and authentication information. The RESTful API interface unit provides interfaces for server CRUD operations, connectivity testing, metric collection, container operation, storage maintenance, and network configuration.

[0114] Based on the same inventive concept, this application also provides a computer-readable storage medium storing computer-readable instructions thereon, which are executed by a processor to achieve server operation and maintenance management based on the SSH protocol as described above.

[0115] Based on the same inventive concept, this application also provides a device, the device comprising: One or more processors; and A memory storing computer-readable instructions, which, when executed, cause the processor to perform server operation and maintenance management operations as described above based on the SSH protocol.

[0116] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A server operation and maintenance management method based on the SSH protocol, characterized in that, Includes the following steps: Communication connections are established with N target servers via the SSH protocol; where N≥1 and N is a natural number, the target servers are pre-installed with only the standard SSH server program, and no operation and maintenance monitoring related client software or external script files are installed; Through an established SSH session, standard operation and maintenance data collection commands are sent to the target server to obtain the standard output stream of the commands. This includes: sending a sequence of standard operation and maintenance data collection commands to output multiple segments in a pre-defined order, with each segment separated by a unique delimiter; obtaining the complete standard output stream containing the multiple segments and the delimiters; and dividing the standard output stream into several sections based on the delimiters for parsing to obtain structured operation and maintenance data. The sequence of standard operation and maintenance data collection commands is sent and outputs multiple segments of content in a pre-defined order, including: At the first time point, the cumulative CPU count in / proc / stat is read and the first CPU segment is output; at the first time point, the network statistics in / proc / net / dev are read and the first network segment is output; a fixed-duration sleep is performed; at the second time point, the cumulative CPU count in / proc / stat is read and the second CPU segment is output; at the second time point, the network statistics in / proc / net / dev are read and the second network segment is output; each segment is delimited by a unique separator, so that the local system can calculate the CPU utilization based on the difference between the counts of the first CPU segment and the second CPU segment, and calculate the network throughput rate based on the statistical difference between the first network segment and the second network segment; Read data from / proc / meminfo and output memory segments; execute the JSON output mode of the ip command and output the network card and address segments; execute the df command and output the disk usage segments; check the existence of dedicated hardware command-line tools, outputting dedicated hardware segments if they exist, and outputting an empty identifier if they do not exist; wherein, the memory segments, network card and address segments, disk usage segments, dedicated hardware segments or empty identifiers are all delimited by unique delimiters for local parsing into structured operation and maintenance data; The standard output stream is parsed to obtain structured operation and maintenance data; Based on the structured operation and maintenance data, execute the corresponding operation and maintenance command on the target server.

2. The server operation and maintenance management method based on the SSH protocol according to claim 1, characterized in that, The process of establishing communication connections with N target servers via the SSH protocol includes: Perform transport layer reachability detection on the target server's address and SSH port, and distinguish the port status type, which includes port unreachable, port reachable but authentication failed, and port reachable and authentication successful; Based on the port status type, an SSH client connection to the target server is established using a unified timeout policy. The SSH client connection is used to perform metric collection, connectivity verification, container operations, and storage and network configuration operations.

3. The server operation and maintenance management method based on the SSH protocol according to claim 1, characterized in that, The step of sending a standard operation and maintenance data collection command to the target server and obtaining the standard output stream of the command also includes: The full collection command set is divided into multiple independent sub-command modules, including a system resource collection sub-command module, a disk usage collection sub-command module, and a dedicated hardware detection sub-command module. Configure multiple API endpoints, each of which triggers a corresponding sub-command module to execute on the target server via an SSH session and returns the standard output stream of the sub-command module; By calling the corresponding API endpoint through the operation terminal, multiple sub-command modules are triggered to execute in parallel, and the execution task of each sub-command module is configured with an independent timeout. The operation terminal is configured with an integrated program packaged and generated based on the Tauri framework.

4. The server operation and maintenance management method based on the SSH protocol according to claim 1, characterized in that, Send a standard operation and maintenance data collection command to the target server and obtain the standard output stream of the command, including: Send a container runtime probe command to the target server; Probe the availability of the Docker container runtime and the podman container runtime in turn; Select an available container runtime based on the detection results; Send a command to the target server, causing the target server to output a list of containers in JSON line format using the selected container runtime; Insert runtime identifier rows and list body boundary markers into the output stream so that the container data can be segmented and parsed locally based on the boundary markers.

5. The server operation and maintenance management method based on the SSH protocol according to claim 4, characterized in that, The parsing of the standard output stream yields structured operation and maintenance data, including: The output stream is segmented based on the runtime identifier row and the list body boundary marker; Perform line-by-line JSON deserialization on the container list data; Implement custom deserialization for port mapping fields, compatible with both string and object array formats; The various JSON formats are unified into a single display structure for subsequent operation and maintenance.

6. The server operation and maintenance management method based on the SSH protocol according to claim 1, characterized in that, Send a standard operation and maintenance data collection command to the target server and obtain the standard output stream of the command, including: Send the lsblk command to the target server to obtain the block device tree data in JSON output mode; The block device tree data is deserialized locally. Recursively check the mount point field of block devices to filter out unmounted block device nodes; Based on the unmounted block device nodes, partition identifiers and formatting identifiers are generated for subsequent operation and maintenance.

7. The server operation and maintenance management method based on the SSH protocol according to claim 1, characterized in that, The step of executing maintenance operation commands on the target server based on the structured maintenance data also includes: The network configuration parameters submitted by the operator are received, including network interface card name, working mode, static address, gateway, and DNS list. The network configuration parameters are locally validated, including network card naming character set validation, loopback interface operation prohibition validation, and address format validation. The verified network configuration parameters are Base64 encoded. The Base64 encoded network configuration parameters are used as command parameters and assembled into a directly executable configuration command. The network configuration parameters are configured on the target server via the SSH session. The network configuration is applied by invoking network management stack commands through the configuration command.

8. A management terminal device for operation and maintenance based on the SSH protocol, characterized in that, include: The first unit is used to establish communication connections with N target servers via the SSH protocol; where N≥1 and N is a natural number, the target servers are pre-installed with only standard SSH server programs and have not installed any operation and maintenance monitoring related client software or deployed any external script files; The second unit is used to send standard operation and maintenance data collection commands to the target server via an SSH session and obtain the standard output stream of the commands. This includes: sending a sequence of standard operation and maintenance data collection commands to output multiple segments in a pre-defined order, with each segment separated by a unique delimiter; obtaining the complete standard output stream containing the multiple segments and the delimiter; and dividing the standard output stream into several sections based on the delimiter for parsing to obtain structured operation and maintenance data. The sequence of standard operation and maintenance data collection commands is sent and outputs multiple segments of content in a pre-defined order, including: At the first time point, the cumulative CPU count in / proc / stat is read and the first CPU segment is output; at the first time point, the network statistics in / proc / net / dev are read and the first network segment is output; a fixed-duration sleep is performed; at the second time point, the cumulative CPU count in / proc / stat is read and the second CPU segment is output; at the second time point, the network statistics in / proc / net / dev are read and the second network segment is output; each segment is delimited by a unique separator, so that the local system can calculate the CPU utilization based on the difference between the counts of the first CPU segment and the second CPU segment, and calculate the network throughput rate based on the statistical difference between the first network segment and the second network segment; Read data from / proc / meminfo and output memory segments; execute the JSON output mode of the ip command and output the network card and address segments; execute the df command and output the disk usage segments; check the existence of dedicated hardware command-line tools, outputting dedicated hardware segments if they exist, and outputting an empty identifier if they do not exist; wherein, the memory segments, network card and address segments, disk usage segments, dedicated hardware segments or empty identifiers are all delimited by unique delimiters for local parsing into structured operation and maintenance data; The third unit is used to parse the standard output stream to obtain structured operation and maintenance data; The fourth unit is used to execute operation and maintenance commands on the target server based on the structured operation and maintenance data.

9. A server operation and maintenance management system based on the SSH protocol, used to execute the server operation and maintenance management method based on the SSH protocol as described in any one of claims 1-7, characterized in that, include: The management service module provides a RESTful API interface, maintains a list of target servers and connection parameters, establishes SSH sessions with target servers through an SSH client library, sends operation and maintenance data collection commands to the target servers and parses the standard output stream of the commands, and executes operation and maintenance operations according to the operation instructions. The target server runs a Unix-like operating system, provides SSH service, and comes pre-installed with a general toolchain including lsblk, ip, and df. It receives and executes operation and maintenance data collection commands and operation and maintenance operation commands issued by the management service module. The target server only comes pre-installed with a standard SSH server program and does not have any operation and maintenance monitoring related client software installed or any external script files deployed. The operation terminal is used to call the RESTful API interface of the management terminal service module through an integrated program packaged based on the Tauri framework, display operation and maintenance data, and receive operation instructions input by the operator.

Images