Hai generato la tua coppia di chiavi e ora vuoi usarla per entrare nel tuo hosting. In questa guida vediamo come funziona da noi: con quali dati ci si collega, come si aggiunge la chiave pubblica, come ci si collega e come rendere tutto più comodo con un piccolo file di configurazione.

Se ancora non hai una chiave, parti da Generare una chiave SSH su Windows, macOS e Linux.

Passo 1: i dati di accesso

Sui nostri server l’accesso SSH è disponibile sulla porta 7530. La porta 22, quella data per scontata da molte guide online, da noi è chiusa: provandola otterresti solo un timeout.

Per collegarti ti servono tre dati:

  1. Utente: il nome utente del tuo account di hosting.
  2. Server: l’indirizzo del server indicato nell’email di attivazione del servizio.
  3. Porta: 7530.

Il metodo consigliato è la chiave SSH: è più sicura e più comoda di una password, e la aggiungi da solo dal pannello, come vediamo al passo successivo.

Mai condividere la chiave privata (il file senza .pub, che inizia con -----BEGIN OPENSSH PRIVATE KEY-----): non ti verrà mai chiesta, né da noi né da nessun altro con buone intenzioni.

Passo 2: la chiave pubblica sul server

Ci sono più modi per far arrivare la chiave pubblica nel posto giusto. Scegli quello più comodo.

Dal pannello di controllo

È la strada più semplice. Il pannello DirectAdmin, a cui accedi direttamente dall’area clienti, ha una sezione dedicata alle chiavi SSH, da cui puoi aggiungere o rimuovere le chiavi autorizzate. Incolla lì la chiave pubblica: il contenuto del file che termina in .pub, una sola riga che inizia con ssh-ed25519 o ssh-rsa. La posizione esatta della voce può variare a seconda del tema del pannello: cerca quella relativa alle chiavi SSH. Se non la trovi, scrivici e ti guidiamo.

Dal terminale, se sei già dentro

Se hai già un accesso funzionante (per esempio con un’altra chiave) e vuoi aggiungerne una nuova, la chiave pubblica va aggiunta come nuova riga nel file ~/.ssh/authorized_keys sul server:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys     # incolla la chiave su una nuova riga, salva ed esci
chmod 600 ~/.ssh/authorized_keys

Una chiave per riga, senza spezzarla. I permessi sono importanti: se sono troppo larghi, il server ignora il file.

Su macOS e Linux esiste anche il comando ssh-copy-id, che fa tutto da solo:

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 7530 tuoutente@server

Funziona però solo se il server accetta già un altro modo di accesso per il tuo account. In caso contrario usa il pannello.

Passo 3: il primo collegamento

Ora puoi collegarti con:

ssh -p 7530 tuoutente@server

Sostituisci tuoutente con il nome utente del tuo account e server con l’indirizzo indicato nell’email di attivazione. Se la tua chiave non ha il nome predefinito, indicala esplicitamente:

ssh -i ~/.ssh/id_ed25519_hosting -p 7530 tuoutente@server

Al primo collegamento ti verrà chiesto di confermare l’impronta del server: rispondi yes. Se hai messo una passphrase sulla chiave, ti verrà chiesta (in locale: non viaggia verso il server).

Una volta dentro, ti trovi nella tua home. I file dei siti sono in ~/domains/tuodominio.it/public_html.

Passo 4: renditi la vita facile con ~/.ssh/config

Ricordare porta, utente, indirizzo e nome della chiave ogni volta è scomodo. Sul tuo computer puoi creare (o modificare) il file ~/.ssh/config e dare un nome breve alla connessione:

Host miosito
  HostName server
  Port 7530
  User tuoutente
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Da quel momento ti basta scrivere:

ssh miosito

Lo stesso nome funziona anche con scp, rsync e Git, come vediamo in Copiare file con SCP e rsync e in Git per pubblicare il tuo sito. Su Windows il file si trova in C:\Users\TuoNome\.ssh\config (senza estensione).

IdentitiesOnly yes dice al client di provare solo la chiave indicata: evita che, se hai molte chiavi caricate, il server rifiuti la connessione per troppi tentativi.

Quando non funziona

Sintomo Causa probabile
Connection timed out Porta sbagliata: spesso la 22 copiata da una guida, mentre da noi la porta SSH è la 7530.
Connection refused Indirizzo o porta non corretti: ricontrolla l’indirizzo del server nell’email di attivazione e usa la porta 7530.
Permission denied (publickey) Il server non riconosce la chiave: pubblica non aggiunta dal pannello, installata spezzata su più righe, o il client sta usando un’altra chiave (prova con -i).
Ti chiede una password che non conosci La chiave non viene accettata e il client ripiega su altro: vedi la riga precedente.
UNPROTECTED PRIVATE KEY FILE Permessi troppo larghi sulla chiave privata nel tuo computer: chmod 600 ~/.ssh/id_ed25519.

Per capire cosa succede puoi aggiungere -v al comando (ssh -v -p 7530 tuoutente@server): il client stampa ogni passaggio, comprese le chiavi che prova. Se ci apri un ticket, allegare quell’output ci aiuta a risolvere più in fretta (non contiene la tua chiave privata).

Gestire le chiavi nel tempo

  • Una chiave per dispositivo: portatile, PC dell’ufficio, eventuale server di sviluppo. Se ne perdi uno, revochi solo quella chiave.
  • Collaboratori: aggiungi la loro chiave pubblica, mai condividere la tua. A lavoro finito, toglila.
  • Pulizia periodica: ogni tanto controlla l’elenco delle chiavi autorizzate e rimuovi quelle che non riconosci o non usi più.
  • Chiave compromessa: rimuovila subito dal server, generane una nuova e, se hai dubbi, scrivici.

E se ti serve solo trasferire file?

Per caricare e scaricare file non serve SSH: puoi usare SFTP sulla porta 2300 con le credenziali di un account FTP, oppure FTPS sulla porta 2100, come indicato nell’email di attivazione del servizio. SSH conviene quando hai bisogno di eseguire comandi, per esempio con WP-CLI.

Altri articoli su SSH, terminale e sviluppo

Parliamone

Un hosting che ti spiega le cose, e poi le fa

Questi articoli nascono dalle domande dei nostri clienti. Se vuoi un hosting dove dietro ogni risposta c’è un tecnico vero, parliamone.

  • 4,9 su 5 su Trustpilot264 recensioni, il 96% a cinque stelle
  • Risponde un tecnicoIn italiano, da chi gestisce i server
  • Il trasloco lo facciamo noiSito, database e posta, controllati prima di spostare i DNS