Am extins virtuțile SSH de nenumărate ori, atât pentru securitate, cât și pentru accesul la distanță. Să aruncăm o privire asupra serverului în sine, a unor aspecte importante de "întreținere" și a unor ciudățenii care pot adăuga turbulențe unei călătorii fără probleme.
În timp ce am scris acest ghid cu Linux în minte, acest lucru se poate aplica și pentru OpenSSH în Mac OS X și Windows 7 prin Cygwin.
Am menționat de mai multe ori cum SSH este o modalitate excelentă de a conecta în siguranță și de a tunona date de la un punct la altul. Să aruncăm o scurtă privire asupra modului în care lucrurile funcționează, astfel încât să aveți o idee mai bună de ce lucrurile pot deveni uneori ciudate.
Când ne hotărâm să inițiem o conexiune cu alt computer, folosim adesea protocoale ușor de utilizat. Telnet și FTP vin în minte. Trimiteți informații către un server de la distanță și apoi primim confirmări în legătură cu conexiunea noastră. Pentru a stabili un anumit tip de siguranță, aceste protocoale folosesc adesea combinații de nume de utilizator și parole. Asta înseamnă că sunt complet siguri, nu? Gresit!
Dacă ne gândim la procesul nostru de conectare ca și poștă, atunci folosirea FTP și Telnet și altele asemănătoare nu este ca utilizarea plicurilor de corespondență standard. Este mai mult să folosiți cărți poștale. Dacă se întâmplă să se întâmple cineva în mijloc, aceștia pot vedea toate informațiile, inclusiv adresele celor doi corespondenți și numele de utilizator și parola trimise. Ei pot schimba apoi mesajul, păstrând aceleași informații și impersonalizează un corespondent sau altul. Acest lucru este cunoscut sub numele de atac "om-in-mijloc", și nu numai că compromite contul dvs., dar pune sub semnul întrebării fiecare mesaj trimis și fișierul primit. Nu poți fi sigură dacă vorbești cu expeditorul sau nu și chiar dacă ești, nu poți fi sigur că nimeni nu se uită la tot ce se întâmplă între ele.
Acum, să ne uităm la criptarea SSL, care face ca HTTP să fie mai sigur. Aici avem un oficiu poștal care se ocupă de corespondență, care verifică dacă destinatarul este persoana pe care o susține că este și are legi care protejează corespondența dvs. de la a fi examinată. Este mai sigur în ansamblu, iar autoritatea centrală - Verisign este una, pentru exemplul nostru HTTPS - asigură că persoana pe care trimiteți e-mailuri este verificată. Ei fac acest lucru prin faptul că nu permit cărți poștale (acreditări necriptate); în schimb, mandatează plicuri reale.
În cele din urmă, să ne uităm la SSH. Aici, configurația este puțin diferită. Nu avem aici un autentificator central, dar lucrurile sunt încă sigure. Asta pentru că trimiteți scrisori unei persoane a cărei adresă deja o cunoașteți - să zicem, vorbind cu ei la telefon - și folosiți niște matematică cu adevărat fantezie pentru a vă înscrie plicul. Îi dai fratelui tău, prietenei, tatei sau fiicei tale să o primească la adresă și numai dacă meciurile matematice ale destinatarului presupun că adresa este ceea ce ar trebui să fie. Apoi, veți primi o scrisoare înapoi, de asemenea protejată de ochii curioși de acest minunat matematică. În cele din urmă, vă trimiteți acreditările într-un alt plic curajos algoritmic către destinație. Dacă matematica nu se potrivește, putem presupune că destinatarul inițial sa mutat și trebuie să-i confirmăm din nou adresa.
Cu explicația atâta timp cât este, credem că o vom tăia acolo. Dacă aveți mai multe informații, nu ezitați să discutați în comentarii, desigur. Deocamdată, însă, să examinăm cea mai relevantă caracteristică a SSH, autentificarea gazdei.
Gestiunea gazdă este, în esență, partea în care cineva în care aveți încredere duce plicul (sigilat cu matematică magică) și confirmă adresa destinatarului. Este o descriere destul de detaliată a adresei și se bazează pe câteva matematici complicate pe care le vom trece imediat. Există câteva lucruri importante pe care trebuie să le îndepărtați:
Deoarece cheia gazdă este utilizată înainte de autentificare pentru a stabili identitatea serverului SSH, trebuie să verificați cheia înainte de a vă conecta. Veți vedea un dialog de confirmare ca mai jos.
Nu trebuie să vă faceți griji, totuși! Adesea, atunci când securitatea este o preocupare, va exista un loc special pe care cheia gazdă (amprenta ECDSA de mai sus) poate fi confirmată. Într-o afacere în întregime on-line, adesea va fi pe un site securizat numai pentru conectare. S-ar putea să trebuiască (sau să alegeți să!) Telefonul departamentului IT pentru a confirma această tastă pe telefon. Am auzit chiar și despre unele locuri unde cheia este pe insigna dvs. de lucru sau pe lista specială "Numere de urgență". Și dacă aveți acces fizic la mașina țintă, puteți verifica și dvs.!
Există 4 tipuri de algoritmi de criptare folosiți pentru a face chei, dar implicit pentru OpenSSH de la începutul acestui an este ECDSA (cu unele motive întemeiate). Ne vom concentra pe asta astăzi. Iată comanda pe care o puteți rula pe serverul SSH la care aveți acces:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Rezultatul dvs. ar trebui să returneze așa ceva:
256 ca: 62: ea: 7c: e4: 9e: 2e: a6: 94: 20: 11: db: 9c: 78: c3: 4c /etc/ssh/ssh_host_ecdsa_key.pub
Primul număr este lungimea de biți a cheii, apoi este cheia în sine și, în final, aveți fișierul în care este stocată. Comparați partea intermediară cu ceea ce vedeți când vi se solicită să vă conectați de la distanță.Ar trebui să se potrivească și sunteți toți pregătiți. Dacă nu, atunci se poate întâmpla ceva altceva.
Puteți vizualiza toate host-urile la care v-ați conectat prin SSH, analizând fișierul dvs. known_hosts. Acesta este situat, de obicei, la:
~ / .Ssh / known_hosts
Puteți să o deschideți în orice editor de text. Dacă te uiți, încercați să acordați atenție modului în care sunt stocate cheile. Sunt stocate cu numele computerului (sau adresa web) și cu adresa IP a acestuia.
Există câteva motive pentru care cheile gazdă se modifică sau nu se potrivesc cu ceea ce este înregistrat în fișierul dvs. known_hosts.
Cel mai probabil, problema este una dintre primele trei și puteți ignora schimbarea. În cazul în care leasingul IP / DNS sa schimbat, este posibil să existe o problemă cu serverul și este posibil să fiți direcționat către o altă mașină. Dacă nu sunteți sigur care este motivul schimbării, ar trebui probabil să presupuneți că este ultima din listă.
OpenSSH are o setare pentru modul în care se ocupă gazde necunoscute, reflectate în variabila "StrictHostKeyChecking" (fără ghilimele).
În funcție de configurație, conexiunile SSH cu gazde necunoscute (ale căror chei nu se află deja în fișierul dvs. known_hosts) pot merge în trei moduri.
Puteți modifica cu ușurință această variabilă pe linia de comandă utilizând următoarea paradigmă:
ssh -o 'StrictHostKeyChecking [opțiune]' user @ host
Înlocuiți [opțiunea] cu "nu", "întrebați" sau "da". Aveți în vedere faptul că există citate unice în jurul acestei variabile și setarea acesteia. De asemenea, înlocuiți user @ host cu numele de utilizator și numele de gazdă al serverului la care vă conectați. De exemplu:
ssh -o 'StrictHostKeyChecking întrebați' [email protected]
Dacă aveți un server pe care încercați să-l accesați, dacă cheia sa schimbat deja, configurația implicită OpenSSH vă va împiedica să îl accesați. Ai putea schimba valoarea StrictHostKeyChecking pentru acea gazdă, dar asta nu ar fi în întregime, bine, paranoic sigur, nu-i așa? În schimb, putem elimina valoarea de ofensator din fișierul nostru known_hosts.
Este cu siguranță un lucru urât pe ecran. Din fericire, motivul nostru pentru acest lucru a fost un OS reinstalat. Deci, să mărim linia de care avem nevoie.
Vom merge acolo. Vedeți cum citează fișierul pe care trebuie să îl editați? Chiar ne dă numărul liniei! Deci, hai să deschidem dosarul în Nano:
Iată cheia de ofensator, în linia 1. Tot ce trebuie să faceți este să apăsați pe Ctrl + K pentru a decupa întreaga linie.
Asta-i mult mai bine! Deci, acum apăsăm Ctrl + O pentru a scrie (salva) fișierul, apoi Ctrl + X pentru a ieși.
Acum avem un prompt frumos, la care putem răspunde pur și simplu cu "da".
Pentru înregistrare, într-adevăr nu există prea multe motive pentru a vă schimba cheia gazdă, dar dacă veți găsi vreodată nevoia, puteți face cu ușurință.
În primul rând, treceți la directorul sistem corespunzător:
cd / etc / ssh /
Acest lucru este, de obicei, în cazul în care cheile globale gazdă sunt, deși unele distros au le plasate în altă parte. Când aveți dubii, verificați documentația!
Apoi, vom șterge toate cheile vechi.
sudo rm / etc / ssh / ssh_host_ *
Alternativ, este posibil să doriți să le mutați într-un director de rezervă sigur. Doar un gand!
Apoi, putem spune serverului OpenSSH să se reconfigureze:
sudo dpkg-reconfigura openssh-server
Veți vedea o solicitare în timp ce computerul își creează noile chei. Ta-da!
Acum că știți cum SSH funcționează puțin mai bine, ar trebui să vă puteți scoate din locurile grele. "Identificarea gazdei la distanță a schimbat" avertisment / eroare este ceva care aruncă o mulțime de utilizatori off, chiar și cei care sunt familiarizați cu linia de comandă.
Pentru punctele bonus, puteți verifica cum să copiați de la distanță fișierele de pe SSH fără a vă introduce parola. Acolo veți afla mai multe despre celelalte tipuri de algoritmi de criptare și despre modul în care utilizați fișierele cheie pentru a vă asigura securitatea.
