Захист папки сайту паролем через .htaccess і .htpasswd

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

Як це працює

Потрібні два файли:

• .htpasswd — список користувачів із хешами паролів;
• .htaccess — файл у каталозі, що захищається, який вмикає перевірку та вказує шлях до .htpasswd.

Спосіб працює на вебсервері Apache і сумісному з ним LiteSpeed — вони використовуються на більшості тарифів віртуального хостингу. Для Nginx налаштування описано наприкінці статті.

Крок 1. Створіть файл із паролями

На сервері з доступом по SSH використовуйте утиліту htpasswd. Вона входить до пакета apache2-utils (Debian, Ubuntu) або httpd-tools (AlmaLinux, Rocky Linux).

htpasswd -c -B /home/user/.htpasswd admin

• -c створює новий файл;
• -B використовує стійкий алгоритм bcrypt;
• admin — ім’я користувача.

Утиліта двічі запитає пароль. Щоб додати ще одного користувача, виконайте команду без ключа -c — інакше файл буде перезаписано:

htpasswd -B /home/user/.htpasswd editor

Видалити користувача:

htpasswd -D /home/user/.htpasswd editor

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

Крок 2. Створіть .htaccess

У каталозі, який потрібно закрити, створіть файл .htaccess:

AuthType Basic
AuthName "Restricted area"
AuthUserFile /home/user/.htpasswd
Require valid-user

• AuthName — текст, який браузер може показати у вікні входу;
• AuthUserFile — абсолютний шлях до файлу паролів на сервері;
• Require valid-user — доступ для будь-якого користувача з файлу.

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

Доступ лише для окремих користувачів

Require user admin editor

Захист одного файлу

Щоб закрити паролем один файл, наприклад сторінку входу WordPress, загорніть директиви в блок Files:

<Files "wp-login.php">
    AuthType Basic
    AuthName "Restricted area"
    AuthUserFile /home/user/.htpasswd
    Require valid-user
</Files>

Це помітно знижує навантаження від ботів, що перебирають паролі: запити відсікаються вебсервером і не доходять до PHP.

Пароль або довірена IP-адреса

Зручний варіант для офісу: з робочої адреси пускати без пароля, решту — лише за паролем.

AuthType Basic
AuthName "Restricted area"
AuthUserFile /home/user/.htpasswd

<RequireAny>
    Require ip 198.51.100.7
    Require valid-user
</RequireAny>

Щоб вимагати і адресу, і пароль одночасно, замініть RequireAny на RequireAll.

Перевірка

Відкрийте захищену адресу в приватному вікні браузера — має з’явитися вікно із запитом логіна й пароля. З консолі:

curl -I https://example.com/admin/
curl -I -u admin:пароль https://example.com/admin/

Перша команда має повернути код 401, друга — 200.

Якщо не працює

• Помилка 500. Друкарська помилка в .htaccess або неправильний шлях в AuthUserFile. Подробиці — у журналі помилок вебсервера.
• Пароль не запитується. Обробку .htaccess вимкнено. У конфігурації Apache для каталогу сайту має бути директива AllowOverride All або принаймні AllowOverride AuthConfig.
• Пароль не підходить. Перевірте шлях до файлу та права на читання для вебсервера: chmod 644 .htpasswd.
• Вікно входу з’являється повторно. Неправильний логін або пароль; регістр символів враховується.

Аналог для Nginx

Nginx не читає .htaccess. Захист задається в конфігурації сайту:

location /admin/ {
    auth_basic "Restricted area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Файл паролів створюється тією самою утилітою htpasswd. Після зміни виконайте sudo nginx -t && sudo systemctl reload nginx. Решта прикладів конфігурації — у статті про віртуальні хости Nginx.

Обмеження способу

• Лише разом із HTTPS. За базової автентифікації пароль передається під час кожного запиту майже у відкритому вигляді. Без SSL-сертифіката його може перехопити будь-хто, хто бачить трафік.
• Немає виходу із системи. Браузер пам’ятає пароль до закриття.
• Немає захисту від перебору. Сам вебсервер не обмежує кількість спроб — на власному сервері доповніть захист Fail2Ban.

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

Відеоінструкція