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