Met het known_hosts -bestand kan de client de server verifiëren om te controleren of deze geen verbinding maakt met een imitator. Met het authorized_keys -bestand de server authenticeert de gebruiker.

Serverauthenticatie

Een van de eerste dingen die gebeuren wanneer de SSH-verbinding tot stand wordt gebracht, is dat de server zijn publieke sleutel naar de client stuurt en bewijst (dankzij cryptografie met openbare sleutel ) aan de client dat deze de bijbehorende privésleutel kent. Hiermee wordt de server geverifieerd: als dit deel van het protocol succesvol is, client weet dat de server is wie hij beweert te zijn.

De client kan controleren of de server bekend is en niet een of andere malafide server proberen door te gaan als de juiste. SSH biedt slechts een eenvoudig mechanisme om de legitimiteit van de server te verifiëren: het onthoudt servers waarmee u “al verbinding hebt gemaakt” in het ~/.ssh/known_hosts -bestand op de clientcomputer (er is ook een systeem -wide bestand /etc/ssh/known_hosts). De eerste keer dat u verbinding maakt met een server, moet u op een andere manier controleren of de openbare sleutel die door de server wordt gepresenteerd, in werkelijkheid de openbare sleutel van de server is waarmee u verbinding wilde maken. Als u de openbare sleutel heeft van de server waarmee u verbinding wilt maken, kunt u deze handmatig toevoegen aan ~/.ssh/known_hosts op de client.

Overigens, known_hosts kan elk type openbare sleutel bevatten dat wordt ondersteund door de SSH-implementatie, niet alleen DSA (ook RSA en ECDSA).

Authenticatie van de server moet worden gedaan voordat u er vertrouwelijke gegevens naartoe stuurt. In het bijzonder als de gebruikersauthenticatie een wachtwoord omvat, mag het wachtwoord niet naar een niet-geverifieerde server worden gestuurd.

Gebruikersauthenticatie

De server laat een externe gebruiker alleen inloggen als die gebruiker kunnen bewijzen dat ze het recht hebben om toegang te krijgen tot dat account. Afhankelijk van de serverconfiguratie en de keuze van de gebruiker, kan de gebruiker een van de verschillende vormen van inloggegevens opgeven (de onderstaande lijst is niet volledig).

• De gebruiker kan het wachtwoord voor het account waarop hij probeert in te loggen; de server controleert vervolgens of het wachtwoord correct is.
• De gebruiker kan een openbare sleutel presenteren en bewijzen dat hij de privésleutel bezit die bij die openbare sleutel hoort. Dit is precies dezelfde methode die wordt gebruikt om de server te authenticeren, maar nu probeert de gebruiker zijn identiteit te bewijzen en verifieert de server deze. De inlogpoging wordt geaccepteerd als de gebruiker bewijst dat hij de privésleutel kent en dat de openbare sleutel in de autorisatielijst van de account staat (~/.ssh/authorized_keys op de server).
• Een ander type methode is het delegeren van een deel van het authenticatiewerk van de gebruiker naar de clientcomputer. Dit gebeurt in gecontroleerde omgevingen zoals ondernemingen, wanneer veel machines dezelfde accounts delen. De server verifieert de clientcomputer door hetzelfde mechanisme dat gebruikt andersom, vertrouwt vervolgens op de client om de gebruiker te authenticeren.

Opmerkingen

• bedankt, dit is erg nuttig. Zou het is juist om te zeggen dat het bestand bekende_hosts op de client wordt onderhouden, terwijl het bestand geautoriseerde_sleutel op de server wordt onderhouden
• @Ankit Ja, dat is het geval.
• Ik heb beide bestanden op de server en ssh ernaar om het te testen. Maar de 2 bestanden hebben een verschillende inhoud. Dus de sleutels zijn verschillend in deze bestanden?
• @Timo De sleutels zijn volledig niet opgetogen. De ene is de sleutel van een machine, de andere is de sleutel van een gebruiker.
• @Gilles Dus zodra de invoer voor een server ‘ s openbare sleutel is toegevoegd naar het bekende_hosts -bestand in de client ‘ s machine, elke volgende ssh-sessie tussen de twee niet ‘ t vereisen dat de server aantoont dat hij de juiste privésleutel heeft?

Deze twee bestanden worden beide gebruikt door SSH maar voor totaal andere doeleinden, wat gemakkelijk uw verwarring zou kunnen verklaren.

Geautoriseerde sleutels

Standaard gebruikt SSH gebruikersaccounts en wachtwoorden die worden beheerd door het host-besturingssysteem. (Nou, eigenlijk beheerd door PAM , maar dat onderscheid is hier waarschijnlijk niet erg handig.) Dit betekent dat wanneer je probeert verbinding te maken met SSH met de gebruikersnaam “bob” en een wachtwoord dat het SSH-serverprogramma zal vragen aan het besturingssysteem ” Ik heb een man genaamd “bob” die me vertelt dat zijn wachtwoord “wonka” is. Mag ik hem binnenlaten? ” Als het antwoord ja is, dan stelt SSH je in staat je te authenticeren en ga je op je vrolijke manier verder.

Naast wachtwoorden SSH laat je ook de zogenaamde cryptografie met openbare sleutel gebruiken om je te identificeren. Het specifieke versleutelingsalgoritme kan variëren, maar is meestal RSA of DSA , of recenter ECDSA . In elk geval wanneer u uw sleutels instelt, gebruikt u de ssh-keygen programma, maakt u twee bestanden. Een die uw privésleutel is en een die uw openbare sleutel is. De namen zijn redelijk zelf -explanatory. Door het ontwerp kan de public key als paardenbloemzaden in de wind worden uitgestrooid zonder u in gevaar te brengen. De private key moet altijd strikt vertrouwelijk worden gehouden.

Dus wat u doet, is uw publiek plaatsen toets het authorized_keys -bestand in. Wanneer u vervolgens probeert verbinding te maken met SSH met gebruikersnaam “bob” en je privésleutel zal het het besturingssysteem vragen ” Ik heb de naam van deze man “bob”, kan hier zijn? ” Als het antwoord is ja, dan zal SSH uw privésleutel inspecteren en verifiëren of de openbare sleutel in het authorized_keys -bestand het paar is. Als beide antwoorden ja zijn, mag u meedoen.

Bekende hosts

Net zoals het authorized_keys -bestand wordt gebruikt om gebruikers te authenticeren het known_hosts -bestand wordt gebruikt om servers te authenticeren. Telkens wanneer SSH op een nieuwe server is geconfigureerd, genereert het altijd een openbare en privésleutel voor de server, net zoals u deed voor uw gebruiker. Elke keer dat u verbinding maakt met een SSH-server, toont het u zijn openbare sleutel, samen met een bewijs dat het de bijbehorende privésleutel bezit. Als u de publieke sleutel niet heeft, zal uw computer ernaar vragen en deze toevoegen aan het known_hosts -bestand. Als je de sleutel hebt, en hij past, dan maak je meteen verbinding. Als de toetsen niet overeenkomen, krijg je een grote vervelende waarschuwing. Dit is waar dingen interessant worden. De 3 situaties waarin een sleutelmismatch meestal optreedt, zijn:

1. De sleutel is gewijzigd op de server. Dit kan komen door het opnieuw installeren van het OS of op sommige besturingssystemen wordt de sleutel opnieuw aangemaakt bij het updaten van SSH.
2. De hostnaam of het IP-adres waarmee je verbinding maakt om vroeger tot een andere server te behoren. Dit kan een nieuwe toewijzing van adressen zijn, DHCP of iets dergelijks.
3. Schadelijk man- in-the-middle-aanval vindt plaats. Dit is het belangrijkste waar sleutelcontrole u tegen probeert te beschermen.

In beide gevallen known_hosts en authorized_keys, gebruikt het SSH-programma cryptografie met openbare sleutels om de client of de server te identificeren.

Opmerkingen

• ” Elke keer dat u verbinding maakt met een SSH-server presenteert deze zijn privésleutel om zijn identiteit te bewijzen. ” Ik hoop het zeker van niet! Ik neem aan dat je zijn openbare sleutel bedoelde. Als een server mij presenteerde, zou de client, met zijn privésleutel – het (A) niet ‘ t voor mij werken om het te authenticeren en (B) is een indicatie dat de server zo is slecht geconfigureerd dat ik er onmiddellijk geen zaken meer mee moet doen. Privésleutels mogen alleen toegankelijk zijn op de machine van herkomst door aangewezen gebruikers. Dat ‘ is een beetje het punt. 😉
• Dit antwoord heeft me meer geholpen dan het geaccepteerde antwoord (:
• Als ik naar een lokale server (lokaal IP) ssh, en dan later vanaf dezelfde computer maar nu op afstand verbinding maken met dezelfde server (openbaar IP-adres) zal het niet-overeenkomende sleutels activeren? Hoe kunt u dit verminderen?

Over beveiligde bestanden die openbare sleutels bevatten

Om u te helpen begrijpen hoe “bekende_hosts” en “geautoriseerde_toetsen” verschillen, is hier wat context waarin wordt uitgelegd hoe die bestanden in “ssh” passen. Dit is een te eenvoudige vereenvoudiging Er zijn veel meer mogelijkheden en complicaties bij “ssh” dan hier vermeld.

Associaties zijn in vertrouwde bronnen

Hoewel er is gezegd dat waarden met openbare sleutels “veilig kunnen worden verspreid als zaden in de wind”, moet u er rekening mee houden dat dit de Gardner, niet de seed-pod, die beslist welke zaden zich in de tuin vestigen. Hoewel een public-key niet geheim is, is er krachtige bescherming nodig om de vertrouwde associatie van de sleutel met het ding dat de sleutel verifieert te behouden. die aan deze associatie zijn toevertrouwd, omvatten vermeldingen “bekende_hosts”, “geautoriseerde_sleutels” en “Certificaatautoriteit”.

De vertrouwde bronnen die worden gebruikt door “ssh”

Voor een openbare sleutel die moet worden relevant voor ssh, moet de sleutel van tevoren worden geregistreerd en worden opgeslagen in het juiste beveiligde bestand. (Deze algemene waarheid heeft één belangrijke uitzondering, die later zal worden besproken.) De server en client hebben elk hun eigen, veilig opgeslagen lijst met openbare sleutels; een login zal alleen slagen als elke kant bij de andere is geregistreerd.

• “bekende_hosts” bevindt zich op de client nt
• “geautoriseerde_sleutels” bevindt zich op de server

Het beveiligde bestand van de client heet “bekende_hosts”, en het beveiligde bestand van de server heet “geautoriseerde_toetsen” . Deze bestanden lijken op elkaar omdat ze allemaal tekst hebben met één openbare sleutel per regel, maar ze hebben subtiele verschillen in formaat en gebruik.

Sleutelparen worden gebruikt voor authenticatie

Een openbare -private sleutelparen worden gebruikt om “asymmetrische cryptografie” uit te voeren. Het “ssh” -programma kan asymmetrische cryptografie gebruiken voor authenticatie, waarbij een entiteit een uitdaging moet beantwoorden om zijn identiteit te bewijzen. De uitdaging wordt gecreëerd door te coderen met de ene sleutel en beantwoord door te decoderen met de andere sleutel. (Merk op dat asymmetrische cryptogrofie alleen wordt gebruikt tijdens de inlogfase; dan schakelt “ssh” (TSL / SSL) over naar een andere vorm van versleuteling om de gegevensstroom af te handelen.)

Een sleutelpaar voor server, een ander voor Client

In “ssh” zijn beide kanten (client en server) wantrouwend tegenover de ander; dit is een verbetering ten opzichte van de voorganger van “ssh”, dat “telnet” was. Met “telnet” moest de klant een wachtwoord opgeven, maar de server werd niet doorgelicht. Door het gebrek aan doorlichting konden “man-in-the-middle” -aanvallen plaatsvinden, met catastrofale gevolgen voor de veiligheid. In het “ssh” -proces daarentegen geeft de klant geen informatie over totdat de server eerst een uitdaging beantwoordt.

De stappen in “ssh” -authenticatie

Voordat u inloggegevens deelt, de “ssh” -client elimineert eerst de mogelijkheid voor een man-in-the-middle-aanval door de server uit te dagen om te bewijzen “Ben je echt wie ik denk dat je bent?” Om deze uitdaging aan te gaan, moet de client de openbare sleutel kennen die aan de doelserver is gekoppeld. De client moet de naam van de server vinden in het bestand “bekende_hosts”; de bijbehorende openbare sleutel staat op dezelfde regel, na de servernaam. De associatie tussen servernaam en openbare sleutel moet ongeschonden blijven; daarom zijn machtigingen voor het bestand “bekende_hosts” moet 600 zijn – niemand anders kan schrijven (of lezen).

Zodra de server zich heeft geauthenticeerd, krijgt hij de kans om de client uit te dagen. De authenticatie zal een van de sleutels gevonden in de “geautoriseerde_sleutels”. (Als geen van deze sleutels werkt, valt het “sshd” -proces terug op authenticatie in wachtwoordstijl.)

De bestandsindelingen

Dus voor ” ssh “, zoals bij elk inlogproces, zijn er lijsten met” vrienden “, en alleen degenen op de lijst mogen proberen een uitdaging aan te gaan. Voor de klant is het bestand” bekende_hosts “een lijst met vrienden die kunnen fungeren als servers (hosts); deze worden op naam vermeld. Voor de server is de equivalente lijst met vrienden het bestand “geautoriseerde_sleutels”; maar er zijn geen namen in dat bestand, aangezien de publicatie c-sleutels zelf fungeren als identifiers. (Het maakt de server niet uit waar de login vandaan komt, maar alleen waar het naartoe gaat. De client probeert toegang te krijgen tot een bepaald account, de accountnaam is gespecificeerd als een parameter toen ssh werd aangeroepen. Onthoud dat de “Authorized_keys” -bestand is specifiek voor dat account, aangezien het bestand zich onder de homedirectory van dat account bevindt.)

Hoewel er veel mogelijkheden zijn die kunnen worden uitgedrukt in een configuratie-item, is het basisgebruik heeft de volgende parameters. Houd er rekening mee dat parameters worden gescheiden door spaties.

Voor “bekende_hosts”:

{server-id} ssh-rsa {public-key-string} {comment} 

Voor “geautoriseerde_sleutels”:

ssh-rsa {public-key-string} {comment} 

Merk op dat het token ssh-rsa aangeeft dat het algoritme dat voor codering wordt gebruikt “rsa” is. Andere geldige algoritmen omvatten “dsa” en “ecdsa”. Daarom kan een ander token de plaats innemen van de ssh-rsa die hier wordt weergegeven.

Laat “ssh” de “bekende_hosts” Invoer

In beide gevallen, als th De openbare sleutel wordt niet gevonden in een beveiligd bestand, dan vindt er geen assymetrische codering plaats. Zoals eerder vermeld, is er één uitzondering op deze regel.Een gebruiker mag er bewust voor kiezen om de mogelijkheid van een man-in-the-middle-aanval te riskeren door in te loggen op een server die niet wordt vermeld in het bestand “bekende_hosts” van de gebruiker. Het programma “ssh” waarschuwt de gebruiker, maar als de gebruiker ervoor kiest om verder te gaan, staat de “ssh” -client het “slechts een keer” toe. Om er zeker van te zijn dat het maar één keer gebeurt, configureert het “ssh” -proces automatisch het “bekende_hosts” -bestand met de vereiste informatie door de server om de public-key, en die vervolgens in het bestand “bekende_hosts” schrijven. Deze uitzondering ondermijnt de beveiliging volledig door de tegenstander toe te staan de koppeling van een servernaam aan een openbare sleutel te geven. Dit beveiligingsrisico is toegestaan omdat het de dingen zo veel maakt gemakkelijker voor zoveel mensen. De juiste en veilige methode zou natuurlijk zijn geweest als de gebruiker handmatig een regel met servernaam en openbare sleutel in het bestand “bekende_hosts” invoerde voordat hij ooit probeerde in te loggen op de server. voor situaties met een laag risico kan het extra werk zinloos zijn.)

De één-op-veel relaties

Een invoer in het “bekende_hosts” -bestand van de client heeft de naam van een server en een publieke sleutel die van toepassing is op de servermachine. De server heeft een enkele privésleutel die wordt gebruikt om alle uitdagingen te beantwoorden, en de “bekende_hosts” -vermelding van de client moet de overeenkomende openbare sleutel hebben. Daarom zullen alle clients die ooit toegang hebben tot een bepaalde server dezelfde openbare sleutel hebben. vermelding in hun “bekende_hosts” -bestand. De 1: N-relatie is dat de openbare sleutel van een server kan voorkomen in veel “bekende_hosts” -bestanden van de client.

Een vermelding in het “geautoriseerde_toetsen” -bestand identificeert dat een vriendelijke klant toegang heeft tot het account. De vriend kan hetzelfde publiek-private sleutelpaar gebruiken om toegang te krijgen tot meerdere, verschillende servers. Hierdoor kan een enkel sleutelpaar worden geverifieerd bij alle servers die ooit contact hebben gehad. Elk van de beoogde serveraccounts zou dezelfde openbare sleutel hebben in hun “geautoriseerde_sleutels” -bestanden. De 1: N-relatie is dat de openbare sleutel van één cliënt kan verschijnen in de “geautoriseerde_toetsen” -bestanden voor meerdere accounts op meerdere servers.

Soms repliceren gebruikers die vanaf meerdere clientmachines werken hetzelfde sleutelpaar; Dit gebeurt meestal wanneer een gebruiker op een bureau en een laptop werkt. Omdat de clientmachines authenticeren met identieke sleutels, komen ze overeen met hetzelfde item in de server “s” geautoriseerde_sleutels.

Locatie van privésleutels

Voor de serverkant, een systeemproces , of daemon, behandelt alle inkomende “ssh” aanmeldingsverzoeken. De daemon heet “sshd”. De locatie van de privésleutel is afhankelijk van de SSL-installatie, Apple plaatst deze bijvoorbeeld op /System/Library/OpenSSL, maar na het installeren van uw eigen versie van OpenSSL, zal de locatie /opt/local/etc/openssl zijn.

Voor de clientzijde roept u “ssh” (of “scp” ) wanneer je het nodig hebt. Je opdrachtregel zal verschillende parameters bevatten, waarvan er een optioneel kan aangeven welke privésleutel moet worden gebruikt. Standaard wordt het sleutelpaar aan de clientzijde vaak $HOME/.ssh/id_rsa genoemd en $HOME/.ssh/id_rsa.pub.

Samenvatting

Waar het op neerkomt is dat zowel “bekende_hosts” als “geautoriseerde_sleutels” openbare sleutels bevatten, maar …

• bekende_hosts – de client controleert of de host echt is
• geautoriseerde_sleutels – de host controleert of het inloggen van de client is toegestaan.

Opmerkingen

• SSH-clients gebruiken meestal ‘ heeft geen sleutels. De openbare sleutels die worden vermeld in authorized_keys identificeren gebruikers, niet machines.
• Bedankt. Dit is een zeer duidelijke en gemakkelijk te begrijpen uitleg van de relaties tussen de bestanden en de sleutels.

Helemaal niet waar.

Het bestand bekende_hosts bevat de vingerafdruk van de host. Het is niet de openbare of privésleutel van de externe host.

Het wordt gegenereerd op basis van hun sleutel – maar het is nadrukkelijk NIET de sleutel zelf.

Als u via SFTP naar een adres kan worden opgelost naar verschillende (variërende) hosts (load-balanced enz.), moet u de vingerafdrukken van alle mogelijke eindpunten toevoegen, anders werkt het aanvankelijk en mislukt het wanneer het naar de tweede (of volgende) host wordt geleid.

Reacties

• euh kijk naar je bekende_hosts-bestand en vergelijk het met een host-vingerafdruk wanneer je verbinding maakt … Dat zou het een beetje moeten oplossen. Bovendien zou uw voorbeeld exact hetzelfde zijn, ongeacht of het vingerafdrukken of openbare sleutels in het bestand bekende_hosts zijn.