Научете Ins и Out на OpenSSH на вашия Linux компютър

Многократно сме възхвалявали предимствата на SSH, както за сигурност, така и за отдалечен достъп. Нека да разгледаме самия сървър, някои важни аспекти на „поддръжката“ и някои особености, които могат да добавят турбулентност към иначе гладкото движение.

Макар да имаме предвид това ръководство с Linux, това може да се отнася и за OpenSSH в Mac OS X и Windows 7 чрез Cygwin.

Защо е сигурно

Много пъти споменахме как SSH е чудесен начин за сигурно свързване и тунелни данни от една точка в друга. Нека вземем един кратък преглед на това как работят нещата, така че да получите по-добра представа защо нещата понякога могат да станат странни.

Когато решим да инициираме връзка към друг компютър, често използваме протоколи, с които лесно се работи. Telnet и FTP идват на ум. Изпращаме информация на отдалечен сървър и след това получаваме потвърждение за връзката. За да се установи някакъв вид безопасност, тези протоколи често използват комбинации от потребителско име и парола. Това означава, че те са напълно сигурни, нали? погрешно!

Ако мислим за процеса на свързване като поща, тогава използването на FTP и Telnet и други подобни не е като използването на стандартни пощенски пликове. Прилича повече на използването на пощенски картички. Ако някой се случи да стъпи в средата, те могат да видят цялата информация, включително адресите на двата кореспондента и изпратеното потребителско име и парола. След това те могат да променят посланието, да запазят информацията една и съща и да се представят за един или друг кореспондент. Това е известно като атака „човек в средата“ и не само компрометира профила ви, но поставя под въпрос всяко изпратено и получено съобщение. Не можете да сте сигурни, че говорите с подателя или не, и дори да сте, не можете да сте сигурни, че никой не гледа на всичко между тях.

Сега нека разгледаме SSL криптирането, което прави HTTP по-сигурен. Тук имаме пощенска служба, която обработва кореспонденцията, която проверява дали получателят е този, за когото той или тя претендира, че е, и има закони, които защитават пощата ви от това да бъдат разглеждани. Той е по-сигурен като цяло, а централният орган - Verisign е един, за нашия HTTPS пример - гарантира, че лицето, което изпращате поща, се проверява. Те правят това, като не позволяват пощенски картички (некриптирани идентификационни данни); вместо това те налагат реални пакети.

И накрая, нека разгледаме SSH. Тук настройката е малко по-различна. Тук нямаме централен идентификатор, но нещата все още са сигурни. Това е така, защото изпращате писма на някой, чийто адрес вече знаете - да речем, като говорите с тях по телефона - и използвате някаква наистина фантастична математика, за да подпишете плик. Предаваш го на брат си, приятелка, баща или дъщеря, за да го вземеш на адреса, и само ако фантастичните мачове на получателя приемаш, че адресът трябва да бъде. След това получавате обратно писмо, също защитено от любопитни очи от тази страхотна математика. И накрая, изпращате идентификационните си данни в друг таен алгоритмично омагьосан плик до местоназначението. Ако математиката не съвпада, можем да приемем, че първоначалният получател е преместен и трябва отново да потвърдим адреса им.

С обяснение толкова дълго, колкото и да е, смятаме, че ще го отрежем там. Ако имате по-добра представа, не се колебайте да говорите в коментарите, разбира се. Засега обаче, нека да разгледаме най-подходящата функция на SSH, удостоверяване на хост.

Хост ключове

Удостоверяването на хост е по същество частта, в която някой, на когото вярвате, заема плика (запечатан с магическа математика) и потвърждава адреса на получателя. Това е доста подробно описание на адреса и се основава на някаква сложна математика, която просто ще пропуснем. Има няколко важни неща, които трябва да отнемете от това:

Тъй като няма централна власт, истинската сигурност е в ключа на хоста, публичните ключове и частните ключове. (Последните два ключове са конфигурирани, когато имате достъп до системата.)
Обикновено, когато се свързвате към друг компютър чрез SSH, ключът на хоста се съхранява. Това прави бъдещите действия по-бързи (или по-малко).
Ако хост ключът се промени, най-вероятно ще бъдете предупредени и ще бъдете предпазливи!

Тъй като ключът на хоста се използва преди удостоверяване, за да се установи самоличността на SSH сървъра, трябва да проверите ключа преди да се свържете. Ще видите диалогов прозорец за потвърждение, както е показано по-долу.

Не бива да се тревожите! Често, когато сигурността е повод за загриженост, ще има специално място, на което може да бъде потвърден ключът на хоста (отпечатъци от ECDSA по-горе). В изцяло он-лайн начинания, често това ще бъде само на защитен сайт. Може да се наложи да (или да изберете!) Да се обадите на ИТ отдела, за да потвърдите този телефон по телефона. Дори съм чувал за някои места, където ключът е в работната ви значка или в специалния списък „Спешни номера“. И ако имате физически достъп до целевата машина, можете да проверите сами!

Проверка на ключа на хоста на вашата система

Има 4 вида алгоритми за шифроване, използвани за създаване на ключове, но по подразбиране за OpenSSH от началото на тази година е ECDSA (с някои добри причини). Днес ще се съсредоточим върху това. Ето командата, която можете да изпълните на SSH сървъра, до който имате достъп:

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

Изходът ви трябва да върне нещо подобно:

256 ок: 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 обработва неизвестни хостове

OpenSSH има настройка за това как обработва неизвестни хостове, отразени в променливата “StrictHostKeyChecking” (без кавички).

В зависимост от вашата конфигурация, SSH връзките с неизвестни хостове (чиито ключове не са вече във вашия файл known_hosts) могат да вървят по три начина.

StrictHostKeyChecking е настроен на no; OpenSSH автоматично ще се свърже към всеки SSH сървър, независимо от статуса на хоста. Това е несигурно и не се препоръчва, освен ако не добавяте няколко хостове след преинсталиране на вашата операционна система, след което ще я промените обратно.
StrictHostKeyChecking е настроен да пита; OpenSSH ще ви покаже нови ключове на хоста и ще поиска потвърждение, преди да ги добавите. Това ще попречи на връзките да преминат към променени ключове за хост. Това е по подразбиране.
StrictHostKeyChecking е настроено на yes; Обратното на „не“, това ще ви попречи да се свържете с който и да е хост, който вече не присъства във вашия файл known_hosts.

Можете лесно да промените тази променлива в командния ред, като използвате следната парадигма:

ssh -o 'StrictHostKeyChecking [опция]' потребител @ host

Заменете [опция] с “не”, “попитайте” или “да”. Имайте предвид, че съществуват единични прави цитати, заобикалящи тази променлива и нейната настройка. Също така заменете user @ 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-reconfigure openssh-сървър

Ще видите подкана, докато компютърът ви създава новите си ключове. Та-га!

Сега, когато знаете как SSH работи малко по-добре, трябва да можете да се измъкнете от трудни места. Предупреждението / грешката „Идентифициране на отдалечен хост се промени“ е нещо, което изключва много потребители, дори и тези, които са запознати с командния ред.