Linux время ssh сессии

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 .

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.

7 Answers 7

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:

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 .

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 from TCPKeepAlive (below) (above). The client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive 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.

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.

Источник

How to Keeping SSH Session Alive in Linux

SSH or Secure Shell is an invaluable utility when it comes to undertaking remote login objectives on remote machines. For Linux users, the SSH utility offers more than just remote login solutions.

The mentioned users are also able to effortlessly accomplish Linux administrative tasks. Regardless of whether the targeted remote machine is untrustworthy or whether the network that facilitates the communication between the two machines is insecure, SSH ensures that these communications are secure and encrypted.

It is sometimes frustrating when an SSH session ends too soon while we are multitasking on the Linux terminal environment. Finding a way of keeping the SSH session alive for as long as possible can be a game changer for Linux users who don’t want to keep on re-initiating new SSH sessions.

This article will walk us through the needed steps that will help us keep any SSH session alive as long as possible until we manually decide to close the Linux terminal window.

Prerequisites

• Have openssh-client installed on the Linux system initiating the SSH connection (client machine).
• Have openssh-server installed on the remote Linux system receiving the initiated SSH connection (server machine).

Why SSH Sessions End

Usually, it is the ssh daemon running on the server machine that makes it possible for an ssh connection from the client machine to be possible. If the SSH connection is successful and the server and client machines do not periodically communicate, the server machine closes the connection after some fixed grace period.

To address this issue, we have made some configuration changes on an SSH config file on either the server or client machine.

When SSH Connection is Coming from the Client Machine

On the client machine, the SSH config file should be located at $HOME/.ssh/config. If it does not exist, we will need to create it.

$ cat $HOME/.ssh/config OR $ touch $HOME/.ssh/config

Use the chmod command to reserve the read and write privileges of this file only to the current user and no other user. In short, we are keeping this file access private.

Let us now open and add some ssh rules to this file, you can use a text editor of your choice if needed.

Add the following lines in the file before saving and closing it.

Host * ServerAliveInterval 300



If your SSH connection is tied to a specific host, you could edit the above file entry to look like the following:

Host my_hostname.com ServerAliveInterval 300

From the above demonstration, the client machine will wait for 300 seconds before allowing the server machine to close the ssh connection.

When SSH Connection is Coming from the Server Machine

You might also find yourself in circumstances where you need to use your server machine or a remote machine to access a client.

On the server machine, access and open the file /etc/ssh/sshd_config or /etc/ssh/ssh_config as its naming convention sometimes depends on the Linux OS distribution in use.

$ sudo nano /etc/ssh/ssh_config

Since we are after an ssh connection to a client machine, add the following key value at the bottom of the file:



This value ensures that the SSH connection lasts for 300 seconds before the connection is timed out.

It is also advisable to set a timeout value when accessing machines from hosting platforms to avoid high run-up costs especially when their billings are per minute.

When using the client machine for ssh connection, your updated config values in the file $HOME/.ssh/config will look like this:

Host * ServerAliveInterval 300 ServerAliveCountMax 2

When using a server machine for an ssh connection, your updated config values in the file /etc/ssh/ssh_config will look like this:

ClientAliveInterval 300 ClientAliveCountMax 2

We can now comfortably handle ssh sessions without worrying about unexpected timeouts. Hope you enjoyed the article. Feel free to leave a comment or feedback.

Источник

Set SSH idle timeout Ubuntu 20.04

I would expect sshd not to send KeepAlive-Packages due to TCPKeepAlive and ClientAliveCountMax — and my sessions to timeout after 30 seconds. On top of that I think TCPKeepAlive could be left at its default which should be yes . I’ve checked existing sessions like that:

root@:/etc/apache2# w 06:53:51 up 2 days, 21:25, 2 users, load average: 0,00, 0,00, 0,00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT _____-ad pts/0 ____________ Do11 6.00s 0.99s 0.00s sshd: _____-admin [priv] _____-us pts/1 ____________ 06:40 13:26 0.02s 0.02s -bash 

root@:/etc/apache2# sshd -T | grep -i "ClientAlive" clientaliveinterval 30 clientalivecountmax 0 

Could the client still be sending KeepAlive-Packages? I cannot control all versions of clients that connect.. References: https://www.golinuxcloud.com/disconnect-idle-ssh-session-tcpkeepaliv-linux/ https://secscan.acron.pl/centos7/5/2/13 EDIT: TCPKeepAlive yes doesn’t change the behaviour, sessions still linger. I also started a new session after I restarted sshd to avoid having old settings in my ssh-session. EDIT2: Added keyword «incoming» to the description above to make it clearer, that I want my ssh server (sshd) to drop connections after an idle timeout, because users might forget about their open (and unsed) ssh sessions. EDIT3: Just for information — used sshd version:

root@:/etc/apache2# dpkg -l openssh-server Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/ Halb installiert/Trigger erWartet/Trigger anhängig |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht) ||/ Name Version Architektur Beschreibung +++-==============-==================-============-================================================================= ii openssh-server 1:8.2p1-4ubuntu0.1 amd64 secure shell (SSH) server, for secure access from remote machines root@:/etc/apache2# sshd -V unknown option -- V OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020 

• Debian 10 (OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019)*
• Ubuntu 16.04 (OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016)

*For Debian 10 I wanted to compare sshd -T . Options that differ: casignaturealgorithms , gssapikexalgorithms , hostbasedacceptedkeytypes , hostkeyalgorithms , kexalgorithms , passwordauthentication , permitrootlogin , pubkeyacceptedkeytypes , pubkeyauthoptions , securitykeyprovider

I’ve only set passwordauthentication no

I’ve connected from the same host, the only difference is I used pubkey authentication for the server in question and password authentication for the Debian 10 server.

Sorry that it’s getting long.. It kinda turns into a bug report..

• ClientAliveInterval 10 , ClientAliveCountMax 3 : ssh -v records the message debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1 every 10 seconds
• ClientAliveInterval 10 , ClientAliveCountMax 0 : session disconnects after 10 seconds.
• ClientAliveInterval 10 , ClientAliveCountMax 0 : ssh -v records the message debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1 every 10 seconds

Источник

Увеличиваем время ожидания SSH сессии в Linux

Если вы имеете свой сервер с Linux на борту, не важно, будь это домашний сервер или VDS, вам приходится подключаться к нему разными способами, и один из самых распространенных это SSH. При работе с сервером через SSH вы возможно замечали, что через определенное время соединение разрывается. Иногда этого времени может быть не достаточно и вам нужно увеличить время ожидание при бездействии.

А для надежности так же рекомендуется настроить SSH соединения по ключу, как это реализовать описано в этой статье. При необходимости так же можно настроить подключение по ssh из под root пользователя.

Если вам нужен VPS/VDS сервер, вы можете заказать его у TimeWeb. TimeWeb предоставляет сервера под любые задачи, на которых вы можете поднять все, что вам необходимо. Не высокие цены, круглосуточная поддержка, возможность самому собрать необходимую конфигурацию сервера и многое другое, подробности смотрите на официальном сайте TimeWeb.

Настраиваем время соединения SSH

И так, что бы увеличить время ожидания необходимо отредактировать конфигурационный файл на сервере, который расположен по адресу “/etc/ssh/sshd_config”. Для его редактирования воспользуемся текстовым редактором Nano, о котором вы можете прочесть подробнее перейдя по этой ссылке. Открываем конфигурационный файл и переходим к строкам:



Первый параметр отвечает за отправку нулевых пакетов клиентам, а второй отвечает за закрытие соединения, если клиент был неактивен в течение заданного интервала. Рассчитать время можно следующим образом, в первом параметре – ClientAliveInterval зададим 1200 секунд и помножим его на значение параметра ClientAliveCountMax которое зададим равное – 3.

В итоге получим 3600 секунд, что будет равняться одному часу. Эти параметры можно задать произвольно, в зависимости от ваших потребностей. И так, раскомментируем эти параметры и зададим им значения:



Сохраняем отредактированный файл – “ctrl + o” и выходим из текстового редактора – “ctrl + x”. Можно пойти и другим путем, просто задать 3600 секунд в первом параметре, и этот вариант тоже будет работать точно так же:



Заключение

Вот таким не хитрым и простым способом мы увеличили время ожидания аж на целый час, как уже говорилось, можно задать любое необходимое время, но, оно обязательно должно задаваться в секундах. Рассчитать это довольно просто. При необходимости вы всегда можете изменить заданное время обратно, по умолчанию закомментировав эти значения. В любом случае, прежде чем вносить какие-то изменения в конфигурационные файлы на вашем сервере, рекомендуется делать бэкапы, что бы у вас была возможность восстановить исходники если пойдет что-то не так. Кроме того, не рекомендуется без необходимости устанавливать большое время ожидания в SSH, так как это может негативно сказаться на безопасности.

А на этом сегодня все, надеюсь, данная статья будет вам полезна.
Хотелось бы выразить огромную благодарность тем, кто принимает активное участие в жизни и развитии журнала, огромное спасибо вам за это.
Журнал Cyber-X

Источник

Читайте также:  Посмотреть все пароли linux