Захист SSH-сервера: налаштування sshd_config для безпечного доступу

sshd типове налаштування: де ламається доступ

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

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

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

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

Кожен такий запис — ще один валідний ключ від машини, і в списку користувачів його не видно, доки не почнеш звіряти його вручну.

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

Що дає вивірена конфігурація сервера доступу

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

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

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

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

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

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

Порівняння підходів: налаштування sshd за ключами та за паролем

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

Дешевий у налаштуванні варіант зазвичай дорожчий в експлуатації: ключі потрібно видавати, відкликати при виході співробітника й ротувати.

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

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

Службові облікові записи ізолюють окремо — примусовою командою та власним правилом Match, щоб у автоматизації не було інтерактивного доступу.

Етапи впровадження: від аудиту конфігурації до передачі

Сервер доступу — єдина точка, помилка в налаштуванні якої відрізає адміністратора від машини.

Тому правки sshd_config ідуть не «за один вечір на всьому парку», а послідовністю кроків, де на кожному є спосіб повернутися назад: спочатку фіксуємо поточний стан, потім змінюємо по одному блоку й підтверджуємо вхід заново.

1. Аудит поточної конфігурації. Знімаємо робочі файли налаштування з усіх серверів, фіксуємо облікові записи, дозволені методи входу й те, хто з яких адрес реально підключається. Зводимо в один документ розбіжності між машинами — зазвичай вони й є джерелом зайвих прав.
2. Схема доступу за ролями. Розводимо адміністраторів, чергових і службові облікові записи: кому вхід за ключем, кому лише з певних адрес, які групи обмежені набором команд. Схема стає основою конфігурації, а не навпаки.
3. Тестовий контур. Копіюємо поточні налаштування на окремі машини й обкатуємо правила там, включно з перевіркою входу нових ролей.
4. Поетапна правка. Вмикаємо зміни блоками: спочатку ключі, потім відмова від паролів, потім обмеження для службових записів. Нове підключення перевіряємо в окремій сесії, поточну тримаємо відкритою до підтвердження.
5. Зворотний відкат. Перед кожним кроком зберігаємо робочу копію конфігурації й тримаємо готовий сценарій повернення: відновити файл і перезапустити службу однією дією.
6. Контроль на бойових серверах. Розкочуємо групами з паузою, щоб відмова проявилася на частині парку, а не на всіх одразу.
7. Передача документації. Віддаємо підсумкові конфігурації, регламент видачі та відкликання ключів, порядок дій при виході співробітника й пам'ятку для чергового.

Що залишається у вас після робіт: конфігурації та регламенти

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

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

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

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

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

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

Що показав аудит

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

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

Що зробили і що вийшло

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

Частка серверів з єдиним шаблоном — 100% замість двох третин. Невдалі спроби входу впали на два порядки, успішні входи з чужих адрес припинилися.

Час відкликання доступу скоротився з двох днів до 15 хвилин, розбір інцидентів входу — з тижня до пів години: журнали зіставні, бо вузли налаштовані однаково.

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

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

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

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

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

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

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

Технічні сумніви перед правкою конфігурації

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

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

Автоматизація зупиниться, якщо змінити правила входу. Як уникнути простою?

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

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

Підряднику потрібен доступ на час робіт — як видати й закрити?

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

Якщо після правки доступ зник — як повернутися?

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

Обговоримо вашу конфігурацію доступу та план робіт

Щоб оцінка була предметною, а не «на око», нам потрібен мінімум вихідних даних: перелік серверів з ролями й поточний sshd_config.

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

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

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

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

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