Fișierul known_hosts permite clientului să autentifice serverul, pentru a verifica dacă nu se conectează la un imitator. Fișierul authorized_keys permite serverul autentifică utilizatorul.

Autentificarea serverului

Unul dintre primele lucruri care se întâmplă când se stabilește conexiunea SSH este faptul că serverul trimite cheia sa publică către client și dovedește (datorită criptografiei cu cheie publică ) clientului că știe cheia privată asociată. Aceasta autentifică serverul: dacă această parte a protocolului are succes, clientul știe că serverul este cine pretinde că este.

Clientul poate verifica dacă serverul este unul cunoscut și nu un server necinstit încercând să treacă drept cea potrivită. SSH oferă doar un mecanism simplu pentru a verifica legitimitatea serverului: își amintește serverele la care v-ați conectat deja, în fișierul ~/.ssh/known_hosts de pe computerul clientului (există și un sistem -wide file /etc/ssh/known_hosts). Prima dată când vă conectați la un server, trebuie să verificați prin alte mijloace că cheia publică prezentată de server este într-adevăr cheia publică a serverului ați vrut să vă conectați. Dacă aveți cheia publică a serverului la care sunteți pe punctul de a vă conecta, o puteți adăuga manual la ~/.ssh/known_hosts de pe client.

Apropo, known_hosts poate conține orice tip de cheie publică acceptată de implementarea SSH, nu doar DSA (și RSA și ECDSA).

Autentificarea serverul trebuie făcut înainte de a-i trimite orice date confidențiale. În special, dacă autentificarea utilizatorului implică o parolă, parola nu trebuie trimisă către un server neautentificat.

Autentificare utilizator

Serverul permite unui utilizator la distanță să se conecteze numai dacă acel utilizator pot dovedi că au dreptul de a accesa acel cont. În funcție de configurația serverului și de alegerea utilizatorului, utilizatorul poate prezenta una dintre mai multe forme de acreditare (lista de mai jos nu este exhaustivă).

• Utilizatorul poate prezenta parola pentru contul la care încearcă să se conecteze; serverul verifică apoi dacă parola este corectă.
• Utilizatorul poate prezenta o cheie publică și poate dovedi că deține cheia privată asociată cu acea cheie publică. Aceasta este exact aceeași metodă care este utilizată pentru autentificarea serverului, dar acum utilizatorul încearcă să-și demonstreze identitatea și serverul o verifică. Încercarea de conectare este acceptată dacă utilizatorul dovedește că cunoaște cheia privată și cheia publică se află în lista de autorizare a contului (~/.ssh/authorized_keys de pe server).
• Un alt tip de metodă implică delegarea unei părți a muncii de autentificare a utilizatorului către computerul client. Acest lucru se întâmplă în medii controlate, cum ar fi întreprinderile, atunci când mai multe mașini partajează aceleași conturi. folosit invers, apoi se bazează pe client pentru a autentifica utilizatorul.

Comentarii

• mulțumesc că este foarte util. este corect să spunem că fișierul cunoscut_hosts este păstrat pe client, în timp ce fișierul autorizat_cheie este păstrat pe server
• @Ankit Da, acesta este cazul.
• Am ambele fișiere pe server și ssh la el pentru a-l testa. Dar cele două fișiere au conținut diferit. Deci, cheile sunt diferite în aceste fișiere?
• @Timo Cheile sunt complet nerecuperabile entuziasmat. Una este cheia unei mașini, cealaltă este cheia unui utilizator.
• @Gilles Deci, odată adăugată intrarea pentru cheia publică a unui server ‘ la fișierul known_hosts din computerul ‘, orice sesiune ssh ulterioară între cele două nu ‘ t solicitați serverului să demonstreze că are cheia privată corectă?

Aceste două fișiere sunt utilizate ambele de SSH , dar în scopuri complet diferite, ceea ce ar putea explica cu ușurință confuzia dvs.

Chei autorizate

În mod implicit, SSH folosește conturi de utilizator și parole gestionate de sistemul de operare gazdă. (Ei bine, de fapt gestionat de PAM , dar această distincție probabil că nu este prea utilă aici.) Ce înseamnă asta când încerci să te conectezi la SSH cu numele de utilizator „bob” și o parolă pe care o va cere programul server SSH ” Am primit acest tip pe nume „bob” care îmi spune că parola lui este „wonka”. Îl pot lăsa să intre? ” Dacă răspunsul este da, atunci SSH vă permite să vă autentificați și mergeți pe drumul dvs. vesel.

În plus față de parolele SSH vă va permite, de asemenea, să utilizați ceea ce se numește criptografie cu cheie publică pentru a vă identifica. Algoritmul specific de criptare poate varia, dar este de obicei RSA sau DSA , sau mai recent ECDSA . În orice caz, când configurați cheile, utilizând ssh-keygen , creați două fișiere. Una care este cheia dvs. privată și una care este cheia dvs. publică. Numele sunt destul de auto -explicativ. Prin proiectare, cheia publică poate fi împrăștiată ca semințele de păpădie în vânt, fără a vă compromite. Cheia privată ar trebui păstrată întotdeauna în cea mai strictă încredere.

Deci, ceea ce faceți este să vă plasați publicul tastați fișierul authorized_keys. Apoi, când încercați să vă conectați la SSH cu numele de utilizator „bob” și cheia dvs. privată va solicita sistemul de operare ” Am acest nume de tip „bob”, poate fi aici? ” Dacă răspunsul este da, atunci SSH vă va inspecta cheia privată și va verifica dacă cheia publică din fișierul authorized_keys este perechea sa. Dacă ambele răspunsuri sunt da, atunci aveți permisiunea de a intra.

Gazde cunoscute

La fel ca modul în care fișierul authorized_keys este utilizat pentru autentificarea utilizatorilor fișierul known_hosts este utilizat pentru autentificarea serverelor. Ori de câte ori SSH este configurat pe un server nou, acesta generează întotdeauna o cheie publică și privată pentru server, la fel cum ați făcut-o pentru utilizatorul dvs. De fiecare dată când vă conectați la un server SSH, acesta vă arată cheia sa publică, împreună cu o dovadă că deține cheia privată corespunzătoare. Dacă nu aveți cheia sa publică, atunci computerul dvs. o va solicita și o va adăuga în fișierul known_hosts. Dacă aveți cheia și se potrivește, atunci vă conectați imediat. Dacă tastele nu se potrivesc, atunci veți primi un avertisment urât. Aici lucrurile devin interesante. Cele 3 situații în care se întâmplă de obicei o nepotrivire a cheii sunt:

1. Cheia a fost modificată pe server. Acest lucru ar putea proveni din reinstalarea sistemului de operare sau pe unele sisteme de operare, cheia se recreează la actualizarea SSH.
2. Numele de gazdă sau adresa IP pe care o conectați pentru a aparține unui alt server. Aceasta ar putea fi reatribuirea adresei, DHCP sau ceva similar.
3. man- rău intenționat se produce un atac în mijloc . Acesta este cel mai mare lucru de care verificarea cheilor încearcă să vă protejeze.

În ambele cazuri, known_hosts și authorized_keys, programul SSH folosește criptografie cu cheie publică pentru a identifica fie clientul, fie serverul.

Comentarii

• ” De fiecare dată când vă conectați la un server SSH, acesta prezintă cheia sa privată pentru a-și demonstra identitatea. ” Sper că nu! Presupun că v-ați referit la cheia sa publică . Dacă un server mi-ar fi prezentat, clientul, cu cheia sa privată – acesta (A) nu ar funcționa ‘ pentru a-l autentifica și (B) este o indicație că serverul este așa configurat greșit că ar trebui să nu mai fac afaceri cu el imediat. Cheile private ar trebui să fie accesibile doar pe mașina de origine de către utilizatorii desemnați. Asta este ‘ 😉
• Acest răspuns m-a ajutat mai mult decât cel acceptat (:
• Dacă trimit la un server local (IP local) și apoi mai târziu de pe același computer, dar acum de la distanță conectați-vă la același server (IP public) va declanșa chei de nepotrivire? Cum puteți atenua acest lucru?

Despre fișierele securizate care conțin chei publice

Pentru a vă ajuta să înțelegeți diferența dintre „cunoscut_hosts” și „autorizat_chei”, iată un context care explică modul în care aceste fișiere se încadrează în „ssh”. Aceasta este o simplificare excesivă ; există mult mai multe capabilități și complicații la „ssh” decât sunt menționate aici.

Asociațiile sunt în surse de încredere

Deși s-a spus că valorile cheii publice „pot fi împrăștiate în siguranță ca semințele în vânt”, rețineți că este gardner, nu semințele, care decide ce semințe se stabilesc în grădină. Deși o cheie publică nu este secretă, este necesară o protecție acerbă pentru a păstra asocierea de încredere a cheii cu ceea ce cheia autentifică. încredințat pentru a face această asociație include listele „cunoscut_hosts”, „autorizate_chei” și „Autoritatea de certificare”.

Sursele de încredere utilizate de „ssh”

Pentru ca o cheie publică să fie relevante pentru „ssh”, cheia trebuie înregistrată din timp și stocată în fișierul securizat corespunzător (acest adevăr general are o excepție importantă, care va fi discutată mai târziu). Serverul și clientul au fiecare propriile lor, stocate în siguranță. listă de chei publice; o autentificare va avea succes numai dacă fiecare parte este înregistrată cu cealaltă.

• „cunoscut_hosts” se află pe clie nt
• „autorizat_chei” se află pe server

Fișierul securizat al clientului se numește „cunoscut_hosts”, iar fișierul securizat al serverului este numit „autorizat_chei” . Aceste fișiere sunt similare prin faptul că fiecare are text cu o cheie publică pe linie, dar au diferențe subtile în format și utilizare.

Perechile de chei sunt utilizate pentru autentificare

Un public -perechea de chei private este utilizată pentru a efectua „criptografie asimetrică”. Programul „ssh” poate utiliza criptografia asimetrică pentru autentificare, în care o entitate trebuie să răspundă unei provocări pentru a-și dovedi identitatea. Provocarea este creată prin codificarea cu o cheie și se răspunde prin decodarea cu cealaltă cheie. (Rețineți că criptogrofia asimetrică este utilizată numai în timpul fazei de conectare; apoi „ssh” (TSL / SSL) trece la o altă formă de criptare pentru a gestiona fluxul de date.)

O pereche de chei pentru server, alta pentru Client

În „ssh”, ambele părți (client și server) sunt suspecte față de cealaltă; aceasta este o îmbunătățire față de predecesorul față de „ssh”, care era „telnet”. Cu „telnet”, clientul a fost obligat să furnizeze o parolă, dar serverul nu a fost verificat. Lipsa verificării a permis atacurilor „om-la-mijloc”, cu consecințe catastrofale asupra securității. În schimb, în procesul „ssh”, clientul nu cedează nicio informație până când serverul nu răspunde mai întâi la o provocare.

Pașii în autentificarea „ssh”

Înainte de a partaja orice informație de conectare, clientul „ssh” elimină mai întâi oportunitatea unui atac om-în-mijloc provocând serverul să demonstreze „Ești cu adevărat cine cred că ești?” Pentru a face această provocare, clientul trebuie să cunoască cheia publică care este asociată cu serverul țintă. Clientul trebuie să găsească numele serverului în fișierul „cunoscut_hosts”; cheia publică asociată se află pe aceeași linie, după numele serverului. Asocierea dintre numele serverului și cheia publică trebuie păstrată inviolată; prin urmare, permisiunile pentru fișierul „cunoscut_hosts” trebuie să fie 600 – nimeni altcineva nu poate scrie (și nici nu poate citi).

Odată ce serverul s-a autentificat, are șansa de a provoca clientul. Autentificarea va implica unul din public- chei găsite în „chei_autorizate”. (Când niciuna dintre aceste chei nu funcționează, procesul „sshd” revine la autentificarea stilului parolei.)

Formatele fișierelor

Deci pentru ” ssh „, ca și în cazul oricărui proces de autentificare, există liste de” prieteni „și numai cei de pe listă au voie să încerce să treacă o provocare. Pentru client, fișierul” cunoscut_hosts „este o listă de prieteni care pot acționa ca servere (gazde); acestea sunt listate după nume. Pentru server, lista echivalentă de prieteni este fișierul „chei autorizate”, dar nu există nume în acel fișier, deoarece tastele c în sine acționează ca identificatori. (Serverului nu-i pasă de unde provine datele de conectare, ci doar de unde merge. Clientul încearcă să acceseze un anumit cont, numele contului a fost specificat ca parametru când a fost invocat „ssh”. Amintiți-vă că Fișierul „autorizat_chei” este specific contului respectiv, deoarece fișierul se află în directorul de acasă al contului respectiv.)

Deși există multe funcții care pot fi exprimate într-o intrare de configurare, utilizarea de bază, cea mai obișnuită are următorii parametri. Rețineți că parametrii sunt separați de caractere spațiale.

Pentru „cunoscute_hosts”:

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

Pentru „chei_autorizate”:

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

Rețineți că simbolul ssh-rsa indică faptul că algoritmul utilizat pentru codificare este „rsa”. Alți algoritmi valabili includeți „dsa” și „ecdsa”. Prin urmare, un alt simbol ar putea lua locul ssh-rsa afișat aici.

Permiteți „ssh” Auto-Configure the Intrare „known_hosts”

În ambele cazuri, dacă th Cheia publică nu se găsește într-un fișier securizat, atunci criptarea asimetrică nu se întâmplă. După cum sa menționat anterior, există o excepție de la această regulă.Unui utilizator i se permite să aleagă în cunoștință de cauză riscul posibilității unui atac de tip „man-in-the-middle” conectându-se la un server care nu este listat în fișierul utilizatorului „s” known_hosts ”. Programul„ ssh ”avertizează utilizatorul, dar dacă utilizatorul alege să meargă înainte, clientul „ssh” îi permite „o singură dată.” Pentru a se asigura că se întâmplă o singură dată, procesul „ssh” configurează automat fișierul „cunoscut_hosts” cu informațiile solicitate cerând serverului public-key, apoi scriind-o în fișierul „known_hosts”. Această excepție subminează total securitatea, permițând adversarului să furnizeze asocierea unui nume de server cu o cheie publică. Acest risc de securitate este permis deoarece face lucrurile atât de mult mai ușor pentru atât de mulți oameni. Desigur, metoda corectă și sigură ar fi fost ca utilizatorul să introducă manual o linie cu numele serverului și cheia publică în fișierul „cunoscut_hosts” înainte de a încerca vreodată să se conecteze la server. pentru situații cu risc scăzut, munca suplimentară ar putea fi inutilă.)

Relațiile One-to-Many

O intrare în fișierul „s” cunoscut_hosts „al clientului are numele unui server și o cheie publică care este aplicabilă computerului server. Serverul are o singură cheie privată care este utilizată pentru a răspunde la toate provocările, iar intrarea clientului „cunoscute” gazde ”trebuie să aibă cheia publică potrivită. Prin urmare, toți clienții care accesează vreodată un anumit server vor avea cheia publică identică intrarea în fișierul lor „cunoscut_hosts”. Relația 1: N este că cheia publică a unui server poate apărea în mai multe fișiere ale clientului „cunoscut_hosts”.

O intrare în fișierul „autorizat_chei” identifică că un client prietenos are permisiunea de a accesa contul. Prietenul ar putea folosi aceeași pereche de chei public-private pentru a accesa mai multe servere diferite. Acest lucru permite unei singure perechi de chei să se autentifice pe toate serverele contactate vreodată. Fiecare dintre conturile de server vizate ar avea aceeași intrare de cheie publică în fișierele lor „autorizate_chei”. Relația 1: N este că cheia publică a unui client poate apărea în fișierele „autorizate_chei” pentru mai multe conturi de pe mai multe servere.

Uneori, utilizatorii care lucrează de pe mai multe mașini client vor reproduce aceeași pereche de chei; de obicei, acest lucru se face atunci când un utilizator lucrează pe un birou și un lap-top. Deoarece mașinile client se autentifică cu chei identice, acestea se vor potrivi cu aceeași intrare în „cheile autorizate” ale serverului.

Locația cheilor private

Pentru partea serverului, un proces de sistem , sau daemon, gestionează toate cererile de conectare „ssh” primite. Daemonul este denumit „sshd”. Locația cheii private depinde de instalarea SSL, de exemplu Apple o plasează la /System/Library/OpenSSL, dar după instalarea propriei versiuni de OpenSSL, locația va fi /opt/local/etc/openssl.

Pentru partea clientului, invocați „ssh” (sau „scp” ) când aveți nevoie. Linia de comandă va include diverși parametri, dintre care unul poate specifica opțional ce cheie privată să utilizați. În mod implicit, perechea de chei din partea clientului este adesea numită $HOME/.ssh/id_rsa și $HOME/.ssh/id_rsa.pub.

Rezumat

Concluzia este că atât „cunoscut_hosts”, cât și „autorizat_chei” conțin chei publice, dar …

• cunoscut_hosts – clientul verifică dacă gazda este autentică
• authorized_keys – gazda verifică dacă este permisă autentificarea clientului

Comentarii

• Clienții SSH de obicei nu nu au chei. Cheile publice listate în authorized_keys identifică utilizatorii, nu mașinile.
• Vă mulțumim. Aceasta este o explicație foarte clară și ușor de înțeles a relațiilor dintre fișiere și chei.

Deloc adevărat.

Fișierul known_hosts conține amprenta gazdei. Nu este cheia publică sau privată a gazdei la distanță.

Este generată din cheia lor – dar NU este cheia însăși.

Dacă SFTP la o adresă care s-ar putea rezolva la mai multe gazde (variabile) (încărcare echilibrată etc.) trebuie să adăugați amprentele digitale din toate punctele finale posibile, sau va funcționa inițial și apoi nu va reuși atunci când este direcționat către a doua gazdă (sau ulterioară).

Comentarii

• erm uită-te la fișierul known_hosts și compară-l cu o amprentă gazdă atunci când te conectezi … Asta ar trebui să o clarifice puțin. În plus, exemplul dvs. ar fi exact același, indiferent dacă este vorba de amprente digitale sau chei publice în fișierul known_hosts.