known_hosts -filen lader klienten godkende serveren for at kontrollere, at den ikke opretter forbindelse til en efterligning. authorized_keys -filen lader serveren godkender brugeren.

Servergodkendelse

En af de første ting, der sker, når SSH-forbindelsen oprettes, er, at serveren sender sin offentlige nøgle til klienten og beviser (tak til kryptografi med offentlig nøgle ) til klienten, at den kender den tilknyttede private nøgle. Dette godkender serveren: hvis denne del af protokollen er vellykket, klienten ved, at serveren er den, som den hævder, at den er.

Klienten kontrollerer muligvis, at serveren er en kendt, og ikke en slags useriøs server forsøger at passere som den rigtige. SSH giver kun en enkel mekanisme til at verificere serverens legitimitet: den husker servere, som du allerede har oprettet forbindelse til, i ~/.ssh/known_hosts -filen på klientmaskinen (der er også et system -omfattende fil /etc/ssh/known_hosts). Første gang du opretter forbindelse til en server, skal du på anden måde kontrollere, at den offentlige nøgle, der præsenteres af serveren, virkelig er den offentlige nøgle på serveren du ville oprette forbindelse til. Hvis du har den offentlige nøgle på den server, du er ved at oprette forbindelse til, kan du tilføje den til ~/.ssh/known_hosts på klienten manuelt.

Af den måde kan known_hosts indeholde enhver form for offentlig nøgle, der understøttes af SSH-implementeringen, ikke kun DSA (også RSA og ECDSA).

Godkendelse af serveren skal udføres, før du sender fortrolige data til den. Især hvis brugergodkendelse involverer en adgangskode, skal adgangskoden ikke sendes til en ikke-godkendt server.

Brugergodkendelse

Serveren lader kun en fjernbruger logge ind, hvis den bruger kan bevise, at de har ret til at få adgang til den konto. Afhængigt af serverens konfiguration og brugerens valg kan brugeren muligvis præsentere en af flere former for legitimationsoplysninger (listen nedenfor er ikke udtømmende).

• Brugeren kan præsentere adgangskoden til den konto, som han prøver at logge på; serveren verificerer derefter, at adgangskoden er korrekt.
• Brugeren kan præsentere en offentlig nøgle og bevise, at han har den private nøgle, der er knyttet til den offentlige nøgle. Dette er nøjagtigt den samme metode, der bruges til at godkende serveren, men nu prøver brugeren at bevise sin identitet, og serveren verificerer den. Loginforsøget accepteres, hvis brugeren beviser, at han kender den private nøgle, og den offentlige nøgle er i kontoens autorisationsliste (~/.ssh/authorized_keys på serveren).
• En anden type metode involverer delegering af en del af arbejdet med at godkende brugeren til klientmaskinen. Dette sker i kontrollerede miljøer som virksomheder, når mange maskiner deler de samme konti. Serveren godkender klientmaskinen ved hjælp af den samme mekanisme, som brugt omvendt og stoler derefter på klienten til at godkende brugeren.

Kommentarer

• tak, dette er meget nyttigt. Ville det er rigtigt at sige, at known_hosts-filen opretholdes på klienten, mens den autoriserede_key-fil opretholdes på serveren
• @Ankit Ja, det er tilfældet.
• Jeg har begge filer på serveren og ssh til det for at teste det. Men de 2 filer har forskelligt indhold. Så nøglerne er forskellige i disse filer?
• @Timo Nøglerne er helt unr ophidset. Den ene er nøglen til en maskine, den anden er nøglen til en bruger.
• @Gilles Så når posten til en server ‘ s offentlige nøgle er tilføjet til kendte_hosts -filen i klienten ‘ s maskine, enhver efterfølgende ssh-session mellem de to gør ikke ‘ t kræve, at serveren skal bevise, at den har den rigtige private nøgle?

Disse to filer bruges begge af SSH men til helt andre formål, hvilket let kan forklare din forvirring.

Autoriserede nøgler

Som standard bruger SSH brugerkonti og adgangskoder, der administreres af værts-OS. (Nå, faktisk administreret af PAM , men denne skelnen er sandsynligvis ikke for nyttig her.) Hvad dette betyder er, at når du forsøger at oprette forbindelse til SSH med brugernavnet “bob” og noget kodeord, SSH-serverprogrammet spørger OS ” Jeg fik denne fyr ved navn “bob”, som fortæller mig, at hans adgangskode er “wonka”. Kan jeg lade ham komme ind? ” Hvis svaret er ja, giver SSH dig mulighed for at godkende, og du fortsætter din glade vej.

Ud over adgangskoder SSH vil også lade dig bruge det, der hedder kryptografi med offentlig nøgle til at identificere dig. Den specifikke krypteringsalgoritme kan variere, men er normalt RSA eller DSA , eller for nylig ECDSA . Under alle omstændigheder når du konfigurerer dine nøgler ved hjælp af ssh-keygen program opretter du to filer. En, der er din private nøgle, og en, der er din offentlige nøgle. Navnene er ret selvstændige -forklarende. Ved design kan den offentlige nøgle strøs omkring som mælkebøttefrø i vinden uden at gå på kompromis med dig. Den private nøgle skal altid opbevares i den strengeste tillid.

Så hvad du gør er at placere din offentlige indtast authorized_keys -filen. Når du derefter forsøger at oprette forbindelse til SSH med brugernavnet “bob” og din private nøgle vil det spørge OS ” Jeg fik dette fyrnavn “bob”, kan være her? ” Hvis svaret er ja, så vil SSH inspicere din private nøgle og kontrollere, om den offentlige nøgle i authorized_keys -filen er dens par. Hvis begge svar er ja, får du adgang.

Kendte værter

Meget ligesom hvordan authorized_keys -filen bruges til at godkende brugere known_hosts -filen bruges til at godkende servere. Når SSH er konfigureret på en ny server, genererer den altid en offentlig og privat nøgle til serveren, ligesom du gjorde for din bruger. Hver gang du opretter forbindelse til en SSH-server, viser den din offentlige nøgle sammen med et bevis på, at den har den tilsvarende private nøgle. Hvis du ikke har dens offentlige nøgle, så beder din computer om den og føjer den til known_hosts -filen. Hvis du har nøglen, og den matcher, opretter du straks forbindelse. Hvis tasterne ikke stemmer overens, får du en stor grim advarsel. Det er her ting bliver interessante. De 3 situationer, hvor der typisk forekommer en nøglefejltilpasning, er:

1. Nøglen ændret på serveren. Dette kan være fra geninstallation af OS eller på nogle operativsystemer genskabes nøglen, når SSH opdateres.
2. Værtsnavnet eller IP-adressen, du opretter forbindelse til bruges til at tilhøre en anden server. Dette kan være adressetildeling, DHCP eller noget lignende.
3. Ondsindet mand- midt-angreb sker. Dette er den største ting, som nøglekontrol forsøger at beskytte dig mod.

I begge tilfælde known_hosts og authorized_keys, SSH-programmet bruger kryptografi med offentlig nøgle for at identificere enten klienten eller serveren.

Kommentarer

• ” Hver gang du opretter forbindelse til en SSH-server, præsenterer den sin private nøgle for at bevise sin identitet. ” Jeg håber bestemt ikke! Jeg antager, at du mente dens offentlige nøgle . Hvis en server præsenterede mig, ville klienten med sin private nøgle – den (A) ville ikke ‘ ikke arbejde for mig at godkende den, og (B) er en indikation af, at serveren er sådan dårligt konfigureret, at jeg skulle stoppe med at handle med det med det samme. Private nøgler skal kun være tilgængelige på oprindelsesmaskinen af udpegede brugere. At ‘ er lidt pointen. 😉
• Dette svar hjalp mig mere end den accepterede (:
• Hvis jeg ssh til en lokal server (lokal IP) og derefter senere fra den samme computer, men nu eksternt oprette forbindelse til den samme server (offentlig IP) vil det udløse fejlparende nøgler? Hvordan kan du afbøde dette?

Om sikre filer, der indeholder offentlige nøgler

For at hjælpe dig med at forstå, hvordan “kendte_hosts” og “autoriserede_taster” er forskellige, her er nogle sammenhænge, der forklarer, hvordan disse filer passer ind i “ssh”. Dette er en overdreven forenkling der er meget flere muligheder og komplikationer ved “ssh”, end der er nævnt her.

Foreninger er i pålidelige kilder

Selvom det er blevet sagt, at offentlige nøgleværdier “sikkert kan strøes omkring som frø i vinden, skal du huske på, at det er Gardner, ikke frøbælgen, der beslutter, hvilke frø der etableres i haven. Selvom en offentlig nøgle ikke er hemmelig, kræves der hård beskyttelse for at bevare den pålidelige tilknytning af nøglen med den ting, som nøglen autentificerer. betroet at gøre denne tilknytning til at omfatte “kendte_hosts”, “autoriserede_taster” og “Certificate Authority” -fortegnelser.

De tillidskilder, der bruges af “ssh”

For at en offentlig nøgle relevant for “ssh”, skal nøglen registreres i forvejen og opbevares i den relevante sikre fil. (Denne generelle sandhed har en vigtig undtagelse, som vil blive diskuteret senere.) Serveren og klienten har hver deres, sikkert gemt liste over offentlige nøgler; et login vil kun lykkes, hvis hver side er registreret hos den anden.

• “kendt_hosts” er bosat på clien nt
• “autoriserede_taster” findes på serveren

Klientens sikre fil kaldes “kendte_hosts”, og serverens sikre fil kaldes “autoriserede_taster” . Disse filer er ens, idet hver af dem har tekst med en offentlig nøgle pr. Linje, men de har subtile forskelle i format og brug.

Nøglepar bruges til godkendelse

En offentlig -private nøglepar bruges til at udføre “asymmetrisk kryptografi.” Programmet “ssh” kan bruge asymmetrisk kryptografi til godkendelse, hvor en enhed skal besvare en udfordring for at bevise sin identitet. Udfordringen skabes ved at kode med en nøgle og besvares ved at afkode med den anden nøgle. (Bemærk, at asymmetrisk kryptogrofi kun bruges i loginfasen; derefter skifter “ssh” (TSL / SSL) til en anden form for kryptering for at håndtere datastrømmen.)

Et nøglepar til server, et andet for klient

I “ssh” er begge sider (klient og server) mistænkelige over for den anden; dette er en forbedring i forhold til forgængeren til “ssh”, som var “telnet”. Med “telnet” krævede klienten at angive en adgangskode, men serveren blev ikke undersøgt. Manglen på kontrol lod “man-i-midten” -angreb forekomme med katastrofale konsekvenser for sikkerheden. I “ssh” -processen afleverer klienten derimod ingen oplysninger, før serveren først svarer på en udfordring.

Trinene i “ssh” -godkendelse

Før deling af loginoplysninger, “ssh” -klienten fjerner først muligheden for et mand-i-midten-angreb ved at udfordre serveren til at bevise “Er du virkelig den, jeg tror du er?” For at gøre denne udfordring skal klienten kende den offentlige nøgle, der er knyttet til målserveren. Klienten skal finde serverens navn i filen “known_hosts”; den tilknyttede offentlige nøgle er på samme linje efter servernavnet. Forbindelsen mellem servernavn og offentlig nøgle skal holdes ukrænkelig, derfor tilladelser til “kendte_hosts” -filen skal være 600 – ingen andre kan skrive (eller læse).

Når serveren er godkendt, får den en chance for at udfordre klienten. Godkendelsen involverer en af de offentlige- nøgler fundet i “autoriserede_taster”. (Når ingen af disse nøgler virker, falder “sshd” -processen tilbage på godkendelse af adgangskodestil.)

Filformaterne

Så for ” ssh “, som med enhver loginproces, er der lister over” venner “, og kun dem på listen har lov til at forsøge at bestå en udfordring. For klienten er filen” known_hosts “en liste over venner, der kan fungere som servere (værter); disse er opført efter navn. For serveren er den tilsvarende liste over venner “autoriserede_taster” -filen, men der er ingen navne i den fil, da publi c-taster selv fungerer som identifikatorer. (Serveren er ligeglad med, hvor login kommer fra, men kun hvor det går. Klienten forsøger at få adgang til en bestemt konto, kontonavnet blev angivet som en parameter, da “ssh” blev påkaldt. Husk, at “autoriserede_taster” -filen er specifik for den konto, da filen er under den kontos hjemmekatalog.)

Selvom der er mange muligheder, der kan udtrykkes i en konfigurationsindgang, er den grundlæggende, mest almindelige brug har følgende parametre. Bemærk, at parametrene er adskilt af mellemrumstegn.

For “kendte_hosts”:

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

For “autoriserede_taster”:

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

Bemærk, at tokenet ssh-rsa angiver, at algoritmen, der bruges til kodning, er “rsa”. Andre gyldige algoritmer inkluderer “dsa” og “ecdsa”. Derfor kan et andet token erstatte ssh-rsa vist her.

Lad “ssh” Konfigurer automatisk “kendt_hosts” -indtastning

I begge tilfælde, hvis th e offentlig nøgle findes ikke i en sikker fil, så sker der ikke assymetrisk kryptering. Som nævnt tidligere er der en undtagelse fra denne regel.En bruger har tilladelse til bevidst at vælge at risikere muligheden for et menneske-i-midten-angreb ved at logge ind på en server, der ikke er angivet i brugerens “kendte_hosts” -fil. Programmet “ssh” advarer brugeren, men Hvis brugeren vælger at gå fremad, tillader “ssh” -klienten det “netop denne gang.” For at sikre, at det sker en gang, konfigurerer “ssh” -processen automatisk “known_hosts” -filen med de nødvendige oplysninger ved at bede serveren om offentlig nøgle og derefter skrive det til filen “known_hosts”. Denne undtagelse undergraver sikkerheden fuldstændigt ved at lade modstanderen give tilknytningen af et servernavn med en offentlig nøgle. Denne sikkerhedsrisiko er tilladt, fordi den gør tingene lettere for så mange mennesker. Naturligvis ville den korrekte og sikre metode have været for brugeren at manuelt indsætte en linje med servernavn og offentlig nøgle i filen “known_hosts”, før han nogensinde forsøgte at logge ind på serveren. (Men i lavrisikosituationer kan det ekstra arbejde være meningsløst.)

En-til-mange-forholdet

En post i klientens “kendte_hosts” -fil har navnet på en server og en offentlig nøgle, der gælder for servermaskinen. Serveren har en enkelt privat nøgle, der bruges til at besvare alle udfordringer, og klientens “kendte_hosts” -indgang skal have den matchende offentlige nøgle. Derfor vil alle klienter, der nogensinde har adgang til en bestemt server, have den samme offentlige nøgle post i deres “kendte_hosts” -fil. 1: N-forholdet er, at en server “s public-key kan vises i mange klient” s “kendte_hosts” -filer.

En post i “autoriserede_taster” -filen identificerer at en venlig klient har adgang til kontoen. Vennen bruger muligvis det samme offentlig-private nøglepar til at få adgang til flere forskellige servere. Dette gør det muligt for et enkelt nøglepar at godkende til alle servere, der nogensinde er kontaktet. Hver af de målrettede serverkonti ville have den samme indtastning af den offentlige nøgle i deres “autoriserede_nøgler” -filer. Forholdet 1: N er, at en klients offentlige nøgle kan vises i “autoriserede_nøgler” -filerne til flere konti på flere servere.

Nogle gange vil brugere, der arbejder fra flere klientmaskiner, replikere det samme nøglepar; typisk gøres dette, når en bruger arbejder på en bordplade og en lap-top. Fordi klientmaskinerne godkendes med identiske nøgler, vil de matche den samme post i serverens “autoriserede_taster”.

Placering af private nøgler

For serversiden er en systemproces , eller dæmon, håndterer alle indgående “ssh” -loginanmodninger. Dæmonen hedder “sshd”. Placeringen af den private nøgle afhænger af SSL-installationen, for eksempel sætter Apple den på /System/Library/OpenSSL, men efter installation af din egen version af OpenSSL vil placeringen være /opt/local/etc/openssl.

For klientsiden påkalder du “ssh” (eller “scp” ) når du har brug for det. Din kommandolinje vil omfatte forskellige parametre, hvoraf den ene eventuelt kan angive, hvilken privat nøgle der skal bruges. Som standard kaldes nøgleparet på klientsiden ofte $HOME/.ssh/id_rsa og $HOME/.ssh/id_rsa.pub.

Resumé

Bundlinjen er, at både “kendte_hosts” og “autoriserede_taster” indeholder offentlige nøgler, men …

• kendte_hosts – klienten kontrollerer, om værten er ægte
• autoriserede_taster – værten kontrollerer, om klientlogin er tilladt

Kommentarer

• SSH-klienter don normalt ikke ‘ t har nøgler. De offentlige nøgler, der er anført i authorized_keys, identificerer brugere, ikke maskiner.
• Tak. Dette er en meget klar og let forståelig forklaring på forholdet mellem filerne og nøglerne.

Overhovedet ikke sandt.

Den kendte_hosts-fil indeholder værtens fingeraftryk. Det er ikke den offentlige eller private nøgle til den eksterne vært.

Den genereres ud fra deres nøgle – men det er bestemt ikke selve nøglen.

Hvis du SFTP til en adresse, der kan løse til flere (varierende) værter (belastningsbalanceret osv.), skal du tilføje fingeraftryk fra alle mulige slutpunkter, ellers fungerer det oprindeligt og fejler derefter, når det dirigeres til den anden (eller efterfølgende) vært.

Kommentarer

• erm kig på din kendte_hosts-fil og sammenlign den med et værtsfingeraftryk, når du opretter forbindelse …. Det skulle rydde det op lidt. Desuden ville dit eksempel være nøjagtigt det samme, uanset om det er fingeraftryk eller offentlige nøgler i filen known_hosts.