SSH connection constantly drops

Troubleshooting
1

Hello. This all started randomly about a month ago while still on Buster. When SSH’d into my server my ssh connection will just drop out of no where while performing commands from apt upgrades to moving files onto external storage for my plex server. This is a complete nightmare as files being transferred to my external hard drive are constantly broken and apt upgrades are constantly in a state of disrepair from the dropped commands. I can’t SCP files over to my server either because the connection will drop in the middle of the file transfer.

This occured on Buster so I upgraded to Bullseye – problem still persisted. I’ve tried running the commands on different terminals and on different devices. It all ends with the same error – session closed. I have no idea where to begin looking for the error but I’m at my wits end. Google shows nothing near my problem when researching.

I’ve tried dropbear and openssh. Issue persists. No changes have been made to my router. I’m on an Odroid N2 with Bullseye.

Also, I don’t know if it’s placebo or what, but it seems that if I continue pressing (for example) the right arrow key while apt upgrade is running, it will not time out.

2

did you checked your SSH client settings if there are any time out values defined?

3

In /etc/ssh/ssh_config my ConnectTimeout 0 line is commented out. No configs exist in ssh_config.d/. Googling increasing the ssh timeout says to adjust the ClientAliveInterval and ClientAliveCountMax lines, but those do not exist (and the guide online ponits to sshd_config which I do not have).

4

I mean to check the client side. Not the server side.

5

Ahhh understood. Yes. I use Terminus on Windows 10. Keep alive interval is 60000ms with a max keep alive count of 3. Ready timeout is 20000ms

6

I use Putty as client on my Win11 systems. There I never experianced any connection drop.

7

One thing is to use another client in windows to identify if the issue is on windows. Putty is reliable and for free.
Other than that you could run the sshd on the foreground, with verbosity in logs, and check for anything useful why is the connection closed.