Ми неодноразово вихваляли достоїнства 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: еа: щц: еч: яйця: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
Перше число - це бітова довжина ключа, потім - сам ключ, і нарешті, у вас є файл, у якому він зберігається. Порівняйте цю середню частину з тим, що ви бачите, коли вам буде запропоновано дистанційно ввійти. Він повинен збігатися, і все готово. Якщо цього не станеться, то може трапитися щось інше.
Ви можете переглянути всі хости, до яких ви підключилися за допомогою SSH, переглянувши ваш файл known_hosts. Зазвичай він знаходиться за адресою:
~ / .ssh / відомі_хости
Ви можете відкрити це в будь-якому текстовому редакторі. Якщо ви дивитесь, спробуйте звернути увагу на те, як зберігаються ключі. Вони зберігаються з іменем головного комп’ютера (або веб-адресою) та його IP-адресою.
Зміна ключів і проблем хоста
Є кілька причин, чому ключі хоста змінюються або вони не збігаються з тим, що входить у ваш файл known_hosts.
- Система була перевстановлена / переналаштована.
- Ключі хоста були змінені вручну через протоколи безпеки.
- Сервер OpenSSH оновлений та використовує різні стандарти через проблеми безпеки.
- Змінено оренду IP або DNS. Це часто означає, що ви намагаєтесь отримати доступ до іншого комп’ютера.
- Система була якось скомпрометована таким чином, що ключ хоста змінився.
Швидше за все, проблема є однією з перших трьох, і ви можете ігнорувати зміни. Якщо оренда IP / DNS змінилася, може виникнути проблема із сервером, і ви можете бути перенаправлені на іншу машину. Якщо ви не впевнені, в чому причина зміни, то, мабуть, слід припустити, що це остання у списку.
Як OpenSSH обробляє невідомих хостів
OpenSSH має налаштування того, як він обробляє невідомі хости, що відображається у змінній “StrictHostKeyChecking” (без лапок).
Залежно від вашої конфігурації, з'єднання SSH з невідомими хостами (ключі яких ще не містяться у вашому файлі known_hosts) можуть три шляхи.
- StrictHostKeyChecking встановлено на значення no; OpenSSH автоматично підключатиметься до будь-якого сервера SSH незалежно від статусу ключа хосту. Це небезпечно і не рекомендується, крім випадків, коли ви додаєте купу хостів після перевстановлення вашої ОС, після чого ви зміните її назад.
- StrictHostKeyChecking налаштовано запитувати; OpenSSH покаже вам нові ключі хоста та попросить підтвердження перед їх додаванням. Це запобіжить переходу з’єднань до змінених ключів хосту. Це за замовчуванням.
- StrictHostKeyChecking встановлено так; Навпаки "ні", це заважатиме вам підключатися до будь-якого хосту, якого ще немає у вашому файлі known_hosts.
Ви можете легко змінити цю змінну в командному рядку, використовуючи таку парадигму:
ssh -o 'StrictHostKeyChecking [option]' user @ host
Замініть [option] на "ні", "запитати" або "так". Майте на увазі, що навколо цієї змінної та її налаштування є окремі прямі лапки. Також замініть user @ host на ім'я користувача та ім'я хосту сервера, до якого ви підключаєтесь. Наприклад:
ssh -o 'StrictHostKeyChecking ask' [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-server
Ви побачите запит, коли комп’ютер створюватиме нові ключі. Та-да!
Тепер, коли ви знаєте, як SSH працює трохи краще, ви зможете вийти з важких місць. Попередження / помилка «Ідентифікація віддаленого хоста змінилася» - це те, що відкидає багатьох користувачів, навіть тих, хто знайомий з командним рядком.
Для отримання бонусних балів ви можете перевірити Як віддалено копіювати файли через SSH без введення пароля . Там ви дізнаєтесь трохи більше про інші типи алгоритмів шифрування та про те, як використовувати ключові файли для додаткової безпеки.
