Ssh connection to router gets reset every few seconds

[haridsv]

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):

$ time ssh admin@192.168.1.5
admin@192.168.1.5's password:

ASUSWRT-Merlin RT-AC68U 384.19_0 Fri Aug 14 19:17:44 UTC 2020
admin@RT-AC68U-E770:/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]

Check the value of Administration > System > SSH inactivity timeout

 

[haridsv]

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]

Sorry, I don't know anything about AiMesh.

Try issuing this command and seeing if it's got some strange timeout value set:

ps w | grep dropbear

 

[haridsv]

Thank you Colin! This is the output, I don't see anything strange:

admin@RT-AC68U-E770:/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]

Strange... now I see that my new rt-ac86u also does exactly the same.

$ time ssh admin@192.168.1.1
admin@192.168.1.1's password:


ASUSWRT-Merlin RT-AC86U 384.19_0 Fri Aug 14 19:19:51 UTC 2020
admin@asus-router:/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:

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]

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]

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]

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.

 

[haridsv]

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]

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.

 

[haridsv]

Nice finding! Thanks for the update!