Обмеження спроб введення пароля в Linux для захисту SSH та сервісів

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

На невеликому сервері ці спроби можуть призвести до Піки використання процесора, зниження продуктивності та навіть епізодичні збої в роботі сервісівГарна новина полягає в тому, що Linux пропонує арсенал інструментів для обмеження спроб введення пароля, блокування агресивних IP-адрес та посилення захисту SSH, що значно ускладнює роботу зловмиснику.

Виявлення SSH-атак методом перебору та їх вплив на сервер

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

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

Для аналізу того, що відбувалося в певний інтервал, дуже корисно використовувати journalctlІнструмент systemd для читання журналів системи, служб, ядра та автентифікації. Класичний приклад запиту:

journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"

За допомогою такого запиту ви можете детально переглянути Які повідомлення система зареєструвала протягом вікна, в якому спостерігалося пікове навантаження на процесор?: служби, що перезавантажуються, помилки автентифікації, помилки ядра тощо.

У багатьох випадках ви знайдете повторювані рядки, пов'язані з SSH, такі як «Невдалий пароль для», що означає невдалі спроби входуЦе практично синонім перевірки облікових даних ботами методом повного перебору.

Кількісно підрахувати невдалі спроби у /var/log/auth.log

У системах Debian/Ubuntu ключовий файл для відстеження всього, що пов'язано з автентифікацією, це /var/log/auth.logТут реєструються успішні спроби входу в систему, невдалі спроби, події PAM, блокування облікових записів тощо.

Якщо ви хочете знати, скільки разів було записано візерунок «Невдалий пароль» у поточному журналі, ви можете використовувати:

sudo grep 'Failed password' /var/log/auth.log | wc -l

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

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

head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.log

Таким чином ви дізнаєтесь, Дата першого та останнього запису, присутнього в auth.logРешта попередніх спроб буде у файлі auth.log.1 та у стиснутих файлах auth.log.N.gz.

Щоб переглянути стиснуті старі журнали та підрахувати невдалі спроби введення пароля, ви можете скористатися:

zgrep 'Failed password' /var/log/auth.log.*.gz | wc -l

Якщо підсумувати те, що ви бачите в auth.log, auth.log.1 та auth.log.*.gz Ви отримаєте гарне уявлення про Історія атак методом грубої сили, враховуючи, що найстаріші з них, можливо, вже зникли через ротацію.

Як працює ротація журналу автентифікації

Спосіб і частота обертання колод залежить від конфігурації logrotateВ Ubuntu ротація auth.log зазвичай визначається у файлі /etc/logrotate.d/rsyslog, де зазвичай можна знайти щось на кшталт:

weekly
rotate 4
compress

Це означає, що воно Журнал ротується щотижня, зберігаються чотири старі копії, а старі стискаються у файли .gz.Щоденне завдання cron відповідає за запуск logrotate та застосування цих правил.

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

Визначення користувачів-атак та їх IP-адрес

Окрім загальної кількості, важливо знати які користувачі є ціллю атак і з яких IP-адрес здійснюються атаки?З невеликим awk на auth.log у вас це під рукою.

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

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-5)}' \
  | sort | uniq -c

А щоб побачити IP-адреси з найбільш підозрілою активністю:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | head

Це дозволить вам швидко виявити, чи вони атакують. реальні облікові записи з вашої системи або звичайні користувачі такі як root, admin, test, user тощо, а також які IP-адреси слід терміново заблокувати.

Невже це так серйозно, що спроб тисячі?

Слід припустити, що якщо ваш сервер доступний з Інтернету та має SSH прослуховує порт 22 або будь-який іншийЦей сервер отримуватиме цей тип трафіку 24 години на добу. Тисячі невдалих спроб є нормальним явищем, якщо сервер працює протягом певного часу.

Фактична сила тяжіння залежить від ваших налаштувань:

конфігурація	Приблизний ризик
Слабкі паролі + відкритий SSH до Інтернету	Дуже високий ризик компрометації
Надійні паролі	Помірний ризик, але споживання ресурсів
Правильно налаштовано Fail2ban	Низький ризик та високий рівень пом'якшення ризиків атак
Доступ лише за допомогою SSH-ключів	Ризик дуже близький до нуля через грубу силу

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

Базове посилення захисту SSH: критичні параметри в sshd_config

Перша лінія захисту знаходиться всередині тебе самого Демон SSH (sshd) та його файл конфігурації /etc/ssh/sshd_config (та пов'язані з ними D-файли). Кілька добре налаштованих директив значно зменшують поверхню атаки.

Майте на увазі, що в сучасних дистрибутивах, таких як Ubuntu 22.04 і пізніших версій, sshd спочатку читає /etc/ssh/sshd_config, а потім файли з /etc/ssh/sshd_config.d/*.conf в алфавітному порядку. Будь-що, що з’явиться пізніше, може перезаписати раніше визначені параметри, тому будьте дуже обережні зі змінами.

Вимкніть доступ без пароля та непотрібні сеанси

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

PermitEmptyPasswords no

Зазвичай це закоментовано або явно встановлено на "ні". Також переконайтеся, що у вас вимкнено функції, які ви не використовуватимете, такі як... Переадресація X11 (X11Forwarding) Якщо ви не проводите віддалені сеанси роботи з графікою:

X11Forwarding no

Щодо протоколів, якщо з якоїсь причини ви керуєте дуже старою системою, перевірте, чи дозволені лише певні дії. Протокол SSH 2:

Protocol 2

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

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

Port 2222
ListenAddress 192.168.56.8

Окрім зміни порту, ви можете вказати конкретну адресу, на якій SSH прослуховуватиметься, наприклад, вашу внутрішню IP-адресу, якщо ви хочете обмежити його певною мережею. Однак, якщо ваш дистрибутив використовує ssh.socket systemd, вам може знадобитися... Вимкніть сокет і поверніться до класичного сервісу ssh.service. дотримуватися конфігурації порту:

sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.service

Щоразу, коли ви змінюєте порт, перевірте з'єднання з іншого терміналу перед закриттям основного сеансу, щоб не залишитися без віддаленого доступу.

Блокування або обмеження root-доступу

Користувач root є легкою здобиччю для зловмисників, тому це має сенс. заборонити підключення через SSHнавіть з паролями. Ви контролюєте цю поведінку за допомогою директиви:

PermitRootLogin no

У багатьох сучасних інсталяціях він працює в режимі "prohibit-password", який запобігає входу за паролем, але залишає двері відкритими для сертифікатів. Якщо ви хочете бути в безпеці, залиште його в режимі "no" та використовуйте звичайний обліковий запис із sudo для адміністрування.

Визначення доступу для користувачів: AllowUsers та AllowGroups

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

Щоб обмежити кількість дозволених користувачів, у вас є такі директиви. Дозволити користувачам y Дозволити Групи, Наприклад:

AllowUsers harry hermione
AllowGroups gryffindor

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

Гарною практикою є робота переважно з типовими групами. ssh-користувачі або адміністратори і додайте туди авторизовані облікові записи, замість того, щоб зберігати список користувачів по одному у файлі.

Обмежте спроби автентифікації та час простою

Ще один рівень захисту всередині Зменшити кількість невдалих спроб для одного підключення і як довго сеанс може залишатися неактивним. Для першого питання ви можете використовувати:

MaxAuthTries 3

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

Щодо часу простою, SSH дозволяє завершувати з'єднання, які залишаються відкритими без активності понад визначений поріг. Інтервал активності клієнта (у секундах):

ClientAliveInterval 180

Після трьох хвилин відсутності трафіку сервер надсилатиме повідомлення keepalive, і якщо клієнт не відповідає, Сеанс закриється автоматичноЦе спосіб зменшити ризики, пов'язані із забутими, розблокованими терміналами.

Обмеження доступу за IP-адресою: TCP Wrappers та Match

У деяких випадках вас може зацікавити Доступ через SSH можна отримати лише з певних IP-адрес або діапазонівУ вас є кілька способів зробити це: від самого брандмауера (iptables/nftables), через TCP Wrappers, до блоків Match sshd_config.

За допомогою TCP Wrappers, які досі використовуються в багатьох дистрибутивах, доступ контролюється за допомогою /etc/hosts.allow та /etc/hosts.deny. Послідовність дій така: Спочатку оцінюється hosts.allow, а потім hosts.deny.Обмежувальним прикладом буде:

# /etc/hosts.deny
ALL: ALL

# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENY

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

Інший варіант, більш типовий для SSH, полягає в використанні блоків. матч у sshd_config для застосування правил на основі адреси або користувача. Уявіть, що ви хочете, щоб користувач "git" міг входити з будь-якого місця, але ваш адміністратор "greg" може входити лише з локальної мережі 192.168.1.0/24. Ви можете поєднати правила AllowUsers з Match Address, хоча ви повинні бути дуже обережні... не закривайся від себе.

Fail2ban: Автоматичні блоки проти грубої сили

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

Fail2ban написаний на Python та спирається на "в'язниці" або тюремні в'язниці, кожна з яких пов'язана з певним сервісом, та один або кілька файлів журналівКоли він виявляє повторювану схему помилок (збої пароля, заборонений доступ тощо), він запускає дії, зазвичай правила брандмауера, щоб заблокувати джерело.

Встановлення Fail2ban на поширені дистрибутиви Linux

Базова інсталяція досить проста за допомогою менеджера пакетів вашого дистрибутива. У Ubuntu або Debian цього буде достатньо:

sudo apt update
sudo apt install fail2ban

У системах на базі RHEL (RHEL, CentOS, AlmaLinux, Rocky тощо) типова команда буде with dnf або yum, залежно від версії:

sudo dnf install fail2ban

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

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2ban

Структура конфігурації: jail.conf, jail.local та jail.d

Конфігурація знаходиться в /і т.д./fail2ban/Основний файл — jail.conf, але редагувати його безпосередньо не рекомендується, оскільки він перезаписується під час оновлень. Натомість слід:

• Створення або редагування /etc/fail2ban/jail.local щоб перезаписати значення за замовчуванням.
• Або додайте певні файли до /etc/fail2ban/jail.d/*.conf.

Fail2ban завантажує конфігурацію в такому порядку:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local

Все, що ви визначаєте в jail.local, має пріоритет над усім, що було раніше, тому Ви можете налаштувати, не торкаючись файлів пакета..

Важливі глобальні параметри: bantime, maxretry, ignoreip

Усередині jail.conf (або jail.local) ви побачите розділ [DEFAULT] з глобальними параметрами, які впливають на всі джейли, якщо вони не перевизначені. Найважливіші з них:

• бантайм: час, протягом якого IP-адреса буде заблокована (у секундах) після перевищення дозволеної кількості збоїв.
• максретрія: максимальна кількість невдалих спроб перед застосуванням заборони.
• знайти час: часовий проміжок, у якому враховуються ці спроби (наприклад, 10 хв протягом десяти хвилин).
• ignoreip: список IP-адрес або діапазонів, які Fail2ban ніколи не повинен блокувати (наприклад, ваша власна публічна IP-адреса або ваша мережа керування).

Наприклад, у [DEFAULT] може бути щось подібне:

[DEFAULT]
bantime  = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

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

Налаштуйте jail sshd для зупинки SSH-атак

Найпоширенішим джейл-пакетом є SSH-джейл. У багатьох дистрибутивах він попередньо налаштований у jail.conf; вам просто потрібно активувати його або точно налаштувати його значення у jail.local. Простий приклад:

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 600
findtime = 10m

У цьому випадку, Три невдалі спроби входу, зареєстровані в auth.log протягом десяти хвилин, призведуть до десятихвилинного блокування IP-адреси зловмисника.Fail2ban впроваджує правила у брандмауер (iptables, nftables або UFW, залежно від системи), щоб з'єднання з цієї IP-адреси навіть не досягали sshd.

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

sudo systemctl restart fail2ban

Перегляд статусу в'язниць та заблокованих IP-адрес

Fail2ban містить дуже зручну утиліту керування, fail2ban-клієнтЗа допомогою цього інструменту ви можете побачити, які в'язниці активні, а які IP-адреси заблоковані. Наприклад:

sudo fail2ban-client status

Це б показало щось подібне до:

Status
|- Number of jail: 1
`- Jail list: sshd

Детальнішу інформацію про в'язницю SSHD можна знайти за посиланням:

sudo fail2ban-client status sshd

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

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

Постійні блокування та поступовий час заборони

Якщо ви хочете бути особливо суворими до рецидивістів, Fail2ban пропонує дві цікаві стратегії: постійна заборона та поступова заборона.

Щоб назавжди заблокувати будь-яку IP-адресу, яка перевищує поріг збоїв, просто введіть:

bantime = -1

З цим коригуванням, Санкціоновані IP-адреси ніколи не розблоковуються автоматичноВидалити їх вручну можна лише за потреби.

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

bantime           = 10m
bantime.increment = true
bantime.rndtime   = 0
bantime.factor    = 4
bantime.maxtime   = -1

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

• 1-й блок: 10 хвилин
• 2-й блок: 40 хвилин
• 3-й блок: 160 хвилин (~2 години 40)
• 4-й блок: навколо 10,6 годин
• 5-й блок: деякий 42 годин

Оскільки bantime.maxtime дорівнює -1, то тривалість може продовжувати зростати нескінченно, назавжди вибиваючи з гри справді важких гравців.

Використання Fail2ban поза межами SSH: Apache, WordPress, MySQL, інтернет-магазини…

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

Наприклад, для інтернет-магазину (Magento, PrestaShop, WooCommerce…) має сенс створити в'язницю, яка відстежує Журнали доступу Apache або Nginx шукають багато кодів 401/403 у /admin або /loginМінімальна конфігурація на основі Apache може бути такою:

[apache-auth]
enabled  = true
filter   = apache-auth
logpath  = /var/log/apache2/access.log
maxretry = 5
bantime  = 3600

У середовищах WordPress поширеною комбінацією є моніторинг /wp-login.php та /xmlrpc.phpЦе класичні точки входу для атак методом повного перебору та ботів. Фільтр можна розмістити у /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =

І відповідний в'язничний файл у jail.local:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/apache2/access.log
maxretry = 3
bantime  = 3600

Та сама ідея стосується й відкритих баз даних (чого зазвичай краще уникати): якщо ви хочете захистити MySQL від постійних невдалих спроб доступу, ви можете створити фільтр для Повідомлення «Користувачу заборонено доступ» у журналі помилок:

[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =

А потім у в'язницю:

[mysqld-auth]
enabled  = true
filter   = mysql
logpath  = /var/log/mysql/error.log
maxretry = 5
bantime  = 1800

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

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

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

Ідея проста: кожен легітимний користувач має пару ключів, закритий ключ, який залишається на вашому пристрої а відкритий ключ, який копіюється на сервер у файлі ~/.ssh/authorized_keys відповідного користувача.

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

Чому SSH-ключі запобігають перебору пароля

У класичній схемі з паролями зловмиснику просто потрібно спробувати ввести рядки тексту, доки один з них не збігатиметься зі збереженим паролем (або його хешем). Хоча хороший пароль має багато можливих комбінацій, Йдеться про порядки величини, як-от 10¹⁰ варіантів для середніх паролів..

Типовий 256-бітний SSH-ключ (як ті, що в Ed25519) переміщується в просторах пошуку в порядку 10⁶¹⁷ комбінаційНа практиці, математично неможливо для зловмисника вгадати закритий ключ методом перебору за допомогою сучасних комп'ютерів.

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

Генерація та перевірка SSH-ключів на клієнті

Перш ніж звертатися до сервера, перевірте, чи на вашому комп'ютері вже згенерована пара ключів SSH. Просто перелічіть вміст ~/.ssh:

ls -l ~/.ssh

Якщо ви бачите файли типу id_ed25519 та id_ed25519.pub Якщо у вас є id_rsa та id_rsa.pub, у вас вже є дійсна пара. Ed25519 є сучаснішим та легшим, тому зазвичай це найкращий варіант у наші дні.

Якщо у вас немає ключів, згенеруйте нові за допомогою:

ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"

Команда створить два файли:

• id_ed25519: закритий ключ, яким ніколи не слід ділитися.
• id_ed25519.pub: відкритий ключ, який можна скопіювати на сервери.

Ви можете переглянути вміст відкритого ключа за допомогою:

cat ~/.ssh/id_ed25519.pub

Скопіюйте відкритий ключ на сервер і перевірте доступ

На сервері переконайтеся, що каталог ~/.ssh існує для користувача, від імені якого ви входите в систему (наприклад, git або ваш адміністратор), і що він має дозволи 700:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Потім додайте вміст id_ed25519.pub вашого клієнта до ~/.ssh/авторизовані_ключі (створення файлу, якщо його не існує) та надання йому прав доступу 600:

echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Не забудьте замінити YOUR_PUBLIC_KEY на повний рядок, який ви бачили, використовуючи `cat` на вашому комп'ютері. Звідти ви можете перевірити з'єднання, явно вказавши ключ, якщо бажаєте.

ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDOR

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

Повністю вимкнути PasswordAuthentication на сервері

Після того, як ви переконаєтеся, що можете отримати доступ до свого облікового запису за допомогою пароля принаймні з одного пристрою (в ідеалі з двох, на випадок, якщо ви один загубите), варто Вимкнути вхід з паролем для SSHЦе припиняє в зародку будь-яку спробу класичної грубої сили.

Перш ніж торкатися конфігурації, варто перевірити, які файли визначають PasswordAuthentication, оскільки в багатьох сучасних інсталяціях Існують D-файли, які перезаписують значення основного sshd_config.:

sudo grep -R "PasswordAuthentication" /etc/ssh/

Часто можна знайти щось на кшталт:

/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication no

У такому випадку ефективною конфігурацією буде "так", оскільки файл 50-cloud-init.conf завантажується пізніше та перезаписує значення. Ви можете перевірити кінцевий результат, який застосовує sshd, за допомогою:

sudo sshd -T | grep passwordauthentication

Щоб вимкнути справжні паролі, відредагуйте відповідний файл (наприклад, /etc/ssh/sshd_config.d/50-cloud-init.conf) і залиште:

PasswordAuthentication no

Потім перезапустіть службу SSH:

sudo systemctl restart ssh

І ще раз перевірте за допомогою:

sudo sshd -T | grep passwordauthentication

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

Поєднання SSH-ключів з Fail2ban та іншими заходами

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

Якщо ця комбінація Тільки SSH-ключі + Fail2ban + root-блокування + точно налаштовані списки AllowUsers/AllowGroups Додайте обмежувальний брандмауер (iptables/nftables, UFW, firewalld) та, за потреби, списки контролю доступу з TCP Wrappers, і ви зменшите ймовірність вторгнення методом грубої сили до незначного рівня.

У ще більш делікатних середовищах ви можете піти далі та запровадити двофакторна автентифікація (2FA) для SSHвикористання модулів, таких як Google Authenticator або подібних, через PAM, або навіть обмеження доступу до SSH-порту за допомогою виділених VPN.

Завдяки добре інтегрованим усім цим елементам — виявленню журналів, ретельному налаштуванню sshd, широкому використанню Fail2ban, ключам SSH замість паролів і, за необхідності, елементам керування на основі IP — сервер Linux може обробляти постійні атаки методом перебору на SSH та інші незахищені сервісизберігаючи при цьому зручний та безпечний доступ для адміністраторів.