Стаття також доступна російською (перейти до перегляду).

Вступ

• Питання безпечної аутентифікації на сервері
• Практичне використання файлу know_hosts
• Демонстрація роботи з know_hosts
• Використання утиліти ssh-keyscan
• Використання утиліти ssh-keygen
• Проблеми при роботі з know_hosts
• Управління реакцією системи та процесом верифікації хостів

Питання безпечної роботи в мережі, зокрема, вдосконалення захисту при аутентифікації на сервері Linux є на часі. Використання файлу know_hosts для фіксації параметрів безпеки віддалених серверів для їх подальшої ідентифікації є одним із таких шляхів. Розглянемо основні характеристики файлу, правила його використання та продемонструємо роботу з ним на конкретних прикладах.

Питання безпечної аутентифікації на сервері

На даний час з'єднання та робота з віддаленим сервером в основному відбуваються з використанням шифрованих з'єднань та каналів, котрі забезпечуються відомим протоколом SSH (Secure Shell), зокрема, його OpenSSH реалізацією. Цей протокол є заміною застарілих аналогів типу RSH, FTP, Telnet та інших, у яких не використовуються методи шифрування при з'єднанні та передачі даних і тому вони є небезпечними для використання. SSH усуває проблему з безпекою типу «людина посередині», коли зловмисник, може мати доступ до проміжної мережі може перехопити ваші дані та замість них «підсунути» свої – заражені вірусом. Взагалі ж, варіантів маніпуляцій з даними тут може бути безліч, якщо ви працюєте за посередництвом незахищеного протоколу.

Безпечність каналу SSH забезпечується не лише безпосередньо методами або алгоритмами шифрування даних, а й різноманітними підходами, пов'язаними з використанням ключів. Одним з таких підходів є верифікація віддалених хостів, до яких ви під'єднуєтесь.

Сама ідея такої верифікації не нова, оскільки вже давно використовується верифікація веб-вузлів у захищеному варіанті протоколу HTTP, тобто, у HTTPS з методами шифрування типу SSL або TLS. Це дозволяє уникнути багатьох проблем при роботі у Веб-просторі. Фактично, SSH використовує той самий принцип верифікації хостів, що і у зазначеному вище протоколі, лише з деякими відмінностями. Зокрема, у процесі верифікації тут відсутня третя довірена Certificate Authority сторона, така як Thawte або Verisign у випадку HTTPS, котра б засвідчила автентичність та підписала б відкритий ключ. Замість неї такою стороною виступає сам користувач, котрий має змогу перевірити відкритий ключ віддаленого серверу та засвідчити його ідентичність. Достатньо зробити це лише раз, оскільки SSH у автоматичному режимі збереже відкритий ключ віддаленого хоста під час першого сеансу з'єднання, причому, не лише у користувацькому файлі $HOME/.ssh/know_hosts, а й у системному файлі /etc/ssh/known_hosts, що забезпечить у подальшому автоматичне під'єднання до віддаленого хоста без будь-яких запитів до користувача. Лише в цьому випадку канал буде захищений на всіх рівнях.

Практичне використання файлу know_hosts

Для можливості повноцінної роботи з know_hosts необхідно забезпечити наявність оновленої версії протоколу SSH на вашій станції. Для цього запустимо з терміналу групу команд.

$ apt update

$ apt list --upgradable

$ apt install ssh
$ apt install openssh-server

Демонстрація роботи з know_hosts

Переглянемо вміст файлу know_hosts за допомогою відповідної команди:

$ cat ~/.ssh/known_hosts

Тепер спробуємо встановити з'єднання з одним з віддалених хостів, та після завершення сеансу знову перевіримо вміст вказаного файлу. Введемо у терміналі:

$ ssh ukrobyava.com.ua

Виходом команди буде повідомлення про те, що автентифікація не може бути встановлена для вказаної адреси віддаленого хоста, виведений відбиток відкритого ключа та запропоновано обрати один із варіантів: продовжити з'єднання, відмовитись, або ввести відповідний відбиток ключа. Обираємо перший варіант та підтверджуємо вибір. В результаті, як показано нижче, з'являється повідомлення про те, що запис для хоста «ukrobyava.com.ua» у форматі ECDSA буде доданий у список файлу know_hosts та з'єднання закривається. Вочевидь, автоматична верифікація хоста саме тому і не відбулась, що був відсутній відповідний запис у файлі know_hosts. Нижче ми перевіримо цю тезу.

Тепер знову перевіримо вміст файлу know_hosts, щоб переконатися, що новий запис з'явився. Введемо команду:

$ cat ~/.ssh/known_hosts

Із зображення видно, що новий запис дійсно з'явився (останній у списку). В ньому можна побачити відкритий ключ віддаленого хоста, котрий починається з символу «А», а закінчується знаком рівняння «=». Після цього спробуємо знову під'єднатися до того ж хоста. Введемо у терміналі:

$ ssh ukrobyava.com.ua

В результаті, нам буде запропоновано ввести пароль доступу для SSH з'єднання з віддаленим хостом. Це означає, що верифікація вказаного хоста тепер завжди буде відбуватися автоматично. Це стало можливим саме завдяки запису у файлі know_hosts, тобто, наша теза підтвердилася. Звісно, після введення існуючого паролю з'єднання буде встановлено.

Використання утиліти ssh-keyscan

Для формування списків відкритих ключів віддалених машин для know_hosts використовується утиліта ssh-keyscan з відповідними параметрами. Скористаємося нею для додавання запису для визначеного хоста:

$ ssh-keyscan -t rsa kievobyava.kiev.ua >> ~/.ssh/known_hosts

Як бачимо, вихід команди містить інформацію про версію протоколу SSH та операційну систему (ОС) хоста, тобто, команда спрацювала. Перевіримо вміст know_hosts:

$ cat ~/.ssh/known_hosts

Із вмісту файлу видно, що запис про хост «kievobyava.kiev.ua» із rsa кодуванням доданий, тобто, команда працює.

Використання утиліти ssh-keygen

Для управління, генерування та конвертації ключів автентифікації машин можна скористатися можливостями утиліти ssh-keygen, яка має великий набір відповідних параметрів. Вказана утиліта здатна забезпечити формування ключів, як для ssh(1), так і для більш сучасної версії протоколу - ssh(2). Якщо утиліта використовується без параметрів, то формується ключ типу RSA.

Для прикладу, скористаємося утилітою для пошуку та отримання відбитка ключа хоста kievobyava.kiev.ua:

$ ssh-keygen -F kievobyava.kiev.ua

Ми бачимо, що утиліта успішно виконала задачу і знайшла потрібну інформацію у файлі know_hosts.

Для перевантажених систем іноді буває дуже важливим не тільки оперативно знайти, а й видалити запис про той чи інший хост. Це можна зробити за допомогою параметру «R» вказаної утиліти. Для прикладу, видалимо запис про один з доданих нами хостів. Введемо у терміналі:

ssh-keygen -R ukrobyava.com.ua

Із виходу команди бачимо, що запис був видалений та поміщений у файл .ssh/know_hosts.old на випадок необхідності його поновлення.

На всяк випадок перевіримо вміст know_hosts, щоб переконатися, що це дійсно так.

Введемо:

$ cat ~/.ssh/known_hosts

Так, дійсно, запис про хост «ukrobyava.com.ua» був видалений.

Проблеми при роботі з known_hosts

Найбільш розповсюджена проблема використання файлу полягає в тому, що не завжди ключ, що надає віддалений сервер співпадає з ключем, який вже занотований у файлі для цього серверу. Найчастіше це пов'язано із оновленням обладнання або зміною налаштувань на сервері. При цьому може буде видане повідомлення, на кшталт «REMOTE HOST IDENTIFICATION HAS CHANGED!». У цьому випадку можна спробувати видалити з файлу запис для цього серверу та додати її знову. Найвірогідніше, що проблема зникне, оскільки інформація про ключі оновиться і стане актуальною.

Також можлива ситуація, коли при спробі під'єднання до неіснуючого хоста ви побачите повідомлення типу «POSSIBLE DNS SPOOFING DETECTED!». Маєте відповідним чином реагувати. Бажано перевірити запис про хост на відповідність реаліям, зокрема, поле IP-адреси.

Управління реакцією системи та процесом верифікації хостів

Взагалі ж, можливості SSH дозволяють керувати реакцією системи у випадку невідповідності ключа. Для цього існує параметр StrictHostKeyChecking, котрий знаходиться у файлі конфігурації ssh_config. Він може приймати три значення: no, ask та yes.

У першому варіанті (no) з'єднання встановлюється у будь-якому випадку без запиту до користувача. При цьому ключ автоматично додається у список хостів.

У другому варіанті (ask), якщо відсутній ключ віддаленого хоста, то у терміналі буде виведений його відбиток та запропоновано підтвердити. Якщо буде встановлене з'єднання, але ключі не співпадуть, то вхід у систему буде призупинений і видане повідомлення «REMOTE HOST IDENTIFICATION HAS CHANGED!», про що ми вже говорили вище. Це значення параметру встановлене за замовченням.

Третій варіант (yes) є самим безпечним, оскільки ви взагалі не зможете увійти в систему, якщо у списку хостів сервер відсутній. Однак, якщо ключ знайдений, але він не співпадає, то отримаєте те ж саме повідомлення, що і для другого варіанту.

Найкраще керувати процесом верифікації віддалених хостів за допомогою системного файлу /etc/ssh/known_hosts, що дасть змогу встановити однаковий та достовірний список хостів для всіх без винятку користувачів системи та швидко оновлювати файл у випадку зміни конфігурації системи. Треба також переконатися, що ви отримали усі типи ключів: rsa, dsa, rsa1 та інші.

Пропонуємо Вам скористатися нашими послугами з оренди серверного обладнання. Надання налаштування серверу на протязі 24 годин, безперебійне живлення, якісний інтернет, підтримка 24/7.

Підписуйтесь на наш телеграм–канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів. Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

Напишіть Про це у коментарях, ми з задоволенням відповімо та обговорюємо Ваші зауваження та пропозиції.

Дата: 05.11.2022 Автор: Євген #security#ssh

Голосування 1 2 3 4 5