known_hosts -filen lar klienten autentisere serveren for å kontrollere at den ikke kobler til en etterligner. authorized_keys -filen lar serveren autentiserer brukeren.

Serverautentisering

En av de første tingene som skjer når SSH-forbindelsen opprettes, er at serveren sender sin offentlige nøkkel til klienten, og beviser (takk til kryptografi med offentlig nøkkel ) til klienten at den kjenner den tilknyttede private nøkkelen. Dette autentiserer serveren: hvis denne delen av protokollen er vellykket, klienten vet at serveren er den den påstår at den er.

Klienten kan sjekke at serveren er en kjent, og ikke noen useriøs server. prøver å passere som den rette. SSH gir bare en enkel mekanisme for å verifisere serverens legitimitet: den husker servere du allerede har koblet til, i ~/.ssh/known_hosts -filen på klientmaskinen (det er også et system -omfattende fil /etc/ssh/known_hosts). Første gang du kobler til en server, må du kontrollere på annen måte at den offentlige nøkkelen som serveren presenterer virkelig er den offentlige nøkkelen til serveren du ønsket å koble til. Hvis du har den offentlige nøkkelen til serveren du skal koble til, kan du legge den til ~/.ssh/known_hosts på klienten manuelt.

Forresten, known_hosts kan inneholde hvilken som helst type offentlig nøkkel som støttes av SSH-implementeringen, ikke bare DSA (også RSA og ECDSA).

Autentisering av serveren må gjøres før du sender konfidensielle data til den. Spesielt hvis brukerautentiseringen innebærer et passord, må passordet ikke sendes til en uautentisert server.

Brukerautentisering

Serveren lar bare en ekstern bruker logge på hvis den brukeren kan bevise at de har rett til å få tilgang til den kontoen. Avhengig av serverens konfigurasjon og brukerens valg, kan brukeren presentere en av flere former for legitimasjon (listen nedenfor er ikke uttømmende).

• Brukeren kan presentere passordet for kontoen han prøver å logge på; serveren verifiserer deretter at passordet er riktig.
• Brukeren kan presentere en offentlig nøkkel og bevise at han har den private nøkkelen som er knyttet til den offentlige nøkkelen. Dette er nøyaktig den samme metoden som brukes til å autentisere serveren, men nå prøver brukeren å bevise sin identitet, og serveren verifiserer den. Innloggingsforsøket aksepteres hvis brukeren beviser at han kjenner den private nøkkelen og den offentlige nøkkelen er i kontoens autorisasjonsliste (~/.ssh/authorized_keys på serveren).
• En annen type metode innebærer å delegere en del av arbeidet med å autentisere brukeren til klientmaskinen. Dette skjer i kontrollerte miljøer som bedrifter, når mange maskiner deler de samme kontoene. Serveren autentiserer klientmaskinen med den samme mekanismen som brukt omvendt, og stoler deretter på at klienten godkjenner brukeren.

Kommentarer

• takk for dette er veldig nyttig. Ville det er riktig å si at kjent_hosts-filen opprettholdes på klienten mens autorisert_nøkkelfilen opprettholdes på serveren
• @Ankit Ja, det er tilfelle.
• Jeg har begge filene på serveren og ssh til den for å teste den. Men de to filene har forskjellig innhold. Så tastene er forskjellige i disse filene?
• @Timo Tastene er helt unr glade. Den ene er nøkkelen til en maskin, den andre er nøkkelen til en bruker.
• @ Gilles Så når oppføringen for en server ‘ s offentlige nøkkel er lagt til til kjent_hosts -filen i klienten ‘ s maskin, betyr ikke enhver påfølgende ssh-økt mellom de to ‘ t krever serveren å bevise at den har riktig privat nøkkel?

Disse to filene brukes begge av SSH men for helt andre formål, noe som lett kan forklare forvirringen din.

Autoriserte nøkler

Som standard bruker SSH brukerkontoer og passord som administreres av verts-OS. (Vel, faktisk administrert av PAM , men det skillet er sannsynligvis ikke for nyttig her.) Hva dette betyr er at når du prøver å koble til SSH med brukernavnet. «bob» og noe passord SSH-serverprogrammet vil spørre OS » Jeg fikk denne fyren som heter «bob» som forteller meg at passordet hans er «wonka». Kan jeg la ham komme inn? » Hvis svaret er ja, så lar SSH deg autentisere, og du går videre på din glade vei.

I tillegg til passord SSH vil også la deg bruke det som heter kryptografi med offentlig nøkkel for å identifisere deg. Den spesifikke krypteringsalgoritmen kan variere, men er vanligvis RSA eller DSA , eller nylig ECDSA . Uansett når du setter opp tastene dine, bruker du ssh-keygen , du oppretter to filer. En som er din private nøkkel og en som er din offentlige nøkkel. Navnene er ganske selv -forklarende. Ved utforming kan den offentlige nøkkelen bli strødd rundt som løvetannfrø i vinden uten å gå på kompromiss med deg. Den private nøkkelen bør alltid oppbevares strengt fortrolig.

Så det du gjør er å plassere publikum tast inn authorized_keys -filen. Når du prøver å koble til SSH med brukernavnet «bob» og din private nøkkel, det vil spørre OS » Jeg har dette fyrnavnet «bob», kan være her? » Hvis svaret er ja da vil SSH inspisere den private nøkkelen din og verifisere om den offentlige nøkkelen i authorized_keys -filen er dens par. Hvis begge svarene er ja, får du lov til det.

Kjente verter

I likhet med hvordan authorized_keys -filen brukes til å autentisere brukere known_hosts -filen brukes til å autentisere servere. Når SSH er konfigurert på en ny server, genererer den alltid en offentlig og privat nøkkel for serveren, akkurat som du gjorde for brukeren din. Hver gang du kobler til en SSH-server, viser den deg den offentlige nøkkelen, sammen med et bevis på at den har den tilsvarende private nøkkelen. Hvis du ikke har den offentlige nøkkelen, vil datamaskinen din be om den og legge den til i known_hosts -filen. Hvis du har nøkkelen, og den stemmer overens, kobler du deg straks. Hvis nøklene ikke stemmer overens, får du en stor stygg advarsel. Det er her ting blir interessante. De tre situasjonene som en nøkkelforskjell vanligvis skjer, er:

1. Nøkkelen endret på serveren. Dette kan være fra å installere OS på nytt eller i noen OSer blir nøkkelen gjenskapt når du oppdaterer SSH.
2. Vertsnavnet eller IP-adressen du kobler til pleide å tilhøre en annen server. Dette kan være adressetilordning, DHCP , eller noe lignende.
3. Skadelig mann- midt i angrepet skjer. Dette er den største tingen som nøkkelkontroll prøver å beskytte deg mot.

I begge tilfeller known_hosts og authorized_keys, SSH-programmet bruker kryptografi med offentlig nøkkel for å identifisere klienten eller serveren.

Kommentarer

• » Hver gang du kobler til en SSH-server, presenterer den sin private nøkkel for å bevise identiteten. » Jeg håper absolutt ikke! Jeg antar at du mente den offentlige nøkkelen . Hvis en server presenterte meg, ville klienten med sin private nøkkel – den (A) ville ikke ‘ ikke jobbet for meg å autentisere den og (B) er en indikasjon på at serveren er slik dårlig konfigurert at jeg skulle slutte å gjøre forretninger med det med en gang. Private nøkler skal bare være tilgjengelige på opprinnelsesmaskinen av utpekte brukere. At ‘ er ganske poenget. 😉
• Dette svaret hjalp meg mer enn den aksepterte (:
• Hvis jeg ssh til en lokal server (lokal IP), og deretter senere fra samme datamaskin, men nå eksternt koble til samme server (offentlig IP) vil det utløse feilnøkler? Hvordan kan du dempe dette?

Om sikre filer som inneholder offentlige nøkler

For å hjelpe deg med å forstå hvordan «kjent_hosts» og «autoriserte_taster» er forskjellige, er det noen sammenheng som forklarer hvordan disse filene passer inn i «ssh». Dette er en forenkling , det er mange flere muligheter og komplikasjoner til «ssh» enn det som er nevnt her.

Foreninger er i pålitelige kilder

Selv om det er blitt sagt at offentlige nøkkelverdier «trygt kan strøs rundt som frø i vinden,» husk at det er Gardner, ikke seed-pod, som bestemmer hvilke frø som blir etablert i hagen. Selv om en offentlig nøkkel ikke er hemmelig, kreves det sterk beskyttelse for å bevare den pålitelige tilknytningen til nøkkelen med det som nøkkelen autentiserer. betrodd å gjøre at denne tilknytningen inkluderer «kjent_hosts», «autoriserte_nøkler» og «Certificate Authority» -lister.

De pålitelige kildene som brukes av «ssh»

For at en offentlig nøkkel skal være relevant for «ssh», må nøkkelen registreres på forhånd og lagres i riktig sikker fil. (Denne generelle sannheten har ett viktig unntak, som vil bli diskutert senere.) Serveren og klienten har hver sin, sikkert lagret liste over offentlige nøkler. En pålogging vil bare lykkes hvis hver side er registrert hos den andre.

• «kjent_hosts» ligger på clie nt
• «autoriserte_nøkler» ligger på serveren

Klientens sikre fil kalles «kjent_hosts», og serverens sikre fil kalles «autoriserte_nøkler» . Disse filene er like ved at hver har tekst med en offentlig nøkkel per linje, men de har subtile forskjeller i format og bruk.

Nøkkelpar brukes til autentisering

En offentlig -private nøkkelpar brukes til å utføre «asymmetrisk kryptografi.» Programmet «ssh» kan bruke asymmetrisk kryptografi for autentisering, der en enhet må svare på en utfordring for å bevise sin identitet. Utfordringen skapes ved å kode med en nøkkel, og besvares ved å dekode med den andre nøkkelen. (Merk at asymmetrisk kryptogrofi bare brukes i påloggingsfasen; deretter bytter «ssh» (TSL / SSL) til en annen form for kryptering for å håndtere datastrømmen.)

Ett nøkkelpar for server, et annet for klient

I «ssh» er begge sider (klient og server) mistenkelige for den andre; dette er en forbedring i forhold til forgjengeren til «ssh», som var «telnet». Med «telnet» måtte klienten oppgi et passord, men serveren ble ikke kontrollert. Mangelen på prøving tillot «mann-i-midten» -angrep å forekomme, med katastrofale konsekvenser for sikkerheten. Derimot, i «ssh» -prosessen, gir klienten ingen informasjon før serveren først svarer på en utfordring.

Fremgangsmåten i «ssh» Autentisering

Før du deler påloggingsinformasjon, «ssh» -klienten eliminerer først muligheten for et mann-i-midten-angrep ved å utfordre serveren til å bevise «Er du virkelig den jeg tror du er?» For å gjøre denne utfordringen, må klienten kjenne den offentlige nøkkelen som er tilknyttet målserveren. Klienten må finne serverens navn i «kjent_hosts» -filen. Den tilhørende offentlige nøkkelen er på samme linje etter servernavnet. Forbindelsen mellom servernavn og offentlig nøkkel må holdes ukrenkelig, derfor tillatelser på «kjent_hosts» -filen må være 600 – ingen andre kan skrive (eller lese).

Når serveren er autentisert, får den en sjanse til å utfordre klienten. Autentiseringen vil involvere en av de offentlige nøkler funnet i «autoriserte_taster». (Når ingen av disse nøklene fungerer, faller «sshd» -prosessen tilbake på godkjenning av passordstil.)

Filformatene

Så for » ssh «, som med alle påloggingsprosesser, er det lister over» venner «, og bare de på listen har lov til å prøve å passere en utfordring. For klienten er» kjent_hosts «-filen en liste over venner som kan fungere som servere (verter); disse er oppført etter navn. For serveren er den tilsvarende listen over venner «autoriserte_nøkler» -filen, men det er ingen navn i den filen siden publi c-tastene fungerer som identifikatorer. (Serveren bryr seg ikke hvor påloggingen kommer fra, men bare hvor den går. Klienten prøver å få tilgang til en bestemt konto. Kontonavnet ble spesifisert som en parameter da «ssh» ble påkalt. Husk at «autoriserte_taster» -filen er spesifikk for den kontoen, siden filen er under den kontoens hjemmekatalog.)

Selv om det er mange muligheter som kan uttrykkes i en konfigurasjonsoppføring, er den grunnleggende, vanligste bruken har følgende parametere. Vær oppmerksom på at parametere er skilt med mellomromstegn.

For «kjent_hosts»:

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

For «autoriserte_taster»:

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

Merk at tokenet ssh-rsa indikerer at algoritmen som brukes for koding er «rsa». Andre gyldige algoritmer inkluderer «dsa» og «ecdsa». Derfor kan et annet token ta plassen til ssh-rsa vist her.

La «ssh» Autokonfigurere «kjent_hosts» -oppføring

I begge tilfeller, hvis e offentlig nøkkel er ikke funnet i en sikker fil, da skjer ikke assymetrisk kryptering. Som nevnt tidligere er det ett unntak fra denne regelen.En bruker har lov til å bevisst velge å risikere muligheten for et mann-i-midten-angrep ved å logge på en server som ikke er oppført i brukerens «s» known_hosts «-fil. Programmet» ssh «advarer brukeren, men Hvis brukeren velger å gå videre, tillater «ssh» -klienten det «bare denne gangen.» For å sikre at det skjer bare en gang, konfigurerer «ssh» -prosessen automatisk «kjent_hosts» -filen med den nødvendige informasjonen ved å be serveren om offentlig nøkkel, og deretter skrive det inn i «kjent_hosts» -filen. Dette unntaket undergraver total sikkerhet ved å la motstanderen gi tilknytningen til et servernavn med en offentlig nøkkel. Denne sikkerhetsrisikoen er tillatt fordi det gjør ting så mye enklere for så mange mennesker. Selvfølgelig ville den riktige og sikre metoden ha vært for brukeren å manuelt sette inn en linje med servernavn og offentlig nøkkel i «kjent_hosts» -filen før han noen gang prøvde å logge på serveren. (Men for lavrisikosituasjoner kan ekstraarbeidet være meningsløst.)

En-til-mange-forholdet

En oppføring i klientens «kjente_hosts» -fil har navnet på en server og en offentlig nøkkel som er gjeldende for servermaskinen. Serveren har en enkelt privat nøkkel som brukes til å svare på alle utfordringer, og klientens «kjente_hosts» -oppføring må ha den tilhørende offentlige nøkkelen. Derfor vil alle klienter som noen gang får tilgang til en bestemt server ha den samme offentlige nøkkelen oppføring i «kjent_hosts» -filen. Forholdet 1: N er at en servers offentlige nøkkel kan vises i mange klientens «kjente_hosts» -filer.

En oppføring i filen «autoriserte nøkler» identifiserer at en vennlig klient har tilgang til kontoen. Vennen kan bruke det samme offentlig-private nøkkelparet for å få tilgang til flere forskjellige servere. Dette gjør at et enkelt nøkkelpar kan autentiseres til alle serverne som noen gang er kontaktet. Hver av de målrettede serverkontoer ville ha den samme offentlige nøkkeloppføringen i deres «autoriserte_nøkler» -filer. Forholdet 1: N er at en klients offentlige nøkkel kan vises i «autoriserte_nøkler» -filene for flere kontoer på flere servere.

Noen ganger kan brukere som jobber fra flere klientmaskiner replikere det samme nøkkelparet; Vanligvis gjøres dette når en bruker jobber på en bordplate og en lap-top. Fordi klientmaskinene autentiserer med identiske nøkler, vil de matche den samme oppføringen i serverens «s» autoriserte_taster «.

Plassering av private nøkler

For serversiden er en systemprosess , eller demon, håndterer alle innkommende «ssh» -innloggingsforespørsler. Demonen heter «sshd». Plasseringen til den private nøkkelen avhenger av SSL-installasjonen, for eksempel Apple setter den til /System/Library/OpenSSL, men etter at du har installert din egen versjon av OpenSSL, vil stedet være /opt/local/etc/openssl.

For klientsiden påkaller du «ssh» (eller «scp» ) når du trenger det. Kommandolinjen din vil inneholde forskjellige parametere, hvorav en eventuelt kan spesifisere hvilken privat nøkkel du skal bruke. Som standard kalles nøkkelparet på klientsiden ofte $HOME/.ssh/id_rsa og $HOME/.ssh/id_rsa.pub.

Sammendrag

Bunnlinjen er at både «kjente_hosts» og «autoriserte_taster» inneholder offentlige nøkler, men …

• kjent_hosts – klienten sjekker om verten er ekte
• autoriserte_taster – verten sjekker om klientinnlogging er tillatt

Kommentarer

• SSH-klienter don vanligvis ikke ‘ t har nøkler. De offentlige nøklene som er oppført i authorized_keys identifiserer brukere, ikke maskiner.
• Takk. Dette er en veldig tydelig og lett forståelig forklaring på forholdet mellom filene og nøklene.

Ikke sant i det hele tatt.

Den kjente_hosts-filen inneholder fingeravtrykket til verten. Det er ikke den offentlige eller private nøkkelen til den eksterne verten.

Den er generert fra nøkkelen deres – men den er ettertrykkelig IKKE selve nøkkelen.

Hvis du SFTP til en adresse som kan løse til flere (varierende) verter (belastningsbalansert osv.), må du legge til fingeravtrykk fra alle mulige sluttpunkter, ellers vil det fungere i utgangspunktet og deretter mislykkes når det blir dirigert til den andre (eller påfølgende) verten.

Kommentarer

• erm se på din kjente_hosts-fil og sammenlign den med et fingeravtrykk fra verten når du kobler til …. Det burde rydde opp litt. Videre vil eksemplet ditt være nøyaktig det samme, uansett om det er fingeravtrykk eller offentlige nøkler i filen kjent_hosts.