January 4 2023

Dear Italian Hosting Providers, start providing SSH access to your customers instead of boycotting each other.

A purely Italian malpractice, mainly due to complicate life for customers who want to migrate elsewhere.

Since we have been working as systems engineers, in a standard 8-hour working day, we lose at least 3 hours organizing the migration of sites from old hosting providers to our infrastructure.

Among the various customers, we find the dissatisfied one with the old hosting provider, the one that comes from Amazon AWS and wants to save important monthly figures, what he wants to optimize i Core Web Vitals, the one that is penalized by Google because it is too slow, curious, time wasters, friends of friends, companies, companies, joint stock companies, corporations and multinationals.

Regardless of who the customer is, the most frustrating part of the web-oriented sysadmin job is onboarding new customers. Frustration is inevitable when, to remedy a simple and trivial operation such as transferring data from the old server to the new server perhaps via a very convenient rsync over SSH, here is that the outgoing supplier (the old one) to make your life more difficult and try to keep the customer, forbids you SSH access, boasting security reasons why SSH is not allowed, and indeed is firewalled.

There are Hosting providers who come up with the most absurd reasons, leaving you at the mercy of a very slow FTP server or to the various backup procedures of scracuse, old obsolete panels, the cause and origin of all evil, such as Plesk and cPanel.

Even when you have to transfer 100 Gigabytes of files, distributed in millions of files. 1 hour transfer with Rsync, full days with FTP.

We've had cases where 800GB of data had to be transferred from the old server to the new one and ended up having to hack through an X server to be able to use the shell as if the hosting provider had given it to us.

Xterm Server

Of course, before the "hack" actually all processes were running perfectly with user privileges, so same UID and GID, and no escalation to root or other users other than authorized ones, we asked and had them ask in every possible way for the possibility of having SSH access with a non-privileged user. From serene e-mails, to cordial phone calls, unofficial mails, formal mails, threats of damages from the lawyer, situations of this type, in which the Hosting company on duty responded with the contract stipulated 10 years earlier, in which the paragraph number, it was explained that SSH access was not allowed for security reasons.

Too bad that the site had started 10 years earlier with 5 Gigabytes of space and today they are at 800.

Easy to pull down 5 Gigabytes of data using Plesk's backup wizard utility or cPanel, a little less to do it with 800GB since there wouldn't even be enough disk space to produce the tar.gz archive that these panels scare for amateurs produce, instead of copying directly to the target server.

Unthinkable to make such a transfer with FTP or lftp, not even with parallels of 50 simultaneous processes.

Therefore, we wanted to write this post with the technical answer to the most common objections that incapable systems engineers usually foist on their customers when they refuse to facilitate the migration to a new supplier.

SSH is not provided for security reasons

Hosting providers often do not provide SSH (Secure Shell) access to their users for security reasons. SSH is a protocol that allows you to establish a secure connection between two systems, usually between a client and a server, and to execute commands remotely.

A major concern for hosting providers is ensuring the security of their systems and their users' data. SSH access can be a potential security risk, as it can be used by malicious users to gain unauthorized access to systems or to perform malicious actions.

To protect their systems, hosting providers often decide not to provide SSH access to users and instead offer other tools, such as a control panel or web interface, to manage their sites and servers. This way, users can still perform basic administration tasks without running the risk of compromising system security.

In addition, hosting providers often offer technical support services to help users manage their sites and servers by providing them with all the information and tools they need. This way, users can get the support they need without having to use SSH access.

This reasoning could be considered valid if it weren't for the fact that regardless of the SSH access that could have been provided to the customer, it would still have been of a non-administrative type (non-root) and that regardless of the much-vaunted security, the same hosting providers who do not grant you SSH are then the same to guarantee access to FTP (and not Secure FTP) with clear passwords.

If we also take into consideration that SSH access could be on a different port than SSH and linked to a static IP to be opened on the firewall, it is easy to understand that a categorical refusal of SSH access even on a different port has a completely different motivation rather than the much vaunted safety motivation.

Clear and unencrypted FTP is provided as standard.

FTP (File Transfer Protocol) was one of the first systems used to transfer files from one system to another. However, as the years have gone by and online security risks have increased, it has become less and less secure to use FTP for file transfers.

One major concern with FTP is that login information, such as username and password, is sent in the clear during the connection. This means that if an attacker manages to intercept this information, he can gain unauthorized access to files transmitted via FTP.

A more secure alternative to FTP is Secure File Transfer Protocol (SFTP), which uses encryption to protect login information and files during transfer. This makes it much more difficult for malicious users to gain unauthorized access to files transmitted via SFTP.

Additionally, SFTP offers a number of other security features, such as two-factor authentication and the ability to set access permissions for each file or folder.

The real reasons why SSH access is not granted

Hosting providers may deny SSH access to make it more difficult for a website to be migrated to another hosting provider. SSH (Secure Shell) access is a network protocol used to securely manage and control remote servers. It allows you to execute commands and transfer files over an encrypted connection.

SSH access can make moving a website to another server much easier and faster, especially using the Linux “rsync” utility. Rsync is a tool that allows you to synchronize files and directories between different computers, so you always have the same copies of files on both systems. Rsync is much faster than a File Transfer Protocol (FTP) transfer because it transfers only the files that have changed, rather than transferring all the files each time.

In addition, SSH access allows you to execute commands directly on the server, which can be very useful for managing and maintaining the website. For example, you can use commands like "mysqldump" to export your website database, or use "tar" to create an archive of your website files.

In summary, SSH access can make migrating a website to another server much easier and faster, but some hosting providers may deny this functionality to make migrating to another provider more difficult.

How this affects the life of Hosting providers and costs to end customers.

The difficulty of transferring a website from one vendor to another due to lack of SSH access can take much longer than a transfer with SSH access. This can lead to additional costs, especially if the site transfer takes a long time or if you need to use alternative methods, such as FTP transfer or manual file download and upload.

Also, in some cases, hosting providers may charge additional fees for migrating a website without SSH access. This may be because the transfer process becomes more complex and requires more time and resources to complete.

In summary, lack of SSH access can make migrating a website from one vendor to another more difficult and costly. It is important to consider this factor when choosing a hosting provider and check if they offer SSH access, as it could save you time and money in the future.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

Back to top