Collegarsi in SSH a un abbonamento Plesk (e il client che consigliamo: Termius)

La cosa che fa perdere piu' tempo: l'utenza non e' quella del pannello

Su un server Plesk ogni abbonamento ha due identita' diverse, e vengono confuse continuamente:

• le credenziali con cui si entra nel pannello (porta 8443), che sono un indirizzo email e una password;
• le credenziali dell'utente di sistema dell'abbonamento, che sono un nome utente Linux e servono per SSH, SFTP e FTP.

Con le prime il collegamento SSH non funzionera' mai, per quante volte si riprovi la password. Serve il nome utente di sistema, che in Plesk si legge in Abbonamenti → (nome dell'abbonamento) → Accesso all'hosting web, nel campo Nome utente. E' un nome breve, spesso derivato dal dominio, del tipo miodominio oppure miodominio_a1b2c3.

Prima di tutto: l'accesso va abilitato

Per impostazione predefinita Plesk tiene l'accesso SSH disattivato su ogni abbonamento. Se non lo si abilita, il collegamento viene rifiutato anche con le credenziali giuste.

Si abilita in Abbonamenti → (nome dell'abbonamento) → Accesso all'hosting web, alla voce Accesso alla shell del server tramite SSH. Le scelte possibili sono tre, e la differenza conta molto:

• Vietato — nessun accesso. E' il valore predefinito.
• /bin/bash (chroot) — accesso in ambiente isolato. L'utente vede solo il proprio spazio e ha a disposizione pochi comandi.
• /bin/bash — shell completa. L'utente resta confinato alla propria cartella per i permessi, ma ha a disposizione tutti i comandi del sistema.

Se la voce non e' modificabile, significa che il piano di hosting associato all'abbonamento non concede quel permesso: va cambiato nel piano, oppure sull'abbonamento tolta la sincronizzazione con il piano.

Che dati servono per collegarsi

Quattro informazioni, non di piu':

• indirizzo del server — l'hostname (per esempio server1.miodominio.it) oppure direttamente l'indirizzo IP. Attenzione: usare il dominio del sito funziona solo se quel dominio punta davvero al server. Se sta dietro a Cloudflare con il proxy acceso, il nome risolve all'IP di Cloudflare e il collegamento non arriva mai a destinazione: in quel caso serve l'IP reale del server.
• porta — 22 se nessuno l'ha cambiata. Su molti server viene spostata per ridurre i tentativi automatici di accesso: se la 22 non risponde, chiedere qual e' la porta giusta prima di pensare a un guasto.
• nome utente di sistema dell'abbonamento (vedi sopra).
• password dell'utente di sistema, oppure — meglio — una chiave SSH.

Collegarsi dal terminale (Linux e macOS)

Su Linux e macOS il programma c'e' gia' installato. Il comando e':

ssh nomeutente@server1.miodominio.it

Se la porta non e' la 22, si indica con -p:

ssh -p 2222 nomeutente@server1.miodominio.it

Al primo collegamento viene chiesto di confermare l'impronta del server: e' normale e va accettata una sola volta.

Il programma che consigliamo: Termius

Su Windows il programma non c'e' di serie, e anche su Linux e macOS gestire a memoria decine di server diversi diventa scomodo. Termius e' il programma che consigliamo, per tre ragioni pratiche:

• funziona su Windows, macOS, Linux, iPhone e Android con la stessa interfaccia, quindi si impara una volta sola;
• conserva l'elenco dei server con nome, porta, utenza e chiave, raggruppabili per cliente: non serve ricordare niente a memoria;
• include il trasferimento file (SFTP) nella stessa finestra del terminale, quindi non serve un secondo programma per caricare o scaricare un file.

Si scarica da termius.com. La versione gratuita e' sufficiente per collegarsi e trasferire file; la sincronizzazione delle credenziali fra piu' dispositivi e' a pagamento.

Aggiungere un server in Termius

1. Aprire Termius e scegliere New Host.
2. Address: l'hostname o l'IP del server.
3. Port: 22, oppure la porta effettiva.
4. Username: il nome utente di sistema dell'abbonamento.
5. Password: la password dell'utente di sistema. Se invece si usa una chiave, scegliere Key e selezionare quella giusta.
6. Dare un nome riconoscibile nel campo Label — consigliato il nome del cliente, non quello del dominio: i domini cambiano, i clienti meno.
7. Salvare e fare doppio clic sulla voce per collegarsi.

Per il trasferimento file, dalla stessa voce si apre la scheda SFTP: le credenziali sono le medesime, non va configurato niente di nuovo.

Meglio una chiave che una password

Una password su una porta esposta a Internet viene provata da programmi automatici migliaia di volte al giorno. Con una chiave il problema non esiste.

La chiave si genera una volta sola, sul proprio computer:

ssh-keygen -t ed25519 -C "nome.cognome"

Si ottengono due file: id_ed25519 (la parte privata, che non si manda a nessuno e non si copia su nessun server) e id_ed25519.pub (la parte pubblica, che si consegna senza problemi).

La parte pubblica va messa sul server, nel file ~/.ssh/authorized_keys della cartella dell'utente dell'abbonamento. Se il server ha l'estensione SSH Keys Manager di Plesk, si carica dal pannello senza toccare il terminale.

In Termius le chiavi si importano una volta in Keychain e poi si associano a tutti i server che le usano.

Dove si finisce dopo il collegamento

Si entra nella cartella dell'abbonamento, che su Plesk e' /var/www/vhosts/nomedominio.it/. Dentro si trovano:

• httpdocs/ — i file del sito, la cartella pubblica;
• logs/ — i log di accesso e di errore del dominio;
• conf/ — la configurazione generata da Plesk, da non modificare a mano perche' viene riscritta.

Se si e' in ambiente isolato (chroot)

Con l'opzione /bin/bash (chroot) molti comandi semplicemente non esistono: niente git, spesso niente mysql, a volte nemmeno unzip. Non e' un guasto, e' il recinto che fa il suo lavoro.

Per capire se si e' dentro un recinto, basta questo:

ls /usr/bin | wc -l

In una shell completa i risultati sono qualche centinaio; in chroot sono poche decine. Un altro segnale e' cd / seguito da ls: se si vede solo una manciata di cartelle invece dell'albero completo del sistema, si e' nel recinto.

Se serve un comando che manca, le strade sono due: passare l'abbonamento alla shell completa, oppure far aggiungere quel comando all'ambiente isolato dall'amministratore del server. La prima e' immediata ma concede molto di piu'; la seconda e' piu' prudente.

Gli errori che si incontrano, e cosa significano davvero

• Permission denied (publickey,password) — nove volte su dieci si stanno usando le credenziali del pannello invece di quelle dell'utente di sistema. Altrimenti: accesso SSH impostato su Vietato, o password sbagliata.
• Connection refused — si e' arrivati al server ma su quella porta non risponde nessuno: porta sbagliata, oppure servizio SSH spento.
• Connection timed out — non si e' arrivati affatto: un firewall blocca, oppure l'indirizzo e' quello di Cloudflare e non quello del server.
• Troppi tentativi e poi silenzio — dopo alcuni accessi sbagliati il proprio indirizzo IP viene bloccato dal sistema di protezione. Non serve insistere: va sbloccato dall'amministratore, oppure si aspetta la scadenza del blocco.
• bash: comando non trovato su un comando che dovrebbe esserci — si e' in ambiente isolato (vedi sopra).
• REMOTE HOST IDENTIFICATION HAS CHANGED — l'impronta del server non e' piu' quella memorizzata. Capita legittimamente dopo una reinstallazione o una migrazione, ma va verificato prima di accettarla: e' lo stesso avviso che comparirebbe se qualcuno si fosse messo in mezzo.

Due avvertenze

La shell da' accesso a tutti i file del sito, log e configurazioni comprese. Su un server condiviso, concederla equivale a dare le chiavi di casa: va valutato caso per caso, non attivato per abitudine.

E chi ha la shell puo' cancellare in un comando quello che ci si e' messi mesi a costruire, senza nessuna richiesta di conferma e senza cestino. Prima di operare su un sito in produzione, assicurarsi che esista un backup recente e verificato.