Дізнайтеся про виведення з 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: е.о .: 7с: е4: 9д: 2д: а6: 94: 20: 11: дб: 9с: 78: с3: 4с / і т.п.

Перше число - це довжина біта ключа, тоді саме ключ, і, нарешті, у вас є файл, в якому він зберігається. Порівняйте цю середню частину з тим, що ви бачите, коли вам буде запропоновано віддалено ввійти. Він повинен збігатися, і ви все налаштовані. Якщо цього не станеться, то може відбутися щось інше.

Ви можете переглянути всі хости, з якими ви підключилися через 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; Протилежне від "no", це перешкоджатиме вам підключення до будь-якого вузла, який ще не присутній у вашому файлі known_hosts.

Ви можете легко змінити цю змінну в командному рядку, використовуючи наступну парадигму:

ssh -o 'StrictHostKeyChecking [опція]' user @ host

Замінити [опція] на "ні", "попросити" або "так". Майте на увазі, що існують окремі прямі лапки, що оточують цю змінну та її налаштування. Також замінити user @ host ім'ям і ім'ям хоста сервера, до якого ви підключаєтеся. Наприклад:

ssh -o 'StrictHostKeyChecking запитайте' [email protected]

Заблоковані хости через змінені ключі

Якщо у вас є сервер, до якого ви намагаєтеся отримати доступ, і його ключ вже змінився, налаштування OpenSSH за замовчуванням не дозволить вам отримати доступ до нього. Ви можете змінити значення StrictHostKeyChecking для цього вузла, але це не буде повністю, ретельно, параноїдно безпечно, чи не так? Замість цього ми можемо просто вилучити значення, що порушує, з нашого файла known_hosts.

Це, безумовно, потворна річ, щоб мати на екрані. На щастя, причиною цього була перевстановлена ОС. Отже, давайте збільшимо потрібну нам лінію.

Там ми йдемо. Подивіться, як він цитує файл, який нам потрібно редагувати? Це навіть дає нам номер лінії! Отже, давайте відкриємо цей файл у Nano:

Ось наш порушуючий ключ, в рядку 1. Все, що нам потрібно зробити, це натиснути Ctrl + K, щоб вирізати весь рядок.

Це набагато краще! Отже, зараз ми натискаємо Ctrl + O, щоб виписати (зберегти) файл, потім Ctrl + X, щоб вийти.

Тепер ми отримуємо гарну підказку, на яку ми можемо просто відповісти «так».

Створення нових ключів хосту

Для довідки, дійсно немає занадто багато причин для вас, щоб змінити ключ хоста на всіх, але якщо ви коли-небудь знайти необхідність, ви можете легко зробити це.

Спочатку перейдіть у відповідний системний каталог:

cd / etc / ssh /

Як правило, тут знаходяться глобальні ключі хоста, хоча деякі дистрибутиви розміщуються в іншому місці. У сумніві перевірте документацію!

Далі ми видалимо всі старі ключі.

sudo rm / etc / ssh / ssh_host_ *

Крім того, ви можете перенести їх у безпечний каталог резервного копіювання. Просто думка!

Потім, ми можемо сказати серверу OpenSSH про переналаштування:

sudo dpkg-reconfigure openssh-сервер

Під час створення нових ключів з'явиться запит. Ta-da!

Тепер, коли ви знаєте, як SSH працює трохи краще, ви повинні мати можливість вийти з жорстких місць. Попередження / помилка "Ідентифікація віддаленого хоста змінилося" - це те, що виключає багатьох користувачів, навіть тих, хто знайомий з командним рядком.