1

Initial Connection to the RPi is flawless, even with VS Code Remote Dev. But after some time (without special command) the RPi closes the connection ("Connection to 10.0.0.11 closed by remote host"). In Debug mode it says following right before:

debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1)

debug3: Successfully set console output code page from 65001 to 65001
debug3: Successfully set console input code page from 65001 to 850
Connection to 10.0.0.11 closed by remote host.
Connection to 10.0.0.11 closed.
Transferred: sent 3684, received 93440 bytes, in 115.0 seconds
Bytes per second: sent 32.0, received 812.2
debug1: Exit status -1

I have a Node.js Server running, with PM2 to restart on crash and just installed a HTTPS Certificate with Certbot.

Edit

This is how the connection's idle and suddently closes

Linux raspberrypi-webserver 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Apr 25 20:51:26 2022 from 10.0.0.138
admin@raspberrypi-webserver:~ $ debug3: send packet: type 80
debug3: receive packet: type 82

admin@raspberrypi-webserver:~ $
admin@raspberrypi-webserver:~ $
admin@raspberrypi-webserver:~ $
admin@raspberrypi-webserver:~ $ debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82

admin@raspberrypi-webserver:~ $
admin@raspberrypi-webserver:~ $ debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1)

debug3: Successfully set console output code page from 65001 to 65001
debug3: Successfully set console input code page from 65001 to 850
Connection to ****.ddns.net closed by remote host.
Connection to ****.ddns.net closed.
Transferred: sent 2276, received 4108 bytes, in 304.0 seconds
Bytes per second: sent 7.5, received 13.5
debug1: Exit status -1

C:\Users\****>

Does anybody know why this happens?

1 Answer 1

1

SSH server will send keep-alive messages to the client every few seconds, and if several of them are left without a reply, it closes the connection. This often happens because of temporary network connection issues.

You can increase ClientAliveCountMax in /etc/ssh/sshd_config to make SSH connection more robust, at the expense of longer disconnect time for clients who lost network connection. Ultimately, you can set TCPKeepAlive to no and let SSH sessions hang until the TCP protocol itself kills a stale socket (which happens after more than 2 hours). It's fine to do so on your Pi as long as you don't try to open thousands of simultaneous SSH sessions.

Note that your SSH client may have its own keepalive/timeout configuration, but you didn't say which one you use. Some clients set the $TMOUT variable in the shell to close the session if there's no input from the user for some time. PuTTY has its own client-side keepalive configuration.

1
  • One thing I maybe forgot to mention is that 1. Always the RPi closes the connection (unexpectedly) and that 2. It even happens if I am activiely sending commands/working with VS Code over Remote Dev. It often happens after about 5 min after connection, but sometimes it takes longer. I suspect it is some kind of overflow or overload, but CPU and RAM are all fine Apr 26, 2022 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.