I spent last weekend working through a real pain in the arse problem: couldn’t get remote SSH access configured on to server C1.<\/p>\n
Local access via console worked brilliantly.<\/p>\n
And I could attach another device to the internal network and run SSH sessions to the internal IP that server C1 had been configured with.<\/p>\n
But I couldn’t get SSH consistently working, in a stable, always-up, kind of way, via remote.<\/p>\n
The best I could get was for remote SSH to stay up and running for around 20 minutes.<\/p>\n
In the end, frustrated beyond belief, I binned the router that Plusnet had supplied (a neat-looking Sagecom device).<\/p>\n
Then I looked out a spare Netgear router that I had at home.<\/p>\n
I copied the config details from my home-hosted NAS in to the spare Netgear router, and installed that in the datacentre.<\/p>\n
Changed the account credentials to match those of the datacentre, obv.<\/p>\n
And lo and behold, I had remote SSH.<\/p>\n
But for how long?<\/p>\n
An hour later it was still working.<\/p>\n
This was a new record.<\/p>\n
Three hours later it was still up and running.<\/p>\n
Twenty-one hours later, we were still golden.<\/p>\n
So it seems like, to me at least, that the Plusnet router had a ‘go to sleep’ rule set in the firmware.<\/p>\n
If it hadn’t seen any port 22 traffic for around 20 minutes, it shut down port 22.<\/p>\n
And wouldn’t wake up when port 22 traffic came knocking on the door.<\/p>\n
Marvellous.<\/p>\n
Except not, obv.<\/p>\n
But the Netgear router fixed that and I had remote SSH and public port 80 access to the server C1.<\/p>\n
For 72 hours.<\/p>\n","protected":false},"excerpt":{"rendered":"
I spent last weekend working through a real pain in the arse problem: couldn’t get remote SSH access configured on to server C1. Local access via console worked brilliantly. And I could attach another device to the internal network and run SSH sessions to the internal IP that server C1 \u2026 Continue reading