Opennet стаття - аутентифікація на ssh сервері з використанням ключів (ssh auth pam)

Переклад: Сгибнев Михайло

OpenSSH крім паролів підтримує ще кілька методів аутентифікації. Він може бути налаштований на використання методів PAM (Pluggable authentication modules), протоколу Challenge / Response, Kerberos, аутентифікації по довірених хостів і така екзотика як ключі X509. Але найпопулярнішим є метод Identity / Pubkey.

Ось деякі з позитивних моментів цього типу аутентифікації:
  • Ніхто не зможе увійти на сервер з вашим профілем, так як їм необхідно володіти приватним ключем і кодовою фразою.
  • Адміністратор сервера може взагалі прибрати пароль облікового запису, щоб виключити його дискредитацію.
  • Ви можете використовувати утиліту ssh-agent і він буде надавати аутентифікаційні дані за Вас.
  • Ви можете встановлювати певні обмеження, наприклад забороняючи перенаправлення портів, виконання певних програм і т.д.
У цій статті ми розглянемо методу створення ключів і конфігурація облікового запису.

Створення Identity / Pubkey

В оригінальній реалізації SSHv1 Ви могли створити Identity, яке було парою RSA публічного і приватного ключів. У SSHv2 формат цих ключів був змінений, стали підтримуватися ключі RSA і DSA, і ця аутентифікація була перейменована в Pubkey. У контексті даної статті ці позначення будуть використовуватися як взаємозамінні, так як реалізують ідентичні функції.

За допомогою утиліти ssh-keygen створимо необхідні ключі:
Зверніть увагу, що 'ssh-rsa. xahria @ mydesktop 'це один рядок, а не кілька.

Як Ви могли переконатися, ssh-keygen створив два файли: id_rsa і id_rsa.pub. У першому файлі зберігається приватний ключ, захищений кодовою фразою, введеної Вами при створенні, НІКОМУ не давайте копатися в цьому файлі. Другий файл - Ваш публічний ключ, він не містить ніяких таємниць і може бути доступний кожному зустрічному-поперечному. У разі втрати він може бути відновлений з приватного ключа.

Типи ключів SSH

При створенні ключів Ви вказували опцію -t rsa. Цим параметром ми вказуємо тип створюваних ключів. Також можливо створити ключі rsa1, rsa або dsa. Розглянемо їх відмінності:

Ви можете змінити ім'я файлу за допомогою опції -f filename. Якщо Ви не визначили ім'я файлу, то ключі будуть записані в каталог $ HOME / .ssh / с ім'ям, прийнятим за замовчуванням для даного типу ключа.

Дозвіл Identity / Pubkey аутентифікації на сервері

Після того, як ми створили ключі, Вам потрібно включити даний тип аутентифікації на сервері SSH. Спочатку визначимо тип аутентифікації - Pubkey або Identity, встановивши наступні настройки в sshd_config:
Наведені вище значення дозволяють аутентифікацію Identity / Pubkey для протоколу SSH версії 1 і 2, і перевіряють наявність публічних ключів у файлі $ HOME / .ssh / authorized_keys.

Перевірте наявність цих рядків у файлі конфігурації sshd_config (зазвичай він знаходиться в каталозі / etc / ssh /), при необхідності додайте і перезапустіть сервіс.

Вміст файлу authorized_keys

Файл authorized_keys просто містить список ключів, по одному в рядку. У нього ми і пропишемо ключ, згенерований нами на своїй машині.
Прядок дій наступний: копіюємо публічний ключ RSA на сервер, використовуючи scp або будь-який інший спосіб. Створюємо файл authorized_keys, якщо каталогу .ssh не існує - створюємо. Додаємо публічний ключ RSA в файл authorized_keys. Перевіряємо, встановлюємо права доступу і виходимо. Прийшла пора перевірити. що ми наваяли:
Ваш SSH клієнт буде спочатку пробувати пройти аутентифікацію по Pubkey / Identity, в разі невдачі - ідентифікацію по паролю. Він буде шукати три імені файлів, заданих за замовчуванням, якщо Ви не вказали айл ключа явно і передасть його серверу.

вибір ключів

/.ssh/config вказівку на відображення еспользуемого ключа:
Зверніть увагу, що змінна config завжди дорівнює IdentityFile, незалежно від того, використовується Pubkey або Identity.

Безпека кодової фрази

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

authorized_keys2

Більш ранні версії OpenSSH використовували два різних публічних ключа для доступу до сервера - authorized_keys для Identities (SSHv1) і authorized_keys2 для Pubkeys (SSHv2). Пізніше було вирішено, що це нерозумно і тепер використовується один файл для ключів всіх типів, але при відсутності відповідного ключа буде перевірений і authorized_keys2. Пізніші версії OpenSSH можуть цілком припинити підтримувати authorized_keys2 зовсім.

Щоб не думати про це обмеження, створимо жорстку посилання authorized_keys2 на файл authorized_keys.
Так ми задовольнимо потреби будь-якої версії OpenSSH.

Схожі статті