Filen known_hosts låter klienten autentisera servern för att kontrollera att den inte ansluter till en efterliknande. authorized_keys -filen låter servern verifierar användaren.

Serverautentisering

En av de första sakerna som händer när SSH-anslutningen upprättas är att servern skickar sin offentliga nyckel till klienten och bevisar (tack vare kryptografi med offentlig nyckel ) till klienten att den känner till den associerade privata nyckeln. Detta autentiserar servern: om den här delen av protokollet lyckas, klienten vet att servern är den som den hävdar att den är.

Klienten kan kontrollera att servern är känd och inte någon oseriös server försöker försvinna som den rätta. SSH tillhandahåller bara en enkel mekanism för att verifiera serverns legitimitet: den kommer ihåg servrar du redan har anslutit till, i ~/.ssh/known_hosts -filen på klientmaskinen (det finns också ett system -omfattande fil /etc/ssh/known_hosts). Första gången du ansluter till en server måste du på något annat sätt kontrollera att den offentliga nyckel som presenteras av servern verkligen är den offentliga nyckeln till servern du ville ansluta till. Om du har den offentliga nyckeln till servern som du ska ansluta till kan du lägga till den till ~/.ssh/known_hosts på klienten manuellt.

Förresten, known_hosts kan innehålla vilken typ av offentlig nyckel som stöds av SSH-implementeringen, inte bara DSA (även RSA och ECDSA).

Autentisering av server måste göras innan du skickar konfidentiell information till den. Om användarautentiseringen innebär ett lösenord får lösenordet i synnerhet inte skickas till en obehörig server.

Användarautentisering

Servern låter bara en fjärranvändare logga in om den användaren kan bevisa att de har rätt att få åtkomst till det kontot. Beroende på serverkonfigurationen och användarens val kan användaren presentera en av flera former av referenser (listan nedan är inte uttömmande).

• Användaren kan presentera lösenordet för kontot som han försöker logga in på; servern verifierar sedan att lösenordet är korrekt.
• Användaren kan presentera en offentlig nyckel och bevisa att han har den privata nyckel som är associerad med den offentliga nyckeln. Detta är exakt samma metod som används för att autentisera servern, men nu försöker användaren bevisa sin identitet och servern verifierar den. Inloggningsförsöket accepteras om användaren bevisar att han känner till den privata nyckeln och den offentliga nyckeln finns i kontots behörighetslista (~/.ssh/authorized_keys på servern).
• En annan typ av metod innebär att delegera en del av arbetet med att autentisera användaren till klientmaskinen. Detta händer i kontrollerade miljöer som företag, när många maskiner delar samma konton. Servern autentiserar klientmaskinen med samma mekanism som använt tvärtom och förlitar sig sedan på att klienten autentiserar användaren.

Kommentarer

• tack det här är mycket hjälpsamt. Skulle det är rätt att säga att känd_hosts-filen upprätthålls på klienten medan den auktoriserade_nyckelfilen bibehålls på servern
• @Ankit Ja, så är det.
• Jag har båda filerna på servern och ssh till det för att testa det. Men de två filerna har olika innehåll. Så tangenterna är olika i dessa filer?
• @Timo Nycklarna är helt ok upprymd. En är nyckeln till en maskin, den andra är användarens nyckel.
• @Gilles Så när posten för en server ’s offentliga nyckel har lagts till till kända_hosts -filen i klienten ’ s maskin, någon efterföljande ssh-session mellan de två ’ t kräva att servern bevisar att den har rätt privat nyckel?

Dessa två filer används båda av SSH men för helt andra ändamål, vilket lätt kan förklara din förvirring.

Auktoriserade nycklar

Som standard använder SSH användarkonton och lösenord som hanteras av värd-operativsystemet. (Tja, hanteras faktiskt av PAM men den skillnaden är förmodligen inte för användbar här.) Vad det här betyder är att när du försöker ansluta till SSH med användarnamnet ”bob” och något lösenord kommer SSH-serverprogrammet att fråga OS ” Jag fick den här killen som heter ”bob” som säger att hans lösenord är ”wonka”. Kan jag släppa in honom? ” Om svaret är ja, så låter SSH dig autentisera och du fortsätter din goda väg.

Förutom lösenord SSH låter dig också använda det som kallas kryptografi med offentlig nyckel för att identifiera dig. Den specifika krypteringsalgoritmen kan variera, men är vanligtvis RSA eller DSA , eller mer nyligen ECDSA . Under alla omständigheter när du ställer in dina nycklar med ssh-keygen skapar du två filer. En som är din privata nyckel och en som är din offentliga nyckel. Namnen är ganska själv -förklarande. Genom design kan den offentliga nyckeln ströas omkring som maskrosfrön i vinden utan att kompromissa med dig. Den privata nyckeln bör alltid förvaras i strikt förtroende.

Så vad du gör är att placera din offentliga skriv in authorized_keys -filen. När du sedan försöker ansluta till SSH med användarnamnet ”bob” och din privata nyckel kommer det att fråga OS ” Jag fick det här killen namnet ”bob”, kan vara här? ” Om svaret är ja då kommer SSH att inspektera din privata nyckel och verifiera om den offentliga nyckeln i authorized_keys -filen är dess par. Om båda svaren är ja, får du komma in.

Kända värdar

Precis som authorized_keys -filen används för att autentisera användare known_hosts -filen används för att autentisera servrar. När SSH är konfigurerad på en ny server genererar den alltid en offentlig och privat nyckel för servern, precis som du gjorde för din användare. Varje gång du ansluter till en SSH-server visar den din offentliga nyckel, tillsammans med ett bevis på att den har motsvarande privata nyckel. Om du inte har sin offentliga nyckel kommer din dator att be om den och lägga till den i known_hosts -filen. Om du har nyckeln och den matchar, ansluter du genast. Om nycklarna inte matchar får du en stor otäck varning. Det är här saker blir intressanta. De tre situationer som en nyckelöverensstämmelse vanligtvis inträffar är:

1. Nyckeln som ändrats på servern. Detta kan vara från att installera om OS eller på vissa operativsystem återskapas nyckeln när du uppdaterar SSH.
2. Värdnamnet eller IP-adressen du ansluter brukade tillhöra en annan server. Detta kan vara adressfördelning, DHCP , eller något liknande.
3. Skadligt man- in-the-middle attack händer. Detta är den största sak som nyckelkontroll försöker skydda dig från.

I båda fallen known_hosts och authorized_keys, SSH-programmet använder kryptografi med offentlig nyckel för att identifiera antingen klienten eller servern.

Kommentarer

• ” Varje gång du ansluter till en SSH-server presenterar den sin privata nyckel för att bevisa sin identitet. ” Jag hoppas verkligen inte! Jag antar att du menade dess offentliga nyckel . Om en server presenterade mig skulle klienten, med sin privata nyckel – den (A) inte ’ t fungera för mig att autentisera den och (B) är en indikation på att servern är så dåligt konfigurerad att jag ska sluta göra affärer med det omedelbart. Privata nycklar bör endast vara åtkomliga på ursprungsmaskinen av utsedda användare. Att ’ är ganska poängen. 😉
• Det här svaret hjälpte mig mer än det accepterade (:
• Om jag ssh till en lokal server (lokal IP), och sedan senare från samma dator men nu på distans ansluta till samma server (offentlig IP) kommer det att utlösa matchande nycklar? Hur kan du mildra detta?

Om säkra filer som innehåller offentliga nycklar

För att hjälpa dig att förstå hur ”kända_hostar” och ”auktoriserade_tangenter” är olika, här är ett sammanhang som förklarar hur dessa filer passar in i ”ssh”. Detta är en överförenkling , det finns mycket mer funktioner och komplikationer för ”ssh” än vad som nämns här.

Föreningar finns i betrodda källor

Även om det har sagts att offentliga nyckelvärden ”säkert kan ströas omkring som frön i vinden,” kom ihåg att det är Gardner, inte utsäde, som bestämmer vilka frön som etableras i trädgården. Även om en offentlig nyckel inte är hemlig krävs ett hårt skydd för att bevara den betrodda kopplingen mellan nyckeln och det som nyckeln autentiserar. anförtrotts att göra denna koppling till listor med ”kända_hostar”, ”auktoriserade_knappar” och ”Certifikatutfärdare”.

De betrodda källorna som används av ”ssh”

För att en offentlig nyckel ska relevant för ”ssh”, måste nyckeln registreras i förväg och lagras i lämplig säker fil. (Denna allmänna sanning har ett viktigt undantag, som kommer att diskuteras senare.) Servern och klienten har var och en sin egen, säkert lagrad lista över offentliga nycklar; en inloggning lyckas bara om varje sida är registrerad hos den andra.

• ”kända_hostar” finns på clien nt
• ”auktoriserade_knappar” finns på servern

Klientens säkra fil heter ”kända_hostar” och serverns säkra fil kallas ”auktoriserade_knappar” . Dessa filer liknar varandra eftersom de har text med en offentlig nyckel per rad, men de har subtila skillnader i format och användning.

Nyckelpar används för autentisering

En allmänhet -privat nyckelpar används för att utföra ”asymmetrisk kryptografi.” Programmet ”ssh” kan använda asymmetrisk kryptografi för autentisering, där en enhet måste svara på en utmaning för att bevisa sin identitet. Utmaningen skapas genom kodning med en nyckel och besvaras genom avkodning med den andra nyckeln. (Observera att asymmetrisk kryptogrofi endast används under inloggningsfasen; sedan växlar ”ssh” (TSL / SSL) till en annan form av kryptering för att hantera dataströmmen.)

Ett nyckelpar för server, ett annat för klient

I ”ssh” är båda sidor (klient och server) misstänksamma mot den andra; detta är en förbättring jämfört med föregångaren till ”ssh”, som var ”telnet”. Med ”telnet” krävdes klienten att ange ett lösenord, men servern kontrollerades inte. Bristen på granskning möjliggjorde ”man-i-mitten” -attacker med katastrofala konsekvenser för säkerheten. Däremot lämnar klienten i ”ssh” -processen ingen information förrän servern först svarar på en utmaning.

Stegen i ”ssh” Autentisering

Innan du delar någon inloggningsinformation, ”ssh” -klienten eliminerar först möjligheten för en man-i-mitten-attack genom att utmana servern för att bevisa ”Är du verkligen den jag tror att du är?” För att göra denna utmaning måste klienten känna till den offentliga nyckeln som är associerad med målservern. Klienten måste hitta serverns namn i ”kända_hosts” -filen; den associerade public-nyckeln är på samma rad efter servernamnet. Föreningen mellan server-name och public-key måste hållas okränkt, därför behörigheter på filen ”kända_hostar” måste vara 600 – ingen annan kan skriva (eller läsa).

När servern har autentiserats får den en chans att utmana klienten. Autentiseringen kommer att involvera en av nycklar som finns i ”auktoriserade_knappar”. (När ingen av dessa nycklar fungerar faller ”sshd” -processen tillbaka på autentisering av lösenordsstil.)

Filformaten

Så för ” ssh ”, som med alla inloggningsprocesser, finns det listor med” vänner ”, och endast de på listan får försöka klara en utmaning. För klienten är filen” kända_hostar ”en lista över vänner som kan fungera som servrar (värdar); dessa listas efter namn. För servern är motsvarande vänlista ”auktoriserade_nycklar” -filen, men det finns inga namn i den filen, eftersom publi c-tangenterna själva fungerar som identifierare. (Servern bryr sig inte var inloggningen kommer ifrån, men bara vart den går. Klienten försöker komma åt ett visst konto, kontonamnet specificerades som en parameter när ”ssh” anropades. Kom ihåg att ”Author_keys” -filen är specifik för det kontot, eftersom filen finns under det kontots hemkatalog.)

Även om det finns många funktioner som kan uttryckas i en konfigurationspost, är den vanligaste, vanligaste användningen har följande parametrar. Observera att parametrar är åtskilda av mellanslagstecken.

För ”kända_hostar”:

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

För ”auktoriserade_knappar”:

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

Observera att token ssh-rsa indikerar att algoritmen som används för kodning är ”rsa”. Andra giltiga algoritmer inkludera ”dsa” och ”ecdsa”. Därför kan en annan token ta platsen för ssh-rsa som visas här.

Låt ”ssh” Konfigurera automatiskt ”kända_hostar” -post

I båda fallen, om th En offentlig nyckel finns inte i en säker fil, då sker inte assymetrisk kryptering. Som nämnts tidigare finns det ett undantag från denna regel.En användare får medvetet välja att riskera risken för en man-i-mitten-attack genom att logga in på en server som inte är listad i användarens ”s” kända_hosts-fil. Programmet ”ssh” varnar användaren, men om användaren väljer att gå framåt tillåter ”ssh” -klienten det ”bara den här gången.” För att säkerställa att det händer bara en gång konfigurerar ”ssh” -processen automatiskt ”kända_hosts” -filen med den information som krävs genom att be servern om public-key och sedan skriva in den i ”kända_hosts” -filen. Detta undantag undergräver fullständigt säkerheten genom att låta motståndaren tillhandahålla associering av ett servernamn med en public-key. Denna säkerhetsrisk är tillåten eftersom det gör saker så mycket lättare för så många människor. Naturligtvis skulle den korrekta och säkra metoden ha varit för användaren att manuellt infoga en rad med servernamn och public-nyckel i filen ”kända_hostar” innan han någonsin försökte logga in på servern. (Men i situationer med låg risk kan extraarbetet vara meningslöst.)

Relationerna en-till-många

En post i klientens ”kända_hosts” -fil har namnet på en server och en offentlig nyckel som är tillämplig på servermaskinen. Servern har en enda privat nyckel som används för att svara på alla utmaningar, och klientens ”kända_hosts” -post måste ha matchande public-nyckel. Därför kommer alla klienter som någonsin kommer åt en viss server att ha samma publika nyckel post i deras ”kända_hosts” -fil. Förhållandet 1: N är att en serverns offentliga nyckel kan visas i många klienters kända_hosts-filer.

En post i filen ”auktoriserade_nycklar” identifierar att en vänlig klient får åtkomst till kontot. Vännen kan använda samma offentlig-privata nyckelpar för att få åtkomst till flera olika servrar. Detta gör att ett enda nyckelpar kan autentisera för alla servrar som någonsin har kontaktats. Var och en av de riktade serverkontona skulle ha samma public-key-post i sina ”auktoriserade_nycklar” -filer. Relationen 1: N är att en kunds offentliga nyckel kan visas i ”auktoriserade_nycklar” -filerna för flera konton på flera servrar.

Ibland kommer användare som arbetar från flera klientmaskiner att replikera samma nyckelpar; Detta görs vanligtvis när en användare arbetar på en bordsskiva och en knäskiva. Eftersom klientmaskinerna autentiserar med identiska nycklar, kommer de att matcha samma post i serverns ”s” autoriserade_nycklar ”.

Plats för privata nycklar

För serversidan är en systemprocess , eller daemon, hanterar alla inkommande ”ssh” -inloggningsförfrågningar. Demonen heter ”sshd”. Platsen för den privata nyckeln beror på SSL-installationen, till exempel sätter Apple den till /System/Library/OpenSSL, men efter installation av din egen version av OpenSSL kommer platsen att vara /opt/local/etc/openssl.

För klientsidan åberopar du ”ssh” (eller ”scp” ) när du behöver det. Din kommandorad kommer att innehålla olika parametrar, varav en eventuellt kan ange vilken privat nyckel som ska användas. Som standard kallas klientsidans nyckelpar ofta $HOME/.ssh/id_rsa och $HOME/.ssh/id_rsa.pub.

Sammanfattning

Nedre raden är att både ”kända_värdar” och ”auktoriserade_tangenter” innehåller offentliga nycklar, men …

• kända_hostar – klienten kontrollerar om värden är äkta
• auktoriserade_tangenter – värden kontrollerar om klientinloggning är tillåten

Kommentarer

• SSH-klienter brukar inte ’ t har nycklar. De offentliga nycklarna som listas i authorized_keys identifierar användare, inte maskiner.
• Tack. Detta är en mycket tydlig och lättförståelig förklaring av förhållandet mellan filerna och nycklarna.

Inte alls.

Den kända_hosts-filen innehåller värdens fingeravtryck. Det är inte den offentliga eller privata nyckeln till fjärrvärden.

Den genereras från deras nyckel – men den är eftertryckligen INTE själva nyckeln.

Om du SFTP till en adress som kan lösa sig till flera (varierande) värdar (belastningsbalanserad osv.) måste du lägga till fingeravtryck från alla möjliga slutpunkter, annars fungerar det initialt och misslyckas sedan när det dirigeras till den andra (eller efterföljande) värden.

Kommentarer

• erm titta på din kända_hostsfil och jämför den med ett värdfingeravtryck när du ansluter …. Det borde rensa upp det lite. Dessutom skulle ditt exempel vara exakt detsamma, oavsett om det är fingeravtryck eller offentliga nycklar i filen känd_hosts.