Come connettersi al tuo nuovo server cloud via SSH

Come connettersi al tuo nuovo server cloud via SSH

Il server è acceso, il pannello mostra un indirizzo IP, un login e una password, e ora bisogna entrarci. Questa è quella prima connessione, più le poche cose che vale la pena fare prima di installare qualsiasi cosa.

Cosa ti dà il pannello

Apri il server nel pannello di controllo e guarda il blocco Access. Contiene le tre cose che ti servono: l'indirizzo IP, Login e Password. Accanto ci sono due pulsanti. Generate new password ne crea una casuale nuova, Set new password accetta quella che scegli tu. Entrambi agiscono sul server in funzione, quindi usali se la password è ferma da un po' in qualche finestra di chat.

La prima connessione

Su macOS e su qualsiasi desktop Linux SSH è già installato. Su Windows fa parte del sistema da Windows 10 e Windows Server 2019, quindi lo stesso comando funziona in PowerShell senza installare PuTTY:

ssh root@203.0.113.10

La prima volta SSH mostra un'impronta e chiede se procedere. Quella domanda non è una formalità: SSH ti sta dicendo che non ha mai visto questo host e non può garantire per lui. Su un server appena creato rispondi yes. La chiave finisce in ~/.ssh/known_hosts e la domanda non torna per quell'indirizzo.

Passa alle chiavi, poi chiudi la porta

Le password si riusano, si digitano nella finestra sbagliata e si incollano nei ticket. Le chiavi no. Generane una sulla tua macchina, non sul server:

ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id root@203.0.113.10

Poi verifica che l'accesso con chiave funzioni in una seconda finestra di terminale, prima di cambiare qualcosa. Non chiudere la prima. Se la nuova impostazione è sbagliata, è proprio quella sessione già aperta che userai per tornare indietro.

Appena la seconda finestra entra senza password, modifica /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin prohibit-password

e ricarica con systemctl reload ssh su Debian e Ubuntu, oppure systemctl reload sshd su AlmaLinux e Rocky.

I quattro errori che capitano davvero

Cosa vedi	Cosa significa	Cosa fare
Permission denied (publickey)	Il server non accetta più password e non ha la tua chiave	Apri la console KVM e controlla ~/.ssh/authorized_keys e sshd_config
Connection refused	Qualcosa ha risposto: l'host è acceso, ma sulla porta 22 non ascolta nulla	Console, poi systemctl status ssh - il servizio è fermo o spostato su un'altra porta
Connection timed out	Non ha risposto nessuno: un firewall scarta i pacchetti, l'indirizzo è sbagliato, oppure il server è spento	Controlla lo stato di alimentazione nel pannello, poi le tue regole di firewall
REMOTE HOST IDENTIFICATION HAS CHANGED	La chiave dell'host è diversa da quella salvata	Normale dopo una reinstallazione o il ripristino di uno snapshot. Rimuovi la voce vecchia con ssh-keygen -R 203.0.113.10

La distinzione utile sta nelle due righe centrali. Refused vuol dire che il server è raggiungibile e il problema è un servizio. Timed out vuol dire che i tuoi pacchetti non hanno mai avuto risposta, quindi il problema sta fra te e lui.

La console è la via di ritorno

Ogni errore di questo articolo ti chiude fuori da SSH e nessuno ti chiude fuori dal server. Il pannello ha una console KVM, cioè schermo e tastiera collegati direttamente alla VM, e una console testuale per i sistemi che la supportano. Nessuna delle due passa da SSH, quindi un sshd_config rotto, una regola di firewall che ha bloccato il tuo stesso indirizzo o una chiave cancellata si sistemano in circa un minuto.

Vale la pena saperlo prima di iniziare, perché sposta il confine di ciò che è rischioso. Restare chiusi fuori qui è una scocciatura, non un incidente.

I primi dieci minuti

• Aggiorna il sistema - apt update && apt upgrade oppure dnf upgrade, prima che sul disco arrivi altro
• Crea un utente e lascia stare root - adduser you, mettilo in sudo o wheel e da qui in poi entra con quello
• Imposta l'hostname e controlla l'orologio - hostnamectl set-hostname web-01, poi timedatectl, perché un'ora sbagliata rompe certificati e log
• Attiva gli aggiornamenti di sicurezza automatici - unattended-upgrades su Debian e Ubuntu, dnf-automatic altrove
• Fai uno snapshot - prima della prima installazione, non dopo che qualcosa si è rotto

In sintesi

La prima connessione è un comando solo. Dove conviene rallentare è il passaggio alle chiavi, e la regola che lo rende sicuro è semplice: non chiudere mai la sessione che funziona finché una nuova non si è dimostrata valida. Se va storto lo stesso, la console nel pannello è sempre lì.

Server cloud in Cechia e Portogallo, da EUR 15/mese, con console e reset della password su ognuno: dcxv.com/data-center#cloud