SSH Session Timeouts?

[deed02392]

After 'upgrading' to the superhub, not only am I lacking the ability to use my internal LAN DNS server (at least as issued by the hubs DHCP), I've noticed that SSH connections appear to be dropping whilst left inactive.

This caused quite a mess when I was dist-upgrading last night and it disconnected half way through.

Does anyone know if this is a configurable option of the Superhub before I waste time fiddling through the terrible interface?

PS: Does anyone know if I can get shell access to the Superhub or otherwise modify the routing table? The ability to route everything through another server before going back out to the internet would be great.

[Milambar]

After 'upgrading' to the superhub, not only am I lacking the ability to use my internal LAN DNS server (at least as issued by the hubs DHCP),
Yep - essetially I believe its because VM want you to use their DNS, they removed the ability to specify a dns server from the router. You now have to set it "per device" which sucks, but isn't hard.

I've noticed that SSH connections appear to be dropping whilst left inactive.

Yep, about every 120 seconds by my own testing.


This caused quite a mess when I was dist-upgrading last night and it disconnected half way through.
You should't really be dist-upgrading over a ssh connection unless you are 100% sure of its stability, as an unexpected disconnect can cause problems.

Does anyone know if this is a configurable option of the Superhub before I waste time fiddling through the terrible interface?

Is what a configurable option? The DNS servers? No. The timeout interval? No. There are workarounds though. Change the tcpkeepalive setting in sshd_config and ssh_config to sidestep the timeouts, and set your DNS servers manually on each connected device, or put the superhub into modem mode, and use your own router.

PS: Does anyone know if I can get shell access to the Superhub or otherwise modify the routing table? The ability to route everything through another server before going back out to the internet would be great.


There was a bug in the firmware that left an active ssh port open on the superhub, but they fixed it. I guess they didn't want to risk anyone figuring out how to use this privileged access to change stuff that shouldnt be changed. Can't say I blame them.

[deed02392]

It sucks, it's not possible on all devices and it's an unnecessary restriction.

Dist-upgrading over SSH is fine (and necessary on my headless leased server), I just forgot to do it in a screen session. That would have prevented any issues. Although not the inconvenience.

I would put my superhub into 'modem' mode, but that seems to eliminate the whole point of it being a gigabit router with a decent wifi chip. It's so frustrating to have all that functionality locked up in a crap interface. I wish they'd just sent me a SACM and had done with it. This is just a tease.

Or at the very least, access to the routing table and ability to change DNS servers. Unbelievable.

[Milambar]

Dist-upgrading over SSH is fine (and necessary on my headless leased server), I just forgot to do it in a screen session. That would have prevented any issues. Although not the inconvenience.


Usually, but not garunteed. Ive had sshd fall over during an upgrade process. Not just disconnect, but completely fall over, now that DOES make a mess (and cost a service ticket for them to go and hard reboot the box). That wasn't exactly a network issue, but did highlight to me how risky dist-upgrade over ssh actually was. We invested in a KVM-over-ip for that now. Yes, an expensive solution, but less expensive than downtime and service tickets.

Running it inside screen is a good option if your network tends to disconnect however.

[Chrysalis]

Milambar how else are they going to dist-upgrade?

ssh is the primary means to manage unix servers. Its a stable protocol but obviously relies on a network connection to hold up. The OP I uggest you use 'screen' tho, that way if you lose your ssh connection the session stays up in screen and you can reattach to it.

Seems the lame timeouts in the superhub still exist then. Another workaround is to force the sshd server to send frequent keepalive packets.

---------- Post added at 16:02 ---------- Previous post was at 15:58 ----------

Usually, but not garunteed. Ive had sshd fall over during an upgrade process. Not just disconnect, but completely fall over, now that DOES make a mess (and cost a service ticket for them to go and hard reboot the box). That wasn't exactly a network issue, but did highlight to me how risky dist-upgrade over ssh actually was. We invested in a KVM-over-ip for that now. Yes, an expensive solution, but less expensive than downtime and service tickets.

Running it inside screen is a good option if your network tends to disconnect however.

In 10 years or so of managing servers I honestly cannot remember a time of sshd just falling over. I have had it crash due to mistakes have made during work but not just randomly fallover. Also when ssh crashes it doesnt take the existing ssh connections down, it just stops new ones been made.

kvm is great but in many cases it cant be justified for the 24/7 cost. I have a 24/7 kvm on some servers, usually ones with built in ilo and colo'd rather than rented, and a few 'expensive' rented servers, but pretty much all low cost rented ones I just ask for a kvm when its needed (extremely rare). The dc's I use will typically provide a kvm within 10-20 minutes. Hard rebooting the server is overkill for a downed ssh. But if you do hard reboot I think its very rare now days to not have a remote reboot port (APC), as even cheap servers usually get supplied with one now, as it saves the dc costs on tech support.

[deed02392]

Milambar, I really don't think you need to be paying out for KVM just on the off-chance your SSHd might crash. Mine has never crashed on Debian, even after well over two years up-time.

Back on-topic, so far a solution has been to configure PuTTY to send keep-alive packets every 60 seconds. I think there's a server-side solution too which I'll probably get around to eventually, as at the moment WinSCP freezes for several seconds before making me go through the 'abort, reconnect, go back to where I was' rigmarole.

All because Virgin are enforcing something which is probably just a workaround for the router's poor ability to handle too many open connections at once? Probably.

[Milambar]

Back on-topic, so far a solution has been to configure PuTTY to send keep-alive packets every 60 seconds. I think there's a server-side solution too which I'll probably get around to eventually,

I already said that :P


Change the tcpkeepalive setting in sshd_config and ssh_config to sidestep the timeouts


Mine reads:

/etc/ssh/sshd_config

TCPKeepAlive yes
ClientAliveInterval 60

[deed02392]

Thanks for the config directives Milambar.

[Chrysalis]

I already said that :P



Mine reads:

/etc/ssh/sshd_config

TCPKeepAlive yes
ClientAliveInterval 60


yeah for the superhub set it real low, like 15 seconds or something.