Ssh connection to router gets reset every few seconds

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

haridsv

Occasional Visitor
I have trouble keeping my ssh connection from my Mac to the router alive. It stays connected for only about 30 seconds if I leave it idle, as you can see below (the timing includes the time to enter password):
Code:
$ time ssh [email protected]
[email protected]'s password:

ASUSWRT-Merlin RT-AC68U 384.19_0 Fri Aug 14 19:17:44 UTC 2020
[email protected]:/tmp/home/root# Shared connection to 192.168.1.5 closed.

real    0m42.551s
user    0m0.013s
sys    0m0.009s
I am experimenting with some scripts so I really need a long running session. This is not an issue with my ssh client, as I connect to several ssh servers at work over VPN and don't have any problem with having them stay connected for days.

I wanted to check if there is a sshd_config sort of a file somewhere, but not sure where to look. Could someone please help?
 

ColinTaylor

Part of the Furniture
Check the value of Administration > System > SSH inactivity timeout
 

haridsv

Occasional Visitor
It should be set to 20 minutes, the default (I never changed it). However, I can't check it now because this router is now configured as an AiMesh node. When I had this router as primary, that was the first thing I checked. Now that it is reconfigured as a node, I am not sure how to check it. Won't the node configuration involve a config reset anyway?
 

ColinTaylor

Part of the Furniture
Sorry, I don't know anything about AiMesh.

Try issuing this command and seeing if it's got some strange timeout value set:
Code:
ps w | grep dropbear
 

haridsv

Occasional Visitor
Thank you Colin! This is the output, I don't see anything strange:
Code:
[email protected]:/tmp/home/root# ps w | grep dropbear
  224 admin     1116 S    dropbear -p 22 -j -k
 1216 admin     1136 S    dropbear -p 22 -j -k
17223 admin     1136 S    dropbear -p 22 -j -k
17242 admin     1436 S    grep dropbear
Both the -j and -k options are for port forwarding.
 

haridsv

Occasional Visitor
Strange... now I see that my new rt-ac86u also does exactly the same.
Code:
$ time ssh [email protected]
[email protected]'s password:


ASUSWRT-Merlin RT-AC86U 384.19_0 Fri Aug 14 19:19:51 UTC 2020
[email protected]:/tmp/home/root# Shared connection to 192.168.1.1 closed.

real    0m45.036s
user    0m0.012s
sys    0m0.009s
So, I suspected that it is something in my client config and tried commenting out stuff and sure enough the issue went away after I commented this line:
Code:
ServerAliveInterval 10
I added that config a few months back for exactly the same reason, to keep a connection alive when one of our servers was dropping it. Perhaps this is some dropbear bug, but I am glad I found the root cause.
 

ColinTaylor

Part of the Furniture
Well that looks correct. If there were a timeout set in dropbear I'd expect to see the -I parameter, e.g. -I 600.

EDIT: OK, I see you have found the cause. :) I was about to suggest you look for that in ~/.ssh/config
 

haridsv

Occasional Visitor
Well, ServerAliveInterval is meant to keep the connection alive. Per documentation

ServerAliveInterval: number of seconds that the client will wait before sending a null packet to the server (to keep the connection alive).

That means, setting it to 10 must result in getting a null packet sent every 10 seconds. I am guessing that dropbear doesn't like these packet (bug?). I would have still expected the connection to get dropped in 10 seconds (the first packet) instead of 30 seconds, may be ssh client has a programmed delay for the very first packet.
 

ColinTaylor

Part of the Furniture
I managed to recreate this problem. It only happens when you're running dropbear with the -k (disable remote port forwarding) option.

What appears to be happening is that whatever the client has set for ServerAliveInterval is being used by dropbear in the same way as if it were set for the -K (timeout) parameter, albeit per client rather than globally. You can see this behaviour by changing the value of ServerAliveInterval. dropbear will timeout after 4 times the value being set.

Whether this is deliberate or a bug I can't tell. I also have no idea how dropbear is picking up the timeout value from the client.
 
Last edited:

haridsv

Occasional Visitor
Thanks a lot @ColinTaylor for reproducing this and confirming the behavior. It is interesting that it doesn't take the value as is, but instead uses 4 times the given value. I hope this thread will help others who are googling.
 

ColinTaylor

Part of the Furniture
OK forget what I speculated earlier about dropbear picking up the ServerAliveInterval value, that's not the case. The timeout delay is entirely a client side function.

If ServerAliveInterval is set the client uses that value in combination with ServerAliveCountMax (which defaults to 3) to determine when it will timeout the connection. So the timeout happens after (ServerAliveCountMax + 1) * ServerAliveInterval seconds.

So the problem happens when using ServerAliveInterval in combination with dropbear using the -k option. The client sends type 80 packets to dropbear and expects to receive type 82 packets in return. With -k set dropbear never sends those replies so the client thinks the connection is dead and terminates the session.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top