Strange behavior of ssh ( Rocky 9.3 vs. Cent OS 7.9)

Rocky Linux General
1

Strange behavior of ssh ( Rocky 9.3 vs. Cent OS 7.9)

windows pc → Wifi → Rocky 9.3 node a → pocky 9.3 node b

ssh to node a , node a to node b
sudo -i (make root)
less /var/log/messages
PC Wifi off (15 min)
PC wifi on
We found Zombei process on node b

sshd_conf parameter is ( not killed setting)
cat sshd_config | grep Client
#ClientAliveInterval 0
#ClientAliveCountMax 3
ClientAliveInterval 180
$TMOUT not set

but, sane operation on CentOS is

windows pc → Wifi → Cent 7.9 node a’ → cent 7.9 node b’
CentOS Linux release 7.9.2009 (Core)
clean up zombies.

These situations depend on this?
https://bugzilla.mindrot.org/show_bug.cgi?id=3281

Rocky or Cent befavior , Whitch is right?

/regards!

2

There has been clear rebase of openssh between el7 and el9, so change of behaviour should not be unexpected.

I have, AFAIK, default config on both and that seems identical:

[root@el9 ~]# sshd -T | grep -E "alive|time"
logingracetime 120
clientaliveinterval 0
clientalivecountmax 3
tcpkeepalive yes

[root@el7 ~]# sshd -T | grep -E "alive|time"
logingracetime 120
clientaliveinterval 0
clientalivecountmax 3
tcpkeepalive yes

I have not tested loss of link though.

Logically, there are at least two players: sshd and systemd. What sshd does when (TCP) connection appears dead, and how systemd cleans out “closing” sessions. The latter with assumption that sshd does tell systemd that session is over.

3

client_loop: send disconnect: Connection reset
is displayed pc terminal.
also Rocky and CentOS is same value
sshd -T | grep -E “alive|time”
logingracetime 120
clientaliveinterval 180
clientalivecountmax 3
tcpkeepalive yes

Cent os
ssh -v 0
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

Rocky
ssh -v 0
OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022

4

adding infomation
node a (relay) scripts cmd doing . ( logging operation)
node b (end) less command waiting file update

Wifi disconnected and met windows terminal get messages “client_loop: send disconnect: Connection reset”
wait five min re-connect wifi
we can reproduce this.

but , Cent OS Node a (relay) ,b(end)
cleanup

regards!

5

replaced script
script -V
script from util-linux 2.37.4 ( Rocky)
./script -V ( Coped from Linux (centos 7.9.2009)
script from util-linux 2.23.2

ssh time out process cleanup works well

Please let me know , I would ask to Where or who?
about "script "

regrds!

6

man script of util-linux-2.23.2-65.el7_9.1.x86_64 writes:

BUGS
Script places everything in the log file, including linefeeds and backspaces. This is not what the naive user expects.

man script of util-linux-2.37.4-15.el9.x86_64 writes:

BUGS
script places everything in the log file, including linefeeds and backspaces. This is not what the naive user expects.

script is primarily designed for interactive terminal sessions. When stdin is not a terminal (for example: echo foo | script ), then the session can hang, because the interactive shell within the script session misses EOF and script has no clue when to close the session. See the NOTES section for more information.

The “has no clue when to close the session” sounds like what you get.

The URL in rpm -qi util-linux points to Wikipedia, doesn’t it? script (Unix) - Wikipedia
and the man script says:

REPORTING BUGS
For bug reports, use the issue tracker at Issues · util-linux/util-linux · GitHub

So perhaps util-linux/util-linux · Discussions · GitHub is the place where one could ask?

PS. I don’t even recall noticing the whole script command before. Are you sure that is the best way to do what you need to achieve?

7

Thanks jlehtone-san
i’ll try report to ‘util-linux/util-linux · Discussions · GitHub’
very Thanks and regarts!

8

posted

and has a reply . this issue was fixed scripts v 2.4 , in thread.

regards!

9

On CentOS 7 machine I do see that it has had util-linux based on upstream 2.32.2 at least from 2016 onwards.
On CentOS 8/AlmaLinux 8 the util-linux has been based on 2.32.1 all the time.
On AlmaLinux 9 the util-lnux seems to be based on 2.37.4.

While AlmaLinux is no longer as close to RHEL as Rocky is, I bet that RHEL 9 – and thus Rocky 9 – will stay at util-linux-2.37.4-x for quite while. Perhaps even to EOL at 2032. It is possible though that Red Hat backports some bug fixes to the util-linux-2.37.4-x.el9.

10

Thanks! jlehtone -san
/minami