Uzziniet par OpenSSH Ins un Out jūsu Linux datorā

Daudzas reizes esam izgājuši SSH tikumus gan drošībai, gan attālinātai piekļuvei. Paskatīsimies uz pašu serveri, dažiem svarīgiem “uzturēšanas” aspektiem un dažiem jautājumiem, kas var pievienot turbulenci citai gludai braukšanai.

Lai gan mēs esam izstrādājuši šo rokasgrāmatu ar Linux, tas var attiekties arī uz OpenSSH Mac OS X un Windows 7, izmantojot Cygwin.

Kāpēc tas ir drošs

Mēs daudzkārt esam minējuši, kā SSH ir lielisks veids, kā droši savienot un noskaidrot datus no viena punkta uz citu. Ņemsim ļoti īsu ieskatu par to, kā lietas darbojas, lai iegūtu labāku priekšstatu par to, kāpēc lietas dažkārt var dīvaini.

Kad mēs nolemjam uzsākt savienojumu ar citu datoru, mēs bieži izmantojam protokolus, ar kuriem ir viegli strādāt. Gan prātā nāk Telnet, gan FTP. Mēs nosūtām informāciju uz attālo serveri un pēc tam saņemam apstiprinājumu par mūsu savienojumu. Lai noteiktu kāda veida drošību, šie protokoli bieži izmanto lietotājvārdu un paroles kombinācijas. Tas nozīmē, ka viņi ir pilnīgi droši, vai ne? Nepareizi!

Ja mēs domājam par mūsu savienošanas procesu kā pastu, tad, izmantojot FTP un Telnet un tamlīdzīgi, nav kā standarta pasta aploksnes. Tas ir vairāk kā pastkaršu izmantošana. Ja kāds notiek soli pa vidu, viņi var redzēt visu informāciju, ieskaitot gan korespondentu adreses, gan izsūtīto lietotājvārdu un paroli. Pēc tam viņi var mainīt vēstījumu, saglabājot to pašu informāciju un uzdoties par vienu korespondentu vai otru. Tas ir pazīstams kā „cilvēka vidū” uzbrukums, un tas ne tikai apdraud jūsu kontu, bet gan apšauba katru nosūtīto ziņojumu un saņemto failu. Jūs nevarat būt pārliecināts, vai jūs runājat ar sūtītāju vai nē, un pat tad, ja jūs esat, jūs nevarat būt pārliecināts, ka neviens neko neredzēs no iekšpuses.

Tagad aplūkosim SSL šifrēšanu, kas padara HTTP drošāku. Šeit mums ir pasta nodaļa, kas rīkojas ar korespondenci, kas pārbauda, vai jūsu saņēmējs ir tas, ko viņš vai viņa apgalvo, ka ir, un vai jūsu likumi aizsargā jūsu vēstuli. Kopumā tā ir drošāka, un centrālā iestāde - Verisign - ir viena no mūsu HTTPS piemēriem - pārliecinās, ka persona, kurai sūtāt pastu, pārbauda. Viņi to dara, nepieļaujot pastkartes (nešifrētas pilnvaras); tā vietā viņi pilnvaro reālas aploksnes.

Visbeidzot, apskatīsim SSH. Šeit uzstādīšana ir nedaudz atšķirīga. Mums šeit nav centrālā autentifikatora, bet lietas joprojām ir drošas. Tas ir tāpēc, ka jūs sūtāt vēstules kādam, kura adrese jūs jau zināt - piemēram, sarunājoties ar viņiem pa tālruni - un jūs izmantojat dažas patiesi iedomātas matemātikas, lai parakstītu savu aploksni. Jūs nododat to savam brālim, draudzene, tētim vai meitai, lai to nogādātu uz adresi, un tikai tad, ja saņēmēja iedomātā matemātikas spēles atbilst, jūs uzskatāt, ka adrese ir tā, kas tai vajadzētu būt. Tad jūs saņemsiet vēstuli atpakaļ, ko aizsargā arī no nevēlamiem skatieniem. Visbeidzot, jūs nosūtāt savu pilnvaru citā slepenā algoritmiski apburētā aploksnē uz galamērķi. Ja matemātika neatbilst, mēs varam pieņemt, ka sākotnējais saņēmējs pārvietojās un mums vēlreiz jāapstiprina viņu adrese.

Ar skaidrojumu, ja vien tas ir, mēs domājam, ka mēs to sagriezīsim. Ja jums ir vēl vairāk ieskatu, varat, protams, runāt komentāros. Šobrīd, lai gan, aplūkosim visatbilstošāko SSH iezīmi, uzņēmējas autentifikāciju.

Host Keys

Uzņēmēja autentifikācija būtībā ir tā daļa, kurā kāds uzticaties ņem aploksni (aizzīmogots ar burvju matemātiku) un apstiprina adresāta adresi. Tas ir diezgan detalizēts adreses apraksts, un tas ir balstīts uz kādu sarežģītu matemātiku, kuru mēs vienkārši izlaidīsim. Tomēr ir dažas svarīgas lietas, no kurām atņemt:

Tā kā nav centrālās iestādes, reālā drošība ir uzņēmēja atslēga, publiskās atslēgas un privātas atslēgas. (Šie pēdējie divi taustiņi ir konfigurēti, kad jums ir piekļuve sistēmai.)
Parasti, kad izveidojat savienojumu ar citu datoru, izmantojot SSH, resursdatora atslēga tiek saglabāta. Tas padara turpmākās darbības ātrākas (vai mazāk).
Ja mainās resursdatora atslēga, jūs, visticamāk, brīdināsiet, un jums vajadzētu būt piesardzīgiem!

Tā kā resursdatora atslēga tiek izmantota pirms autentifikācijas, lai noteiktu SSH servera identitāti, pirms savienojuma izveides pārliecinieties, vai pārbaudāt atslēgu. Jūs redzēsiet apstiprinājuma dialoglodziņu, kā norādīts tālāk.

Jums nevajadzētu uztraukties! Bieži vien drošības problēma ir īpaša vieta, kur var apstiprināt saimniekdatora atslēgu (iepriekš redzamo ECDSA pirkstu nospiedumu). Pilnībā tiešsaistes uzņēmumos bieži vien tas būs tikai drošā pieteikšanās vietā. Lai apstiprinātu šo atslēgu pa tālruni, jums, iespējams, būs jāsazinās ar savu IT nodaļu vai jāizvēlas! Esmu pat dzirdējis par dažām vietām, kur atslēga ir jūsu darba emblēmā vai īpašajā sarakstā „Neatliekamie numuri”. Un, ja jums ir fiziska piekļuve mērķa mašīnai, varat arī pārbaudīt sevi!

Jūsu sistēmas resursdatora atslēgas pārbaude

Atslēgu izgatavošanai tiek izmantoti 4 veidu šifrēšanas algoritmi, bet OpenSSH noklusējums no šī gada sākuma ir ECDSA (ar dažiem pamatotiem iemesliem). Mēs šodien pievērsīsimies tam. Šeit ir komanda, kuru varat palaist SSH serverī, kuram ir piekļuve:

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

Jūsu izvadam jāatgriež kaut kas tamlīdzīgs:

256 ca: 62: ea: 7c: e4: 9e: 2e: a6: 94: 20: 11: db: 9c: 78: c3: 4c /etc/ssh/ssh_host_ecdsa_key.pub

Pirmais numurs ir atslēgas bitu garums, tad pats atslēga, un visbeidzot, jums ir fails, kurā tas ir saglabāts. Salīdziniet šo vidējo daļu ar to, ko redzat, kad tiek piedāvāts pieteikties attālināti. Tam ir jāatbilst, un jūs visi esat iestatījuši. Ja tā nav, tad kaut kas cits varētu notikt.

Jūs varat apskatīt visus resursdatorus, kurus esat savienojis, izmantojot SSH, apskatot jūsu zināmo failu. Tā parasti atrodas:

~ / .ssh / ismert_hosts

To var atvērt jebkurā teksta redaktorā. Ja paskatās, mēģiniet pievērst uzmanību tam, kā tiek glabātas atslēgas. Tie tiek glabāti ar saimniekdatora nosaukumu (vai tīmekļa adresi) un tās IP adresi.

Mainot resursdatora atslēgas un problēmas

Ir daži iemesli, kāpēc mainās resursdatora atslēgas, vai arī tie neatbilst tam, kas ir reģistrēts jūsu zināmā faila failā.

Sistēma tika atkārtoti instalēta / pārkonfigurēta.
Tīkla atslēgas tika mainītas manuāli drošības protokolu dēļ.
OpenSSH serveris drošības problēmu dēļ atjaunināja un izmanto dažādus standartus.
IP vai DNS noma mainījās. Tas bieži nozīmē, ka mēģināt piekļūt citam datoram.
Sistēma kaut kādā veidā tika apdraudēta tā, ka mainījies resursdators.

Visticamāk, šis jautājums ir viens no pirmajiem trim, un jūs varat ignorēt izmaiņas. Ja mainās IP / DNS noma, tad var rasties problēma ar serveri, un jūs varat tikt novirzīts uz citu mašīnu. Ja neesat pārliecināts, kāds ir iemesls izmaiņām, tad, iespējams, pieņemat, ka tas ir pēdējais sarakstā.

Kā OpenSSH apstrādā nezināmus saimniekus

OpenSSH ir iestatījums, kā tā apstrādā nezināmus resursdatorus, kas atspoguļots mainīgajā “StrictHostKeyChecking” (bez pēdiņām).

Atkarībā no konfigurācijas SSH savienojumi ar nezināmiem saimniekiem (kuru atslēgas jau nav jūsu zināmā faila failā) var iet trīs veidos.

StrictHostKeyChecking ir iestatīts uz nē; OpenSSH automātiski izveidos savienojumu ar jebkuru SSH serveri neatkarīgi no saimniekdatora atslēgas statusa. Tas ir nedrošs un nav ieteicams, izņemot gadījumus, kad pēc operētājsistēmas atkārtotas instalēšanas pievienojat ķekars..
StrictHostKeyChecking ir iestatīts uz jautājumu; OpenSSH parādīs jaunus resursdatora taustiņus un lūgs apstiprinājumu pirms pievienošanas. Tas novērsīs, ka savienojumi tiek pārslēgti uz mainītiem resursdatora atslēgām. Tā ir noklusējuma.
StrictHostKeyChecking ir iestatīts uz jā; Pretstatā “nē”, tas neļaus jums izveidot savienojumu ar jebkuru uzņēmēju, kas vēl nav iekļauts jūsu zināmajā failā.

Šo mainīgo var viegli mainīt komandrindā, izmantojot šādu paradigmu:

ssh -o 'StrictHostKeyChecking [opcija]' lietotāja @ resursdators

Aizstājiet [opcija] ar "nē", "jautājiet" vai "jā". Jāapzinās, ka šajā mainīgajā lielumā un tā iestatījumā ir viena taisna citāts. Aizstājiet arī lietotāja @ resursdatoru ar tā servera lietotājvārdu un resursdatora nosaukumu, ar kuru izveidojat savienojumu. Piemēram:

ssh -o 'StrictHostKeyChecking jautājiet' [email protected]

Bloķētie saimnieki mainīto taustiņu dēļ

Ja jums ir serveris, kuru mēģināt piekļūt, ja tā atslēga jau ir mainīta, noklusējuma OpenSSH konfigurācija neļaus jums to piekļūt. Jūs varētu mainīt StrictHostKeyChecking vērtību šai saimniekam, bet tas nebūtu pilnīgi, rūpīgi, paranoiski drošs, vai tas būtu? Tā vietā mēs varam vienkārši noņemt pārkāpēju vērtību no mūsu zināmā faila faila.

Tas noteikti ir neglīts, kas ir ekrānā. Par laimi, mūsu iemesls tam bija pārinstalēta OS. Tātad, tuvināsim vajadzīgo līniju.

Tur mēs ejam. Skatiet, kā tā citē failu, kas mums ir nepieciešams rediģēt? Tas pat dod mums līnijas numuru! Tātad, atveriet šo failu Nano:

Lūk, mūsu pārkāpēja atslēga 1. rindā. Mums ir jānospiež Ctrl + K, lai izgrieztu visu līniju.

Tas ir daudz labāk! Tātad, tagad mēs nospiežam Ctrl + O, lai ierakstītu (saglabātu) failu, tad izietu no Ctrl + X.

Tagad mēs saņemam jauku uzvedni, uz kuru mēs varam vienkārši atbildēt ar „jā”.

Jauna resursdatora atslēgu izveide

Ierakstam ir patiešām pārāk daudz iemeslu, lai jūs vispār nemainītu uzņēmēja atslēgu, bet, ja jūs kādreiz atradīsiet vajadzību, varat to izdarīt viegli.

Pirmkārt, mainiet atbilstošo sistēmas direktoriju:

cd / etc / ssh /

Parasti tas ir, ja globālie uzņēmēja taustiņi ir, lai gan dažiem rajoniem tie ir novietoti citur. Šaubu gadījumā pārbaudiet dokumentāciju!

Tālāk mēs izdzēsīsim visas vecās atslēgas.

sudo rm / etc / ssh / ssh_host_ *

Varat arī pārvietot tos uz drošu rezerves direktoriju. Tikai ideja!

Tad mēs varam pateikt OpenSSH serverim, lai tā pati pārkonfigurētu:

sudo dpkg-reinfigure openssh-server

Jūs redzēsiet uzvedni, kamēr jūsu dators izveidos jaunas atslēgas. Ta-da!

Tagad, kad jūs zināt, kā SSH darbojas mazliet labāk, jums vajadzētu būt spējīgam izkļūt no grūtiem punktiem. “Remote Host Identification ir mainīts” brīdinājums / kļūda ir kaut kas, kas izslēdz daudz lietotāju, pat tiem, kuri ir iepazinušies ar komandrindu.