Come collegarti al tuo VPS via SSH per la prima volta

Accedere come root è un po' come muoversi con un passe-partout: è un metodo rapido e potente, ma basta un singolo errore per fare danni irreparabili.

In breve: per creare un utente non-root con privilegi sudo, occorre prima creare un account utente standard, fornirgli l'autorizzazione per eseguire attività amministrative tramite sudo, verificare che l'accesso funzioni e, soltanto alla fine, limitare o disabilitare l'accesso diretto come root. Questo approccio rende la gestione quotidiana del server molto più sicura: i comandi ordinari vengono eseguiti con permessi limitati, mentre le facoltà amministrative vengono richiamate solo quando strettamente necessario.

Cos’è un utente non-root con privilegi sudo?

Su un server Linux, root è l'account amministrativo supremo. Può modificare file di sistema, rimuovere applicazioni, alterare le impostazioni di sicurezza ed eliminare intere directory senza mai chiedere conferma.

Un utente non-root, al contrario, è un account standard con permessi circoscritti. Può essere paragonato a un badge aziendale standard anziché al passe-partout dell'edificio: permette di accedere unicamente ai locali necessari, evitando di sbloccare o compromettere inavvertitamente l'intera struttura ad ogni movimento.

L'acronimo sudo sta per superuser do. Questo comando consente a un utente standard autorizzato di eseguire un singolo comando con i privilegi di amministratore. Anziché operare costantemente come root, si attivano i poteri amministrativi solo per la singola operazione richiesta, per poi tornare immediatamente al profilo standard.

Questa breve pausa riflessiva è fondamentale: ogni volta che si digita sudo, si compie un'azione consapevole, ricordando a se stessi che il comando in esecuzione modificherà il sistema.

Perché l'accesso diretto come root è rischioso?

Accedere direttamente come root è pericoloso perché ogni singolo comando viene eseguito con la massima autorità. Non esiste alcuna barriera di protezione tra un semplice errore di battitura e una modifica irreversibile al sistema.

Durante una sessione root, un errore di digitazione in un comando di eliminazione, una configurazione errata dei permessi di un file o un codice copiato da un tutorial datato possono compromettere seriamente l'intero server. È come cucinare tenendo la fiamma al massimo: può anche funzionare, ma non concede il minimo margine di disattenzione.

Inoltre, root rappresenta il bersaglio primario per gli attacchi informatici. I malintenzionati sanno bene che l'account root esiste su gran parte dei server Linux e concentrano i loro tentativi automatici per violarne le credenziali o sfruttarne le vulnerabilità. Creare un utente dedicato con permessi sudo non elimina qualsiasi rischio, ma chiude la porta d'accesso più evidente ed esposta.

Per questa ragione, la creazione di un utente sudo rappresenta uno dei pilastri fondamentali della messa in sicurezza iniziale, al pari di un firewall. A questo proposito, una volta completata la gestione degli accessi, ti consigliamo di consultare la nostra guida su come configurare un firewall sul server.

Come creare un utente sudo in tutta sicurezza?

La procedura consigliata è lineare: si crea il nuovo utente, gli si assegnano i privilegi sudo, si verifica il funzionamento dell'accesso e, solo al termine, si limita l’accesso diretto dell'utente root.

Sui principali sistemi Ubuntu o Debian, il procedimento è il seguente:

bashadduser sam
usermod -aG sudo sam

È sufficiente sostituire sam con il nome utente desiderato. Il primo comando crea il nuovo account; il secondo lo aggiunge al gruppo sudo, ovvero la lista degli utenti autorizzati a eseguire comandi con i privilegi di sistema.

Successivamente, occorre verificare che il nuovo utente riesca ad autenticarsi correttamente. Se si utilizzano chiavi SSH, è necessario copiare la chiave pubblica all'interno del profilo del nuovo utente. Importante: non chiudere la sessione root corrente! Apri una seconda finestra del terminale e verifica le nuove credenziali.

Una volta effettuato l'accesso, prova ad eseguire un comando amministrativo non invasivo tramite sudo (ad esempio, il controllo degli aggiornamenti di sistema). Se il sistema richiede la password dell'utente ed esegue il comando senza errori, l'accesso sudo è configurato correttamente.

Soltanto a questo punto è opportuno disabilitare il login diretto come root via SSH. La tempistica è cruciale: se si disattiva l'accesso root prima di aver verificato le nuove credenziali, si rischia di rimanere bloccati fuori dal server, trasformando un'operazione da cinque minuti in un ripristino di emergenza.

Cosa può andare storto con una gestione errata dei permessi?

L'errore più frequente è il messaggio: sudo: user is not in the sudoers file. Questo indica che l'utente è stato creato, ma non è stato abilitato ad eseguire operazioni amministrative. Per risolverlo, occorre associare l'utente al gruppo con i permessi sudo o aggiungere una regola specifica nel file sudoers, operando da un account amministrativo già attivo.

Un'altra anomalia diffusa è l'errore Permission denied (publickey). Generalmente segnala che il server non ha riscontrato una chiave SSH valida abbinata al profilo in uso. L'account potrebbe essere corretto, ma la chiave potrebbe trovarsi in un percorso errato, avere permessi/proprietario non validi o appartenere a un altro utente.

Inoltre, occorre prestare attenzione alla titolarità (ownership) dei file. Se i file di un'applicazione vengono creati da root e successivamente l'applicazione viene eseguita con un utente standard, quest'ultimo potrebbe non avere i permessi per scrivere i log, caricare file o completare gli aggiornamenti. L'applicazione sembrerà malfunzionante, ma la causa risiede semplicemente in un conflitto di proprietà dei file.

In caso di problemi con gli accessi, la consultazione dei log del sistema offre solitamente la chiave di svolta. Se vuoi approfondire questo argomento, puoi consultare questa guida alla lettura dei log del server per imparare a distinguere i problemi di autenticazione da quelli legati alle applicazioni.

FAQ

L'account root serve ancora? Sì, ma in linea generale non è necessario effettuare il login diretto come root. I privilegi amministrativi rimangono accessibili tramite il comando sudo eseguito da un utente autorizzato.

Ogni progetto dovrebbe utilizzare un utente dedicato? Nella maggior parte dei casi sì. Utilizzare utenti distinti previene il rischio che un'applicazione vada a modificare o sovrascrivere accidentalmente i file di un altro progetto.

**sudo è davvero più sicuro dell'accesso come root?** Sì, perché nell'operatività quotidiana limita l'uso dei privilegi amministrativi a operazioni temporanee e mirate. Pur non essendo una soluzione infallibile, riduce drasticamente i danni dovuti a sviste o errori accidentali.

**Si può disabilitare subito il login diretto come root?** No, mai farlo prima di aver testato il nuovo utente con permessi sudo in una sessione SSH parallela, altrimenti si corre il rischio concreto di rimanere chiusi fuori dal server.

La scorciatoia

Server Manager semplifica l'intera gestione rendendo sempre visibile la configurazione degli accessi, evitando di dover fare affidamento sulla memoria o su appunti sparsi. In questo modo è possibile verificare immediatamente quale utente gestisce il server e l'allocazione dei vari progetti, prevenendo le classiche sovrapposizioni in cui root risulta proprietario di risorse necessarie all'applicazione.

Questo evita il sorgere di problematiche insidiose a distanza di tempo, come applicazioni che non riescono a registrare i log, procedure di deploy bloccate dai permessi o configurazioni dimenticate. Il beneficio principale non risiede nello saltare le nozioni tecniche, ma nel mantenere la struttura del server chiara e ordinata anche dopo la fase iniziale.

Un'organizzazione trasparente si rivela preziosa quando si torna sul server a distanza di mesi per aggiornare un'applicazione, effettuare un ripristino o trasferire un sito web: l'architettura degli accessi rimane comprensibile ed efficiente. A tal proposito, ricordati di verificare che i backup del server siano effettivamente ripristinabili e non semplicemente generati.

Quali sono i vantaggi di una configurazione di accesso sicura?

Configurare un utente non-root dotato di privilegi sudo garantisce un ambiente di lavoro decisamente più sereno e controllato. Mantieni intatta la possibilità di installare software, aggiornare i servizi e risolvere malfunzionamenti, senza tuttavia applicare la massima autorità amministrativa a ogni singolo comando.

Il risultato è immediato: drastica riduzione del rischio di incidenti critici, totale chiarezza nella gestione dei permessi e una struttura di sistema semplice da comprendere anche a distanza di tempo.

Hai un server appena creato, un accesso ricevuto dal provider e una finestra nera del terminale che sembra pronta a rompere qualcosa se scrivi la parola sbagliata.

Versione breve: SSH, abbreviazione di Secure Shell, è il metodo standard per aprire una sessione di riga di comando remota e sicura sul tuo server. Per collegarti la prima volta ti servono l'indirizzo IP del server, un nome utente e una password oppure una chiave SSH fornita dal provider. La maggior parte dei problemi al primo accesso dipende da un nome utente errato, una chiave mancante, una porta bloccata o un server che non ha ancora completato l'avvio.

Cosa ti serve prima di collegarti?

Pensa a SSH come alla porta d'ingresso di un edificio. Ti servono tre elementi: l'indirizzo dell'edificio, il nome presente nella lista all'ingresso e una prova che confermi il tuo permesso ad accedere.

L'indirizzo corrisponde solitamente all'IP pubblico del tuo server, ad esempio 203.0.113.10. Il provider lo mostra chiaramente nel pannello di controllo del server.

Il nome utente è spesso root su un server nuovo, ma con alcune eccezioni. Alcune immagini di sistema utilizzano account come ubuntu, debian o admin. Se l'accesso come root non funziona, verifica l'email di benvenuto del provider o la scheda dei dettagli del server.

La prova di accesso è rappresentata da una password o da una chiave SSH. La password è un concetto familiare; una chiave SSH consiste invece in una coppia di file abbinati: una chiave pubblica installata sul server e una chiave privata salvata sul tuo computer. La chiave privata equivale alle chiavi di casa: non va mai condivisa, né incollata su siti web, chat, ticket di supporto o appunti.

Come ci si collega via SSH?

Su macOS e Linux è sufficiente aprire il Terminale. Su Windows, puoi utilizzare Windows Terminal o PowerShell. Le versioni recenti di Windows includono il comando ssh nativo, rendendo superfluo l'uso di client esterni come PuTTY.

La sintassi di base è la seguente:

bashssh nomeutente@indirizzo_ip_server

Per un server appena creato, il comando sarà simile a questo:

bashssh root@203.0.113.10

Al primo collegamento, SSH ti chiederà di confermare l'impronta digitale (fingerprint) del server. È la procedura di sicurezza con cui il computer rileva un nuovo host sconosciuto. Se l'indirizzo IP è corretto e il server è stato appena creato, è del tutto normale digitare yes per proseguire.

A questo punto si verificano due scenari: se il server richiede l'autenticazione tramite password, ti verrà chiesto di digitarla (è normale che il cursore rimanga fermo durante la digitazione per ragioni di sicurezza). Se il server è configurato per l'uso di chiavi SSH, il computer utilizzerà automaticamente la chiave privata presente nel sistema oppure potrai indicare manualmente il file della chiave corretto.

Un'autenticazione riuscita si conclude con l'apparizione di un prompt del tipo root@server:~# o user@server:~$. Questo segnale conferma che qualsiasi comando digitato verrà eseguito direttamente sul server remoto.

Se sei al tuo primo giorno di gestione di un server, è utile abbinare l'accesso SSH ad alcune configurazioni di sicurezza fondamentali. Abbiamo illustrato questo percorso iniziale nella guida per principianti sui primi passi dopo l'acquisto di un server, ricordando che SSH rappresenta la porta d'accesso per eseguire la maggior parte di queste operazioni.

Cosa indicano gli errori SSH più comuni?

Sebbene gli errori SSH possano sembrare complessi, nella maggior parte dei casi sono riconducibili a sviste o problemi di facile risoluzione.

Permission denied (publickey) indica che il server ha risposto alla richiesta ma ha rifiutato la chiave. Di solito questo accade se il nome utente è errato, se si sta utilizzando una chiave privata sbagliata oppure se la relativa chiave pubblica non è stata memorizzata sul server.

Permission denied, please try again segnala generalmente che la password inserita è errata oppure che l'accesso tramite password è stato disabilitato per quell'account.

Connection timed out evidenzia l'impossibilità da parte del computer di raggiungere il servizio SSH. Può dipendere da un server ancora in fase di avvio, un indirizzo IP errato, un blocco sulla rete locale o un firewall che filtra la connessione. Una volta effettuato l'accesso, è essenziale impostare correttamente il firewall: a questo scopo, puoi consultare la nostra guida per configurare un firewall sul server.

Connection refused significa che il server è stato raggiunto, ma nessuna applicazione è in ascolto sulla porta SSH specificata. Il servizio SSH potrebbe essere arrestato, configurato in modo non standard o in ascolto su una porta differente.

Host key verification failed indica che il computer rileva una macchina diversa associata a quell'indirizzo IP. Questo accade di frequente quando si ricrea un server mantenendo lo stesso IP. Tuttavia, se non hai effettuato modifiche recenti, non ignorare questo avviso, poiché potrebbe indicare un'anomalia di sicurezza.

SSH è sicuro per il primo accesso?

Sì, il protocollo SSH è progettato per garantire un accesso remoto protetto. La connessione viene completamente cifrata, impedendo a terzi sulla rete di intercettare o leggere i comandi inviati.

Il fattore di rischio non risiede nel protocollo SSH in sé, ma in politiche di accesso poco severe: password deboli, chiavi SSH riutilizzate su più servizi, file chiave salvati in posizioni non sicure o l'account amministrativo root esposto indefinitamente a internet.

Dopo il primo collegamento, le operazioni prioritarie prevedono: l'aggiornamento del sistema, la creazione di un utente standard, la custodia sicura delle chiavi SSH e l'impostazione dei backup prima di distribuire applicazioni importanti. I backup possono sembrare una misura secondaria finché non si rende necessario recuperare il sistema da un errore di digitazione o da un aggiornamento problematico; puoi approfondire questo tema nella nostra guida su come eseguire il backup del server e ripristinarlo.

FAQ

Qual è la porta predefinita di SSH? SSH utilizza di norma la porta 22. Alcuni server vengono configurati su porte differenti: in tal caso, il dato viene fornito dal provider o nelle note di configurazione.

È possibile collegarsi senza inserire ogni volta la password? Sì, l'autenticazione tramite chiavi SSH serve esattamente a questo. La chiave privata autentica l'utente in modo sicuro ed automatico senza richiedere l'inserimento manuale della password.

Perché i caratteri della password non compaiono a schermo mentre digito? Nei terminali è una misura di sicurezza predefinita per nascondere la lunghezza e la composizione della password. Non compaiono né asterischi né pallini: è sufficiente digitare la password e premere Invio.

È opportuno utilizzare l'utente root? Per il primo accesso è prassi comune se il provider fornisce le credenziali di root. Per la gestione a lungo termine, tuttavia, è raccomandato creare un utente dedicato con permessi limitati e ridurre l'uso dell'accesso root diretto.

La scorciatoia

Server Manager semplifica questa fase iniziale evitando che il primo accesso si trasformi in una lista disordinata di appunti, indirizzi IP e credenziali smarrite. Anziché perdere traccia delle modalità di accesso di ciascun server, consente di mantenere una configurazione chiara e strutturata fin dal primo collegamento.

Inoltre, previene i tipici problemi operativi dei primi utilizzi: porte SSH inaccessibili, regole firewall errate, backup dimenticati prima di modifiche cruciali o incertezze sulla configurazione a distanza di mesi.

L'obiettivo non è evitare l'uso del terminale, ma rendere ordinata e tracciabile l'infrastruttura di contorno, evitando che una banale difficoltà di accesso richieda ore di diagnosi.

Quali sono i vantaggi una volta stabilita la connessione SSH?

Quando la connessione SSH è operativa, il server diventa un sistema completamente accessibile, ispezionabile e gestibile. È possibile analizzare i log di errore, aggiornare il software, monitorare i servizi attivi ed effettuare modifiche in totale sicurezza.

Stabilire il primo accesso con successo è un passaggio fondamentale: garantisce una via d'accesso sicura al server e pone le basi per una gestione ordinata e scalabile dell'infrastruttura nel tempo.