Indice dei contenuti dell'articolo:
Da quando facciamo il lavoro di sistemisti, in una giornata lavorativa standard di 8 ore, ne perdiamo almeno 3, nell’organizzare procedure di migrazione di siti da vecchi fornitori di Hosting alla nostra infrastruttura.
Tra i vari clienti, troviamo quello insoddisfatto del vecchio fornitore di Hosting, quello che viene da Amazon AWS e vuol risparmiare importanti cifre mensili, quello che che vuole ottimizzare i Core Web Vitals, quello che viene penalizzato da Google perchè troppo lento, curiosi, perditempo, amici degli amici, aziendine, aziende, Società per azioni, corporation e multinazionali.
A prescindere da chi sia il cliente, la parte più frustrante del lavoro di sistemista orientato al web è nel fare l’onboarding dei nuovi clienti. La frustrazione è inevitabile, quando per ovviare ad un’operazione semplice e banale come fare un trasferimento di dati dal vecchio server al nuovi server magari tramite un comodissimo rsync over SSH, ecco qui che il fornitore uscente (quello vecchio) per renderti la vita più difficile e cercare di tenersi il cliente, ti vieta l’accesso SSH, millantando motivi di sicurezza per cui SSH non viene concesso, e anzi viene firewallato.
Ci sono fornitori di Hosting che tirano in ballo le più assurde motivazioni, lasciandoti alla mercè di un lentissimo server FTP o alle varie procedure di backup di pannelli scrausi, vetusti obsoleti, causa ed origine di ogni male, come Plesk e cPanel.
Anche quando devi trasferire 100 Gigabyte di files, distribuiti in milioni di files. 1 ora di trasferimento con Rsync, intere giornate con FTP.
Abbiamo avuto casi in cui è stato necessario trasferire 800GB di dati dal vecchio server al nuovo e alla fine abbiamo dovuto hackerare tramite un server X per poter utilizzare la Shell come se il fornitore di hosting ce l’avesse data.
Ovviamente prima di “hackerare” in realtà tutti i processi giravano perfettamente con i privilegi utente, quindi stesso UID e GID, e nessuna escalation a root o altri utenti diversi da quelli autorizzati, abbiamo chiesto e fatto chiedere in tutte le salse la possibilità di avere accesso SSH con utente non privilegiato. Da e-mail serene, a telefonate cordiali, mail ufficiose, mail formali, minacce per danni da parte del legale, situazioni di questo tipo, in cui l’azienda di Hosting di turno rispondeva con il contratto stipulato 10 anni prima, in cui al paragrafo numero, si illustrava come l’accesso SSH non fosse consentito per motivi di sicurezza.
Peccato che il sito era partito 10 anni prima con 5 Gigabyte di spazio e ad oggi sono ad 800.
Facile tirare giù 5 Gigabyte di dati utilizzando la utility del backup guidato di Plesk o cPanel, un po’ meno farlo con 800GB dato che non ci sarebbe nemmeno lo spazio sufficiente sul disco per produrre l’archivio tar.gz che questi pannelli scrausi per dilettanti producono, invece di copiare direttamente sul server di destinazione.
Impensabile fare un trasferimento del genere con FTP o lftp, nemmeno con parallelismi di 50 processi simultanei.
Abbiamo voluto scrivere pertanto questo post con la risposta tecnica alle obiezioni più comuni che i sistemisti incapaci sono soliti rifilare ai loro clienti quando si rifiutano di agevolare la migrazione verso un nuovo fornitore.
SSH non viene fornito per motivi di sicurezza
Gli hosting provider spesso non forniscono accesso SSH (Secure Shell) ai loro utenti per motivi di sicurezza. SSH è un protocollo che permette di stabilire una connessione sicura tra due sistemi, solitamente tra un client e un server, e di eseguire comandi da remoto.
Una delle principali preoccupazioni per gli hosting provider è garantire la sicurezza dei loro sistemi e dei dati dei loro utenti. L’accesso SSH può rappresentare un potenziale rischio per la sicurezza, poiché può essere utilizzato da utenti malintenzionati per accedere ai sistemi in modo non autorizzato o per eseguire azioni dannose.
Per proteggere i loro sistemi, gli hosting provider spesso decidono di non fornire accesso SSH agli utenti e di offrire invece altri strumenti, come il pannello di controllo o l’interfaccia web, per gestire i loro siti e i loro server. In questo modo, gli utenti possono comunque svolgere le attività di amministrazione di base senza correre il rischio di compromettere la sicurezza del sistema.
Inoltre, gli hosting provider spesso offrono servizi di assistenza tecnica per aiutare gli utenti a gestire i loro siti e i loro server, fornendo loro tutte le informazioni e gli strumenti di cui hanno bisogno. In questo modo, gli utenti possono ottenere il supporto di cui hanno bisogno senza dover utilizzare l’accesso SSH.
Questa motivazione potrebbe ritenersi valida se non fosse che a prescindere l’accesso SSH che si sarebbe potuto fornire al cliente sarebbe stato comunque di tipo non amministrativo (non root) e che a prescindere dalla tanto millantata sicurezza, gli stessi hosting provider che non vi concedono SSH sono poi gli stessi a garantivi gli accessi FTP (e non Secure FTP) con le password in chiaro.
Se teniamo anche in considerazione che l’accesso SSH potrebbe essere su una porta differente dalla SSH e legata ad un ‘IP statico da aprire sul firewall, è facile capire che un rifiuto categorico dell’accesso SSH anche su porta differente, ha tutt’altra motivazione rispetto alla tanto millantata motivazione di sicurezza.
FTP in chiaro e non crittografato invece viene fornito come standard.
Il protocollo FTP (File Transfer Protocol) è stato uno dei primi sistemi utilizzati per trasferire file da un sistema all’altro. Tuttavia, con il passare degli anni e l’aumento dei rischi per la sicurezza online, è diventato sempre meno sicuro utilizzare FTP per il trasferimento dei file.
Una delle principali preoccupazioni con FTP è che le informazioni di login, come nome utente e password, vengono inviate in chiaro durante la connessione. Ciò significa che, se un utente malintenzionato riesce a intercettare queste informazioni, può accedere ai file trasmessi tramite FTP in modo non autorizzato.
Un’alternativa più sicura al FTP è SFTP (Secure File Transfer Protocol), che utilizza la crittografia per proteggere le informazioni di login e i file durante il trasferimento. Ciò rende molto più difficile per gli utenti malintenzionati accedere ai file trasmessi tramite SFTP in modo non autorizzato.
Inoltre, SFTP offre una serie di altre funzionalità di sicurezza, come l’autenticazione a due fattori e la possibilità di impostare permessi di accesso per ogni file o cartella.
Le vere motivazioni per cui non viene concesso l’accesso SSH
Gli hosting provider potrebbero negare l’accesso SSH per rendere più difficile la migrazione di un sito web verso un altro fornitore di hosting. L’accesso SSH (Secure Shell) è un protocollo di rete utilizzato per gestire e controllare in modo sicuro i server remoti. Permette di eseguire comandi e trasferire file attraverso una connessione crittografata.
L’accesso SSH può rendere molto più facile e veloce il trasferimento di un sito web in un altro server, soprattutto utilizzando l’utility “rsync” di Linux. Rsync è uno strumento che permette di sincronizzare file e directory tra diversi computer, in modo da avere sempre le stesse copie dei file su entrambi i sistemi. Rsync è molto più veloce di un trasferimento FTP (File Transfer Protocol) perché trasferisce solo i file che sono stati modificati, invece di trasferire tutti i file ogni volta.
Inoltre, l’accesso SSH permette di eseguire comandi direttamente sul server, il che può essere molto utile per la gestione e il mantenimento del sito web. Ad esempio, è possibile utilizzare comandi come “mysqldump” per esportare il database del sito web, o utilizzare “tar” per creare un archivio dei file del sito web.
In sintesi, l’accesso SSH può rendere molto più semplice e veloce la migrazione di un sito web in un altro server, ma alcuni hosting provider potrebbero negare questa funzionalità per rendere più difficile la migrazione verso un altro provider.
Come ciò impatta sulla vita dei fornitori di Hosting e sui costi verso i clienti finali.
La difficoltà di trasferire un sito web da un fornitore all’altro a causa della mancanza di accesso SSH può richiedere molto più tempo rispetto ad un trasferimento con accesso SSH. Questo può comportare dei costi aggiuntivi, soprattutto se il trasferimento del sito richiede molto tempo o se è necessario utilizzare metodi alternativi, come il trasferimento FTP o il download e l’upload manuale dei file.
Inoltre, in alcuni casi, i fornitori di hosting potrebbero addebitare tariffe aggiuntive per la migrazione di un sito web senza accesso SSH. Questo può essere dovuto al fatto che il processo di trasferimento diventa più complesso e richiede più tempo e risorse per essere completato.
In sintesi, la mancanza di accesso SSH può rendere più difficoltosa e costosa la migrazione di un sito web da un fornitore all’altro. È importante considerare questo fattore quando si sceglie un fornitore di hosting e verificare se offre l’accesso SSH, poiché potrebbe risparmiare tempo e denaro in futuro.
