Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "how to solve the problem of Centos overtime exit". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

I. explanation

In the evaluation of the host for equal protection, you need to query the configuration of the host's timeout exit. Specifically in centos, there are two main ways to achieve the function of timeout exit. In fact, there is a lot of information in this area, but there are still some areas that are not clear (a parameter of sshd_config), so one of the purposes of this article is to explain those problems clearly.

Note: I am using centos6

Second, set the tmout mode

This is a more general, simple way, by setting tmout, you can at least login to the local tty and remote use of ssh login users, but should not be effective on the graphical interface, of course, you enter the graphical interface and then open the terminal, for the open terminal is also effective.

2.1. Mode of realization

You can add export tmout=900 statements (in seconds) at the end of / etc/profile, ~ / .bashrc, ~ / .bash_profile and other files, and then you need to parse the above files with the source command if you want to take effect without logging in again.

In the above file, / etc/profile works for all users, while ~ / .bashrc and ~ / .bash_profile only have an effect on the current user, which can actually be seen from the location of the file.

2.2. Specific query mode

As you can see from the above, tmout can theoretically be configured in several places, but generally all users should be set in the / etc/profile file, and timeouts may be configured individually for each user.

So look directly at the contents of the / etc/profile file, and then use the echo $tmout statement to see how many tmout variables are in the runtime.

2.3. Configure the points for attention of the query

One more point here, when checking the configuration, it is best to check the configuration file and the actual situation of the linux system together.

Why do you want to check together?

Just because it's written in the configuration file doesn't mean it works. For example, you need to use the source command after / etc/profile modification to take effect. In addition, even if the configuration in the configuration file works, it is not necessarily the same as the rules actually implemented now.

For example, iptables's rules can be dynamically modified with commands, of course, without command persistence (that is, storing the current rules in iptables's configuration file), the temporary rules for restarting the iptables service will be gone.

So again, just because nothing is written in the configuration file doesn't mean there are no rules in the running environment, such as iptables rules that can be temporarily added with commands.

Therefore, if you want to have a more comprehensive understanding of the situation during the evaluation, it is best to check it together.

Third, modify the mode of sshd_config files

Generally speaking, linux servers are managed remotely through the ssh protocol, so configuring sshd_config files is also a way, although it is only valid for all users who log in through ssh.

Remember that you need to restart after modifying the sshd_config file to take effect.

There are two parameters in the sshd_config file, clientaliveinterval and clientalivecountmax.

It seems not clear on the Internet that there are two effects here according to whether the value of clientalivecountmax is 0 or not.

3.1. The value of clientalivecountmax is 0

In this case, it is the effect of automatic exit of the desired operation timeout, that is, when the client does not operate, the server will directly disconnect the ssh connection.

This "how long" is of course determined by the value of clientaliveinterval, which is measured in seconds.

For example, if the clientaliveinterval is 600 and the clientalivecountmax is 0, it means that if the terminal does not operate within 600 seconds, the ssh connection will be disconnected.

3.2. The value of clientalivecountmax is greater than 0

In this case, it is different from what we want:

Clientaliveinterval: specifies the time interval for the server to request messages from the client. The default value is 0: the default is 0: the maximum number of times the client does not respond after the request is sent by the server (but the Internet generally says how many times the server sends such messages to the client, which I don't think is quite right). The default is 3.

If clientaliveinterval is 60 minutes and clientalivecountmax is 1, on the surface, it means that if the client does not respond within 60 seconds, the server will send a request to the client to determine whether it exists, and if there is no reply for 60 seconds, it will disconnect.

So at first glance, there is no difference between the value of clientalivecountmax and the value of 0, or it cannot be disconnected automatically if it is not operated in 60 seconds.

But in fact, it is different at all, because when the server sends a request to the client to determine whether it exists, the client should reply automatically. At the same time, clientalivecountmax does not mean how many times such a message will be sent, or it seems to have nothing to do with this at all. It should refer to the maximum number of times that the client does not respond after the server sends such a request, and it has to be continuous. Because from the source code (see below), as long as there is a normal response, this number of times will be cleared.

In other words, what should be judged here is whether there is something wrong with the network on the client side, such as being disconnected and so on.

Because as long as the network is normal, the client side will always automatically reply to the request sent by the server, then this count will never reach the limited threshold of 1, and will never automatically exit (ideally). It has nothing to do with whether you have done anything or not.

I tested it myself and set the clientaliveinterval to 60 minutes clientalivecountmax setting 1, then I didn't do it all the time, and I turned off the option to keep active in xshell:

The result is that there is no automatic exit after 60 seconds.

Then I set both clientaliveinterval and clientalivecountmax to 1, and the result is that the server sends a message every second (the arrow lights up when a message is transmitted):

If, according to the explanation on the Internet, only one such message is sent to end the conversation, it doesn't make any sense at all. It has been sent to me countless times.

I went to see the explanation in man, but I didn't see why:

Clientalivecountmax sets the number of clientalive messages (see below) which may be sent without sshd (8) receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. It is important to note that the use of client alive messages is very different from tcpkeepalive (below). The client alive messages are sent through the encrypted channel and therefore will not be spoofable. The tcpkeepalive option enabled by tcpkeepalive is spoofable. The client alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive. The default value is 3. If clientaliveinterval (see below) is set to 15, and clientalivecountmax is left at the default, unresponsive ssh clients will be disconnected after approximately 45 seconds. This option applies to protocol version 2 only.clientaliveinterval sets a timeout interval in seconds after which if no data has been received from the client, sshd (8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. This option applies to protocol version 2 only.3.3. Source code interpretation

So I went through the source code, but I was not familiar with the c language, so I could only guess (forgive me for any mistakes):

There is a paragraph in the wait_until_can_do_something function:

/ * wait for something to happen, or the timeout to expire. * / ret = select ((* maxfdp) + 1, * readsetp, * writesetp, null, tvp); if (ret =-1) {memset (* readsetp, 0, * nallocp); memset (* writesetp, 0, * nallocp); if (errno! = eintr) error ("select:% .100s", strerror (errno)) } else {if (ret = = 0 & & client_alive_scheduled) client_alive_check (); if (! compat20 & & program_alive_scheduled & & fdin_is_tty) {if (! fdout_eof) fd_set (fdout, * readsetp) If (! fderr_eof) fd_set (fderr, * readsetp);}}

The definition of the select function is as follows:

Int select (int maxfdp,fd_set * readfds,fd_set * writefds,fd_set * errorfds,struct timeval*timeout)

It can monitor the changes in the file descriptor we need to monitor-read, write or exception, its last parameter timeval*timeout is a timeout, if the value of timeout is greater than 0, this is the timeout for waiting, that is, select blocks within the timeout time, and an event arrives within the timeout time to return, otherwise it must be returned anyway after the timeout.

If the value of timeout is null, it means that the select is placed in a blocking state until one of the file descriptors in the monitoring file descriptor collection changes.

A return value of-1 indicates an exception, and a value of 0 means that the monitored files are neither writable nor readable during the timeout period. In other words, a value of 0 means that there is no action on the client.

In the code, under certain conditions, the value of this timeout is the value of clientaliveinterval we set (if the setting value is greater than 0). If clientaliveinterval is 0, then the value of timeout is null according to some conditions.

Then, according to the value of client_alive_scheduled, it is possible to call client_alive_check (), but if you use the ssh2 protocol and then set clientaliveinterval, the value of client_alive_scheduled should be 1, as follows:

If (compat20 & & max_time_milliseconds = = 0 & & options.client_alive_interval) {client_alive_scheduled = 1; max_time_milliseconds = options.client_alive_interval * 1000;}

Client_alive_check is defined as follows:

Static voidclient_alive_check (void) {int channel_id; / * timeout, check to see how many we have had * / if (packet_inc_alive_timeouts () > options.client_alive_count_max) {logit ("timeout, client not responding."); cleanup_exit } / * * send a bogus global/channel request with "wantreply", * we should get back a failure * / if ((channel_id = channel_find_open ()) =-1) {packet_start (ssh2_msg_global_request); packet_put_cstring ("keepalive@openssh.com") Packet_put_char (1); / * boolean: want reply * /} else {channel_request_start (channel_id, "keepalive@openssh.com", 1);} packet_send ();}

You can see that if packet_inc_alive_timeouts () is greater than options.client_alive_count_max, it's over.

The definition of packet_inc_alive_timeouts is very simple, which is to add 1 to the accumulated timeouts and return.

Intpacket_inc_alive_timeouts (void) {return + + active_state- > keep_alive_timeouts;}

So, if the clientalivecountmax is set to 0, it ends here (0: 1 > 0), and the following code to send the request is not executed.

If (channel_id = channel_find_open ()) is not-1, which should mean that channel is OK, it will be executed:

Channel_request_start (channel_id, "keepalive@openssh.com", 1)

There is a sentence in channel_request_start:

Packet_start (ssh2_msg_channel_request)

Ssh2_msg_channel_request should be bound to a function.

Dispatch_set (ssh2_msg_channel_request, & server_input_channel_req)

So the server_input_channel_req function is called, and the server_input_channel_req function has this paragraph:

Reply = packet_get_char ();. If (reply) {packet_start (success? Ssh2_msg_channel_success: ssh2_msg_channel_failure); packet_put_int (c-> remote_id); packet_send ();}

Here, another function is called according to the value of success. In fact, it is as if the called function is the same:

Dispatch_set (ssh2_msg_channel_success, & server_input_keep_alive); dispatch_set (ssh2_msg_channel_failure, & server_input_keep_alive); dispatch_set (ssh2_msg_request_success, & server_input_keep_alive); dispatch_set (ssh2_msg_request_failure, & server_input_keep_alive)

They are all server_input_keep_alive functions, so the meaning of this function is very simple:

Static voidserver_input_keep_alive (int type, u_int32_t seq, void * ctxt) {debug ("got% dmax% u for keepalive", type, seq); / * reset timeout, since we got a sane answer from the client. * even if this was generated by something other than * the bogus channel_request we send for keepalives. * / packet_set_alive_timeouts (0);}

Packet_set_alive_timeouts (0) sets the value of active_state- > keep_alive_timeouts to 0, which resets the count.

So with a break, the meaning of the code should be like this: if the client does not respond within a specified period of time, it will first determine whether the number of unresponded times exceeds the set value, and if so, it will end.

If it does not exceed, add this number to 1, and then send a request to see if the client is still there. If the client network is normal (which should reply automatically), you will get a reply from the client, so the unresponded count will be reset.

Fourth, the difference between the two ways

The tmout method works for all users when logging in through local tty or remote ssh, while modifying sshd_config is only for users who log in using ssh.

Another point is that tmout determines whether you are operating or not, as if to see if you have typed any characters and then hit enter to execute, you enter the correct command and hit enter to execute the command, even if. Enter meaningless characters and hit enter and don't find an executable command, that counts. It doesn't count if you just enter characters and don't hit enter, but if you judge that you are idle, you will log out when you time out.

And ssh is based on the network to judge, as long as the client sends information to the server, then it is in operation.

This is also some subtle difference between the two.

This is the end of the content of "how to solve the problem of Centos overtime exit". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.