Deze vraag heeft hier al antwoorden :

Reacties

  • Lees RFCs als je meer details wilt, voer ssh client en server uit in foutopsporingsmodus om erachter te komen wat er onder de motorkap gebeurt.
  • Het zou kunnen helpen als je uitlegt waarom het voorgestelde duplicaat niet ' niet van toepassing is. Het lijkt erop dat het uw vraag beantwoordt.
  • Als het mijn vraag beantwoordt, doet het dat op een manier die mij niet helpt. Om een antwoord te krijgen dat ik begrijp, moet ik me daarom afvragen.
  • amflare – dat andere bericht behandelt de dingen die je hier hebt gevraagd. Ik heb een duplicaat gesloten als jij hebt ' t heeft uitgelegd wat je nog meer vroeg, ondanks dat anderen je dat vroegen.
  • Iets wat ik echt kan begrijpen (en ja, Ik heb dit eerder gezegd). Je zegt me dat er een antwoord is, ik zeg dat ik het niet ' begrijp. Je antwoord mag niet " jammer " zijn.

Antwoord

Wat maakt het eigenlijk beter dan een heel lang wachtwoord?

Ze worden niet overgebracht naar de server (aangezien zelfs het zeer lange wachtwoord moet worden overgedragen). Het is niet onveilig in het ssh geval (het kanaal is versleuteld tenzij je gebroken cijfers gebruikt), maar in theorie kan het worden onderschept door Man In the middle of kwaadwillende (super) gebruiker op de externe server.

En hoe speelt de publieke sleutel een rol in dingen?

Dit is het punt van asymmetrische cryptografie. Private key creëert een handtekening en public kan verifiëren dat de handtekening is gemaakt door de respectievelijke publieke sleutel. U verzendt de openbare sleutel en handtekening van de gegevens die door de server worden aangeboden en dit is voldoende voor de server om u toegang te verlenen (als de openbare sleutel overeenkomt met die in authorized_keys).

Reacties

  • Dus het verzendt de openbare sleutel, als deze overeenkomt, worden de gegevens die teruggaan versleuteld met die openbare sleutel, die de privésleutel vervolgens kan ontsleutelen ? En vice versa met de privéversleuteling en de openbare ontsleuteling?
  • versleuteld met die openbare sleutel, die de privésleutel vervolgens kan ontsleutelen – ondertekend met privésleutel, welke openbare sleutel kan verifieer.
  • Wat betekent " ondertekend "? Wat voorkomt dat iets iets ontsleutelt, zelfs als de handtekening niet uitcheckt?
  • @amflare: en.wikipedia.org/wiki/Digital_signature Als er iets is, dan is de zogenaamde decryptor ' s eigen code.
  • Juist, dat begrijp ik. Vandaar mijn (schijnbaar gebrekkige) veronderstelling dat de sleutels de codering en decodering mogelijk maakten. Maar het lijkt erop dat als ik een kwaadwillende partij was, ik de gegevens zou kunnen onderscheppen en de authenticiteit van de handtekening kon negeren en toch zou proberen deze te ontsleutelen. Ik had de indruk dat de sleutels dienden als een middel om ook derden te verhinderen dat te doen.

Antwoord

Ik “weet niet zeker wat je” aan het vergelijken bent met SSH met het “erg lange wachtwoord”. SSH biedt een veilige manier om uw gebruikerslogin en wachtwoord naar een externe server te sturen. Of u kunt de openbare sleutel van een client gebruiken. Asymmetrische sleutels zijn over het algemeen moeilijker te doorbreken omdat gebruikers er geen verkeerde wachtwoorden voor maken. Om die reden heeft op openbare sleutel gebaseerde authenticatie de voorkeur. U kunt specifieke openbare sleutels voor uw gebruiker (en IP) op de witte lijst zetten, zodat niet zomaar iedereen kan inloggen met uw gebruikersnaam en vanaf elke computer. Deze witte lijst is opgenomen in /home/<user>/.ssh/authorized_keys.

Basisprincipes van SSH:

  1. Server presenteert zijn openbare RSA-sleutel aan de cliënt. De client verifieert handmatig dat deze deze sleutel vertrouwt voordat hij verdergaat.

  2. SSH gebruikt Diffie Hellman om een gedeelde geheime waarde vast te stellen.

  3. Het gedeelde geheim wordt samen met veel sleuteluitwisselingsgegevens samen gehasht en ondertekend met behulp van de privésleutel van de server.

  4. De klant kan deze handtekening verifiëren met behulp van de eerdere servergegevens. vertrouwde openbare sleutel.

  5. Beide partijen hebben nu alle informatie die nodig is om sessiesleutels te genereren.

Van sectie 7.2 van RFC4253 

7.2. Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we"ll call it HASH. Encryption keys MUST be computed as HASH, of a known value and K, as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data. "A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. As many bytes as needed are taken from the beginning of the hash value. If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: K1 = HASH(K || H || X || session_id) (X is e.g., "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH.

Zodra het gecodeerde kanaal tot stand is gebracht, begint het SSH-protocol met de clientverificatie op basis van op parameters die je het hebt gegeven. Dit alles wordt veilig uitgevoerd via het versleutelde kanaal.

Antwoord

Laat me een beeld op hoog niveau geven. U begrijpt duidelijk de noodzaak van veilige communicatie, of het nu SSH of HTTPS is. Veilige communicatie betekent dat het kanaal is versleuteld.

Over het algemeen vallen alle versleutelingsalgoritmen in een van twee categorieën:

  • Symmetrische versleuteling. Een sleutel. Dezelfde sleutel wordt gebruikt om te coderen en decoderen. Snel. Bijv. AES.
  • Asymmetrische codering. Twee sleutels. Beide kunnen worden gebruikt om te coderen, maar alleen de andere kan worden gedecodeerd. Veel langzamer dan symmetrische algoritmen. Bijv. RSA.

Symmetrische versleuteling is snel en daarom geschikt voor communicatie met veel gegevens tussen twee partijen. Het gebruikt dezelfde sleutel voor codering en decodering – deze sleutel is analoog aan uw concept van een erg lang wachtwoord. Probleem: hoe deel je je sleutel / wachtwoord in de eerste plaats? Blijkt dat je geen veilig kanaal kunt gebruiken dat uitsluitend op een symmetrisch versleutelingsalgoritme is gebouwd zonder een manier te bedenken om eerst je sleutel / wachtwoord te delen.

Hier komen asymmetrische algoritmen om de hoek kijken, maar deze zijn aanzienlijk langzamer dan symmetrische algoritmen. Onpraktisch om grote hoeveelheden gegevens te verzenden, maar prima als u iets kleins verzendt of uitwisselt, zoals een symmetrische coderingssleutel / wachtwoord. Zodra dat is gebeurd, kunt u nu symmetrische versleuteling gebruiken voor communicatie.

Een van de twee sleutels voor asymmetrische versleuteling wordt de openbare sleutel genoemd en de andere de privésleutel. De openbare sleutel kan aan iedereen worden verspreid, maar de privésleutel moet geheim worden gehouden. 

You (has pub) Server (has prv + pub) asym-encrypt(pub, sym-key/pwd) ----> asym-decrypt(prv, encrypted-data) => sym-key/pwd

pub = openbare sleutel, prv = privésleutel

In elk geval is deze uitleg een vereenvoudiging van wat SSH eigenlijk doet. Twee andere dingen die het vermelden waard zijn:

  • Diffie Hellman is het typische asymmetrische algoritme voor sleuteluitwisseling. Met Diffie Hellman hoef je eigenlijk geen symmetrische sleutel te maken . Beide partijen creëren samen de symmetrische sleutel tijdens de sleuteluitwisseling, wat een prettige beveiligingsfunctie is. Zie " Diffie-Hellman Key Exchange " in gewoon Engels .

  • In mijn uitleg ging ik ervan uit dat u de openbare sleutel van de server had gevonden en dat u erop vertrouwt dat deze de juiste is. Maar u moet echt voorzichtig zijn met welke openbare sleutels u vertrouwen. Om een openbare sleutel te vertrouwen, moet deze digitaal worden ondertekend. Een ondertekende openbare sleutel wordt ook wel een certificaat genoemd.

Hopelijk lost dit de vragen op over een lang wachtwoord en openbare sleutels en heeft voldoende informatie om op een zinvollere manier dieper te graven.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *