SSH: cos’è, come funziona e come usare Secure Shell

SSH, acronimo di Secure Shell, è un protocollo che permette di accedere a un computer o a un server remoto attraverso una connessione crittografata. In pratica, puoi aprire una shell sul server, eseguire comandi, amministrare servizi, trasferire file o creare tunnel di rete senza inviare credenziali e traffico in chiaro.

Se gestisci un server Linux, un VPS, un hosting con accesso da terminale o alcune operazioni avanzate su WordPress, prima o poi incontrerai un comando simile:

ssh [email protected]

Il comando è semplice. La parte importante è capire che cosa succede prima che quella shell venga aperta: il client deve identificare il server, negoziare un canale protetto e infine dimostrare che tu sei autorizzato ad accedere.

Sono tre problemi diversi. Confonderli porta facilmente a fraintendimenti sulle chiavi SSH e sulla sicurezza del protocollo.

Cos’è SSH e a cosa serve

SSH è un protocollo di rete progettato per effettuare login remoto e altre operazioni di rete attraverso un canale protetto, anche quando la rete sottostante non è considerata affidabile.

L’architettura definita nelle specifiche del protocollo SSH separa infatti diversi compiti: creazione del trasporto sicuro, autenticazione dell’utente e apertura dei canali attraverso i quali viaggiano shell, comandi e altre comunicazioni.

Questo significa che SSH non è semplicemente “un terminale remoto”. Il terminale è uno degli utilizzi più visibili del protocollo, ma sotto quella shell esiste un’infrastruttura che gestisce identità, cifratura, integrità e multiplexing dei canali.

Cosa puoi fare con una connessione SSH

L’utilizzo più comune è amministrare un server remoto dalla riga di comando. Dopo l’accesso puoi, nei limiti dei permessi assegnati al tuo account:

• controllare processi e servizi;
• modificare configurazioni e file;
• consultare log;
• eseguire script;
• avviare comandi senza aprire una shell interattiva;
• trasferire file con strumenti che utilizzano l’infrastruttura SSH;
• inoltrare connessioni TCP attraverso un tunnel cifrato.

Se gestisci un sito web, l’accesso remoto diventa particolarmente utile quando devi intervenire a un livello più basso rispetto al CMS o al pannello del provider. Per capire dove si colloca il server rispetto al sito puoi partire anche dalla guida su cos’è un hosting.

SSH non dà però automaticamente accesso completo alla macchina. Quello che puoi fare dipende dall’utente con cui ti autentichi e dai permessi configurati sul server.

SSH e Telnet: perché non sono equivalenti

SSH è nato anche per sostituire strumenti di accesso remoto che non offrivano una protezione adeguata del traffico, come Telnet utilizzato senza ulteriori livelli di sicurezza.

La differenza pratica è fondamentale: con Secure Shell viene creato un canale crittografato prima di trasmettere le informazioni della sessione. Questo protegge credenziali, comandi e dati da una semplice intercettazione del traffico di rete.

Questo non significa che “usare SSH” renda automaticamente sicuro un server. Password deboli, chiavi private esposte, account troppo privilegiati o una host key accettata senza verificarla rimangono problemi reali. Il protocollo offre gli strumenti per creare una connessione protetta; la configurazione deve utilizzarli correttamente.

Come funziona una connessione SSH

Per capire SSH conviene abbandonare l’idea generica secondo cui “usa una coppia di chiavi per cifrare tutto”.

Una connessione reale coinvolge almeno tre concetti differenti:

1. la host key, che identifica il server;
2. il key exchange, che permette di stabilire il materiale crittografico della sessione;
3. l’autenticazione dell’utente, che verifica se il tuo account può entrare.

Le chiavi utilizzate in questi passaggi possono avere funzioni diverse. La tua chiave privata di autenticazione, per esempio, non viene inviata al server e non è la chiave con cui viene cifrato direttamente ogni pacchetto della sessione.

Client SSH, server SSH e sshd

Una comunicazione prevede normalmente due estremi.

Il client SSH è il programma dal quale avvii la connessione. Il comando ssh fornito da OpenSSH è probabilmente l’esempio più conosciuto.

Sul computer remoto deve invece essere attivo un server SSH. Nel caso di OpenSSH, il servizio è generalmente gestito dal demone sshd, che ascolta le connessioni in ingresso, negozia il protocollo, gestisce l’autenticazione e apre le sessioni richieste.

OpenSSH include, oltre a ssh e sshd, diversi strumenti collegati alle chiavi, all’agent e al trasferimento file. La documentazione del progetto OpenSSH rimane il riferimento principale per l’implementazione.

La host key: come il client verifica il server

Prima ancora di verificare chi sei tu, il client deve capire con quale server sta parlando.

Il server possiede una o più host key. Durante la fase di connessione utilizza la propria chiave privata per dimostrare il possesso dell’identità associata alla relativa chiave pubblica.

È qui che compare, durante il primo collegamento, la fingerprint del server.

Il concetto è simile a questo:

Il server dichiara una chiave pubblica
        ↓
il client calcola/mostra la fingerprint
        ↓
tu verifichi che corrisponda a quella attesa
        ↓
il client può ricordare quella host key

La fingerprint non serve a identificare il tuo account. Serve a controllare l’identità del server remoto.

La specifica del transport layer prevede esplicitamente l’autenticazione dell’host all’interno del processo di creazione della connessione sicura.

Key exchange: come nasce il canale crittografato

Client e server devono poi ottenere chiavi utilizzabili per proteggere la sessione senza inviare semplicemente una “password di cifratura” attraverso la rete.

Questo è il compito del key exchange.

Le implementazioni moderne possono supportare differenti algoritmi e il protocollo è progettato per consentire la negoziazione fra quelli disponibili. Le raccomandazioni sugli algoritmi cambiano nel tempo proprio perché la crittografia non è un settore statico.

Il risultato concettuale che interessa a chi utilizza SSH è questo:

client e server arrivano a un segreto condiviso dal quale vengono derivate le chiavi utilizzate per proteggere la sessione.

Le parti private necessarie alle primitive crittografiche non vengono semplicemente spedite attraverso Internet. Una volta completata la negoziazione, il traffico applicativo può viaggiare dentro il canale protetto.

Questo spiega anche perché è sbagliato pensare che tutta la sessione venga cifrata direttamente con la tua chiave privata personale.

Autenticazione dell’utente: password e chiavi SSH

Solo dopo avere creato il trasporto protetto si passa all’altra domanda: il server deve permettere a questo utente di entrare?

SSH supporta differenti meccanismi di autenticazione. Fra quelli più conosciuti trovi password e public key authentication. Le specifiche del protocollo trattano questa fase separatamente dal transport layer.

Con una password, il server verifica le credenziali dell’account secondo la propria configurazione.

Con l’autenticazione a chiave pubblica, invece, il server conosce la tua chiave pubblica, mentre la chiave privata rimane sul dispositivo da cui ti colleghi.

Il client deve dimostrare di possedere la parte privata senza consegnarla al server. OpenSSH descrive il processo proprio in questi termini: il server conosce la public key autorizzata e il client prova di avere accesso alla corrispondente private key.

Questa distinzione è essenziale:

host key → identifica il server
chiave dell’utente → può autenticare l’utente
chiavi di sessione → proteggono il traffico della connessione

Sono collegate all’interno dello stesso protocollo, ma non sono intercambiabili.

Cosa succede dopo l’autenticazione

Quando il server accetta l’autenticazione, il protocollo può aprire uno o più canali all’interno della connessione cifrata.

Il connection protocol contempla, fra le altre cose, shell interattive, esecuzione remota di comandi e forwarding di connessioni TCP. Più canali possono essere multiplexati nello stesso tunnel protetto.

Per questo un’unica connessione SSH può fare molto più che mostrare un prompt di terminale.

Come collegarsi a un server via SSH

Per una normale prima connessione ti servono poche informazioni:

• indirizzo IP o hostname del server;
• nome dell’utente;
• porta del servizio, se diversa da quella standard;
• metodo di autenticazione accettato;
• accesso di rete al server.

Cosa serve prima di iniziare

Se il provider ti ha fornito qualcosa come:

Host: server.example.com
User: deploy
Port: 22

hai già quasi tutto ciò che serve per tentare la connessione.

Al posto dell’hostname può essere fornito direttamente un indirizzo IP. Se vuoi approfondire la differenza, trovi una guida specifica su cos’è un indirizzo IP.

Devi inoltre verificare che sul computer locale sia presente un client compatibile. Su Linux e macOS OpenSSH è comunemente disponibile da terminale; anche Windows dispone oggi di strumenti OpenSSH, quindi PuTTY non è più un requisito per utilizzare SSH su un PC Windows. Microsoft documenta OpenSSH come funzionalità disponibile sui sistemi Windows supportati.

Il comando ssh user@host

La sintassi essenziale è:

ssh utente@host

Per esempio:

ssh [email protected]

oppure:

ssh [email protected]

mario è l’utente remoto. La parte successiva alla @ identifica invece il server.

Non inserire alla cieca root solo perché in molti tutorial viene utilizzato negli esempi. Devi usare l’account realmente abilitato dal server o dal provider.

Come specificare una porta SSH diversa

La porta registrata per il servizio SSH è la 22, come indicato nel registro ufficiale IANA dei service name e delle porte. Un amministratore può comunque configurare sshd su un’altra porta.

In quel caso utilizza -p:

ssh -p 2222 [email protected]

Cambiare porta può ridurre parte del rumore generato da scansioni automatiche molto banali, ma non sostituisce autenticazione, aggiornamenti e corretta configurazione del server.

Cosa significa la fingerprint mostrata al primo collegamento

Durante il primo accesso potresti ricevere un avviso che indica che l’autenticità dell’host non è ancora stata stabilita e mostra una fingerprint.

Non è un errore da eliminare premendo automaticamente “yes”.

Significa semplicemente che il client non dispone ancora di una host key fidata per quel nome o indirizzo. Prima di accettarla dovresti confrontare la fingerprint con quella comunicata dal provider o dall’amministratore attraverso un canale attendibile.

Una volta accettata, OpenSSH può memorizzare l’associazione nel file known_hosts.

Da quel momento il client ha un riferimento con cui confrontare la chiave presentata nelle connessioni successive. Questo è uno dei meccanismi che permettono di accorgersi di un cambiamento inatteso dell’identità del server.

Come chiudere la sessione SSH

Per terminare una normale shell remota puoi utilizzare:

exit

oppure chiudere la shell remota con la combinazione prevista dal terminale.

Quando la sessione termina vengono chiusi anche i canali associati alla connessione, inclusi eventuali forwarding legati a quella specifica sessione.

SSH su Windows, macOS e Linux

Il protocollo non cambia in base al sistema operativo. Quello che può cambiare è il client utilizzato e il modo in cui viene installato.

OpenSSH da terminale

Su sistemi che dispongono del client OpenSSH puoi verificare la presenza del comando con:

ssh -V

e collegarti con la stessa sintassi:

ssh utente@host

Questo approccio rende anche più semplice riutilizzare gli stessi concetti fra Linux, macOS e Windows.

Su Windows, la documentazione Microsoft dedicata a OpenSSH descrive installazione, configurazione e utilizzo degli strumenti client e server.

Quando può essere utile PuTTY su Windows

PuTTY rimane un client SSH valido, soprattutto se preferisci un’interfaccia grafica per configurare sessioni, chiavi, proxy e tunneling oppure se devi lavorare in ambienti che lo utilizzano già.

Non è però obbligatorio solo perché stai utilizzando Windows.

Se scegli PuTTY, scaricalo dal sito ufficiale del progetto PuTTY e non da portali o domini che utilizzano il nome del programma senza appartenere al progetto.

Chiavi SSH: cosa sono e come funzionano

L’autenticazione a chiave pubblica utilizza una coppia composta da:

• chiave pubblica, che può essere installata sul server;
• chiave privata, che deve restare sotto il controllo dell’utente.

La sicurezza del modello non deriva dal “nascondere l’algoritmo”, ma dalle proprietà matematiche della crittografia a chiave pubblica e dalla protezione della private key.

Chiave pubblica e chiave privata

Se il server autorizza la tua public key, durante il login il client può dimostrare di possedere la corrispondente private key.

La chiave privata non deve essere copiata sul server come metodo normale per abilitare l’accesso e non va inviata ad altri utenti.

In OpenSSH le chiavi pubbliche autorizzate per un account vengono normalmente registrate nel file:

~/.ssh/authorized_keys

La documentazione del client OpenSSH descrive questo modello e specifica che la private key rimane conosciuta dall’utente mentre il server dispone della public key autorizzata.

Dove vengono salvate le chiavi

Nelle configurazioni OpenSSH classiche, i file dell’utente si trovano nella directory:

~/.ssh/

Un esempio comune con Ed25519 è:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

Il primo è il file privato. Il secondo, riconoscibile dall’estensione .pub, contiene la parte pubblica.

Il nome può comunque essere diverso: non devi quindi assumere che ogni chiave si chiami necessariamente id_ed25519.

Come creare una coppia di chiavi con ssh-keygen

OpenSSH include ssh-keygen, lo strumento dedicato alla generazione e alla gestione delle chiavi di autenticazione. La pagina manuale ufficiale di ssh-keygen documenta i tipi di chiave e le relative opzioni.

Per creare esplicitamente una chiave Ed25519 puoi utilizzare:

ssh-keygen -t ed25519

Lo strumento ti chiederà dove salvare la chiave e se vuoi impostare una passphrase.

Dopo la generazione dovrai installare la parte pubblica sull’account remoto attraverso il metodo previsto dal server: pannello del provider, strumenti dell’amministratore o file authorized_keys.

Non pubblicare e non copiare sul server la parte privata per “far funzionare” l’autenticazione.

Passphrase e protezione della chiave privata

Una passphrase protegge il file contenente la private key.

È una distinzione importante: la passphrase non è necessariamente la password dell’account remoto. Serve a rendere più difficile utilizzare la chiave privata se qualcuno riesce a copiarne il file.

In ambienti in cui devi utilizzare frequentemente una chiave protetta puoi impiegare un SSH agent, che mantiene disponibili le identità necessarie per l’autenticazione senza obbligarti a gestire manualmente il file a ogni collegamento.

Resta comunque fondamentale proteggere il dispositivo locale e i permessi del file: OpenSSH rifiuta o ignora in vari contesti file di identità accessibili con permessi inappropriati.

I comandi e le opzioni SSH più utili

Una volta compresa la connessione di base, poche opzioni coprono una parte significativa delle necessità quotidiane.

Collegarsi con una chiave specifica

Se non vuoi utilizzare l’identità selezionata automaticamente dal client:

ssh -i ~/.ssh/mia_chiave utente@host

È utile quando gestisci più server o account con identità differenti.

La private key indicata con -i deve naturalmente essere quella corretta per una public key autorizzata dal server.

Eseguire un comando sul server remoto

Non sei obbligato ad aprire una shell interattiva.

Puoi eseguire direttamente un comando:

ssh utente@host 'uptime'

Il comando viene eseguito sul sistema remoto e il relativo output viene restituito nel terminale locale.

Questa possibilità rende il protocollo utile anche in script e procedure di amministrazione, purché vengano gestiti correttamente autenticazione, errori e privilegi.

Usare un file di configurazione SSH

Quando inizi ad avere numerosi server, ricordare ogni volta hostname, utente, porta e file della chiave diventa scomodo.

OpenSSH supporta un file di configurazione personale, normalmente:

~/.ssh/config

La documentazione di ssh_config specifica che il client può leggere impostazioni per host differenti da questo file.

Un esempio:

Host produzione
    HostName server.example.com
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Dopo avere salvato la configurazione, la connessione diventa:

ssh produzione

Non è solo una scorciatoia estetica: riduce il rischio di utilizzare utente, porta o identità sbagliati quando gestisci più macchine.

SSH, SFTP e SCP: cosa cambia

SSH, SFTP e SCP vengono spesso citati insieme perché servono in scenari vicini, ma non hanno la stessa funzione.

SSH viene utilizzato principalmente per accesso remoto, esecuzione di comandi e tunneling.

SFTP è pensato per la gestione e il trasferimento dei file attraverso l’infrastruttura SSH. Se il tuo obiettivo è caricare, scaricare, rinominare e gestire file remoti, trovi la procedura nella guida dedicata a come utilizzare SFTP.

SCP è invece lo strumento che incontrerai spesso quando vuoi copiare file da riga di comando fra sistemi locali e remoti.

Quando usare SSH

Utilizza una normale sessione Secure Shell quando hai bisogno di:

• una shell sul server;
• eseguire comandi;
• modificare configurazioni;
• analizzare log;
• controllare processi;
• creare port forwarding.

Quando usare SFTP o SCP

SFTP è più adatto quando il task è prevalentemente gestione dei file e vuoi utilizzare un client dedicato o operazioni tipiche di un file manager remoto.

SCP è pratico per copie mirate da terminale.

Il punto da ricordare è che aprire una shell, trasferire file e inoltrare porte sono task differenti, anche quando condividono la stessa infrastruttura sicura.

Tunneling SSH e port forwarding

Secure Shell può trasportare connessioni TCP all’interno del proprio canale cifrato. È il cosiddetto port forwarding.

La specifica del connection protocol prevede le connessioni TCP inoltrate come uno dei tipi di canale disponibili.

È una funzione potente perché permette, per esempio, di raggiungere un servizio disponibile soltanto dal server remoto senza esporlo direttamente sulla rete pubblica.

Local forwarding

Con -L apri una porta sul tuo computer locale e inoltri le connessioni verso una destinazione raggiungibile dal server remoto.

La struttura è:

ssh -L porta_locale:destinazione:porta_destinazione utente@server

Per esempio:

ssh -L 8080:127.0.0.1:8000 [email protected]

Una connessione alla porta locale 8080 viene trasportata attraverso SSH e, dal lato remoto, indirizzata verso 127.0.0.1:8000.

È utile per raggiungere dashboard, database o servizi di sviluppo che non vuoi rendere pubblicamente accessibili.

Remote e dynamic forwarding: quando servono

Con -R la direzione viene invertita: chiedi al lato remoto di esporre una porta e inoltrare il traffico attraverso la connessione verso una destinazione raggiungibile dal client.

Con -D, invece, il client crea un forwarding dinamico utilizzabile come proxy SOCKS:

ssh -D 1080 [email protected]

Queste funzioni non devono essere attivate senza comprenderne l’esposizione. Binding address, firewall e configurazione di sshd possono determinare chi è realmente in grado di utilizzare una porta inoltrata.

In altre parole, un tunnel cifrato protegge il trasporto, ma una porta esposta al destinatario sbagliato rimane una configurazione pericolosa.

Problemi comuni con SSH e come interpretarli

Quando la connessione fallisce, il testo dell’errore spesso indica in quale fase si è fermato il processo.

Questo rende la diagnosi più rapida se distingui rete, servizio, host verification e autenticazione.

Per ottenere più dettagli dal client OpenSSH puoi aumentare la verbosità:

ssh -v utente@host

Se necessario sono disponibili ulteriori livelli di verbose mode. La documentazione di OpenSSH indica -v proprio come strumento utile per diagnosticare problemi di connessione e autenticazione.

Connection refused

Un errore di tipo:

Connection refused

indica normalmente che la connessione TCP ha raggiunto la destinazione ma non è stato possibile stabilire la sessione sulla porta richiesta.

Le cause da controllare includono:

• porta sbagliata;
• servizio sshd non in ascolto;
• servizio arrestato;
• firewall o apparato di rete che rifiuta esplicitamente la connessione.

Prima di cambiare chiavi o password, verifica quindi host e porta. Il problema avviene prima della normale autenticazione SSH.

Connection timed out

Con:

Connection timed out

il client non ha ricevuto in tempo la risposta necessaria per stabilire la connessione.

Può dipendere da:

• host non raggiungibile;
• routing;
• firewall che scarta il traffico;
• porta filtrata;
• indirizzo errato;
• server offline.

Anche qui cambiare password o rigenerare le chiavi non è il primo passo: devi prima risolvere la connettività.

Permission denied (publickey)

Questo errore porta la diagnosi a un livello successivo.

La connessione al server esiste, ma il metodo di autenticazione a chiave pubblica non ha prodotto un’identità accettata per quell’utente.

Controlla:

• username;
• private key realmente utilizzata dal client;
• public key installata sull’account remoto;
• permessi dei file;
• configurazione del server;
• eventuali restrizioni associate alla chiave.

Puoi verificare quale identità viene proposta aumentando la verbosità del client.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

Questo è un messaggio da trattare con maggiore attenzione.

Significa che la host key presentata dal server non corrisponde a quella precedentemente memorizzata dal client.

Potrebbe trattarsi di un cambiamento legittimo, per esempio dopo la reinstallazione o sostituzione del server. Ma lo stesso sintomo può indicare che stai raggiungendo un host differente o che la connessione viene intercettata.

Non risolvere il problema eliminando automaticamente la voce da known_hosts.

Prima:

1. verifica che il server sia stato realmente sostituito o riconfigurato;
2. recupera la nuova fingerprint da una fonte attendibile;
3. confrontala;
4. solo dopo rimuovi la vecchia associazione.

Quando il cambio è stato verificato, OpenSSH permette di eliminare le vecchie entry attraverso ssh-keygen. Per esempio:

ssh-keygen -R server.example.com

Lo strumento supporta operazioni di gestione di known_hosts; il punto importante è eseguirle dopo avere verificato perché la chiave è cambiata, non prima.

Come usare SSH in modo più sicuro

Non esiste una singola opzione capace di rendere sicura qualsiasi installazione. La protezione nasce dalla combinazione fra verifica dell’host, autenticazione, gestione delle chiavi, privilegi e manutenzione del software.

Verificare la fingerprint del server

Durante il primo collegamento, confronta la fingerprint con un valore ricevuto attraverso un canale attendibile.

Accettare automaticamente ogni host key trasforma un meccanismo di verifica in una semplice finestra da chiudere.

La stessa cautela vale quando la chiave cambia improvvisamente.

Proteggere la chiave privata

La private key è un elemento di autenticazione sensibile.

Non:

• inviarla via email o chat;
• copiarla nel document root del sito;
• pubblicarla in un repository;
• condividerla fra più persone come se fosse una password comune.

Proteggila con permessi appropriati e, quando compatibile con il workflow, con una passphrase.

Se un collaboratore deve accedere al server, è generalmente preferibile autorizzare una chiave distinta e identificabile per quel collaboratore, così da poter revocare quell’accesso senza sostituire le credenziali degli altri utenti.

Password, chiavi e policy del server

Una chiave pubblica non rende automaticamente inutile qualsiasi password e una password non è necessariamente l’unico fattore che un server può richiedere.

SSH supporta più metodi di autenticazione e il server può determinare quali utilizzare e in quali combinazioni.

La scelta corretta dipende quindi dalla policy dell’infrastruttura.

Per un server gestito professionalmente, il punto non è applicare indiscriminatamente una ricetta trovata online, ma controllare:

• quali account possono collegarsi;
• con quali metodi;
• da quali reti;
• con quali privilegi;
• come vengono create e revocate le credenziali.

Aggiornare client e server SSH

Gli algoritmi e le implementazioni crittografiche cambiano nel tempo. Alcuni metodi che erano comuni anni fa possono essere successivamente sconsigliati o disabilitati.

Per questo conviene mantenere client e server supportati e aggiornati, evitando di riabilitare vecchi algoritmi soltanto per far funzionare un sistema legacy senza averne valutato le conseguenze.

Se una connessione verso un vecchio apparato fallisce per incompatibilità crittografica, la soluzione migliore non è automaticamente “abilitare tutto”: bisogna capire quale componente è obsoleto e se può essere aggiornato o isolato.

Se il server ospita un sito WordPress e devi intervenire da terminale senza avere un workflow tecnico sicuro, può avere più senso affidare la verifica a un servizio di assistenza WordPress piuttosto che modificare configurazioni di sistema alla cieca.

Conclusione

SSH diventa molto più semplice quando separi correttamente i problemi che risolve.

Prima il client deve verificare il server attraverso la sua host key. Poi client e server negoziano il materiale necessario per creare il canale crittografato. Solo a quel punto il server verifica l’identità dell’utente, per esempio con una password o una chiave pubblica autorizzata.

Capita spesso di chiamare tutte queste cose genericamente “chiavi SSH”, ma comprenderne i ruoli differenti cambia anche il modo in cui diagnostichi gli errori: un timeout riguarda la rete, Permission denied riguarda l’autenticazione, mentre una host key modificata richiede di controllare l’identità del server.

Per iniziare, ti basta quindi imparare bene pochi elementi: ssh user@host, la porta corretta, la verifica della fingerprint e il metodo di autenticazione previsto dal server. File di configurazione, tunneling e automazioni vengono dopo. Con queste basi puoi usare Secure Shell con molta più consapevolezza, senza limitarti a copiare comandi che non sai realmente cosa stiano facendo.