You are not logged in.

#1 2020-04-15 17:04:56

Intr0sp3ctive
Member
Registered: 2020-04-14
Posts: 8

[SOLVED] SSH server does not timeout the client

Hi folks,

Can someone please advise on what could be the problem here or what to have a look at?

The problem:
The openSSH server on my Archlinux laptop seems to be running just fine except that it somehow does not drop the connection to the client after the timeout period has passed.

I can connect to if from client (debian 10 laptop) without any problem. If i leave it as it is and do nothing no matter how long, the client remains connected - the server does not timeout connection.
(This client has its own ssh server running that i can connect to from Archlinux laptop, it does timeout the connection after the period set in sshd_config,)

As for the Archlinux laptop:
this is just normal installation of Archlinux, with  iwd, dhcpcd & openSSH installed. XFCE4 too - i do not use it much, mainly move around it through tmux or cli. Btw, the iwd, dhcpcd & openSSH - these are started manually, they are not enabled.

Both laptops connected to router, Debian by cable, Archlinux by wifi. Not sure if it matters but the time on the Archlinux is 5 sec ahead of the time on Debian.

I have tried to google this but folks are all interested in how to prolong/avoid timeout..

This is sshd_config (archlinux laptop):

 
#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 9378
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no # was ,,prohibit-password,,.
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
#AuthorizedKeysFile	.ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PermitEmptyPasswords no # was commented out

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no # pam does that
PrintLastLog yes # was commented out.
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 60
ClientAliveCountMax 0
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

### testing this 13/04/2020 at 17:47
#AcceptEnv LANG LC_*

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/lib/ssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

this is the client (debian laptop) ssh_config:

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Protocol 2
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

Last edited by Intr0sp3ctive (2020-04-16 18:12:06)

Offline

#2 2020-04-15 17:26:43

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: [SOLVED] SSH server does not timeout the client

Well ... you set the ClientAliveInterval which does exactly this.  If you don't want that, why did you set it in the config?


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2020-04-15 18:01:45

Intr0sp3ctive
Member
Registered: 2020-04-14
Posts: 8

Re: [SOLVED] SSH server does not timeout the client

That's correct, but i also set the ClientAliveCountMAx to zero, should not the server send no message to client in this case? (i mean after these 60 seconds and then terminate the connection?)

I'll try do change it to ClientAliveInterval to 30 and ClientAliveMAxCount to 2 to see just in case the zero does it no good.

Ehm,, just have had a proper look at the last sentence in paragraph for ClientAliveCountMAx in sshd_config man pages- it does literally says that ,,Setting a zero ClientAliveCountMax disables connection termination,,.

Offline

#4 2020-04-15 18:13:20

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: [SOLVED] SSH server does not timeout the client

The ClientAliveCountMax setting isn't particularly relevant as your client is most likely responding to messages reliably.  ClientAliveCountMax is essentially how many times the server should retry if it doesn't get a reply to a message.

Changing the Interval to 30 and MaxCount to 2 will also not get the results you want.  That will also not timeout after 1 minute of inactivity.

Again, why did you change ClientAliveInterval in the first place?  If you do not want this setting, comment it out so that it defaults to 0 (or set it to zero yourself).  That way the session will timeout on inactivity.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2020-04-15 19:06:16

Intr0sp3ctive
Member
Registered: 2020-04-14
Posts: 8

Re: [SOLVED] SSH server does not timeout the client

Trilby,

Again, why did you change ClientAliveInterval in the first place?

Out of curiosity - this is commonly advised on internet on how to do it - decided to give it a go. Not like i particularly need it but i want it to timeout on inactivity lets say after 4 minute.

(I have similar setting in sshd_config on this debian machine (i think 4 minutes -> ClientAliveInterval 240 & ClientAliveCountMax 0) and it happily kicks the client (Archlinux laptop) out on inactivity.)
I am obviously not complaining that it works in Debian but not in Arch.. It simply sucks that i try to tell it to do something and it happily ignores me.

I will comment it out then, but how does the server decide when to drop the connection (obviously if it see there is no activity) in terms of the time period?


By the way thanks a lot for your time.

Offline

#6 2020-04-15 19:41:52

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: [SOLVED] SSH server does not timeout the client

Intr0sp3ctive wrote:

this is commonly advised on internet on how to do it ... i want it to timeout on inactivity lets say after 4 minute.

Do you have sources for this?  Either they are wrong, or you misinterpretted them.  Setting ClientAliveInterval is not the way to make the server time out on inactivity, it is the way to prevent the server from timing out on inactivity.  It times out on inactivity by default.  You've overriddent the default explicitly instructing the server to try to prevent timing out.

Whether or not a connection actually times out will depend both on the server and on the client.  Either one of them can engage in activity to prevent idle timeouts: i.e., when the human user is idle/away the client or the server can send null packets or initate some other keep-alive activity - if either one is actively keeping the connection alive, it will remain alive.  So preventing your server from keeping the connection alive may not be sufficient, but it's definitely necessary.

Last edited by Trilby (2020-04-15 19:43:40)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#7 2020-04-16 16:56:13

Intr0sp3ctive
Member
Registered: 2020-04-14
Posts: 8

Re: [SOLVED] SSH server does not timeout the client

Hi,

I mean, if one googles ,,how to secure ssh server,, the returned results would be of the following kind:

https://www.howtogeek.com/443156/the-be … sh-server/
https://securitytrails.com/blog/mitigat … -practices
https://medium.com/@jasonrigden/hardeni … cb99cd4cef

It might be well out of date or perhaps not applying specifically to this current version of openssh. Or perhaps now a myth that used to work under certain circumstances.

I did read about ClientAliveInterval in man sshd_config as well as about ClientAliveCountMax, there is a section about these that illustrate what i would like to achieve (source: https://man.openbsd.org/sshd_config:

ClientAliveCountMax
    Sets the number of client alive messages 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. 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 unresponsive.

    The default value is 3. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Setting a zero ClientAliveCountMax disables connection termination.

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.

That is why i tried it, cross-referencing the other so-called guides..

I am aware of the fact that it could be the client that keeps the connection alive.
I have got Wireshark running displaying only trafic for server and client - no traffic unless I key something at the terminal on client apart from a broadcast asking (arp protocol) ,,who has 192.168.50.3,, (client) to tell 192.168.50.4 (server) and obviously the response to it..
I may play a bit with the client setting to see..

Offline

#8 2020-04-16 17:11:08

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: [SOLVED] SSH server does not timeout the client

I think you are missing the point of these settings.  These are not for user-idle circumstances, they are - as that man page excerpt notes - for unresponsive SSH clients.  The client will be unresponsive if the client program has frozen or the connection has been broken.  The client should not be unresponsive simply because the human user has stepped away from the keyboard: the ssh client will still receive packets sent from the server.

These settings enable the server (program) to maintain an active dialog with the client (program) even when the human user at the client end is away, asleep, dead, etc.  It is not clear whether openssh itself will ever terminate a connection simply for being idle (the docs are a bit vague on this point, but the main loop in the code doesn't appear to have any such condition).  Other components may terminate an idle connection.  BASH has the TMOUT variable, and firewalls can be configured to sever an idle connection.  The important thing to note is that setting ClientAlive* to anything but the default may prevent the BASH or firewall timeout as the purpose is to maintain a connection that may otherwise be terminated.

I just tested locally, and receiving a null-byte will not prevent BASH from timing out on TMOUT, so I'd speculate that null packets probably also wouldn't.  So if you are using Bash as your shell, you could just set TMOUT for the effect you want.  (note: TMOUT seems to work with buysbox's ash as well, so there's a fair chance it'd be used by other shells as well).

I also just confirmed, setting TMOUT in my server's shell rc did indeed result in an idle timeout disconnect.

Last edited by Trilby (2020-04-16 17:21:46)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#9 2020-04-16 18:11:39

Intr0sp3ctive
Member
Registered: 2020-04-14
Posts: 8

Re: [SOLVED] SSH server does not timeout the client

Trilby,

Thanks a lot for your patience and time.

I see where I went wrong - none of these ,,guides,, say/mention ,,unresponsive clients,, these all create an illusion that by such settings the server timeouts the idling connection.
I should have read the sshd_config man pages more carefully, perhaps it would have clicked in my head when reading ,,unresponsive,,. My fault.


Perhaps Debian's implementation of ssh server utilizes $TMOUT & that's why it happily kicks out Arch laptop (vice versa scenario) but that i can google about some more.

Offline

#10 2020-04-16 18:19:32

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,445
Website

Re: [SOLVED] SSH server does not timeout the client

Well, I did glance at the openssh change log, and it looks like there may have been previous versions where the effect of these settings may have inadvertently resulted in something more like what you indended.  It was changed, however, because it was not the intended behavior of the software.  It's possible that some of these guides were written with older versions of openssh where they were taking advantage of undocumented and unintended behavior.

It wouldn't be the first time a software "fix" annoyed lots of users because they had been taking advantage of the brokenness.

Last edited by Trilby (2020-04-16 18:21:03)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB