Detailed Description
The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.
In the description of the present application, it should be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or an implicit indication of the number of technical features being indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "plurality" is at least two, such as two, three, etc., unless explicitly defined otherwise.
In the description of the present specification, a description referring to the terms "one embodiment," "some embodiments," "exemplarily," "specific examples," or "some examples," etc., means that a specific feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
In order to facilitate understanding of the aspects of the embodiments of the present application, the technical terms referred to herein will first be explained below.
Secure shell protocol (SSH): a technique for remotely logging onto another computer or server over a network is based on a network protocol of secure socket layer (secure sockets layer, SSL) or transport layer security (transport layer security, TLS), which is one of the most commonly used logging modes in Linux systems for secure communication between a client and a server.
Control groups (cgroups): a resource management mechanism provided by the Linux kernel can be used for limiting and distributing the resource use of the process group. It allows an administrator to create and manage groups of cgroups controls on the system and allocate resource constraints, such as processors, memory, disks, networks, etc., for each cgroup; an exemplary processor may be a central processing unit (central processing unit, CPU).
The user: in Linux systems, a User refers to an individual or entity in the system that represents a particular operating system account.
The system daemon system d: the next system and service manager in the Linux system is responsible for starting, stopping and managing other processes and services in the system, and also provides a series of resource control functions.
User resource limitation ulimit: linux commands to limit process resources. It is used to set and display various resource limitations of the process, such as maximum file size, maximum open file number, maximum number of processes, etc. With the ulimit command, the resource limits of the current process can be reviewed and these limits can be dynamically modified using the ulimit command. ulimit commands are typically used in command line terminals, such as: ulimit-n 1024, the command will limit the number of files that the current process can open to 1024.
Process identifier (Process ID, PID): is a digital identification that the operating system uses to uniquely identify a running process. Each running process is assigned a unique PID value. PID is a non-negative integer, commonly denoted as a number, and is therefore also referred to as an identification number.
Remote connection refers to a process of connecting to a remote computer from a local computer through a network, and performing operations and accessing resources on the remote computer. The remote connection may enable interactions and communications between computers across territories, across a network. Remote connections may be implemented through a variety of protocols and techniques, the most common of which include SSH (secure shell), telnet, rlogin, VNC (virtual network computing, virtual network operations), and the like. These protocols not only provide different levels of functionality and security, but also apply to different operating systems and services. In a remote connection, the local computer needs to establish a connection with the remote computer using remote connection client software. Once the connection is established, the user may perform operations on the remote computer such as commanding, managing files, running programs, etc. The remote connection can also realize a plurality of application scenes such as remote desktop access, remote server management, remote technical support and the like. The secure shell protocol SSH remote connection process management method and the computing device provided in the embodiments of the present application may limit any remote connection process resource in SSH, telnet, rlogin and VNC, which are not strictly limited herein. For convenience of description, the embodiments of the present application will be illustrated by SSH as an example, and it should be understood that the embodiments are not limited thereto.
FIG. 1 illustrates an operating system level SSH session resource control flow diagram. As shown in FIG. 1, in a Linux system, the resource control at the operating system level is mainly implemented by adding a system d configuration. For example, when SSH logs in, it is first determined whether or not to configure the system d resource limitation, if the system d resource limitation is configured, there is a resource limitation, and if the system d resource limitation is not configured, there is no resource limitation.
If resources of the ssh session are to be limited, the configuration can be added to a service file of the sshd service, such as a CPU share, a memory limit, an IO bandwidth, and the like. Specifically, by configuring the service file of the sshd service, the resource restrictions such as CPU share, memory restriction, IO bandwidth, etc. can be set for the processes logged in remotely through the SSH, so as to limit the use of the system resources by these processes.
Such as:
1. cpushares=500, indicating that this process is allocated 50% of CPU time relative to other processes. This configuration item is used to specify the priority of the process when competing for CPU resources, with a larger value indicating a higher priority, more CPU time is available.
2. Memory limit=1g, indicating that the memory limit for this process is 1GB. This configuration item is used to limit the physical memory size that can be used by the process, and exceeding this limit triggers the processing mechanism of memory restriction.
3. Blockioweight=500, indicating that the process is allocated 50% of disk IO resources relative to other processes. This configuration item is used to control the access weight of the process to the disk IO, and a larger value indicates that more disk IO bandwidth is available.
4. Taskmax=100, meaning that a maximum of 100 processes are allowed for the systematic unit. This configuration item is used to limit the maximum number of processes that can be created by the system md unit (e.g., service) to avoid excessive numbers of processes that would result in excessive system load.
If the sshd service is configured with resource limitations, then the process of telnet through ssh will be resource limited. Therefore, the occupation of the remote login process to the system resources can be effectively controlled, and the condition that the system performance is reduced or even crashed due to the fact that some remote login processes excessively occupy the resources is avoided. This is a great aid to the stability and safety of the system.
It will be appreciated that sshd services refer to SSH server programs running on the Linux system server that provide secure remote login and command execution functions. When other computers are connected to the local computer through SSH protocol, the sshd service is responsible for authenticating the user identity, establishing an encryption channel, and providing a secure remote Shell environment or file transfer function. The sshd service is a very important service in the system, and its normal operation ensures the security and convenience of remote access. In Linux using systemd as a resource control configuration, each service managed by systemd has a corresponding service file, which stores configuration information and control instructions for the service. For sshd services, the service file of the sshd service includes definitions of operations such as start, stop, restart, and status query, and various configuration parameters of the service, such as resource limitations, dependencies, and execution paths. This file is typically stored in a unit file directory (typically/lib/system d/system/or/etc/system d/system /) of the system and is extended by a service. That is, the sshd service is an SSH server program that actually runs, and the service file of the sshd service is a configuration file when the sshd service is managed by the system d, for defining the behavior and properties of the sshd service, so that the system d can start, stop, control, and monitor the operation of the sshd service according to these definitions.
It should be noted that, when the resource control is performed at the operating system level, the limitation of the resource is generally applied to the entire process group or the user group. Because the granularity of the limitation is thicker, some users or processes may be unnecessarily limited, and fine management cannot be achieved. For example, only a few processes in a process group require more CPU time, while other processes are not, but all processes are subject to the same limitations due to the limited use on the entire process group. If customized resource allocation is required for certain specific processes or users in the system, conventional operating system resource control may not meet the requirements.
To address these issues, some advanced resource management techniques, such as the resource control mechanisms in cgroup v2 and systemd, provide finer granularity of resource control capabilities, allowing administrators to more flexibly and finely manage resources for a single process. This enables a system administrator to better balance the use of system resources, avoid unnecessary limitations, and at the same time achieve a more refined management of system resources.
Referring to fig. 2, for example, fig. 2 shows a schematic flow diagram of an individual SSH session resource control implementation using manual management. As shown in fig. 2, after ssh logging, judging whether the resource occupation is higher, if not, continuing to execute; if the occupation of ssh session resources is higher, after finding, an administrator obtains the pid of the ssh session and adds the pid into a cgroup control group to control the resources; but if the administrator does not find that the resources occupy a higher ssh session, the ssh session will still continue to execute. In other words, in the process, the individual SSH session resource control is mainly completed by manual management and is realized by virtue of the cgroups technology, a system administrator acquires the process number pid of the SSH session, and the process number is written into the cgroups with the resource control capability to realize the individual SSH session resource control.
However, if there are a large number of SSH sessions to be controlled, there are certain limitations and difficulties in using manual management. Specifically, if a large number of users need to remotely log on to a server to operate through an SSH protocol, each session needs to be independently set and managed, including authority configuration, security policy, session monitoring, and the like, the workload and complexity of an administrator are increased, and missing or incorrect setting is easy to occur, so that security risks and management confusion are caused. In addition, because the SSH login time is uncertain, the user can log in and log out at any time, and the manual management mode is difficult to monitor and manage the sessions in time. In particular, in the case where real-time auditing or emergency response is required for user behavior, the manual management manner cannot meet these requirements, because the administrator cannot effectively grasp the status and activity of all SSH sessions. That is, since the SSH login time is not determined, the manual management mode has a certain limitation.
In view of the above, both of the above methods of SSH session resource control require complex configuration and operation, and it may be difficult for those who are unfamiliar or do not have knowledge about the operating system to properly configure and manage these resource limitations. Moreover, the granularity of the resource control is relatively coarse, and the fine resource control cannot be realized.
Therefore, in order to realize dynamic, real-time and finer SSH session resource limitation, the embodiments of the present application provide a secure shell protocol SSH remote connection process management method, mainly by setting the IP address and the user name information of the SSH session to be limited in a blacklist, comparing the information in the blacklist with the source IP information initiating the SSH session, if the information accords with the blacklist, acquiring the corresponding SSH session process PID, adding the PID to the corresponding cgroups resource limitation group, and realizing resource limitation. Meanwhile, for the IP addresses which are not in the blacklist, the application monitors the resource use condition, and once the limit condition (the set resource use threshold value is exceeded and the number of times is exceeded) is exceeded, the IP addresses and the login users are automatically written into the blacklist, and the corresponding PID is added into the resource limit group. Dynamic, real-time, more refined SSH session resource limitation is achieved by using blacklists, cgroups and resource monitoring mechanisms in combination.
Fig. 3 is a schematic flow chart of a secure shell protocol SSH remote connection process management method provided in an embodiment of the present application. As shown in fig. 3, the method is applied to a Linux system, and may include:
S301, acquiring a login session identifier of a SSH remote connection process SSH which is currently logged in.
It can be understood that the login session identifier of the SSH is the PID of the SSH session process, and the PID process identifier represents the unique identifier of the SSH process of the user. In this embodiment, the information of the pseudo terminal device (such as pts/0) of the SSH remote connection process SSH currently logged in is obtained through the system log, and the PID process identifier of the SSH login session is obtained through the pseudo terminal device.
It should be noted that in Linux systems, each terminal device has a specific name, usually starts with tty (such as tty1, tty2, etc.), and when a user logs in remotely by SSH, etc., a pseudo terminal device (pts) is allocated to provide an interactive session. The pts device has a number, such as pts/0, pts/1, etc., for uniquely identifying different terminal sessions, and the pseudo terminal device obtains the bash process number of the ssh login session, where the bash process number of the ssh login session refers to the PID of the bash shell process started in the user login process, and is used for representing the interactive session process of the user. The usual linux commands are typically:
ps-ef|grep"pts/0"|grep bash|awk'{print$2}'
all processes under the subsequent ssh session are sub-processes of this flash process.
S302, acquiring user information based on the login session identifier.
It should be noted that the user information includes the ip address and the user account name of the user. And acquiring the user ip address and the user name user of the SSH remote connection process SSH currently logged in from the system log based on the login session identification. In Linux systems, login information and activity logs of a user are usually recorded, and ip addresses, user account names and pseudo terminal equipment information of the user can be obtained by analyzing the system logs, and the information can be commonly found in a/var/log/auth.
Wherein the ip address of the user refers to the unique identification of the device used by the user in the network. Each device, whether a computer, cell phone, tablet or other network device, that is connected to the internet is assigned an IP address for communication and data exchange over the network. ip addresses are typically composed of numbers, e.g., IPv4 addresses are typically represented by four decimal numbers, whereas IPv6 addresses are more complex and take longer hexadecimal representations. The ip address of the user may be used to determine the approximate geographic location of the user, as well as for routing and data transmission in network communications. The user account name represents the user's account name in the system for identifying the user's identity.
S303, determining whether the user information is in a blacklist.
Illustratively, the blacklist format is shown in table 1:
TABLE 1
IP
|
USER
|
192.168.100.100
|
root
|
192.168.100.101
|
test |
As shown in the table above, the blacklist includes the source IP information of ssh login and the USER name information of login, which need to be limited, for example, the IP information is 192.168.100.100, the USER name information is root, or the IP information is 192.168.100.100, and the USER name information is test. Only when these 2 pieces of information are all compliant will the next step be initiated and ssh resource limitation is performed.
S304, adding the SSH remote connection process into a resource control group under the condition that the user information is in a blacklist; wherein the resource control group is used to limit resource usage of the SSH remote connection process.
Illustratively, an SSH remote connection process and its sub-processes are added to the resource control group. That is, the PID of the ssh process in the blacklist is added to a specific cgroup resource control group for resource control. Specifically, the resource restriction on the bash process and the sub-process thereof can be realized by writing the bash process number of the ssh process into the cgroup.
It will be appreciated that in a SSH session, when a user logs into the system via SSH and initiates a bash shell process as an interactive session, the bash process becomes the parent of the session. All processes that the user initiates in this session will then become child processes of the flash process. The cgroups (control groups) is a mechanism provided by the Linux kernel for resource management and restriction of process groups. The method can put a group of related processes into the same resource group and carry out resource limitation, control and monitoring on the processes in the resource group.
In cgroups, there is one cgroup. Writing the PID of a process to the cgroup. Proc file adds the process to the corresponding resource group. For example, assume we have a group of cgroups resources named "my_group" with a cgroup. If we write the PID of a process to the file, e.g., PID 12345, then the process is added to the "my_group" resource group and is subject to the resource limitations of that resource group. Dynamic management of processes in a particular resource group, including add, remove, and query operations, may be achieved by manipulating the cgroup. This is very useful for resource limitation, monitoring and control, especially for resource management in batch processing tasks, containerized environments, etc.
Therefore, if the PID of the flash process is written into the cgroup. All sub-processes derived from the flash process will be automatically added to the corresponding resource group and thus subject to resource-constrained control. In this way, it is convenient to perform uniform resource management and limitation on all processes in a session, so as to ensure that they do not exceed a limited range when using system resources, thereby enhancing the stability and security of the system.
Based on the above description, the following describes an exemplary manner of logging in the Liunx server by using ip192.168.100.100 and a user name user as a root, referring to fig. 4, fig. 4 shows an example of an SSH remote connection process management method provided in an embodiment of the present application; specifically, a flow chart of logging in the Liunx server by using 192.168.100.100 is shown. As shown in fig. 4, first, log ip, user, pid information is obtained through a log, then, it is verified that the blacklist has ip192.168.100.100, a user is a root, that is, ip192.168.100.100, a user with a user name of the user is a root accords with the blacklist, and then, the pid is added into the limited cgroup resource group, so as to achieve resource limitation.
Fig. 5 is a flow chart of another SSH remote connection process management method provided in an embodiment of the present application. As shown in fig. 5, the method is applied to a Linux system, and the method comprises the following steps:
s501, creating a cgroups resource group.
It should be noted that in this embodiment, the cgroups of resources may be automatically created by creating a directory in the cgroups file system.
Specifically, the creation of the cgroups resource group on the Linux system can be realized by the following steps:
confirm whether cgroups is enabled: it is first necessary to confirm whether the Linux kernel has the cgroups function enabled. Whether cgroups is available can be confirmed by checking the mount point (/ sys/fs/cgroup) of the system or checking the kernel configuration file (/ boot/config-uname-r).
Mounting a cgroups file system: if the cgroups function is not enabled, then the cgroups file system needs to be mounted on the system. The cgroups file system may be mounted using the following commands:
bash
mount-t cgroup-o[subsystem][cgroup_path]
wherein [ subsystem ] represents a specified cgroups subsystem, such as cpu, memory, etc.; [ cgroup_path ] represents the path of the mount.
Creating a cgroups of resources: once the cgroups file system mount is successful, the cgroups resource group can be created by creating a directory in the file system. For example, a set of cgroups resources may be created using the following commands:
bash
mkdir/sys/fs/cgroup/[subsystem]/[resource_group_name]
wherein [ subsystem ] represents a specified cgroups subsystem, such as cpu, memory, etc.; the resource_group_name represents the name of the resource group.
Setting a resource limit: after creating the resource group, resource limits, such as CPU quota, memory limits, etc., may be set by writing values to the corresponding cgroups file.
For example, the CPU quota may be set by modifying/sys/fs/cgroup/CPU/resource_group_name/cpu.cfs_quota_us file.
The written script or program is added to the system start script to ensure automatic operation at the start of the server. Thus, each time the server is started, a designated set of cgroups resources is automatically created. Through the steps, the cgroups resource group can be created on the Linux system, and the resource limitation is carried out on the pid process added into the cgroups resource group. This may enable limiting and managing resource usage by a particular process or user. It should be noted that the specific operations may vary from system version to system version and from cgroups subsystem to cgroups subsystem, and the above is exemplary, and the developer may make corresponding adjustments according to the actual situation.
S502, acquiring a login session identifier of an SSH user of a current login SSH remote connection process.
S503, acquiring user information based on the login session identifier.
S504, judging whether the user information is in a blacklist. If the user information is in the blacklist, the process S505 is performed. If the user information is not in the blacklist, the process S506 is performed.
S505, under the condition that the user information is in a blacklist, adding the ssh process of the user into a cgroup resource control group; wherein the resource control group is used for limiting the resource use of the SSH remote connection process SSH.
In another embodiment, with continued reference to fig. 5, a method for restricting the use of resources of a specified SSH remote connection process based on a login session identification not being in a blacklist may further include:
s506, monitoring the resource use condition of the ssh process of the user under the condition that the login session identifier is not in the blacklist.
Illustratively, the resource usage of the ssh process of the user is monitored by a Linux monitoring tool. For example, the bash process number of the ssh process and the resource use condition of the sub-process thereof can be obtained through a linux monitoring tool such as ps-aux or top. It should be noted that ps commands are used to display the process state in the current system. The "ps-aux" command may be used to list details of all processes, including PID of process, CPU utilization, memory usage, etc. Wherein the "-a" option indicates a process of displaying all users, the "-u" option indicates a process of outputting a result in a format in which the users are displayed, and the "-x" option indicates a process of simultaneously displaying no control terminal. Illustratively, the PID of the target process is found using a "ps-aux" command, and the target process can be screened out, typically based on the process name, user, etc. After the PID of the target process is obtained, the detailed information of the process, including CPU utilization rate, memory occupation and the like, can be checked by using a ps-aux|grep < PID > "command so as to monitor the resource utilization condition of the target process and the sub-processes thereof in real time.
the top command is used to dynamically monitor the running state and process activity of the system in real time. It displays the resource usage of each process in an interactive manner and provides updated information in real time. Through the top command, the information such as PID, CPU utilization rate, memory occupation, process priority and the like of the process can be checked. For example, if a top command is used, the "p" key may be pressed at the top interface and then the PID of the target process entered, with carriage return confirmation. Therefore, the top command only displays the information of the process and the subprocesses thereof, including CPU utilization rate, memory occupation and the like, so that the resource utilization condition of the target process and the subprocesses thereof can be monitored in real time, and the load condition of the system and the performance of the process can be known in real time.
The Linux monitoring tool may be any one of htop, iostat, nmon, sar and dstat, and may be selected for use according to requirements, so as to better obtain the resource usage situation of the ssh process, which is not strictly limited in the embodiments of the present application.
It should be noted that htop, which is a modified version of the top command, provides a more intuitive, interactive interface, and supports mouse operations. iostat, which monitors the input and output devices and CPU utilization of the system, and provides statistical information about disk, network and TTY devices. nmon, a comprehensive system monitoring tool, can provide real-time performance data, including CPU, memory, disk, network, and file system. The sar, system activity reporting tool, can collect, report and analyze the system resource usage, including CPU, memory, disk, network, file system, etc. dstat, a versatile system resource statistics tool, can monitor performance indexes such as CPU, disk, network, memory, IO, etc. in real time.
S507, judging whether the ssh process use resource of the user exceeds a limit condition. If the ssh process usage resource of the user does not exceed the constraint condition, the process S508 is executed. If the ssh process usage resource of the user exceeds the constraint condition, the flow S509 is executed.
S508, if the ssh process use resource of the user does not exceed the limit condition, continuing to execute the ssh process of the user.
S509, writing user information of the user into a blacklist when the ssh process use resource of the user exceeds a limit condition.
Illustratively, ip and user in the user information are written into a blacklist, and simultaneously, PID of the ssh process of the user is added into the cgroup resource control group, so that the resource limitation is performed on the ssh process.
Therefore, the method in this embodiment can automatically create a cgroups resource control group on the logged server to realize resource control, and acquire the logged ip, user and flash process number PID through the system log after monitoring the new connection in ssh, then compare these information with the blacklist, if the user ip and the user name user compound the blacklist, write the flash process number PID into the cgroup. If the resource usage conditions of the base process number and the sub-processes are not met, the base process number and the sub-processes are all written into a cgroup. Simultaneously, the user ip and the user name user of the ssh login are written into a blacklist, and when the user logs in next time, the use of resources is directly limited.
Referring to fig. 6, fig. 6 shows a flow chart for determining whether a user's ssh process uses resources beyond a limit condition. As shown in fig. 6, exemplary, determining whether the ssh process usage resource of the user exceeds the constraint condition includes:
s601, monitoring PID resource usage.
It should be noted that, the description of the specific implementation of the step S601 is the same as that of the step S506, and specific reference may be made to the above description, which is not repeated here.
S602, judging whether the resource usage of the ssh process of the user exceeds a resource threshold.
In this implementation flow, by setting the resource threshold, a maximum limit on the CPU share usage of the SSH process of each user may be specified. This can be achieved by the time interval of the CPUs in the cgroup and the total amount of time the CPUs are used. For example, the resource threshold is set to 80% CPU share usage. If the CPU share usage rate of the ssh process does not reach or equal to the set resource threshold, the process continues to execute the flow S601. If the CPU share usage rate of the SSH process exceeds the set threshold, the flow S603 is executed.
S603, when the resource usage exceeds the resource threshold, acquiring the number of times that the resource usage of the ssh process exceeds the resource threshold and the limit number of times, and judging whether the number of times that the resource usage of the ssh process exceeds the resource threshold exceeds the limit number of times. If the number of times the resource usage of the ssh process exceeds the resource threshold does not exceed (is less than or equal to) the limit number of times, then the flow S604 is executed. If the number of times the resource usage of the ssh process exceeds the resource threshold exceeds (is greater than) the limit number of times, the flow S605 is executed.
It will be appreciated that the limit number is the upper limit number of times the resource usage of the ssh process exceeds the resource threshold, and the specific number of limit numbers may be set by those skilled in the art as required, for example, 5, 6, 7, 8, and no specific limitation is made herein.
S604, when the number of times that the resource usage of the ssh process exceeds the resource threshold is less than or equal to the limit number of times, the number of times that the resource usage of the ssh process exceeds the resource threshold is increased once, and then the process S601 is continued to be executed.
S605, when the number of times that the resource usage of the ssh process exceeds the resource threshold exceeds the limit number of times, the pid of the ssh process of the user is written into the cgroups resource control group.
S606, writing the ip and the user of the ssh process of the user into a blacklist.
In this embodiment, two judgment conditions are set: firstly, judging whether the use threshold of the resource is exceeded, for example judging whether the use of the CPU exceeds 80%; if the number of times exceeds the threshold, the device considers that the habit of using the operating system of the user ip is extremely probable that the habit exceeds the limit in the using process, automatically writes the habit into a blacklist and limits the resource; if the resource threshold is exceeded without exceeding the limit number, the method considers that this is only a occasional behavior of exceeding the resource limit, adds 1 to the number of times the threshold is exceeded, and continues to monitor its process resource usage. Thus, unnecessary limitations on some users or processes can be avoided.
Based on the above description, the following describes an exemplary manner of logging in the Liunx server by using the user ip192.168.100.101 and the user name user as test, referring to fig. 6, fig. 6 shows an example of an SSH remote connection process management method, specifically, a flowchart of logging in the Liunx server by using 192.168.100.101 in the embodiment of the present application. As shown in fig. 6, firstly, log ip, user, pid information is obtained through a log, then, it is verified that ip 192.168.100.100 is provided in a blacklist, a user is root, that is, ip192.168.100.101 is provided, and a user is test, and if the user does not accord with the blacklist, the resource usage of the pid and the sub-process is monitored, specifically, whether the resource usage of the pid and the sub-process exceeds a resource threshold is judged, and if the resource usage of the pid and the sub-process does not exceed the resource threshold, the resource usage of the pid and the sub-process is continuously monitored; if the resource usage of the pid and the sub-process exceeds the resource threshold, judging the times exceeding the threshold; if the limit times are not exceeded, increasing the times that the resource usage of the ssh process exceeds the resource threshold value, and then continuing to monitor the pid and the resource usage of the sub-process; if the limit number is exceeded, the pid is written into the cgroup resource control group to reach the resource limit, and finally the ip192.168.100.101 and the user name user are written into the blacklist.
In this way, the method for limiting the use of resources of the designated SSH remote connection process provided by the embodiment of the present application implements dynamic and real-time SSH session resource limitation by using the blacklist, the cgroups and the resource monitoring mechanism in combination. Compared with the traditional static resource allocation, the scheme has the following innovation and advantages:
dynamic restriction: by using blacklists and PID dynamic management, specific SSH session resources can be limited in real-time as needed without static configuration. This allows for more flexible and accurate resource limiting of sessions.
And (3) automatic management: an automatic monitoring and limiting mechanism for IP addresses that are not on the list is described in the scheme. If the resource usage exceeds the limit, the system will automatically write the relevant IP address to the blacklist and add the corresponding PID to the resource limit group. This automated management reduces the workload of the administrator.
Customizing the limits: with the cgroups resource restriction function, personalized resource restriction can be performed for different sessions according to requirements. The administrator may configure the corresponding restrictions, such as CPU share, memory restrictions, etc., according to specific requirements.
And the safety is improved: through blacklists and resource restrictions, unauthorized SSH sessions can be prevented from misusing system resources. Only authenticated sessions can acquire proper resource quota, thereby improving the security and stability of the system.
In summary, the invention achieves dynamic and automatic SSH session resource limitation by innovatively combining the blacklist, the cgroups and the resource monitoring mechanism, and has the advantages of improving the system safety and the resource management efficiency.
The foregoing is a secure shell protocol SSH remote connection process management method provided in the embodiments of the present application, and the following is an embodiment of a secure shell protocol SSH remote connection process management device provided in the embodiments of the present application.
Referring to fig. 8, fig. 8 is a schematic structural diagram of an SSH remote connection process management device according to an embodiment of the present application. As shown in fig. 8, the apparatus 800 may be divided into an acquisition unit 810, a first judgment unit 820, a first processing unit 830, a second judgment unit 840, and a second processing unit 850 according to the execution function. Specific implementation process of the device 800 referring to fig. 9, fig. 9 shows a diagram of an implementation process of an SSH remote connection process management device provided in the embodiment of the present application, and as shown in fig. 9, the device 800 in this embodiment is installed on a logged-in server, where the device 800 automatically creates a cgroups resource group to implement resource limitation, and the cgroups resource control group limits 80% cpu usage. The corresponding functions of each unit of the device 800 are specifically as follows:
An obtaining unit 810, configured to obtain a login session identifier of the user in response to the user ssh login connection. The login session identifier of the SSH is the SSH session process PID, and based on the login session identifier, the user ip address and the user name user of the SSH remote connection process SSH which is logged in currently are obtained from the system log.
The first judging unit 820 judges whether the user information is in the blacklist. The information recorded in the blacklist may be, for example, a user id (e.g., 192.168.100.100) and a user name user (e.g., root).
The first processing unit 830 adds the ssh procedure of the user to the cgroup resource control group in case the user information is in the blacklist. Illustratively, the pid of the ssh process is added to the restricted set of cgroup resources, limiting the CPU's resource usage. And in the case that the user information is not in the blacklist, monitoring the resource use condition of the ssh process of the user. Illustratively, the cpu resource usage of the pid and sub-process is monitored.
The second judging unit 840 judges whether the ssh process use resource of the user exceeds the limit condition.
The second processing unit 850 writes the login session identifier of the user to the blacklist in case the ssh process usage resource of the user exceeds the limit condition. Specifically, adding the pid into the restricted cgroup resource group to restrict the resource use of the CPU; and writing the user name user and the user id information into a blacklist. In this way, the device 800 may limit further CPU resource acquisition of the ssh process of the user, thereby ensuring that other processes and tasks in the system can obtain enough CPU resources, ensuring that resource allocation between each user is fair and reasonable, thereby reducing risk of system crash or unavailability, and improving stability and performance of the system.
In one embodiment, the second determining unit 840 is further configured to determine whether the resource usage of the ssh process of the user exceeds a resource threshold; and judging whether the number of times that the resource usage of the ssh process exceeds the resource threshold exceeds the limit number of times under the condition that the resource usage exceeds the resource threshold. The second processing unit 850 is further configured to increase the number of times the resource usage of the ssh process exceeds the resource threshold once, if the number of times the resource usage of the ssh process exceeds the resource threshold does not exceed the limit number of times; and writing the login session identification of the user into the blacklist under the condition that the number of times that the resource usage of the ssh process exceeds the resource threshold exceeds the limit number of times. It should be noted that, the description for determining whether the ssh process of the user uses the resource exceeding the constraint condition is the same as that of fig. 6, and specific reference may be made to the above description, which is not repeated here.
Referring to fig. 10, fig. 10 is a schematic diagram of a system architecture according to an embodiment of the present application. As shown in fig. 10, the system is composed of software of a client and a server. The server is a daemon (daemon) that runs in the background and responds to connection requests from clients. The server, typically a sshd process, provides processing of the remote connection, typically including public key authentication, key exchange, symmetric key encryption, and non-secure connections. The client contains ssh programs and other application programs like scp (remote copy), slogin (remote login), sftp (secure file transfer), etc. The working mechanism is that a local client sends a connection request to a remote server, the server checks the applied packet and IP address and then sends the secret key to the SSH client, and the secret key is sent back to the server locally, so that the connection is established.
The device 800 in the embodiment of the present application is configured on a server, and the server is further configured with ssh service and a cgroup control group. The ssh service on the service end comprises port connection, identity authentication interaction session and system log. Through the system log, the acquisition unit 810 in the apparatus 800 acquires login ip, user information, and session pid. The first judging unit 820 judges whether the login session identifier is in the blacklist. The blacklist records that the user logs in ip+user, and if the blacklist matches, the first processing unit 830 writes the pid into the cgroup control group, and the cgroup control group performs resource restriction on the process through its own cpu resource group, mem resource group, and the like. If the blacklists do not match, the second judging unit 840 judges whether the ssh process resource usage of the user exceeds the limiting condition (exceeds the set resource usage threshold+exceeds the number of times), if the ssh process resource usage exceeds the set resource usage threshold times by more than the limiting number of times, the second processing unit 850 writes ip and user into the blacklist, and then writes pid into the cgroup group to limit the resource.
Compared with the unified limitation of the related art and the indiscriminate resource limitation method, the limitation in the embodiment designates the device for using SSH remote connection process resources, and implements resource limitation for SSH session with a great probability exceeding the resource limitation more precisely and accurately by using the blacklist, the cgroups and the resource monitoring mechanism in combination. The device runs in the system background in real time without manual operation of a system manager, so that the problems of untimely manual management caused by uncertainty of SSH login time, incorrect validation of resource limitation caused by manual error configuration and the like are avoided, and the management efficiency and the system safety are improved to a certain extent.
For a more complete understanding of the present application, the following implementation scenario is presented. This implementation scenario is used to specifically illustrate embodiments of the present application and should not be construed in any way as limiting the scope of the present application.
According to the SSH remote connection process management method and device for the secure shell protocol, through creatively combining the blacklist, the cgroups and the resource monitoring mechanism, more refined, dynamic and real-time SSH session resource limitation is achieved.
Future application scenarios may include:
and (3) safety management: the apparatus may act as a security management tool for limiting resource usage of remote SSH sessions. By setting the blacklist, unauthorized IP addresses and login users can be prevented from accessing the system, thereby enhancing access control to the system. Meanwhile, for authorized IP addresses and login users, the device can monitor and limit the use of resources, such as CPU, memory, disk and other resources, so as to prevent abuse and overuse. This helps to increase the security of the system against malicious attacks and unauthorized access.
And (3) resource optimization: in a server cluster environment, resource usage of SSH sessions may have an impact on overall system performance. By the device, each session can be limited in resources, reasonable allocation of resources occupied by each session is ensured, and the overall performance and stability of the system are improved. By monitoring and limiting the resource usage of SSH sessions, it is possible to avoid that a certain session occupies too much resources, resulting in other sessions being affected, thereby optimizing the utilization efficiency of system resources.
Cloud computing environment: in a cloud computing environment, resource limitation of SSH session can be realized through the device. For cloud server providers, different resource restrictions may be set for different SSH sessions according to customer needs and payment plans, thereby providing customized services. For cloud server users, the device can monitor and control the resource use of own SSH session, thereby avoiding additional cost and performance loss. This helps to increase the flexibility and cost control capability of the cloud service while ensuring a fair allocation of resources among users.
Data center management: in a large data center, resource management of SSH sessions can be achieved by the device. An administrator can set a blacklist according to the needs to limit the specific IP address or the resource use of a user, and the stability and the priority of the key tasks are ensured. This helps the data center administrator to better manage and optimize the allocation of resources, ensure proper operation of critical tasks, and avoid degradation of system performance due to resource contention.
By combining the above, the device 800 provided in the embodiment of the present application may be applied to multiple scenarios such as security management, resource optimization, cloud computing environment, data center management, etc., and by monitoring and limiting the resource usage of the SSH session, the security, performance and resource utilization efficiency of the system are improved.
As shown in fig. 11, a computing device 900 is also provided in an embodiment of the present application. The computing device 900 may include: processor 901, memory 902, communication interface 903, and bus 904. The processor 901, the memory 902 and the communication interface 903 may be connected by a bus 904.
The processor 901 is a control center of the computing device 900, and may be a general-purpose central processing unit such as (central processing unit, CPU), or may be another general-purpose processor. Wherein the general purpose processor may be a microprocessor or any conventional processor or the like. In the embodiment of the present application, the secure shell protocol SSH remote connection process management method may be performed by the processor 901 in the computing device 900.
As an example, the processor 901 may include one or more CPUs.
The memory 902 may be a read-only memory (ROM) device, or may be an electrically erasable programmable read-only memory (EEPROM), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such.
In one possible implementation, the memory 902 may exist independent of the processor 901. The memory 902 may be coupled to the processor 901 via the bus 904 for storing data, instructions or program code. When the processor 901 invokes and executes instructions or program codes stored in the memory 902, the secure shell protocol SSH remote connection process management method provided in the embodiment of the present application can be implemented.
In another possible implementation, the memory 902 may also be integrated with the processor 901.
A communication interface 903 for the computing device 900 to connect with other devices through a communication network, which may be ethernet, a radio access network (radio access network, RAN), a wireless local area network (wireless local area networks, WLAN), etc. The communication interface 903 may include a receiving unit for receiving data and a transmitting unit for transmitting data.
Bus 904, which may be an industry standard architecture (industry standard architecture, ISA) bus, an external device interconnect (peripheral component interconnect, PCI) bus, or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The bus may be classified as an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 11, but not only one bus or one type of bus.
It should be noted that the structure shown in fig. 11 is not limiting of the computing device 900, and the computing device 900 may include more or less components than those shown in fig. 11, or may combine some components, or a different arrangement of components. The computing device includes a processor and a memory, the processor and the memory coupled. The memory is used for storing computer program instructions, and the processor is used for calling the computer program instructions in the memory to execute the SSH remote connection process management method shown in the embodiment. The processor is used for calling the computer program instructions in the memory, and the computing device executes the technical scheme of the corresponding protection as shown in fig. 3-6 and the above, so that the computing device has the technical effect of the technical scheme of the protection.
There is further provided in an embodiment of the present application a computer readable storage medium, on which a computer program is stored, which when executed in a computer causes the computer to perform the secure shell protocol SSH remote connection process management method described in any one of the foregoing fig. 3-6 and corresponding description.
There is further provided in an embodiment of the present application a computer program product storing instructions that, when executed by a computer, cause the computer to implement a secure shell protocol SSH remote connection process management method as set forth in any one of the above figures 3-6 and corresponding description.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.
Furthermore, various aspects or features of embodiments of the present application may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein encompasses a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media can include, but are not limited to, magnetic storage devices (e.g., hard disk, floppy disk, or magnetic strips, etc.), optical disks (e.g., compact disk, CD, digital versatile disk, digital versatiledisc, DVD, etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory, EPROM), cards, sticks, or key drives, etc. Additionally, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media capable of storing, containing, and/or carrying instruction(s) and/or data.
In the above-described embodiment, the secure shell protocol SSH remote connection process management apparatus 800 illustrated in fig. 8 may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.
It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic of the processes, and should not constitute any limitation on the implementation process of the embodiments of the present application.
It will be clearly understood by those skilled in the art that, for convenience and brevity of description, specific working procedures of the apparatus, device and unit described above may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the several embodiments provided in this application, it should be understood that the disclosed apparatus, device, and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or, what contributes to the prior art, or part of the technical solution may be embodied in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, or an access network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
Finally, the above embodiments are only used to illustrate the technical solutions of the present application. It will be appreciated by those skilled in the art that, although the present application has been described in detail with reference to the foregoing embodiments, various modifications may be made to the technical solutions described in the foregoing embodiments, or equivalents may be substituted for some of the technical features thereof. Such modifications and substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.