What is the default idle timeout for OpenSSH?
I can't seem to find an answer to this simple question, which I need for some compliance documentation.
On a default install of CentOS 6.5 (OpenSSH 5.3p1-94.el6), after how long of being idle will a user's SSH session be terminated? I believe the following can be set to increase the idle timeout, but they are commented out by default.
$ grep -i alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
Also, is there a command to dump a list of the current sshd
settings? I don't see anything in man sshd
.
ssh centos openssh
add a comment |
I can't seem to find an answer to this simple question, which I need for some compliance documentation.
On a default install of CentOS 6.5 (OpenSSH 5.3p1-94.el6), after how long of being idle will a user's SSH session be terminated? I believe the following can be set to increase the idle timeout, but they are commented out by default.
$ grep -i alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
Also, is there a command to dump a list of the current sshd
settings? I don't see anything in man sshd
.
ssh centos openssh
2
Some shells can be set to exit after a timeout. That would cause the ssh session to terminate. Check whether your TMOUT environment variable is set.
– Kenster
Aug 20 '14 at 18:38
add a comment |
I can't seem to find an answer to this simple question, which I need for some compliance documentation.
On a default install of CentOS 6.5 (OpenSSH 5.3p1-94.el6), after how long of being idle will a user's SSH session be terminated? I believe the following can be set to increase the idle timeout, but they are commented out by default.
$ grep -i alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
Also, is there a command to dump a list of the current sshd
settings? I don't see anything in man sshd
.
ssh centos openssh
I can't seem to find an answer to this simple question, which I need for some compliance documentation.
On a default install of CentOS 6.5 (OpenSSH 5.3p1-94.el6), after how long of being idle will a user's SSH session be terminated? I believe the following can be set to increase the idle timeout, but they are commented out by default.
$ grep -i alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
Also, is there a command to dump a list of the current sshd
settings? I don't see anything in man sshd
.
ssh centos openssh
ssh centos openssh
asked Aug 15 '14 at 14:07
Banjer
1,78051829
1,78051829
2
Some shells can be set to exit after a timeout. That would cause the ssh session to terminate. Check whether your TMOUT environment variable is set.
– Kenster
Aug 20 '14 at 18:38
add a comment |
2
Some shells can be set to exit after a timeout. That would cause the ssh session to terminate. Check whether your TMOUT environment variable is set.
– Kenster
Aug 20 '14 at 18:38
2
2
Some shells can be set to exit after a timeout. That would cause the ssh session to terminate. Check whether your TMOUT environment variable is set.
– Kenster
Aug 20 '14 at 18:38
Some shells can be set to exit after a timeout. That would cause the ssh session to terminate. Check whether your TMOUT environment variable is set.
– Kenster
Aug 20 '14 at 18:38
add a comment |
5 Answers
5
active
oldest
votes
The commented lines in sshd_config
usually display the defaults. This is the case with all of the lines in your question. You can verify this in the sshd_config
manpage. Here are the relevant snippets:
TCPKeepAlive
Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the
connection or crash of one of the machines will be properly noticed. However, this means that connections will die
if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not
sent, sessions may hang indefinitely on the server, leaving “ghost” users and consuming server resources.
The default is “yes” (to send TCP keepalive messages), and the server will notice if the network goes down or the
client host crashes. This avoids infinitely hanging sessions.
To disable TCP keepalive messages, the value should be set to “no”.
This option was formerly called
KeepAlive
.
ClientAliveCountMax
Sets the number of client alive 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
fromTCPKeepAlive
(below)(above). The client alive messages are sent through the encrypted channel and therefore will not
be spoofable. The TCP keepalive option enabled byTCPKeepAlive
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, andClientAliveCountMax
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.
Correct me if wrong, but if there was no firewall in between me and the machine (w/ default configs), then I'd never be disconnected? I know our firewall drops idle TCP connections after 60 minutes, so that's where the closing idle connections is happening. I just wanted to check and see if OpenSSH itself explicitly closes sessions. I think the answer is No, openssh does not explicitly close idle connections, but firewalls typically do. The settings mentioned in your answer actually help to persist the connection or to properly terminate the session if it sees it's been dropped.
– Banjer
Aug 15 '14 at 15:31
2
The quoted text says that the default for ClientAliveInterval is 0, which means that it doesn't define a time interval for which a connection stays open. And yet we know that the time interval has some finite value by default. Therefore it seems that there must be some other parameter that sets how long the connection stays open by default. If my analysis above is correct, then suppose both server and client are linux machines running openssh, and both are using all the defaults. In this case which side sets the default, what is its value, and where is it set?
– Ben Crowell
Apr 8 '15 at 20:09
1
@BenCrowell And yet we know that the time interval has some finite value by default. What time interval and how do you know this?
– Piotr Dobrogost
Nov 13 '17 at 8:21
add a comment |
You can set up SSH keepalive for either the client or server side:
Client side
File: /etc/ssh/ssh_config
Content:
Host *
ServerAliveInterval XX
ServerAliveCountMax YY
Server side
File: /etc/ssh/sshd_config
Content:
ClientAliveInterval XX
ClientAliveCountMax YY
Extracted from: http://www.sysadmit.com/2016/02/linux-y-vmware-ssh-evitar-desconexion.html
6
Useful, but doesn't answer the question in any way.
– bzeaman
Aug 18 '16 at 9:44
add a comment |
OpenSSH will not terminate a shell session that has been idle for some time. This is not something that OpenSSH does. Terminating an idle shell session is unrelated to the configuration of OpenSSH.
The settings that you are showing are related to timeouts when the connection goes down and are unrelated to the shell on the remote host and what the user is doing or not doing there.
To dump the sshd
configuration, use the "extended test mode" as root:
sshd -T
This is documented in the sshd(8)
manual (looking at OpenSSH_7.7, LibreSSL 2.7.2
on OpenBSD here):
-T
Extended test mode. Check the validity of the configuration
file, output the effective configuration to stdout and then exit.
Optionally, Match rules may be applied by specifying the
connection parameters using one or more-C
options.
This option was added to sshd
for OpenSSH 5.1/5.1p1 in 2008.
add a comment |
If the requirement is to close the SSH connection after a period of inactivity, the shells themselves provide timeout variables.
For bash:
TMOUT: If set to a value greater than zero, TMOUT is treated as
the
default timeout for the read builtin. The select command terminates
if input does not arrive after TMOUT seconds when input is coming from a terminal. In an interactive shell, the value is
interpreted as the number of seconds to wait for input after issuing
the primary prompt. Bash terminates after waiting for that number of
seconds if input does not arrive.
test this by running TMOUT=10
and wait for 10 sec to close the connection.
For tcsh:
The autologout shell variable can be set to log out or lock the shell
after a given number of minutes of inactivity.
In tcsh, the syntax for setting the timeout for ten minutes is set autologout=10
. This doesn't work in the original csh.
add a comment |
If you want the timeout to be 10 seconds for everyone, do the following for the server config (sshd_config):
ClientAliveInterval 10
ClientAliveCountMax 0
If you want the timeout to be 10 seconds for local clients, do the following for the client config (ssh_config):
ServerAliveInterval 10
ServerAliveCountMax 0
If the AliveCountMax parameter is non-zero, it probably won't work because the server will reply resetting the timer (unless there's a connection problem). You can see this by running the ssh client with debugging turned on.
Pure nonsense it is.
– Piotr Dobrogost
Nov 13 '17 at 15:51
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f150402%2fwhat-is-the-default-idle-timeout-for-openssh%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
The commented lines in sshd_config
usually display the defaults. This is the case with all of the lines in your question. You can verify this in the sshd_config
manpage. Here are the relevant snippets:
TCPKeepAlive
Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the
connection or crash of one of the machines will be properly noticed. However, this means that connections will die
if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not
sent, sessions may hang indefinitely on the server, leaving “ghost” users and consuming server resources.
The default is “yes” (to send TCP keepalive messages), and the server will notice if the network goes down or the
client host crashes. This avoids infinitely hanging sessions.
To disable TCP keepalive messages, the value should be set to “no”.
This option was formerly called
KeepAlive
.
ClientAliveCountMax
Sets the number of client alive 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
fromTCPKeepAlive
(below)(above). The client alive messages are sent through the encrypted channel and therefore will not
be spoofable. The TCP keepalive option enabled byTCPKeepAlive
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, andClientAliveCountMax
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.
Correct me if wrong, but if there was no firewall in between me and the machine (w/ default configs), then I'd never be disconnected? I know our firewall drops idle TCP connections after 60 minutes, so that's where the closing idle connections is happening. I just wanted to check and see if OpenSSH itself explicitly closes sessions. I think the answer is No, openssh does not explicitly close idle connections, but firewalls typically do. The settings mentioned in your answer actually help to persist the connection or to properly terminate the session if it sees it's been dropped.
– Banjer
Aug 15 '14 at 15:31
2
The quoted text says that the default for ClientAliveInterval is 0, which means that it doesn't define a time interval for which a connection stays open. And yet we know that the time interval has some finite value by default. Therefore it seems that there must be some other parameter that sets how long the connection stays open by default. If my analysis above is correct, then suppose both server and client are linux machines running openssh, and both are using all the defaults. In this case which side sets the default, what is its value, and where is it set?
– Ben Crowell
Apr 8 '15 at 20:09
1
@BenCrowell And yet we know that the time interval has some finite value by default. What time interval and how do you know this?
– Piotr Dobrogost
Nov 13 '17 at 8:21
add a comment |
The commented lines in sshd_config
usually display the defaults. This is the case with all of the lines in your question. You can verify this in the sshd_config
manpage. Here are the relevant snippets:
TCPKeepAlive
Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the
connection or crash of one of the machines will be properly noticed. However, this means that connections will die
if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not
sent, sessions may hang indefinitely on the server, leaving “ghost” users and consuming server resources.
The default is “yes” (to send TCP keepalive messages), and the server will notice if the network goes down or the
client host crashes. This avoids infinitely hanging sessions.
To disable TCP keepalive messages, the value should be set to “no”.
This option was formerly called
KeepAlive
.
ClientAliveCountMax
Sets the number of client alive 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
fromTCPKeepAlive
(below)(above). The client alive messages are sent through the encrypted channel and therefore will not
be spoofable. The TCP keepalive option enabled byTCPKeepAlive
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, andClientAliveCountMax
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.
Correct me if wrong, but if there was no firewall in between me and the machine (w/ default configs), then I'd never be disconnected? I know our firewall drops idle TCP connections after 60 minutes, so that's where the closing idle connections is happening. I just wanted to check and see if OpenSSH itself explicitly closes sessions. I think the answer is No, openssh does not explicitly close idle connections, but firewalls typically do. The settings mentioned in your answer actually help to persist the connection or to properly terminate the session if it sees it's been dropped.
– Banjer
Aug 15 '14 at 15:31
2
The quoted text says that the default for ClientAliveInterval is 0, which means that it doesn't define a time interval for which a connection stays open. And yet we know that the time interval has some finite value by default. Therefore it seems that there must be some other parameter that sets how long the connection stays open by default. If my analysis above is correct, then suppose both server and client are linux machines running openssh, and both are using all the defaults. In this case which side sets the default, what is its value, and where is it set?
– Ben Crowell
Apr 8 '15 at 20:09
1
@BenCrowell And yet we know that the time interval has some finite value by default. What time interval and how do you know this?
– Piotr Dobrogost
Nov 13 '17 at 8:21
add a comment |
The commented lines in sshd_config
usually display the defaults. This is the case with all of the lines in your question. You can verify this in the sshd_config
manpage. Here are the relevant snippets:
TCPKeepAlive
Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the
connection or crash of one of the machines will be properly noticed. However, this means that connections will die
if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not
sent, sessions may hang indefinitely on the server, leaving “ghost” users and consuming server resources.
The default is “yes” (to send TCP keepalive messages), and the server will notice if the network goes down or the
client host crashes. This avoids infinitely hanging sessions.
To disable TCP keepalive messages, the value should be set to “no”.
This option was formerly called
KeepAlive
.
ClientAliveCountMax
Sets the number of client alive 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
fromTCPKeepAlive
(below)(above). The client alive messages are sent through the encrypted channel and therefore will not
be spoofable. The TCP keepalive option enabled byTCPKeepAlive
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, andClientAliveCountMax
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.
The commented lines in sshd_config
usually display the defaults. This is the case with all of the lines in your question. You can verify this in the sshd_config
manpage. Here are the relevant snippets:
TCPKeepAlive
Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the
connection or crash of one of the machines will be properly noticed. However, this means that connections will die
if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not
sent, sessions may hang indefinitely on the server, leaving “ghost” users and consuming server resources.
The default is “yes” (to send TCP keepalive messages), and the server will notice if the network goes down or the
client host crashes. This avoids infinitely hanging sessions.
To disable TCP keepalive messages, the value should be set to “no”.
This option was formerly called
KeepAlive
.
ClientAliveCountMax
Sets the number of client alive 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
fromTCPKeepAlive
(below)(above). The client alive messages are sent through the encrypted channel and therefore will not
be spoofable. The TCP keepalive option enabled byTCPKeepAlive
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, andClientAliveCountMax
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.
edited Mar 12 '18 at 22:11
G-Man
13k93365
13k93365
answered Aug 15 '14 at 14:24
jordanm
30.3k28392
30.3k28392
Correct me if wrong, but if there was no firewall in between me and the machine (w/ default configs), then I'd never be disconnected? I know our firewall drops idle TCP connections after 60 minutes, so that's where the closing idle connections is happening. I just wanted to check and see if OpenSSH itself explicitly closes sessions. I think the answer is No, openssh does not explicitly close idle connections, but firewalls typically do. The settings mentioned in your answer actually help to persist the connection or to properly terminate the session if it sees it's been dropped.
– Banjer
Aug 15 '14 at 15:31
2
The quoted text says that the default for ClientAliveInterval is 0, which means that it doesn't define a time interval for which a connection stays open. And yet we know that the time interval has some finite value by default. Therefore it seems that there must be some other parameter that sets how long the connection stays open by default. If my analysis above is correct, then suppose both server and client are linux machines running openssh, and both are using all the defaults. In this case which side sets the default, what is its value, and where is it set?
– Ben Crowell
Apr 8 '15 at 20:09
1
@BenCrowell And yet we know that the time interval has some finite value by default. What time interval and how do you know this?
– Piotr Dobrogost
Nov 13 '17 at 8:21
add a comment |
Correct me if wrong, but if there was no firewall in between me and the machine (w/ default configs), then I'd never be disconnected? I know our firewall drops idle TCP connections after 60 minutes, so that's where the closing idle connections is happening. I just wanted to check and see if OpenSSH itself explicitly closes sessions. I think the answer is No, openssh does not explicitly close idle connections, but firewalls typically do. The settings mentioned in your answer actually help to persist the connection or to properly terminate the session if it sees it's been dropped.
– Banjer
Aug 15 '14 at 15:31
2
The quoted text says that the default for ClientAliveInterval is 0, which means that it doesn't define a time interval for which a connection stays open. And yet we know that the time interval has some finite value by default. Therefore it seems that there must be some other parameter that sets how long the connection stays open by default. If my analysis above is correct, then suppose both server and client are linux machines running openssh, and both are using all the defaults. In this case which side sets the default, what is its value, and where is it set?
– Ben Crowell
Apr 8 '15 at 20:09
1
@BenCrowell And yet we know that the time interval has some finite value by default. What time interval and how do you know this?
– Piotr Dobrogost
Nov 13 '17 at 8:21
Correct me if wrong, but if there was no firewall in between me and the machine (w/ default configs), then I'd never be disconnected? I know our firewall drops idle TCP connections after 60 minutes, so that's where the closing idle connections is happening. I just wanted to check and see if OpenSSH itself explicitly closes sessions. I think the answer is No, openssh does not explicitly close idle connections, but firewalls typically do. The settings mentioned in your answer actually help to persist the connection or to properly terminate the session if it sees it's been dropped.
– Banjer
Aug 15 '14 at 15:31
Correct me if wrong, but if there was no firewall in between me and the machine (w/ default configs), then I'd never be disconnected? I know our firewall drops idle TCP connections after 60 minutes, so that's where the closing idle connections is happening. I just wanted to check and see if OpenSSH itself explicitly closes sessions. I think the answer is No, openssh does not explicitly close idle connections, but firewalls typically do. The settings mentioned in your answer actually help to persist the connection or to properly terminate the session if it sees it's been dropped.
– Banjer
Aug 15 '14 at 15:31
2
2
The quoted text says that the default for ClientAliveInterval is 0, which means that it doesn't define a time interval for which a connection stays open. And yet we know that the time interval has some finite value by default. Therefore it seems that there must be some other parameter that sets how long the connection stays open by default. If my analysis above is correct, then suppose both server and client are linux machines running openssh, and both are using all the defaults. In this case which side sets the default, what is its value, and where is it set?
– Ben Crowell
Apr 8 '15 at 20:09
The quoted text says that the default for ClientAliveInterval is 0, which means that it doesn't define a time interval for which a connection stays open. And yet we know that the time interval has some finite value by default. Therefore it seems that there must be some other parameter that sets how long the connection stays open by default. If my analysis above is correct, then suppose both server and client are linux machines running openssh, and both are using all the defaults. In this case which side sets the default, what is its value, and where is it set?
– Ben Crowell
Apr 8 '15 at 20:09
1
1
@BenCrowell And yet we know that the time interval has some finite value by default. What time interval and how do you know this?
– Piotr Dobrogost
Nov 13 '17 at 8:21
@BenCrowell And yet we know that the time interval has some finite value by default. What time interval and how do you know this?
– Piotr Dobrogost
Nov 13 '17 at 8:21
add a comment |
You can set up SSH keepalive for either the client or server side:
Client side
File: /etc/ssh/ssh_config
Content:
Host *
ServerAliveInterval XX
ServerAliveCountMax YY
Server side
File: /etc/ssh/sshd_config
Content:
ClientAliveInterval XX
ClientAliveCountMax YY
Extracted from: http://www.sysadmit.com/2016/02/linux-y-vmware-ssh-evitar-desconexion.html
6
Useful, but doesn't answer the question in any way.
– bzeaman
Aug 18 '16 at 9:44
add a comment |
You can set up SSH keepalive for either the client or server side:
Client side
File: /etc/ssh/ssh_config
Content:
Host *
ServerAliveInterval XX
ServerAliveCountMax YY
Server side
File: /etc/ssh/sshd_config
Content:
ClientAliveInterval XX
ClientAliveCountMax YY
Extracted from: http://www.sysadmit.com/2016/02/linux-y-vmware-ssh-evitar-desconexion.html
6
Useful, but doesn't answer the question in any way.
– bzeaman
Aug 18 '16 at 9:44
add a comment |
You can set up SSH keepalive for either the client or server side:
Client side
File: /etc/ssh/ssh_config
Content:
Host *
ServerAliveInterval XX
ServerAliveCountMax YY
Server side
File: /etc/ssh/sshd_config
Content:
ClientAliveInterval XX
ClientAliveCountMax YY
Extracted from: http://www.sysadmit.com/2016/02/linux-y-vmware-ssh-evitar-desconexion.html
You can set up SSH keepalive for either the client or server side:
Client side
File: /etc/ssh/ssh_config
Content:
Host *
ServerAliveInterval XX
ServerAliveCountMax YY
Server side
File: /etc/ssh/sshd_config
Content:
ClientAliveInterval XX
ClientAliveCountMax YY
Extracted from: http://www.sysadmit.com/2016/02/linux-y-vmware-ssh-evitar-desconexion.html
edited Jul 4 '16 at 5:05
Olathe
1715
1715
answered Feb 12 '16 at 22:12
Yamanoteone
7111
7111
6
Useful, but doesn't answer the question in any way.
– bzeaman
Aug 18 '16 at 9:44
add a comment |
6
Useful, but doesn't answer the question in any way.
– bzeaman
Aug 18 '16 at 9:44
6
6
Useful, but doesn't answer the question in any way.
– bzeaman
Aug 18 '16 at 9:44
Useful, but doesn't answer the question in any way.
– bzeaman
Aug 18 '16 at 9:44
add a comment |
OpenSSH will not terminate a shell session that has been idle for some time. This is not something that OpenSSH does. Terminating an idle shell session is unrelated to the configuration of OpenSSH.
The settings that you are showing are related to timeouts when the connection goes down and are unrelated to the shell on the remote host and what the user is doing or not doing there.
To dump the sshd
configuration, use the "extended test mode" as root:
sshd -T
This is documented in the sshd(8)
manual (looking at OpenSSH_7.7, LibreSSL 2.7.2
on OpenBSD here):
-T
Extended test mode. Check the validity of the configuration
file, output the effective configuration to stdout and then exit.
Optionally, Match rules may be applied by specifying the
connection parameters using one or more-C
options.
This option was added to sshd
for OpenSSH 5.1/5.1p1 in 2008.
add a comment |
OpenSSH will not terminate a shell session that has been idle for some time. This is not something that OpenSSH does. Terminating an idle shell session is unrelated to the configuration of OpenSSH.
The settings that you are showing are related to timeouts when the connection goes down and are unrelated to the shell on the remote host and what the user is doing or not doing there.
To dump the sshd
configuration, use the "extended test mode" as root:
sshd -T
This is documented in the sshd(8)
manual (looking at OpenSSH_7.7, LibreSSL 2.7.2
on OpenBSD here):
-T
Extended test mode. Check the validity of the configuration
file, output the effective configuration to stdout and then exit.
Optionally, Match rules may be applied by specifying the
connection parameters using one or more-C
options.
This option was added to sshd
for OpenSSH 5.1/5.1p1 in 2008.
add a comment |
OpenSSH will not terminate a shell session that has been idle for some time. This is not something that OpenSSH does. Terminating an idle shell session is unrelated to the configuration of OpenSSH.
The settings that you are showing are related to timeouts when the connection goes down and are unrelated to the shell on the remote host and what the user is doing or not doing there.
To dump the sshd
configuration, use the "extended test mode" as root:
sshd -T
This is documented in the sshd(8)
manual (looking at OpenSSH_7.7, LibreSSL 2.7.2
on OpenBSD here):
-T
Extended test mode. Check the validity of the configuration
file, output the effective configuration to stdout and then exit.
Optionally, Match rules may be applied by specifying the
connection parameters using one or more-C
options.
This option was added to sshd
for OpenSSH 5.1/5.1p1 in 2008.
OpenSSH will not terminate a shell session that has been idle for some time. This is not something that OpenSSH does. Terminating an idle shell session is unrelated to the configuration of OpenSSH.
The settings that you are showing are related to timeouts when the connection goes down and are unrelated to the shell on the remote host and what the user is doing or not doing there.
To dump the sshd
configuration, use the "extended test mode" as root:
sshd -T
This is documented in the sshd(8)
manual (looking at OpenSSH_7.7, LibreSSL 2.7.2
on OpenBSD here):
-T
Extended test mode. Check the validity of the configuration
file, output the effective configuration to stdout and then exit.
Optionally, Match rules may be applied by specifying the
connection parameters using one or more-C
options.
This option was added to sshd
for OpenSSH 5.1/5.1p1 in 2008.
edited Apr 12 '18 at 16:15
answered Apr 12 '18 at 15:35
Kusalananda
122k16230375
122k16230375
add a comment |
add a comment |
If the requirement is to close the SSH connection after a period of inactivity, the shells themselves provide timeout variables.
For bash:
TMOUT: If set to a value greater than zero, TMOUT is treated as
the
default timeout for the read builtin. The select command terminates
if input does not arrive after TMOUT seconds when input is coming from a terminal. In an interactive shell, the value is
interpreted as the number of seconds to wait for input after issuing
the primary prompt. Bash terminates after waiting for that number of
seconds if input does not arrive.
test this by running TMOUT=10
and wait for 10 sec to close the connection.
For tcsh:
The autologout shell variable can be set to log out or lock the shell
after a given number of minutes of inactivity.
In tcsh, the syntax for setting the timeout for ten minutes is set autologout=10
. This doesn't work in the original csh.
add a comment |
If the requirement is to close the SSH connection after a period of inactivity, the shells themselves provide timeout variables.
For bash:
TMOUT: If set to a value greater than zero, TMOUT is treated as
the
default timeout for the read builtin. The select command terminates
if input does not arrive after TMOUT seconds when input is coming from a terminal. In an interactive shell, the value is
interpreted as the number of seconds to wait for input after issuing
the primary prompt. Bash terminates after waiting for that number of
seconds if input does not arrive.
test this by running TMOUT=10
and wait for 10 sec to close the connection.
For tcsh:
The autologout shell variable can be set to log out or lock the shell
after a given number of minutes of inactivity.
In tcsh, the syntax for setting the timeout for ten minutes is set autologout=10
. This doesn't work in the original csh.
add a comment |
If the requirement is to close the SSH connection after a period of inactivity, the shells themselves provide timeout variables.
For bash:
TMOUT: If set to a value greater than zero, TMOUT is treated as
the
default timeout for the read builtin. The select command terminates
if input does not arrive after TMOUT seconds when input is coming from a terminal. In an interactive shell, the value is
interpreted as the number of seconds to wait for input after issuing
the primary prompt. Bash terminates after waiting for that number of
seconds if input does not arrive.
test this by running TMOUT=10
and wait for 10 sec to close the connection.
For tcsh:
The autologout shell variable can be set to log out or lock the shell
after a given number of minutes of inactivity.
In tcsh, the syntax for setting the timeout for ten minutes is set autologout=10
. This doesn't work in the original csh.
If the requirement is to close the SSH connection after a period of inactivity, the shells themselves provide timeout variables.
For bash:
TMOUT: If set to a value greater than zero, TMOUT is treated as
the
default timeout for the read builtin. The select command terminates
if input does not arrive after TMOUT seconds when input is coming from a terminal. In an interactive shell, the value is
interpreted as the number of seconds to wait for input after issuing
the primary prompt. Bash terminates after waiting for that number of
seconds if input does not arrive.
test this by running TMOUT=10
and wait for 10 sec to close the connection.
For tcsh:
The autologout shell variable can be set to log out or lock the shell
after a given number of minutes of inactivity.
In tcsh, the syntax for setting the timeout for ten minutes is set autologout=10
. This doesn't work in the original csh.
edited 2 days ago
mosvy
6,1761425
6,1761425
answered Apr 12 '18 at 15:27
Sandeep kumar singh
111
111
add a comment |
add a comment |
If you want the timeout to be 10 seconds for everyone, do the following for the server config (sshd_config):
ClientAliveInterval 10
ClientAliveCountMax 0
If you want the timeout to be 10 seconds for local clients, do the following for the client config (ssh_config):
ServerAliveInterval 10
ServerAliveCountMax 0
If the AliveCountMax parameter is non-zero, it probably won't work because the server will reply resetting the timer (unless there's a connection problem). You can see this by running the ssh client with debugging turned on.
Pure nonsense it is.
– Piotr Dobrogost
Nov 13 '17 at 15:51
add a comment |
If you want the timeout to be 10 seconds for everyone, do the following for the server config (sshd_config):
ClientAliveInterval 10
ClientAliveCountMax 0
If you want the timeout to be 10 seconds for local clients, do the following for the client config (ssh_config):
ServerAliveInterval 10
ServerAliveCountMax 0
If the AliveCountMax parameter is non-zero, it probably won't work because the server will reply resetting the timer (unless there's a connection problem). You can see this by running the ssh client with debugging turned on.
Pure nonsense it is.
– Piotr Dobrogost
Nov 13 '17 at 15:51
add a comment |
If you want the timeout to be 10 seconds for everyone, do the following for the server config (sshd_config):
ClientAliveInterval 10
ClientAliveCountMax 0
If you want the timeout to be 10 seconds for local clients, do the following for the client config (ssh_config):
ServerAliveInterval 10
ServerAliveCountMax 0
If the AliveCountMax parameter is non-zero, it probably won't work because the server will reply resetting the timer (unless there's a connection problem). You can see this by running the ssh client with debugging turned on.
If you want the timeout to be 10 seconds for everyone, do the following for the server config (sshd_config):
ClientAliveInterval 10
ClientAliveCountMax 0
If you want the timeout to be 10 seconds for local clients, do the following for the client config (ssh_config):
ServerAliveInterval 10
ServerAliveCountMax 0
If the AliveCountMax parameter is non-zero, it probably won't work because the server will reply resetting the timer (unless there's a connection problem). You can see this by running the ssh client with debugging turned on.
answered Mar 3 '17 at 18:35
JohnA
1
1
Pure nonsense it is.
– Piotr Dobrogost
Nov 13 '17 at 15:51
add a comment |
Pure nonsense it is.
– Piotr Dobrogost
Nov 13 '17 at 15:51
Pure nonsense it is.
– Piotr Dobrogost
Nov 13 '17 at 15:51
Pure nonsense it is.
– Piotr Dobrogost
Nov 13 '17 at 15:51
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f150402%2fwhat-is-the-default-idle-timeout-for-openssh%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Some shells can be set to exit after a timeout. That would cause the ssh session to terminate. Check whether your TMOUT environment variable is set.
– Kenster
Aug 20 '14 at 18:38