Informazioni su Secure Shell Packet Exchange

Introduzione

In questo documento viene descritto lo scambio a livello di pacchetto durante la negoziazione SSH (Secure Shell).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti base sulla sicurezza:

• Autenticazione
• Riservatezza
• Integrità
• Metodi di scambio chiave

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Protocollo SSH

Il protocollo SSH è un metodo per proteggere l'accesso remoto da un computer all'altro. Le applicazioni SSH si basano su un'architettura client-server e connettono un'istanza del client SSH a un server SSH.

SSH Exchange

1. La prima fase del SSH è denominata Identification String Exchange.

 1.1. Il client costruisce un pacchetto e lo invia al server contenente:

•  Versione protocollo SSH
•  Versione del software

Versione protocollo client e versione software

1.2. Il server risponde con la propria stringa di identificazione Exchange, incluse la versione del protocollo SSH e la versione del software.

Versione protocollo server e versione software

2. Il passo successivo è  Algorithm Negotiation. In questo passo, sia il client che il server negoziano i seguenti algoritmi:

• Scambio chiave
• Crittografia
• HMAC (Hash-based Message Authentication Code)
• Compressione

2.1. Il client invia un messaggio di inizializzazione scambio chiave al server, specificando gli algoritmi supportati. Gli algoritmi sono elencati in ordine di preferenza.

Inizializzazione scambio chiave client

Algoritmi supportati dal client

2.2. Il server risponde con il proprio messaggio di inizializzazione scambio chiave, elencando gli algoritmi supportati.

2.3. Poiché questi messaggi sono scambiati contemporaneamente, entrambe le parti confrontano i rispettivi elenchi di algoritmi. Se esiste una corrispondenza negli algoritmi supportati da entrambi i lati, questi procedono al passaggio successivo. Se non esiste una corrispondenza esatta, il server seleziona il primo algoritmo dall'elenco del client supportato.

Nota: Se il client e il server non concordano su un algoritmo comune, lo scambio di chiavi non riesce.

Inizializzazione scambio chiave server

3. Successivamente, entrambi i dispositivi entrano nella Key Exchange fase di generazione del segreto condiviso utilizzando lo scambio di chiave DH e autenticano il server:

3.1. Il client genera una coppia di chiavi, Public and Private, e invia la chiave pubblica DH nel pacchetto Init di Exchange del gruppo Diffie-Hellman. Questa coppia di chiavi viene utilizzata per il calcolo della chiave segreta.

Inizializzazione scambio gruppo Diffie-Hellman client

3.2. Il server genera la propria coppia di Public and Private kchiavi. Utilizza la chiave pubblica e la propria coppia di chiavi per calcolare il segreto condiviso.

3.3. Il server calcola anche un hash di Exchange con questi input:

• Stringa di identificazione client
• Stringa di identificazione server
• Payload inizializzazione scambio chiave client 
• Payload dell'inizializzazione di scambio chiave del server 
• Chiave pubblica del server da chiavi host (coppia di chiavi RSA)
• Chiave pubblica DH client
• Chiave pubblica DH del server
• Chiave privata condivisa

3.4. Dopo aver calcolato l'hash, il server lo firma con la chiave privata RSA.

3.5. Il server crea un messaggio Diffie-Hellman Group Exchange che include:

•  Chiave pubblica del server RSA (per consentire al client di autenticare il server)
•  DH Chiave pubblica del server (per il calcolo del segreto condiviso)
•  HASH (per autenticare il server e dimostrare che il server ha generato il segreto condiviso, in quanto la chiave privata fa parte del calcolo dell'hash)

Risposta di Exchange del gruppo Diffie-Hellman del server

3.6. Dopo aver ricevuto la risposta di scambio del gruppo Diffie-Hellman, il client calcola l'hash nello stesso modo e lo confronta con l'hash ricevuto, decriptandolo con la chiave pubblica RSA del server.

3.7. Prima di decrittografare l'HASH ricevuto, il client deve verificare la chiave pubblica del server. Questa verifica viene eseguita tramite un certificato digitale firmato da un'Autorità di certificazione (CA). Se il certificato non esiste, spetta al client decidere se accettare la chiave pubblica del server.

Nota: quando si usa SSH per accedere per la prima volta a un dispositivo che non usa un certificato digitale, è possibile che venga visualizzata una schermata di popup in cui si chiede di accettare manualmente la chiave pubblica del server. Per evitare di visualizzare questo popup ogni volta che ci si connette, è possibile scegliere di aggiungere la chiave host del server alla cache.

Chiave pubblica server

4. Poiché il segreto condiviso è ora generato, entrambe le entità finali lo utilizzano per derivare le seguenti chiavi:

•  Chiavi di crittografia
•  Chiavi IV: numeri casuali utilizzati come input per algoritmi simmetrici al fine di migliorare la sicurezza.
•  Chiavi di integrità

La fine dello scambio di chiave viene segnalata dallo scambio del NEW KEYS messaggio, che informa ciascuna parte che tutti i messaggi futuri verranno crittografati e protetti utilizzando queste nuove chiavi.

Nuove chiavi client e server

5. La fase finale è la richiesta di assistenza. Il client invia un pacchetto di richiesta del servizio SSH al server per avviare l'autenticazione dell'utente. Il server risponde con un messaggio di accettazione del servizio SSH, in cui viene richiesto al client di eseguire l'accesso. Questo scambio avviene tramite il canale sicuro stabilito.

Informazioni correlate

• Configurazione di SSH su router e switch
• Protocollo SSH (Secure Shell) Transport Layer
• Supporto tecnico Cisco e download