Che cos'è SSH e come funziona

Che cos'è SSH?

SSH (Secure Shell) è un protocollo che consente di accedere a un computer remoto e di eseguire comandi tramite una connessione crittografata. Ciò che si digita viene inviato alla macchina remota, mentre il relativo output viene restituito. Chiunque monitori il traffico di rete tra i due sistemi non può leggere nessuno dei due flussi. Un server Linux noleggiato non ha uno schermo né una tastiera collegati. SSH è quindi il metodo con cui si utilizza la macchina.

Il nome indica due elementi. SSH è il protocollo, descritto negli RFC 4251–RFC 4254. OpenSSH è il programma che lo implementa ed è quello utilizzato praticamente da tutti i server Linux e da quasi tutti i laptop. Quando si dice "accedere al server tramite SSH", si intende che il programma client ssh sul proprio computer comunica con il programma server sshd dall'altra parte della connessione.

Il problema che SSH è stato progettato per risolvere

L’accesso remoto è molto più vecchio di SSH. Telnet apriva una connessione TCP non cifrata sulla porta 23 e inviava ogni byte esattamente come veniva digitato. Nulla era cifrato, inclusa la password. Chiunque potesse osservare il traffico poteva leggerlo: una persona sulla stessa rete dell’ufficio oppure l’operatore di un router lungo il percorso. La famiglia rlogin aveva la stessa vulnerabilità e si fidava del nome della macchina client. In pratica, si fidava di qualunque informazione la rete fornisse per quel nome.

Tatu Ylönen ha scritto il primo SSH nel 1995 presso la Helsinki University of Technology, dopo un attacco di sniffing delle password sulla rete dell’università. Il progetto conserva la parte utile di Telnet, cioè un flusso di byte tra il terminale e una shell remota, e aggiunge le due funzioni che Telnet non può offrire: la cifratura del flusso e la verifica che il server remoto sia quello a cui si intendeva connettersi.

La seconda funzione è facile da trascurare, ma rappresenta metà del modello di sicurezza di SSH. La cifratura da sola non sarebbe sufficiente. Una macchina interposta potrebbe accettare la connessione, cifrarla correttamente, leggere tutto ciò che si invia e inoltrarlo al server reale. SSH impedisce questo scenario assegnando a ogni server un’identità permanente, chiamata chiave host, e verificandola a ogni connessione.

Come funziona il modello client-server

Esistono due programmi. Sul server, sshd è sempre in esecuzione e resta in attesa delle connessioni. Sul tuo computer, ssh le avvia. Sono programmi distinti, con file di configurazione separati. Confonderli è il motivo più comune per cui una modifica non produce alcun effetto.

• Il server legge /etc/ssh/sshd_config. Qui si disabilita l'autenticazione tramite password e si imposta la porta di ascolto.
• Il client legge /etc/ssh/ssh_config per le impostazioni predefinite di sistema, quindi ~/.ssh/config per le impostazioni specifiche dei singoli host.

Su Debian e Ubuntu l'unità del servizio si chiama ssh. Su RHEL, Rocky e Fedora si chiama sshd. Le versioni recenti di Ubuntu lo installano con attivazione tramite socket. Di conseguenza, systemctl status ssh può indicare inactive (dead) anche quando la macchina è perfettamente raggiungibile, perché ssh.socket è l'unità che resta in ascolto e avvia il servizio su richiesta.

Il client non deve essere necessariamente OpenSSH. PuTTY su Windows, Termius su un telefono e le funzioni di supporto remoto integrate negli editor usano tutti lo stesso protocollo per connettersi allo stesso sshd. Windows 10 e 11 includono inoltre il client OpenSSH, quindi ssh you@server funziona in PowerShell senza installare nulla.

Perché SSH usa la porta 22?

Una porta è un numero che indica al kernel a quale programma in ascolto appartiene una connessione in ingresso. Le porte su Linux funzionano nello stesso modo per ogni servizio. SSH usa la porta 22 perché IANA l'ha assegnata nel 1995. Ylönen chiese un numero libero vicino ai protocolli che SSH era stato progettato per sostituire: la porta 21 era usata da FTP, la 23 da telnet e la 22 era libera.

Poiché 22 è la porta predefinita, tutti la danno per scontata. Il remote Git, lo script di backup e il pannello di controllo del provider provano prima la porta 22. Lo fa anche ogni scanner automatico su Internet. Un nuovo server con l'accesso tramite password abilitato inizia a raccogliere righe come questa in /var/log/auth.log entro pochi minuti dall'avvio:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Questo traffico è costante e non è rivolto personalmente a te. Spostare sshd sulla porta 2222 elimina la maggior parte di queste righe, perché gli scanner analizzano l'intera Internet sulla porta 22 invece di studiare il tuo server. Questo non rende la macchina più difficile da violare per chi la esamina intenzionalmente. Considera la modifica della porta solo una riduzione del rumore.

Puoi osservare la risposta del server prima ancora di effettuare l'accesso:

nc 203.0.113.10 22

Su Ubuntu 24.04 questo comando stampa qualcosa di simile a SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. Il banner viene inviato in testo non cifrato, prima che sia attiva qualsiasi cifratura, perché entrambi i lati devono concordare la versione del protocollo. Premi Ctrl+C per chiudere la connessione.

Cosa accade sulla rete quando ti connetti

La sequenza seguente descrive ciò che esegue un ssh you@server prima che venga visualizzato un prompt.

1. Il client risolve il nome host in un indirizzo IP, quindi apre una connessione TCP alla porta 22.
2. Entrambi i lati inviano il proprio banner di versione in chiaro.
3. Entrambi i lati inviano gli elenchi degli algoritmi supportati: scambio di chiavi, cifratura, autenticazione dei messaggi e compressione. Anche questi dati sono ancora in chiaro. Viene scelta l'opzione più robusta supportata da entrambi.
4. Viene eseguito lo scambio di chiavi. Le versioni attuali di OpenSSH preferiscono curve25519-sha256. Al termine, entrambi gli endpoint dispongono dello stesso segreto condiviso, senza che tale segreto attraversi mai la rete. Di conseguenza, chi ha registrato l'intera comunicazione non può ricavarlo in seguito.
5. Il server firma il risultato dello scambio con la propria chiave privata host. Il client verifica la firma usando la chiave pubblica host registrata localmente. Questo passaggio impedisce a una macchina interposta di impersonare il server.
6. Inizia la cifratura. chacha20-poly1305@openssh.com è il cifrario predefinito nelle versioni attuali di OpenSSH.
7. Solo a questo punto il client autentica l'utente con una password o una chiave. Il nome utente e la password viaggiano all'interno del canale cifrato.
8. Il client apre un canale e richiede una shell.

L'ordine di questa sequenza costituisce l'intera differenza rispetto a telnet. L'autenticazione avviene dopo la cifratura del canale e dopo che il server ha dimostrato la propria identità. Non esiste quindi un momento in cui la password attraversa la rete in chiaro.

Chi monitora la rete può comunque ricavare alcune informazioni. Può vedere il tuo indirizzo IP, l'indirizzo IP del server, la porta 22, entrambi i banner di versione in chiaro, nonché la temporizzazione e la dimensione approssimativa di ogni pacchetto. Non può vedere il nome utente, la password, i comandi o il relativo output. La risoluzione del nome host al passaggio 1 non fa parte di SSH e in genere non è privata. Di conseguenza, la query DNS che risolve il nome del server può rivelare quale macchina stai per raggiungere, anche se la sessione resta protetta.

La chiave host e la richiesta dell'impronta alla prima connessione

Quando viene installato openssh-server, genera le coppie di chiavi host per la macchina e le salva in /etc/ssh/, ad esempio ssh_host_ed25519_key e ssh_host_ed25519_key.pub. La parte privata non lascia mai il server. La parte pubblica identifica il server ed è il riferimento con cui viene verificata la firma al passaggio 5.

La prima volta che ti connetti a un nuovo server, il client non ha alcuna chiave con cui confrontare quella ricevuta, quindi chiede:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

L'impronta è un hash SHA256 della chiave pubblica host, codificato in base64, quindi è abbastanza breve da poter essere confrontato visivamente. Digitando yes, la chiave viene scritta in ~/.ssh/known_hosts sulla macchina locale. A ogni connessione successiva allo stesso indirizzo, il client confronta la chiave presentata dal server con quella salvata. Se corrispondono, non viene visualizzato alcun messaggio e si passa direttamente al prompt.

Questo modello è chiamato trust on first use. È importante chiarire il rischio associato. La prima connessione è l'unico momento in cui non sei protetto, perché accetti una chiave che non hai mai verificato. Per eliminare questo rischio, recupera l'impronta tramite un canale diverso e confrontala. La maggior parte dei provider la mostra nell'output di avvio disponibile nella console Web. Puoi anche visualizzarla direttamente sul server:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Questo comando visualizza la stessa stringa SHA256: mostrata dalla richiesta. L'opzione [fingerprint] della richiesta serve proprio a questo: incolla l'impronta attesa e il client continua solo se corrisponde a quella presentata dal server.

Su Debian e Ubuntu, known_hosts è sottoposto a hashing per impostazione predefinita. Il file contiene quindi righe che iniziano con |1| invece di nomi host leggibili. Esegui ssh-keygen -F 203.0.113.10 per trovare la voce relativa a un host.

Perché SSH segnala che la chiave host è cambiata?

Prima o poi incontrerai questo blocco di testo:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Il messaggio termina con Host key verification failed. e il client rifiuta la connessione. Mostra anche Password authentication is disabled to avoid man-in-the-middle attacks., perché digitare la password su una macchina sconosciuta è esattamente il rischio che questo controllo serve a prevenire.

Il messaggio sembra indicare un’emergenza, ma nella maggior parte dei casi non è così. Le cause più comuni sono:

• Hai ricreato o reinstallato il server, quindi sshd ha generato nuove chiavi host al primo avvio. È di gran lunga la causa più frequente.
• Hai eliminato un VPS e ne hai creato un altro, e il provider ha assegnato alla nuova macchina il vecchio indirizzo IP.
• Ti stai connettendo tramite un forward o un load balancer che ora inoltra le connessioni a un backend diverso.
• Qualcuno sta realmente intercettando la connessione.

Stabilisci quale sia la causa prima di eliminare qualsiasi elemento. Se hai reinstallato la macchina dieci minuti fa, la causa è evidente. Se dal tuo lato non è cambiato nulla, fermati e verifica, perché questo avviso indica che il controllo sta funzionando correttamente. Quando hai confermato la causa, elimina la voce obsoleta e riconnettiti:

ssh-keygen -R 203.0.113.10

Alla connessione successiva viene mostrata di nuovo la richiesta dell’impronta digitale. Avrai così una nuova occasione per confrontarla con quella riportata nella console del provider.

Accesso con password e accesso con chiave

L’autenticazione tramite password invia la password all’interno del canale già crittografato e sshd la verifica nel database degli account, normalmente tramite PAM (moduli di autenticazione collegabili). Non richiede preparazione. Per questo un provider può consegnare un nuovo server con la sola password di root.

Il problema non è la crittografia. Il problema è che una password è un segreto breve, viene inviata al server a ogni accesso e la porta 22 è sottoposta continuamente a tentativi da parte di sistemi automatici che non si fermano mai.

L’autenticazione a chiave pubblica funziona in modo diverso. Crei una coppia di chiavi sul tuo computer. La parte pubblica viene inserita in ~/.ssh/authorized_keys all’interno del tuo account sul server. La parte privata resta sul tuo laptop e non viene mai trasmessa. Per accedere, il client firma una porzione di dati che include l’identificatore della sessione dello scambio di chiavi. Il server verifica quindi la firma usando la chiave pubblica già in suo possesso. Poiché i dati firmati sono associati a questa specifica sessione, una firma intercettata non è utilizzabile contro altro.

Presta attenzione alla direzione, perché invertirla è comune e causa problemi: la chiave pubblica va sul server, mentre la chiave privata resta con te. Una chiave privata copiata su un server è una chiave privata che non puoi più considerare affidabile.

Anche l’accesso tramite chiave può non funzionare. sshd ignora le chiavi quando i permessi dei file sono troppo permissivi e lo segnala nel log del server:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Il client comunica soltanto Permission denied (publickey). Lo stesso messaggio può dipendere da una dozzina di cause diverse. Per questo conviene imparare a interpretare correttamente l’errore della chiave pubblica prima di perdere l’accesso. Le attività pratiche per creare le chiavi, proteggerle con una passphrase e caricarle in un agent sono descritte in Gestione delle chiavi SSH. Per disabilitare l’accesso tramite password senza bloccarti fuori dal server, consulta messa in sicurezza di SSH su un VPS.

SFTP, scp e port forwarding usano la stessa connessione

Ecco il concetto che permette di comprendere il resto dell'ecosistema SSH. L'autenticazione apre una connessione crittografata, che può trasportare contemporaneamente più canali indipendenti. Una shell è solo uno dei diversi tipi di canale.

• Una shell remota. ssh you@server apre un canale di sessione e richiede una shell interattiva.
• Un singolo comando. ssh you@server uptime apre un canale, esegue un comando, stampa l'output e termina.
• SFTP. Il client chiede a sshd di avviare il sottosistema sftp; il trasferimento dei file avviene nella stessa connessione. SFTP è un protocollo di trasferimento file che usa SSH e non condivide il modello di FTP. Il protocollo che aggiunge la crittografia a FTP si chiama FTPS ed è indipendente.
• scp. Copia i file usando lo stesso accesso. A partire da OpenSSH 9.0, rilasciato nel 2022, scp usa per impostazione predefinita il protocollo SFTP sottostante.
• Port forwarding. ssh -L 8080:localhost:80 you@server trasforma la porta 8080 del laptop in un punto di accesso alla porta 80 del server, trasportato nella connessione crittografata. -R inoltra il traffico nella direzione opposta e -D 1080 trasforma la sessione in un proxy SOCKS.
• Git. Un remote come git@github.com:user/repo.git corrisponde a un accesso SSH il cui lato remoto esegue un gestore di comandi anziché una shell.
• Anche rsync e Ansible sono client SSH. Aprono un canale, eseguono un'operazione e leggono l'output restituito.

Ogni elemento dell'elenco usa la stessa porta, la stessa verifica della host key e le stesse credenziali. Per questo configurare una volta l'autenticazione tramite chiave ripaga subito lo sforzo: tutti questi strumenti la ereditano. È anche il motivo per cui lo stesso file ~/.ssh/config che abbrevia gli accessi è il file che consente di gestire più server Linux da un unico laptop tramite la gestione di più server Linux.

Cosa non fa SSH

• Non rende sicuro il server. SSH protegge il percorso fino alla porta di accesso. La porta è comunque esposta e continueranno a tentare di accedervi. Bloccare i tentativi di accesso ripetuti con fail2ban gestisce il volume dei tentativi, mentre l'autenticazione esclusivamente tramite chiave elimina l'elemento che gli aggressori cercano di indovinare.
• Non protegge dal proprio computer. Chiunque abbia accesso al laptop dispone della chiave privata e dell'agent caricato.
• Non nasconde l'utilizzo di SSH. Il numero di porta e il banner di versione in chiaro lo rendono evidente.
• Non copre ciò che accade prima che la connessione esista. La risoluzione del nome e la decisione sull'indirizzo da considerare attendibile avvengono prima.

Cosa fare a questo punto

Se in questo momento hai un nuovo server aperto nella console di un provider, l'ordine operativo è definito. Accedi, crea un utente normale, installa la tua chiave, quindi chiudi le modalità di accesso più semplici. I primi dieci minuti su un nuovo VPS descrive questa procedura dall'inizio alla fine, mentre che cos'è realmente un VPS spiega la macchina sottostante se questi termini non ti sono ancora familiari. In seguito, leggi gli articoli sulle chiavi e sull'hardening, in questo ordine.

FAQ

Che cosa significa SSH?

SSH significa secure shell. È un protocollo per accedere a un computer remoto ed eseguire comandi su di esso tramite una connessione crittografata, definito nelle RFC 4251 fino a RFC 4254. OpenSSH è l'implementazione utilizzata quasi universalmente: il client ssh sul proprio computer e il server sshd su quello remoto. Ha sostituito telnet, che inviava in chiaro sulla rete ogni dato, comprese le password.

Perché SSH usa la porta 22?

IANA ha assegnato la porta 22 a SSH nel 1995, accanto a FTP sulla 21 e telnet sulla 23, i protocolli che SSH era destinato a sostituire. Nulla impone di usare quel numero: Port in /etc/ssh/sshd_config lo modifica sul server, mentre ssh -p ne seleziona uno diverso sul client. Poiché 22 è la porta predefinita, gli scanner automatici la contattano continuamente. Per questo, in un server appena installato, /var/log/auth.log si riempie di righe Failed password for invalid user. Cambiare porta riduce questo rumore, ma non offre una protezione reale.

Che cosa devo fare quando SSH segnala che la chiave host è cambiata?

Individuate la causa prima di eliminare qualsiasi dato. Il motivo più comune è innocuo: il server è stato ricreato e sshd ha generato nuove chiavi host, oppure a un nuovo computer è stato assegnato il vecchio indirizzo IP. Se sapete che il computer è stato ricreato, eseguite ssh-keygen -R <host> per eliminare la chiave memorizzata, riconnettetevi e confrontate l'impronta digitale visualizzata con quella riportata dalla console del provider. Se dal vostro lato non è cambiato nulla, non connettetevi e non digitate la password. In questo stato OpenSSH rifiuta già l'autenticazione tramite password proprio per questo motivo.

SFTP e scp sono diversi da SSH?

Vengono eseguiti sopra SSH. Dopo l'autenticazione, la connessione SSH può trasportare più canali e una shell è soltanto uno di questi. SFTP è un protocollo di trasferimento file che usa il sottosistema sftp di sshd sulla stessa connessione, mentre scp usa il protocollo SFTP sottostante dalla versione OpenSSH 9.0. Anche il port forwarding e Git tramite SSH usano canali sulla stessa connessione. Tutti impiegano la stessa porta, lo stesso controllo della chiave host e lo stesso accesso. SFTP non è FTP con la crittografia aggiunta: quel protocollo si chiama FTPS ed è distinto.

L'autenticazione tramite chiave è davvero migliore di una password?

Sì, per qualsiasi server raggiungibile da Internet. Una password è un secret breve che viene fornito al server a ogni accesso, mentre la porta 22 è sottoposta continuamente a tentativi da parte di client automatici. Con una coppia di chiavi, la parte privata non lascia mai il vostro computer: il client firma dati associati alla sessione corrente e il server verifica la firma rispetto alla chiave pubblica in ~/.ssh/authorized_keys. Una firma registrata non può essere riutilizzata contro un altro server. Proteggete la chiave privata con una passphrase, perché un file di chiave senza passphrase consente l'accesso a chiunque ne copi il contenuto.