SSH-аутентифікація за ключами: налаштування доступу без паролів

SSH-ключі замість паролів: де ламається доступ до серверів

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

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

Перебір паролів дешевий для атакувальника: десятки тисяч спроб за хвилину на стандартному порту, слабкі паролі піддаються ще швидше.

Обмеження спроб знижує шум у журналах, але не закриває питання — одна злита пара «логін і пароль» відкриває сервер повністю, разом із ключами та даними всередині.

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

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

Нижче розбираємо на OpenSSH, які параметри відповідають за вхід за ключем, де найчастіше ламається доступ і в якому порядку вимикати паролі, щоб не втратити зв’язок із сервером.

Що змінюється після переходу на ключову автентифікацію

Пароль — спільний секрет: він витікає через листування, осідає в історії команд і в скриптах розгортання, а підбирається автоматичними сканерами за лічені години.

Щойно в конфігурації сервера з’являється заборона на вхід за паролем, цей клас відмов зникає повністю — перебір і підстановка викрадених облікових даних перестають працювати. Клієнт OpenSSH є в будь-якій актуальній гілці системи, окремий агент розгортати не потрібно.

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

Звільнення співробітника — видалення рядка або відкликання сертифіката: хвилини замість зміни паролів на всьому парку серверів.

Ручна робота адміністраторів падає: тікети «забув пароль», планова зміна спільного пароля по всій інфраструктурі та розбір блокувань після серії невдалих входів зникають із черги завдань. Залишається одна операція — додати або прибрати ключ.

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

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

Завдяки цьому керування доступом команди стає відтворюваною процедурою, а безпечний доступ до серверів — перевірюваним, а не договірним.

Варіанти доступу: SSH-ключі, паролі та сертифікати

Пароль на вході — найдешевший у налаштуванні режим і найдорожчий в експлуатації: його перевикористовують на кількох серверах, передають у листуванні й не змінюють роками, а за журналами потім неможливо зрозуміти, хто саме підключався.

Ключова пара знімає підбір пароля, але додає своєї роботи — публічні частини потрібно роздати й врахувати, приватні захистити, а при звільненні співробітника відкликати доступ на всіх вузлах, де ключ прописаний.

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

На практиці режими майже завжди комбінують: ключі — для машин і службових завдань, сертифікати — для людей, шлюз — як єдина точка входу на сервери з журналом усіх підключень.

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

Як відбувається впровадження ключового доступу в інфраструктуру

Впровадження ключового доступу починається не з генерації ключів, а з інвентаризації: хто, звідки й на які хости заходить сьогодні.

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

1. Аудит доступу до серверів: збираємо перелік хостів, облікових записів, джерел підключення та поточних authorized_keys з відбитками. Окремо позначаємо спільні ключі, вхід під root і записи, які ніхто не може підтвердити.
2. Проєктування моделі доступу: ролі (адміністратор, викладка, читання логів), окремий ключ на роль і на людину, єдиний бастіонний вузол для зовнішніх підключень замість прямих портів на кожному сервері.
3. Генерація та зберігання ключів: сучасний алгоритм підпису, парольна фраза на приватній частині, приватний ключ — лише в захищеному сховищі, до реєстру потрапляють публічні частини та відбитки.
4. Розгортання публічних ключів і конфігурації: authorized_keys через шаблони та керування конфігурацією, у sshd_config — вимкнення паролів і входу root, обмеження алгоритмів і кількості сесій. Застосовуємо без перезапуску робочих сервісів.
5. Перевірка налаштування доступу: тестовий вхід за кожною роллю, перевірка відкликання ключа й реакції журналів, контроль, що старі способи входу закриті, але аварійний канал доступний черговому.
6. Передавання ключів команді: видача захищеним каналом, готовий ssh_config з аліасами та бастіоном, порядок ротації й відкликання, коротка інструкція для нових інженерів.
7. Регламент і супровід: строк життя ключів, планова ротація, чек-лист у разі зміни ролі або звільнення співробітника, реєстр відбитків як джерело правди.

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

Що залишається у вас після налаштування доступу

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

• Конфігурації серверів — sshd_config з вимкненою парольною автентифікацією, обмеженням за користувачами й групами, лімітом спроб і таймаутом сесії, у вигляді, який переноситься в систему керування конфігурацією.
• Схема ключового доступу — які SSH-ключі куди ведуть, де зберігаються приватні частини, які вузли відкриті напряму, а які доступні лише через проміжний хост.
• Регламент випуску ключів — хто ініціює заявку, як формується пара, де живе приватний ключ, що фіксується в запиті й хто підтверджує видачу.
• Регламент відкликання — строк видалення запису з authorized_keys, порядок дій у разі звільнення та зміни ролі, перевірка, що попередній ключ більше не дає доступу.
• Документація для чергової зміни — типові симптоми (відмова автентифікації, неправильні права на каталог, переповнення журналу), що перевіряти першим ділом і до кого звертатися в разі інциденту.
• Інвентаризація доступів — таблиця «співробітник — ключ — сервер — строк дії», за якою видно, у кого доступ є і коли він має закінчитися.
• Точки моніторингу — які події пишуться в журнал (успішні та невдалі спроби, зміна складу ключів), куди вони надходять і за яким порогом спрацьовує оповіщення.

Кейс: як закрили парольний вхід у розподіленій команді

До: 140 серверів і паролі в трьох місцях

Команда з 60 інженерів на чотирьох майданчиках тримала близько 140 серверів у трьох контурах. Вхід був парольний: частина облікових записів лежала в спільному файлі, частина — у чергових, у підрядників один службовий користувач на всіх. Видача доступу займала від кількох годин до двох днів.

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

Після: особистий ключ і короткий підпис

Кожен інженер отримав особистий ключ, а сервери — довіру до підпису центру: файл із дозволеними ключами перестав бути точкою зростання, роль доступу видається параметрами сертифіката.

Строк життя сертифіката короткий, продовження автоматичне, тому відкликання — це відмова в перевипуску, а не обхід списку машин вручну.

Розгортання вели через Ansible: склад серверів і правила доступу описані декларативно, нова машина отримує ту саму політику, що й інші.

Що змінилося

Видача доступу скоротилася з днів до хвилин, відкликання — з «коли дійдуть руки» до одного строку життя сертифіката. Парольний вхід закрито на всіх серверах, включно зі стендами. Зникли три класи відмов: перебір паролів, спільний службовий вхід і живі доступи звільнених.

За журналами тепер видно, хто й коли входив, — розбір інциденту спирається на записи, а не на показання.

Що робити, якщо парольний вхід розгорнуто на всіх серверах

Так, порядок є, і він не залежить від того, скільки серверів уже працює на паролях. Спочатку ключі розкладаються на всі машини, потім перевіряється вхід за ними, і лише після цього пароль вимикається — причому не всюди одночасно.

Базове правило міграції: не буває кроку, після якого у вас залишається єдиний спосіб потрапити на сервер.

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

Окремо те, що не можна робити одномоментно: заборона пароля одразу на всьому парку, вимкнення аварійного доступу та поєднання міграції з оновленням системи. Аварійний вхід через консоль провайдера перевіряємо до перших правок — інакше є шанс залишитися без доступу до машини.

Фінальну заборону парольного входу вводимо за групами: спочатку дивимося, хто й звідки заходив, закриваємо залишки й лише потім знімаємо пароль на останній групі.

Сумніви та обмеження перед налаштуванням доступу

Ключовий доступ прибирає пароль як точку підбору, але не знімає питання експлуатації: службові облікові записи, старе обладнання, порядок зміни ключів і дії в разі втрати. Нижче — те, що найчастіше запитують перед стартом.

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

Як видавати доступ службовим обліковим записам і автоматизації?

Під сервіси заводимо окремі ключі на кожен контур, а не один спільний. У списку дозволених обмежуємо дозволену команду й забороняємо інтерактивну оболонку: ключ автоматизації вміє рівно одну дію й не перетворюється на повноцінний вхід.

А якщо частина систем не підтримує ключі?

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

Як часто змінювати ключі й хто це контролює?

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

Обговоримо доступ до серверів без паролів

Щоб обговорити налаштування доступу предметно, а не «на око», потрібен зріз вашого контуру: що є зараз і яким він має стати. Працюємо з OpenSSH — еталонною реалізацією, яка є в будь-якому сучасному дистрибутиві, тож звичний інструментарій змінювати не доведеться. Нижче — перелік, якого достатньо, щоб ми повернулися з оцінкою робіт щодо доступу та планом.

• Інвентар. Скільки серверів і середовищ, які операційні системи, чи залишилося обладнання без оновлень.
• Хто й звідки підключається. Співробітники та сервіси, статичні адреси чи динамічні, вхід напряму або через проміжний вузол.
• Що з паролями сьогодні. Спільні облікові записи, ротація, де лежать приватні ключі й чим захищені — файл, апаратний носій, сховище секретів.
• Права та ролі. Кому потрібен доступ до бойового контуру й адміністративний вхід, як розділено середовища між командами.
• Автоматика. Складальні завдання, викладка релізів, резервне копіювання — де ключ постійно живе на сервері-виконавці.
• Зовнішні виконавці та аудит. Кому видаємо тимчасовий доступ, як відкликаємо, чи потрібні журнали входів із прив’язкою до людини.
• Обмеження та вікно робіт. Що не можна змінювати, чи є тестовий контур для обкатки й коли допустимі зміни.

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