Back to Blog

Two Cloud Container updates - memory reporting and SSH configuration

/ News
We’re tracking memory usage more accurately than ever, and we’ve tweaked the default SSH configuration to better balance security and usability.

As part of our ongoing maintenance and enhancement of the Cloud Container platform, we have two changes to announce. If you’ve noticed a change in your reported memory usage, or in the way SSH is configured, here’s the full story.

Improved Resource Usage Graph

We're rolling out some changes to Cloud Container servers this week so you can see a more accurate representation of memory usage for your servers.

You may notice your server “Resources” graph showing a jump in the 'Memory Used' value.

SiteHost control panel screenshot - memory usage graph.
Resouces

Our new memory usage calculations will probably put a noticeable a jump in your memory usage report.

We realised that our calculation for memory usage wasn't giving customers the full picture and we could see memory issues in our internal monitoring and reporting that the graph didn't accurately capture. Issues such as performance impact due to low available memory weren’t being reflected.

This calculation was based on kernel memory information available in Linux, but recent updates have improved the options here. An “available” value was added to give a more accurate account of memory usage based on buffers, cache, and shared memory. That is where the increase displayed on the server resources graph comes from, meaning your servers aren't using any more memory than before, you’re just seeing the bigger and more accurate picture.

With these changes, you can now see how much memory is available for starting new applications such as adding new containers or handling any increased load on your existing containers, ultimately giving you better insight into your servers' performance.

The roll out to Cloud Container servers has already started and will continue over the course of this week.

Improved SSH Security

Next up, let’s talk about SSH. Over the past few months, we have received numerous requests from customers to disable some of the less secure algorithms and ciphers used by SSH on their Cloud Containers so that their application can be compliant to certain standards and security scans such as PCI DSS compliance.

A completely reasonable request, plus we are always in favour of improving security! So we got to work planning changes to make the Cloud Container platform more secure out of the box. These plans included lengthy discussions about which configuration to deploy, how to keep customer impact minimal and what to do for anyone needing a customised configuration.

Once we had a plan we performed compatibility tests by attempting to SSH into Cloud Containers from reasonably old operating systems and SSH clients (released in 2014-2016) to ensure that our chosen configuration was backward-compatible. Over a few days we then released the changes across our Cloud Container regions leaving the biggest one for last.

Unfortunately, upon releasing to our largest region on 25th November, we realised we had missed something, despite the planning and testing. We hadn’t tested SFTP connections from particular IDEs (like Visual Studio Code and Atom) and we quickly discovered they rely on some old cyphers. Without getting too technical our new configuration was not offering at least one Message Authentication Code (MAC) algorithm that they rely on, so we promptly released a patch to fix this issue.

In hindsight we made the wrong call on the initial release – we know it’s impossible to test the thousands of unique applications and systems used by our customers, so we need to be careful with changes such as these. We should have notified all customers of the changes, explaining them in detail along with potential impacts ahead of time, with the releases happening over a scheduled maintenance window.

Thankfully we can now say after the patch we have the right balance between security and compatibility as our default SSH settings. It is by no means a one-size-fits-all configuration, some applications will need tighter security while some will need more flexibility to support legacy software, which is why the release also included a process to manage such customisations moving forward.

Thanks for your patience if you were one of those impacted during the release and please get in touch if you need a custom SSH configuration.