Unstable SSH connection on old hardware and clean OS

xRef

10/13/23, 5:36 AM

I have a Ubuntu Server 18.04.6 LTS on an Intel Core Quad Q6600 and old Gigabyte 965P-S3 motherboard. Right now SSH is unstable. Client loses connection after 10 minutes of inactivity, but there is no any error. Client just gets stuck. Server continues to keep connection and doesn't kill connection even after one hour. Is the problem possibly hardware?

1 + 3

ssh

openssh

matigo

10/13/23, 5:43 AM

Unfortunately there is not enough information to provide an accurate answer. That said, have you checked the logs in `/var/log` to see if there are any errors or messages about broken pipes, connection drops, or anything else? If the issue is hardware related, `syslog` may contain specific information pointing to a problem

xRef

10/13/23, 6:45 AM

There is no any errors in `syslog`. `auth.log` also doesn't contain any information about my issue. Server even doesn't know that client lost connection and keeps sshd process for this client until I kill this process

xRef

10/13/23, 7:26 AM

Oops.. I've noticed that this issue reproduces only on my 4G internet. But the fact that the server keeps connection until I kill process it's still strange

Score:1

Ubuntu

matigo

10/13/23, 8:18 AM

OpenSSH generally does not close idle (or "lost") connections because there are many ways to define idleness, some which may differ from your definition. However, you can edit your SSH configuration file to include these two lines:

ClientAliveInterval 300
ClientAliveCountMax 2

This will disconnect connections that have not issued a command in 600 seconds (10 minutes).

From the Ubuntu Manpage for 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.

In plain language, the server will send a message every 300 (or however many) seconds to the client. If the client does not respond after 2 (or however many) attempts, the connection is closed.

Be sure to restart OpenSSH after modifying the configuration file, as it is only read at the time the daemon starts.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Unstable SSH connection on old hardware and clean OS

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.