Che cos’è SSH e come funziona?

Secure Shell (SSH) è un protocollo di sicurezza comunemente implementato con una gamma di usi diversi. La sua applicazione più rinomata consente agli utenti di accedere in sicurezza a computer e server remoti, ma può anche essere utilizzato per tunneling, port forwarding, trasferimenti di file sicuri e altro ancora.

In questa guida, tratteremo cos’è SSH, a cosa serve, la storia del protocollo, i suoi dettagli tecnici, così come il problemi di sicurezza che devono essere presi in considerazione.

SSH è composto da tre protocolli separati: il livello di trasporto, il livello di autenticazione e il livello di connessione. Insieme, servono per autenticare l’altra parte nella connessione, fornire riservatezza attraverso la crittografia e verificare l’integrità dei dati. SSH è ora più comunemente implementato come SSH-2 proprietario o come iterazione open source, OpenSSH.

Gli usi di SSH

SSH è un protocollo versatile. La sua struttura e le sue funzionalità di sicurezza ne consentono l’utilizzo in vari modi, ad esempio per l’accesso remoto, port forwarding, tunneling e trasferimenti di file sicuri.

Accesso remoto

L’accesso remoto offre agli utenti un modo per accedere a un altro computer o server dalla propria macchina. Viene utilizzato per accedere ai file locali della macchina target o eseguire servizi su di esso, il tutto senza dover essere fisicamente presente.

Programmi come Telnet e rlogin hanno anche questa funzionalità, ma mancano delle funzionalità di sicurezza di SSH. Le misure di crittografia e autenticazione coinvolte in SSH consentono agli utenti di connettersi a un altro server o computer in modo protetto, anche su una rete intermedia potenzialmente pericolosa.

L’accesso remoto con SSH è comunemente implementato in modo che i dipendenti possano lavorare in remoto o per consentire al reparto IT di eseguire attività senza dover andare fisicamente alla macchina. Può essere utilizzato per l’amministrazione remota, la gestione dell’infrastruttura di rete, per impostare l’automazione, creare backup e altro.

Port forwarding

Il port forwarding viene utilizzato per trasferire le richieste da un indirizzo e numero di porta a un altro set. Applica la traduzione dell’indirizzo di rete (NAT) per reindirizzare le porte tra una rete locale e un computer remoto, consentendo di accedere a un dispositivo dall’esterno della rete.

Il port forwarding può essere effettuato in tre modi diversi:

• Locale Port forwarding – Il port forwarding locale ti consente di connettere il tuo client locale e una rete esterna. Può essere efficace per eseguire operazioni come l’accesso a siti Web bloccati localmente o per la connessione a un database protetto da un firewall.
• Port forwarding remoto – Questo tipo di inoltro consente alle applicazioni lato server di accedere ai servizi sul lato client. Il port forwarding remoto di SSH consente agli utenti di connettersi in modo sicuro a server remoti attraverso il proprio PC locale reindirizzando una porta locale a un server SSH remoto.
• Dinamico Port forwarding – Ciò consente agli utenti di inviare i propri dati attraverso una determinata porta a un computer o server remoto utilizzando un numero di server SSH che fungono da proxy.

traforo

I protocolli di tunneling utilizzano l’incapsulamento per spostare i dati tra le reti. I tunnel possono essere implementati per consentire ai protocolli non nativi di funzionare attraverso reti che normalmente non li supportano. Un altro uso comune è per fornire sicurezza su una rete non sicura.

I protocolli di tunneling avvolgono i pacchetti critici all’interno del payload di un altro pacchetto. Il tunneling SSH consente agli utenti di aggirare la sicurezza della rete, collegare i dispositivi utilizzando un protocollo di rete non nativo e proteggere i dati che vengono trasmessi. Vengono spesso utilizzati per connettere gli utenti remoti alle risorse online della propria organizzazione in modo sicuro.

SFTP

L’SSH File Transfer Protocol (FTP), a volte noto come Secure File Transfer Protocol, fornisce un modo sicuro per accedere, trasferire e gestire i file. È un’alternativa sicura all’FTP e sfrutta il protocollo SSH per inviare, ricevere e amministrare file in modo sicuro.

SCP

Il protocollo Secure Copy Protocol (SCP) è simile a SFTP, ma ha una portata più limitata. Consente solo trasferimenti di file sicuri, anziché l’insieme completo di funzionalità che consentono a SFTP di agire come protocollo di file system remoto.

piattaforme & applicazioni che utilizzano SSH

SSH proprietario o OpenSSH possono essere utilizzati su tutti i principali sistemi operativi. È disponibile su piattaforme basate su Unix come OpenBSD, macOS, Linux e Solaris, mentre gli utenti Windows possono utilizzare SSH tramite PowerShell.

La storia di SSH

SSH è stato sviluppato all’Università di Tecnologia di Helsinki nel 1995 da Tatu Ylönen in risposta a un attacco di sniffing della password alla rete dell’università. Ha mirato a fornire un’alternativa a protocolli simili FTP, TELNET, rsh e rlogin, che non ha garantito la riservatezza o autenticato gli utenti in modo sicuro.

SSH è stato rilasciato gratuitamente al pubblico nel 1995 ed è stato ben accolto. Durante la sua rapida adozione, Ylönen ha fondato SSH Communications Security entro la fine dello stesso anno per continuare lo sviluppo e commercializzare SSH.

Nel 1995, Ylönen ha anche pubblicato una bozza Internet Internet Force Task Force (IETF) documentato il protocollo SSH-1. Le limitazioni sono state presto trovate nel protocollo e non è stato possibile risolverle senza influire sulla compatibilità con le versioni precedenti. La soluzione era una nuova versione del protocollo e SSH-2 fu lanciato dalla società di Ylönen nel 1996.

SSH-2 presentava nuovi algoritmi, che spingevano l’IETF a fondare un gruppo di lavoro che mirava a standardizzare il protocollo. Il gruppo fu soprannominato SECSH, per secondoUre She ha pubblicato la sua prima bozza Internet per SSH-2 nel 1997.

Il software per SSH-2 è stato rilasciato nel 1998, ma non è stato immediatamente adottato in modo diffuso a causa delle sue licenze più restrittive. Nel 2006, una versione modificata del protocollo è stata resa uno standard dall’IETF. Ciò era più sicuro, utilizzando i codici di autenticazione dei messaggi per verificare l’integrità e lo scambio di chiavi Diffie-Hellman per l’autenticazione.

Nel 1999 il progetto OpenBSD ha rilasciato OpenSSH. OpenSSH è una versione gratuita del protocollo che si basa sulle modifiche apportate da Björn Grönvall a SSH 1.1.12. Gli sviluppatori sono tornati a questa versione precedente e l’hanno fortemente modificata, poiché era l’ultima versione di SSH che era completamente open source. OpenSSH è ora l’opzione più utilizzata e da allora è stata implementata in una vasta gamma di sistemi operativi, come Windows, macOS, Linux, Solaris e altri.

SSH-1 vs SSH-2 vs OpenSSH

Come notato sopra, SSH-1 è la prima versione del protocollo, che è stato originariamente rilasciato sotto un licenza open source. È considerato insicuro e non dovrebbe essere implementato. Questo lascia la versione proprietaria, SSH-2, e la versione liberamente disponibile, OpenSSH, come alternative praticabili.

SSH-2 e OpenSSH sono essenzialmente gli stessi quando si tratta della loro architettura e di come funzionano. La differenza principale è che la versione proprietaria include una gamma di opzioni di supporto, mentre quelli che utilizzano OpenSSH devono fare affidamento sulle risorse create liberamente dalla comunità.

SSH: i dettagli tecnici

SSH-1 ha funzionato come un unico protocollo, ma non ci entreremo qui poiché è obsoleto. Invece, ci concentreremo su SSH-2 e OpenSSH, che sono entrambi costituiti da tre protocolli separati:

• Il protocollo di trasporto – Questo stabilisce la connessione e fornisce la sicurezza sottostante.
• Il protocollo di autenticazione – Questo livello viene utilizzato per autenticare il client.
• Il protocollo di connessione – Questo protocollo gestisce i canali su cui vengono trasmessi i dati.

Ognuno di questi protocolli ha un ruolo unico che lavora per stabilire e proteggere una connessione, autenticare l’altra parte e trasferire dati. La porta di connessione TCP predefinita è 22 e le connessioni vengono impostate tra un client SSH e un server SSH lungo il modello client-server.

Il processo di accesso remoto di SSH procede secondo la seguente struttura di base (con variazioni a seconda della configurazione), che tratteremo più dettagliatamente in seguito:

• Il client contatta il server SSH per iniziare la connessione.
• Il server invia quindi la sua chiave pubblica al client per autenticare la sua identità.
• Le due parti negoziano i parametri per la connessione, quindi stabiliscono un canale sicuro lungo tali linee.
• L’utente quindi accede al sistema operativo dell’host del server e ora può amministrare le proprie attività in remoto.

Protocollo di trasporto

Il livello di trasporto è un protocollo di basso livello che si occupa delle seguenti attività.

• Autenticazione host server
• Scambio di chiavi
• Crittografia per la riservatezza dei dati
• Controlli di integrità per verificare che i dati non siano stati alterati
• Stabilire un ID sessione che può essere utilizzato negli altri protocolli

Il il protocollo di trasporto autentica solo il server e non il client (l’autenticazione client viene eseguita nel protocollo di autenticazione se necessario).

Nel livello di trasporto, la connessione viene avviata dal client e le due parti quindi negoziano come verranno scambiate le chiavi, quale algoritmo della chiave pubblica verrà utilizzato, quale cifra della chiave simmetrica crittograferà i dati, quale algoritmo di autenticazione del messaggio verrà utilizzato per verificare i dati e quale metodo di compressione (se presente) verrà implementato.

Una volta avviata la connessione, sia il server che il client devono inviare tramite una stringa di identificazione, che include la versione del protocollo (2.0).

Negoziazione dell’algoritmo

Per impostare i parametri della connessione, entrambe le parti inviano un pacchetto contenente un elenco con le seguenti opzioni:

byte SSH_MSG_KEXINIT

byte [16] cookie (byte casuali)
elenco nomi kex_algorithms
elenco-nomi server_host_key_algorithms
nome-elenco crittografia_algoritmo_cliente_to_server
nome-elenco crittografia_algorithms_server_to_client
elenco nomi mac_algorithms_client_to_server
elenco nomi mac_algorithms_server_to_client
nome-lista compressione_algorithms_client_to_server
nome-lista compressione_algorithms_server_to_client
elenco dei nomi language_client_to_server
elenco dei nomi language_server_to_client
booleano first_kex_packet_follows
uint32 0 (riservato per future estensioni)

Ogni parte elenca i parametri che sono disposti ad accettare nella connessione, separati da virgole. L’algoritmo preferito dovrebbe essere elencato per primo.

Per scambio di chiavi (kex_algorithms), il primo algoritmo supportato da entrambe le parti sarà scelto per la connessione (potrebbero esserci anche altri fattori che devono essere soddisfatti, a seconda dell’algoritmo scelto). Se le due parti non riescono a trovare un algoritmo reciprocamente supportato che soddisfi questi requisiti, la connessione non riesce.

Algoritmi della chiave host del server sono gli algoritmi supportati per la chiave host del server. Il server stabilisce gli algoritmi per cui ha le chiavi host, mentre il client specifica gli algoritmi che è pronto ad accettare. La selezione dipenderà dal fatto che il metodo di scambio delle chiavi impostato richieda una chiave host con crittografia o una firma digitale

Entrambe le parti elencano il algoritmi a chiave simmetrica che sono disposti ad accettare, con i metodi preferiti in alto. Deve essere utilizzata la prima opzione da visualizzare nell’elenco del client che si trova anche nell’elenco del server. Se non è possibile raggiungere un accordo, la connessione non riesce.

Entrambi i Algoritmo MAC e il algoritmo di compressione sono negoziati allo stesso modo.

Scambio di chiavi

Lo scambio di chiavi è responsabile autenticazione del server, ed esso imposta le chiavi che verranno utilizzate per proteggere la connessione nei seguenti passaggi. In genere inizia con le parti che inviano le rispettive liste di algoritmi supportati. In alternativa, ciascuna parte può indovinare l’algoritmo preferito dell’altra parte e inviare un pacchetto che si adatta ai parametri di tale algoritmo all’inizio.

Se l’ipotesi di una parte è corretta, quel pacchetto viene utilizzato come primo pacchetto di scambio di chiavi. Se nessuna delle ipotesi è corretta, ciascuna parte deve fare un passo indietro e inviare le proprie liste di algoritmi preferiti. Se il messaggio di scambio di chiavi include la firma digitale del server come prova della legittimità del server, viene preso in considerazione autenticazione esplicita del server. Se invece utilizza il segreto condiviso, viene indicato come autenticazione implicita del server.

Lo scambio di chiavi ha anche la responsabilità di stabilire un segreto condiviso e un hash. Il valore hash dallo scambio di chiavi iniziale diventa l’identificatore univoco della sessione e viene anche utilizzato come parte delle firme digitali che dimostrano che la parte è il vero proprietario della sua chiave privata.

La funzione hash utilizzata dipenderà dal metodo di scambio delle chiavi deciso nella negoziazione. Quando lo scambio di chiavi è completato, tutte le comunicazioni future useranno il nuovo set di chiavi e algoritmi.

Secondo un progetto Internet Internet Force Task Force (IETF), i seguenti metodi di scambio chiave sono considerati sicuri:

• curve25519-sha256
• curve448-sha512
• Diffie-Hellman-gruppo-scambio-sha256
• Diffie-Hellman-group14-sha256
• Diffie-Hellman-group15-sha512
• Diffie-Hellman-group16-sha512
• Diffie-Hellman-group17-sha512
• Diffie-Hellman-group18-sha512
• ECDH-SHA2-nistp256
• ECDH-SHA2-nistp384
• GSS-group14-sha256
• GSS-group15-sha512
• GSS-group16-sha512
• GSS-group17-sha512
• GSS-group18-sha512
• GSS-nistp256-sha256
• GSS-nistp384-SHA384
• GSS-nistp521-sha512
• GSS-curve25519-sha256
• GSS-curve448-sha512
• rsa2048-sha256

Algoritmo della chiave host del server

Questi algoritmi a chiave pubblica sono usati per autenticazione del server e per stabilire in modo sicuro l’ID della sessione condivisa. Possono anche essere facoltativamente utilizzati per autenticare l’host. SSH è progettato per funzionare con una gamma di algoritmi a chiave pubblica, tipi e formati di codifica:

• Utilizza algoritmi a chiave pubblica per la crittografia e / o le firme digitali.
• È possibile implementare una serie di metodi di codifica, che consente la configurazione con diversi formati di dati, riempimento e ordine dei byte.
• Vari formati di chiavi consentono di codificare le chiavi in ​​diversi modi, nonché una serie di rappresentazioni di certificati.

Gli algoritmi predefiniti includono quanto segue, tuttavia ci sono alcune altre varianti che possono anche essere implementate:

• ssh-rsa
• ssh-rsa-sha256
• ssh-dss
• ssh-dss-sha256
• x509v3-sign-dss
• x509v3-sign-dss-sha256
• x509v3-sign-rsa
• x509v3-sign-rsa-sha256

Algoritmi di crittografia

Gli algoritmi a chiave simmetrica vengono utilizzati per crittografare i dati e fornire riservatezza. I parametri e la chiave condivisa utilizzati nel processo di crittografia vengono stabiliti nelle fasi precedenti della connessione. L’algoritmo scelto crittografa il carico utile, la lunghezza del pacchetto, la lunghezza del riempimento e i campi del riempimento.

Una serie di diversi algoritmi di crittografia è accettata in SSH, ma per motivi di sicurezza, è meglio attenersi ad AES. Le chiavi dovrebbero avere un minimo di 128 bit, ma sono preferibili chiavi più grandi.

Algoritmi MAC

Il protocollo di trasporto verifica l’integrità dei dati aggiungendo un codice di autenticazione dei messaggi (MAC) al pacchetto. Questo MAC si basa sul segreto condiviso (stabilito nello scambio di chiavi), sul numero di sequenza del pacchetto e sul contenuto del pacchetto. Viene calcolato prima che avvenga la crittografia.

Le implementazioni devono offrire un algoritmo indipendente per l’esecuzione in ciascuna direzione, sebbene sia ideale se lo stesso viene utilizzato su entrambi i lati. È possibile implementare un’ampia gamma di algoritmi di autenticazione dei messaggi, tuttavia SHA-256 e versioni successive dovrebbero essere utilizzati nella maggior parte delle situazioni per garantire un elevato livello di sicurezza.

Compressione

La compressione non è obbligatoria nel protocollo SSH e le sue implementazioni devono consentire alle connessioni di procedere senza compressione. La compressione può essere implementata solo come opzione, usando schemi come zlib. Se viene utilizzata la compressione, influisce solo sul payload. Il campo MAC e la lunghezza del pacchetto vengono quindi calcolati in base al payload compresso.

Pacchetto protocollo di trasporto

Il pacchetto del protocollo di trasporto è formattato per includere le seguenti informazioni (nonché alcuni dettagli meno pertinenti che sono stati esclusi):

• La lunghezza del pacchetto
• La lunghezza dell’imbottitura
• Il carico utile
• Imbottitura
• Un codice di autenticazione del messaggio (MAC)

Protocollo di autenticazione

Questo protocollo viene utilizzato dal server per autenticare il client. Può farlo con una varietà di meccanismi diversi, molti dei quali si basano sull’ID di sessione stabilito nel protocollo di trasporto. Alcuni usano i controlli di crittografia e integrità del protocollo di trasporto insieme all’ID sessione, mentre altri usano questi algoritmi da soli.

Il server utilizza la sua politica locale per decidere quali metodi di autenticazione accetta da un singolo utente. Poiché il server è già stato autenticato nel protocollo di trasporto, non è necessario autenticare nuovamente il server.

La sicurezza del protocollo di autenticazione dipende dal protocollo di trasporto che viene eseguito sopra. Se il protocollo di trasporto non può garantire la riservatezza o verificare l’integrità dei dati, ciò limita le modalità di utilizzo sicuro del protocollo di autenticazione.

Ad esempio, se il protocollo di trasporto non applica la protezione dell’integrità, non dovrebbero essere consentite richieste come la modifica della password, in quanto ciò consentirebbe agli aggressori di manomettere i dati senza essere notati.

Il protocollo di autenticazione utilizza l’autenticazione a chiave pubblica presupponendo che né la chiave privata dell’host server né la chiave dell’host client siano state compromesse. Se il server è stato compromesso, ciò può comportare il rilascio del nome utente e della password del client all’attaccante.

Perché l’autenticazione basata su host sia sicura, il client non deve essere compromesso. Se questa è una possibilità, è necessario aggiungere altri metodi di autenticazione. È importante notare questo il processo di autenticazione è efficace quanto il metodo di scambio più debole accettato da un server.

Il processo del protocollo di autenticazione

Il protocollo di autenticazione inizia quando il server invia al client un elenco dei suoi metodi di autenticazione accettati. Il cliente può quindi scegliere tra questi metodi in qualsiasi ordine. Questo processo fornisce il controllo al server, ma consente anche una flessibilità sufficiente affinché il client possa organizzare l’utilizzo del metodo più conveniente.

I metodi di autenticazione client più comuni includono:

• Chiave pubblica – Questo metodo utilizza algoritmi come RSA, DSA ed ECDSA per autenticare il client attraverso la crittografia a chiave pubblica. Alcune implementazioni utilizzano anche certificati x.509. Il server verifica la firma digitale del client rispetto alla sua chiave pubblica per verificare l’identità del client.
• Parola d’ordine – Le password possono anche essere utilizzate per autenticare il client. Il client invia tramite la sua password (che dovrebbe essere crittografata dal protocollo di trasporto). Se la password corrisponde al valore memorizzato del server, viene accettata e l’autenticazione procede.
• GSSAPI – Con questo metodo, è possibile utilizzare schemi esterni come Kerberos per il Single Sign-On.
• Tastiera interattiva – Questa tecnica fornisce l’autenticazione con password una tantum facendo in modo che il server richieda informazioni al client.

Protocollo di connessione

Viene stabilito il protocollo di connessione come più canali di dati verranno combinati sul livello di trasporto sicuro. Si occupa anche dei parametri utilizzati per accedere ai sottosistemi sicuri sull’host del server, nonché di inoltro proxy e accesso alle shell.

Il protocollo di connessione si trova sopra il livello di trasporto e i protocolli di autenticazione. Consente l’esecuzione di comandi remoti, nonché connessioni X11 e TCP / IP inoltrate. Se il server o il client sono stati compromessi, il protocollo di connessione non è sicuro.

canali

I canali sono i percorsi di comunicazione di base e possono essere aperti da entrambe le parti. I canali possono includere sessioni terminali, connessioni inoltrate e altre forme di comunicazione. Quando sono presenti più canali, vengono multiplexati in un’unica connessione.

Canali di apertura

Ogni canale è numerato su entrambe le sue estremità, sebbene i numeri possano potenzialmente essere diversi su entrambi i lati. Quando una parte richiede di aprire un canale, invia il suo numero di canale come parte del messaggio, nonché le informazioni sul dimensione iniziale della finestra e il dimensione massima del pacchetto.

La dimensione della finestra iniziale indica quanti dati può ricevere la parte che apre il canale. Se è necessario inviare più dati, è necessario prima regolare la finestra. Allo stesso modo, la dimensione massima del pacchetto specifica quanto grande può essere ricevuto un pacchetto.

Quando una parte richiede l’apertura di un canale, l’altra parte aprirà il canale se può soddisfarlo. In caso contrario, verrà inviato tramite un messaggio di errore. I canali non possono essere aperti per i seguenti motivi:

• Vietato dall’amministrazione
• Connessione fallita
• Tipo di canale sconosciuto
• Carenza di risorse

Se entrambi i lati della connessione desiderano inviare più dati di quelli consentiti dalla finestra, possono inviare un messaggio che richiede di aggiungere più byte.

Canali di chiusura

Una volta che un lato di una connessione ha completato la sua trasmissione di dati, dovrebbe inviare un messaggio che indica che ha finito di usare il canale. Ciononostante, il canale è aperto e i dati possono comunque essere inviati dall’altra parte. Se una parte desidera terminare completamente il canale, lo fa con un messaggio di terminazione separato.

Sicurezza SSH

Le varie versioni di SSH hanno avuto i loro problemi di sicurezza, sebbene le attuali configurazioni di SSH-2 e OpenSSH sono considerati molto più sicuri di SSH-1.

SSH-1

SSH-1 è generalmente considerato difettoso, con una gamma di diverse vulnerabilità. Questi includono un bug in SSH 1.5 che consentiva agli utenti non autorizzati di inserire contenuto nel flusso di dati SSH. Questo attacco ha sfruttato la protezione minima dell’integrità dei dati dell’algoritmo CRC-32.

Questo attacco è stato mitigato con il SSH Compensation Attack Detector, integrato nella maggior parte delle implementazioni più recenti. Questa correzione presentava una nuova vulnerabilità, che aveva il potere di eseguire codice arbitrario con privilegi di root.

Esiste anche una vulnerabilità che consente agli avversari di modificare l’ultimo blocco in una sessione che utilizza la crittografia IDEA, nonché uno che consente a un server compromesso di inoltrare il processo di autenticazione client a un altro server.

A causa di questi problemi di sicurezza, è necessario utilizzare SSH-2. Per mantenere la tua implementazione sicura, dovresti anche disabilitare la rinegoziazione su SSH-1, perché gli attacchi possono trarne vantaggio per accedere ai tuoi dati tramite il livello di protezione più debole di SSH-1.

SSH-2

SSH-2 è vulnerabile a un attacco teorico contro la sua modalità di crittografia predefinita, CBC. Consente all’attaccante di recuperare fino a 32 bit del testo in chiaro da un blocco crittografato. Ciò può essere mitigato utilizzando la modalità Counter (CTR) e trasformando invece la cifra di blocco in una cifra di flusso.

Alla fine del 2014, Der Spiegel ha rilasciato documenti della NSA che implicavano che a volte la NSA poteva rompere SSH. Questo NSA PowerPoint trapelato afferma che l’NSA può “Recupera potenzialmente nomi utente e password“, Sebbene non vengano forniti ulteriori dettagli. Non è noto quali metodi l’agenzia ha usato per fare questo, ma sembra improbabile che mentirebbe sulle sue capacità nella propria documentazione interna.

Nella fuga di Vault 7 del 2023, è stato rivelato che la CIA aveva due strumenti che potevano essere usati per intercettare e rubare login e password SSH. BothanSpy ha preso di mira i client Windows Xshell, mentre Gyrfalcon è stato usato contro il client OpenSSH su diverse distribuzioni Linux.

Questi strumenti sono in grado di rubare le credenziali e quindi di ritrasmetterle a un server CIA. Nessuno di questi attacchi può violare il protocollo stesso; usano solo altri attacchi del canale laterale che possono aggirarlo in determinate implementazioni.

Nonostante questi attacchi, SSH-2 è considerato sicuro nella maggior parte delle situazioni, purché sia ​​implementato in modo appropriato. Gli obiettivi di alto valore o coloro che utilizzano implementazioni obsolete o scadenti dovrebbero prendere in considerazione altre opzioni.

OpenSSH

In OpenSSH versione 2, è stato scoperto un attacco che ha sfruttato una debolezza del pacchetto binario SSH. L’attacco ha permesso ai ricercatori dell’Università di Londra di recuperare 14 bit del testo in chiaro da un blocco crittografato. Ciò è stato mitigato nella versione 5.2 facendo in modo che il protocollo leggesse l’intera lunghezza di un pacchetto non valido o un codice di autenticazione del messaggio, anziché terminare la connessione.

Nelle versioni 6.8 e 6.9, Linux potrebbe essere usato per eseguire comandi arbitrari sui terminali di altri utenti. Ciò è stato ottenuto attraverso una vulnerabilità di escalation di privilegi che ha consentito agli aggressori di iniettare caratteri con il controllo di input / output TIOCSTI.

SSH è sicuro?

Mentre può sembrare che SSH abbia molti problemi di sicurezza, è relativoÈ normale che una serie di vulnerabilità sia rilevata nelle varie implementazioni di un protocollo. Ciò non significa che il protocollo SSH non sia sicuro. Invece, significa solo questo deve essere implementato correttamente.

Finché stai usando entrambi SSH-2 o OpenSSH ed è configurato in modo adeguato al tuo utilizzo, dovresti sentirti sicuro della protezione che SSH fornisce la tua connessione. Ecco perché è ancora un protocollo così frequentemente utilizzato, soprattutto per l’accesso remoto e il tunneling.

Vedi anche: tipi di crittografia comuni spiegati

Sfondo di tecnologia di rete cyber da TheDigitalArtist su licenza CC0