Известявахме добродетелите на SSH многократно, както за сигурността, така и за отдалечения достъп. Нека да разгледаме самия сървър, някои важни аспекти на "поддръжката" и някои странности, които могат да добавят турбуленция към иначе плавно пътуване.
Докато сме написали това ръководство с Linux, това може да се отнася и за OpenSSH в Mac OS X и Windows 7 чрез Cygwin.
Споменахме многократно как SSH е чудесен начин за сигурно свързване и тунелиране на данни от една точка до друга. Нека да разгледаме много внимателно как работи нещата, за да получите по-добра представа защо нещата понякога могат да станат странни.
Когато решаваме да започнем връзка с друг компютър, често използваме протоколи, с които лесно се работи. Telnet и FTP идват на ум. Изпращаме информацията до отдалечен сървър и след това получаваме потвърждение за връзката ни. За да се установи някакъв вид безопасност, тези протоколи често използват комбинации от потребителско име и парола. Това означава, че са напълно сигурни, нали? Грешка!
Ако мислим за нашия процес на свързване като поща, тогава използването на FTP и Telnet и подобни не е като да използвате стандартни пощенски пликове. Това е по-скоро като използване на пощенски картички. Ако някой се случи да стъпи по средата, той може да види цялата информация, включително адресите на двамата кореспонденти и изпратеното потребителско име и парола. След това те могат да променят съобщението, като запазят информацията същата и да се представят за един или друг кореспондент. Това е известно като атака "човек в средата" и не само компрометира акаунта ви, но поставя под въпрос всяко изпратено съобщение и получен файл. Не можете да сте сигурни дали говорите с подателя или не, и дори и да сте, не можете да сте сигурни, че никой не гледа всичко отвсякъде.
Сега нека разгледаме SSL криптирането, което прави HTTP по-сигурен. Тук имаме пощенска служба, която се занимава с кореспонденцията, която проверява дали получателят ви е този, за когото се твърди, че е, и има закони, които защитават пощата ви от неспазване. Това е по-сигурно цялостно и централният орган - Verisign е един, за нашия HTTPS пример - гарантира, че човекът, на когото изпращате поща, ще се ожени. Те правят това, като не позволяват пощенски картички (некриптирани данни); вместо това те дават реални пликове.
И накрая, нека разгледаме SSH. Тук настройката е малко по-различна. Тук нямаме централен идентификатор, но нещата все още са сигурни. Това е така, защото изпращате писма до някого, чийто адрес вече знаете - да речем, като говорите с тях по телефона - и вие използвате доста интересна математика, за да подпишете плика си. Можете да я предадете на брат си, приятелка, татко или дъщеря, за да го отведете на адреса и само ако любимите математически редове на получателя предполагате, че адресът е това, което трябва да бъде. След това получавате писмо, също така защитено от любопитни очи от тази страхотна математика. И накрая, изпращате вашите пълномощия в друг таен алгоритмично омагьосан плик до местоназначението. Ако математиката не съвпада, можем да приемем, че първоначалният получател се е преместил и трябва отново да потвърдим адреса си.
С обяснението колкото е възможно, мислим, че ще го скъсаме там. Ако имате по-добра представа, не се колебайте да говорите в коментарите, разбира се. Засега обаче нека да разгледаме най-подходящата функция на SSH, удостоверяване на хост.
Удостоверяването на хоста е по същество частта, в която някой, на когото имате доверие, взима плика (запечатан с магическа математика) и потвърждава адреса на получателя ви. Това е доста подробно описание на адреса и се основава на някаква сложна математика, която ще прескочим направо. Има няколко важни неща, които трябва да се вземат от това:
Тъй като ключът хост се използва преди удостоверяване, за да се установи самоличността на SSH сървъра, трябва да сте сигурни, че сте проверили ключа, преди да се свържете. Ще видите диалогов прозорец за потвърждение, както е показано по-долу.
Не трябва да се притеснявате, обаче! Често когато сигурността предизвиква загриженост, ще има специално място, което може да бъде потвърдено от ключовия хост (отпечатъка ECDSA по-горе). В изцяло онлайн начинания, често той ще бъде на сигурен сайт само за влизане. Може да се наложи (или да изберете!) Да се обадите на вашия ИТ отдел, за да потвърдите този ключ по телефона. Дори съм чувал за някои места, където ключът е на вашето работно знаме или на специалния списък "Спешни номера". И ако имате физически достъп до целевата машина, можете също да проверите сами!
Има 4 вида видове алгоритми за кодиране, използвани за изработване на ключове, но по подразбиране за OpenSSH от началото на тази година е ECDSA (с някои добри причини). Сега ще се съсредоточим върху това. Ето командата, която можете да изпълните на SSH сървъра, до който имате достъп:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Резултатът ви трябва да върне нещо подобно:
256 ca: 62: ea: 7c: e4: 9е: 2е: а6: 94: 20: 11: db: 9c: 78: c3: 4c /etc/ssh/ssh_host_ecdsa_key.pub
Първото число е дължината на битовете на ключа, после е самият ключ и накрая имате файла, в който е съхранен. Сравнете средната част с това, което виждате, когато получите подкана да влезете отдалечено.Трябва да съвпадне и вие сте готови. Ако не е така, тогава може да се случи нещо друго.
Можете да видите всички хостове, до които сте свързали, чрез SSH, като разгледате файла known_hosts. Обикновено се намира на адрес:
~ / .Ssh / known_hosts
Можете да го отворите във всеки текстов редактор. Ако погледнете, опитайте се да обърнете внимание как се съхраняват ключовете. Те се съхраняват с името на хост компютъра (или уеб адрес) и неговия IP адрес.
Има няколко причини, поради които ключовете на хоста се променят или не съвпадат с това, което е вписано във вашия файл known_hosts.
Най-вероятно проблемът е един от първите три и можете да пренебрегнете промяната. Ако лизингът на IP / DNS се промени, може да има проблем със сървъра и може да бъде пренасочен към друга машина. Ако не сте сигурни какво е причината за промяната, вероятно би трябвало да приемете, че това е последното в списъка.
OpenSSH има настройка за начина, по който работи с непознати хостове, отразени в променливата "StrictHostKeyChecking" (без кавички).
В зависимост от вашата конфигурация, SSH връзките с неизвестни хостове (чиито ключове все още не са във вашия файл known_hosts) могат да изминат три начина.
Можете лесно да промените тази променлива в командния ред, като използвате следната парадигма:
ssh -o 'StrictHostKeyChecking [опция]' user @ host
Заменете [опция] с "не", "питайте" или "да". Имайте предвид, че има единични кавички около тази променлива и нейната настройка. Също така заменете потребителско име @ host с потребителското име и името на хоста на сървъра, до който се свързвате. Например:
ssh -o 'StrictHostKeyChecking попитайте' [email protected]
Ако имате сървър, до който се опитвате да осъществите достъп, който вече е променен, конфигурацията OpenSSH по подразбиране ще ви попречи да го осъществите. Бихте могли да промените стойността на StrictHostKeyChecking за този хост, но това не би било напълно, напълно, параноично сигурно, нали? Вместо това, можем просто да премахнем обидата от нашия файл known_hosts.
Това определено е грозно нещо, което имате на екрана си. За щастие нашата причина за това беше инсталирана операционна система. Така че, нека да увеличим линията, от която се нуждаем.
Ето. Вижте как цитира файла, който трябва да редактираме? Той дори ни дава номера на линията! Така че, нека да отворим файла в Нано:
Тук е нашият критичен ключ, в ред 1. Всичко, което трябва да направите, е да натиснете Ctrl + K, за да изрежете цялата линия.
Това е много по-добре! Така че, сега натискаме Ctrl + O, за да запишете (запишете) файла, след което Ctrl + X, за да излезете.
Сега вместо това получаваме хубав подсказка, на който можем просто да отговорим с "да".
Всъщност, няма причина да промените изцяло вашия ключ на хост, но ако някога сте намерили нуждата, можете лесно да го направите.
Първо, променете съответната системна директория:
cd / etc / ssh /
Това обикновено е мястото, където се намират основните ключове на хост, въпреки че някои дистрибуции ги поставят на друго място. При съмнение проверете документацията си!
След това ще изтрием всички стари ключове.
sudo rm / etc / ssh / ssh_host_ *
Друга възможност е да ги преместите в безопасна директория за архивиране. Просто мисъл!
След това можем да кажем на OpenSSH сървъра да се преконфигурира:
sudo dpkg - преконфигурирайте openssh-сървъра
Ще видите подкана, докато компютърът ви създаде новите си ключове. Та-га!
Сега, когато знаете как SSH работи малко по-добре, трябва да можете да се измъкнете от трудни места. Промяната на "идентификацията на отдалеченото гостоприемство е променена" е нещо, което изхвърля много потребители, дори тези, които са запознати с командния ред.
За бонус точки можете да проверите как да дистанционно копирате файлове над SSH без да въвеждате паролата си. Там ще научите малко повече за другите видове алгоритми за шифроване и как да използвате ключови файлове за допълнителна сигурност.
