Table des matières de l'article :
Depuis que nous travaillons en tant qu'ingénieurs système, dans une journée de travail standard de 8 heures, nous perdons au moins 3 heures à organiser la migration des sites des anciens hébergeurs vers notre infrastructure.
Parmi les différents clients, on retrouve celui qui est mécontent de l'ancien hébergeur, celui qui vient de Amazon AWS et veut enregistrer des chiffres mensuels importants, ce qu'il veut optimiser i Vitaux Web de base, celui qui est pénalisé par Google parce qu'il est trop lent, curieux, gaspilleur de temps, amis d'amis, entreprises, entreprises, sociétés par actions, corporations et multinationales.
Quel que soit le client, la partie la plus frustrante du travail d'administrateur système orienté Web est l'intégration de nouveaux clients. La frustration est inévitable lorsque, pour remédier à une opération simple et triviale comme le transfert de données de l'ancien serveur vers le nouveau via peut-être un moyen très pratique rsync sur SSH, voilà que le fournisseur sortant (l'ancien) pour vous compliquer la vie et essayer de garder le client, vous interdit l'accès SSH, vantant des raisons de sécurité pour lesquelles SSH n'est pas autorisé, et est en effet protégé par un pare-feu.
Il y a des hébergeurs qui invoquent les raisons les plus absurdes, vous laissant à la merci d'un serveur FTP très lent ou aux diverses procédures de sauvegarde de scracuse, d'anciens panneaux obsolètes, cause et origine de tous les maux, comme Plesk et cPanel .
Même lorsque vous devez transférer 100 gigaoctets de fichiers, répartis en millions de fichiers. 1 heure de transfert avec Rsync, des journées complètes avec FTP.
Nous avons eu des cas où 800 Go de données ont dû être transférés de l'ancien serveur vers le nouveau et ont fini par devoir pirater un serveur X pour pouvoir utiliser le shell comme si l'hébergeur nous l'avait donné.
Bien sûr, avant le "hack", tous les processus fonctionnaient parfaitement avec les privilèges de l'utilisateur, donc les mêmes UID et GID, et aucune escalade vers root ou d'autres utilisateurs autres que ceux autorisés, nous avons demandé et fait demander de toutes les manières possibles la possibilité d'avoir un accès SSH avec un utilisateur non privilégié. Des e-mails sereins, aux appels téléphoniques cordiaux, courriers non officiels, courriers formels, menaces de dommages et intérêts de l'avocat, situations de ce type, dans lesquelles l'hébergeur de service a répondu par le contrat stipulé 10 ans plus tôt, dans lequel le numéro de paragraphe , il a été expliqué que l'accès SSH n'était pas autorisé pour des raisons de sécurité.
Dommage que le site ait démarré 10 ans plus tôt avec 5 Gigaoctets d'espace et aujourd'hui ils en sont à 800.
Facile à extraire 5 gigaoctets de données à l'aide de l'assistant de sauvegarde de Plesk ou de cPanel, un peu moins pour le faire avec 800 Go car il n'y aurait même pas assez d'espace disque pour produire l'archive tar.gz que ces panneaux effraient pour les amateurs produisent, à la place de copier directement sur le serveur de destination.
Impensable de faire un tel transfert avec FTP ou lftp, même pas avec des parallèles de 50 processus simultanés.
Par conséquent, nous avons voulu écrire cet article avec la réponse technique aux objections les plus courantes que les ingénieurs système incapables imposent généralement à leurs clients lorsqu'ils refusent de faciliter la migration vers un nouveau fournisseur.
SSH n'est pas fourni pour des raisons de sécurité
Les hébergeurs ne fournissent souvent pas d'accès SSH (Secure Shell) à leurs utilisateurs pour des raisons de sécurité. SSH est un protocole qui permet d'établir une connexion sécurisée entre deux systèmes, généralement entre un client et un serveur, et d'exécuter des commandes à distance.
Une préoccupation majeure des hébergeurs est d'assurer la sécurité de leurs systèmes et des données de leurs utilisateurs. L'accès SSH peut constituer un risque potentiel pour la sécurité, car il peut être utilisé par des utilisateurs malveillants pour obtenir un accès non autorisé aux systèmes ou pour effectuer des actions malveillantes.
Pour protéger leurs systèmes, les hébergeurs décident souvent de ne pas fournir d'accès SSH aux utilisateurs et proposent à la place d'autres outils, tels qu'un panneau de contrôle ou une interface Web, pour gérer leurs sites et leurs serveurs. De cette façon, les utilisateurs peuvent toujours effectuer des tâches d'administration de base sans courir le risque de compromettre la sécurité du système.
De plus, les hébergeurs proposent souvent des services de support technique pour aider les utilisateurs à gérer leurs sites et leurs serveurs en leur fournissant toutes les informations et tous les outils dont ils ont besoin. De cette façon, les utilisateurs peuvent obtenir l'assistance dont ils ont besoin sans avoir à utiliser l'accès SSH.
Ce raisonnement pourrait être considéré comme valable si ce n'était du fait que quel que soit l'accès SSH qui aurait pu être fourni au client, il aurait toujours été de type non administratif (non root) et que quel que soit le Sécurité tant vantée, les mêmes hébergeurs qui ne vous accordent pas le SSH sont alors les mêmes pour garantir l'accès au FTP (et non au FTP sécurisé) avec des mots de passe clairs.
Si l'on considère également que l'accès SSH peut être sur un autre port que SSH et lié à une IP statique à ouvrir sur le pare-feu, il est aisé de comprendre qu'un refus catégorique d'accès SSH même sur un autre port a un motivation différente plutôt que la motivation de sécurité tant vantée.
Un FTP clair et non crypté est fourni en standard.
FTP (File Transfer Protocol) a été l'un des premiers systèmes utilisés pour transférer des fichiers d'un système à un autre. Cependant, au fil des années et de l'augmentation des risques de sécurité en ligne, il est devenu de moins en moins sûr d'utiliser FTP pour les transferts de fichiers.
L'un des principaux problèmes avec FTP est que les informations de connexion, telles que le nom d'utilisateur et le mot de passe, sont envoyées en clair lors de la connexion. Cela signifie que si un attaquant parvient à intercepter ces informations, il peut obtenir un accès non autorisé aux fichiers transmis via FTP.
Une alternative plus sécurisée au FTP est le protocole SFTP (Secure File Transfer Protocol), qui utilise le cryptage pour protéger les informations de connexion et les fichiers pendant le transfert. Cela rend beaucoup plus difficile pour les utilisateurs malveillants d'obtenir un accès non autorisé aux fichiers transmis via SFTP.
De plus, SFTP offre un certain nombre d'autres fonctionnalités de sécurité, telles que l'authentification à deux facteurs et la possibilité de définir des autorisations d'accès pour chaque fichier ou dossier.
Les vraies raisons pour lesquelles l'accès SSH n'est pas accordé
Les fournisseurs d'hébergement peuvent refuser l'accès SSH pour rendre plus difficile la migration d'un site Web vers un autre fournisseur d'hébergement. L'accès SSH (Secure Shell) est un protocole réseau utilisé pour gérer et contrôler en toute sécurité des serveurs distants. Il vous permet d'exécuter des commandes et de transférer des fichiers via une connexion cryptée.
L'accès SSH peut faciliter et accélérer le déplacement d'un site Web vers un autre serveur, en particulier à l'aide de l'utilitaire Linux "rsync". Rsync est un outil qui vous permet de synchroniser des fichiers et des répertoires entre différents ordinateurs, de sorte que vous ayez toujours les mêmes copies de fichiers sur les deux systèmes. Rsync est beaucoup plus rapide qu'un transfert FTP (File Transfer Protocol) car il ne transfère que les fichiers qui ont été modifiés, plutôt que de transférer tous les fichiers à chaque fois.
De plus, l'accès SSH vous permet d'exécuter des commandes directement sur le serveur, ce qui peut être très utile pour gérer et maintenir le site Web. Par exemple, vous pouvez utiliser des commandes telles que "mysqldump" pour exporter la base de données de votre site Web ou utiliser "tar" pour créer une archive des fichiers de votre site Web.
En résumé, l'accès SSH peut rendre la migration d'un site Web vers un autre serveur beaucoup plus facile et plus rapide, mais certains hébergeurs peuvent refuser cette fonctionnalité pour rendre la migration vers un autre fournisseur plus difficile.
Comment cela affecte la vie des fournisseurs d'hébergement et les coûts pour les clients finaux.
La difficulté de transférer un site Web d'un fournisseur à un autre en raison d'un manque d'accès SSH peut prendre beaucoup plus de temps qu'un transfert avec un accès SSH. Cela peut entraîner des coûts supplémentaires, en particulier si le transfert de site prend beaucoup de temps ou si vous devez utiliser des méthodes alternatives, telles que le transfert FTP ou le téléchargement et le téléchargement manuels de fichiers.
De plus, dans certains cas, les hébergeurs peuvent facturer des frais supplémentaires pour la migration d'un site Web sans accès SSH. Cela peut être dû au fait que le processus de transfert devient plus complexe et nécessite plus de temps et de ressources.
En résumé, le manque d'accès SSH peut rendre la migration d'un site Web d'un fournisseur à un autre plus difficile et coûteuse. Il est important de prendre en compte ce facteur lors du choix d'un fournisseur d'hébergement et de vérifier s'il offre un accès SSH, car cela pourrait vous faire économiser du temps et de l'argent à l'avenir.
