Secure Shell-pakketuitwisseling begrijpen

Inleiding

Dit document beschrijft de uitwisseling op pakketniveau tijdens SSH-onderhandeling (Secure Shell).

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van basisbeveiligingsconcepten:

• Verificatie
• Vertrouwelijkheid
• Integriteit
• Belangrijkste uitwisselingsmethoden

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

SSH-protocol

Het SSH-protocol is een methode voor beveiligde externe aanmelding van de ene computer naar de andere. SSH-toepassingen zijn gebaseerd op een client-serverarchitectuur, waarbij een SSH-client wordt verbonden met een SSH-server.

SSH exchange

1. De eerste stap van SSH wordt genoemd Identification String Exchange.

 1.1. De client maakt een pakket en stuurt het naar de server met:

•  SSH-protocolversie
•  Softwareversie

Versie en softwareversie van clientprotocol

1.2. De server reageert met zijn eigen Identification String Exchange, inclusief zijn SSH-protocolversie en softwareversie.

Versie en softwareversie voor serverprotocol

2. Volgende stap is  Algorithm Negotiation. In deze stap onderhandelen zowel client als server over deze algoritmen:

• Keyexchange
• Versleuteling
• Op hash gebaseerde Berichtverificatiecode (HMAC)
• Compressie

2.1. De client stuurt een Key Exchange Init-bericht naar de server, waarin de ondersteunde algoritmen worden gespecificeerd. De algoritmen worden gerangschikt in volgorde van voorkeur.

Uitruiling clientsleutel

Door client ondersteunde algoritmen

2.2. De server reageert met zijn eigen Key Exchange Init-bericht, met een lijst van de algoritmen die hij ondersteunt.

2.3. Aangezien deze berichten gelijktijdig worden uitgewisseld, vergelijken beide partijen hun algoritmelijsten. Als er een overeenkomst in de algoritmen door beide partijen wordt gesteund, gaan zij aan de volgende stap te werk. Als er geen exacte overeenkomst is, selecteert de server het eerste algoritme uit de lijst van de client die het ook ondersteunt.

Opmerking: Als de client en server het niet eens kunnen worden over een gemeenschappelijk algoritme, mislukt de sleuteluitwisseling.

Exchange-nit voor servers

 Key Exchange 3. Vervolgens gaan beide kanten de fase in om gedeeld geheim te genereren met behulp van DH-toetsuitwisseling en authenticeren de server:

3.1. De client genereert een sleutelpaar Public and Private, en verstuurt de DH Public-sleutel in het Diffie-Hellman Group Exchange Init-pakket. Dit sleutelpaar wordt gebruikt voor de berekening van geheime sleutels.

client voor Diffie-Hellman groep exchange-index

3.2. De server genereert zijn eigen Public and Private ksleutelpaar. Hij gebruikt de openbare sleutel van de client en zijn eigen sleutelpaar om het gedeelde geheim te berekenen.

3.3. De server berekent ook een Exchange Hash met deze ingangen:

• Clientidentificatietekenreeks
• Serveridentificatietekenreeks
• payload-encryptie van client 
• payload-encryptie van serversleutel 
• Server Public-key van hostsleutels (RSA-sleutelpaar)
• Openbare sleutel voor client-DH
• Openbare sleutel voor DH van server
• Gedeelde geheime sleutel

3.4. Na computerhash ondertekent de server het met zijn RSA Private Key.

3.5. De Server construeert een bericht Diffie-Hellman Group Exchange dat het volgende omvat:

•  RSA Public Key of Server (om de client te helpen bij het verifiëren van de server)
•  DH Openbare sleutel van de Server (voor het berekenen van het gedeelde geheim)
•  HASH (om de server te verifiëren en te bewijzen dat de server het gedeelde geheim heeft gegenereerd, aangezien de geheime sleutel deel uitmaakt van de hashberekening)

Antwoord van Server Diffie-Hellman Group Exchange

3.6. Na ontvangst van het antwoord van de Diffie-Hellman Group Exchange, berekent de klant de hash op dezelfde manier en vergelijkt deze met de ontvangen hash, decodeert deze met behulp van de RSA Public Key van de server.

3.7. Alvorens de ontvangen HASH te decrypteren, moet de client de openbare sleutel van de server verifiëren. Deze verificatie wordt uitgevoerd door middel van een digitaal certificaat dat is ondertekend door een certificeringsinstantie (CA). Als het certificaat niet bestaat, is het aan de client om te beslissen of de openbare sleutel van de server wordt geaccepteerd.

Opmerking: Wanneer u SSH gebruikt om voor het eerst in een apparaat in te loggen dat geen digitaal certificaat gebruikt, kunt u een pop-up tegenkomen met het verzoek om de openbare sleutel van de server handmatig te accepteren. Om te voorkomen dat deze pop-up elke keer dat u verbinding maakt, kunt u ervoor kiezen om de host-sleutel van de server aan uw cache toe te voegen.

Openbare sleutel voor servers

4. Aangezien het Gedeelde geheim nu wordt geproduceerd, gebruiken beide einden het om deze sleutels af te leiden:

•  Encryptietoetsen
•  IV-toetsen - Dit zijn willekeurige getallen die worden gebruikt als invoer voor symmetrische algoritmen om de beveiliging te verbeteren.
•  Integriteitstoetsen

Het einde van de sleuteluitwisseling wordt aangegeven door de uitwisseling van het NEW KEYS bericht, dat elke partij informeert dat alle toekomstige berichten versleuteld en beveiligd worden met deze nieuwe sleutels.

Nieuwe toetsen voor client en server

5. De laatste stap is de serviceaanvraag. De client stuurt een pakket met SSH-serviceaanvragen naar de server om gebruikersverificatie te starten. De server reageert met een bericht van SSH Service Accept, waarin de client wordt gevraagd in te loggen. Deze uitwisseling vindt plaats via het gevestigde beveiligde kanaal.

Gerelateerde informatie

• SSH’s op routers en switches configureren
• Het Secure Shell (SSH)-transportlaagprotocol
• Cisco Technical Support en downloads