Иногда возникает желание поставить аутентификацию (запаролить) сайт или же папку на сайте.
Например:
Для области администрирования
Проводятся работы по разработке и рано открывать область или функционал широкому кругу пользователей
Область, предназначенная только для разработки
Необходимо закрыть от индексирования (не через специальные файлы, а совсем)
Есть желание предоставлять доступ к области только для ограниченного круга лиц
Другие причины
Генерация аутентификационного файла
Такого рода аутентификация называется Basic auth (или Http auth), подразумевает ввод логина и пароля и выглядит следующим образом
При этом, если логин и пароль не введен или введен не верно — выдает 401ю ошибку
Обычно, файл, в котором хранятся логин и зашифрованный пароль, находится по пути:
/etc/nginx/.htpasswd
Проверим, существует ли уже такой файл
$ sudo su
# cat /etc/nginx/.htpasswd
И если он не существует, создадим такой файл с пользователем user01
# htpasswd -c /etc/nginx/.htpasswd user01
Система предложит 2 раза ввести пароль, который мы заранее подготовили и сохранили. Именно этот логин (user01) и пароль будут использованы для аутентификации
Если же файл .htpasswd существует, можно добавить пользователя таким образом
# htpasswd -c /etc/nginx/.htpasswd user02
При этом, далее, можно в режиме редактирования файла убрать других пользователей, если это необходимо — удалением соответствующих строк.
Если введенные пользователь (user02) уже существует — таким образом, мы просто поменяем ему пароль…
Конфигурирование Nginx
Следующий шаг — внедрение аутентификации в конфигурацию сайта Nginx. При этом, можно закрыть как весь сайт, расположив строчки:
После добавления в конфигурацию сайте — не забываем перезагрузить nginx.
Исключения для определенных IP
Бонусом, есть возможность добавить какие то айпишники в «белый список», чтобы для них не запрашивалась аутентификация, а для остальных — запрашивались логин и пароль. Делается это следующим образом:
Предположим у нас есть сконфигурированный сервер, готовый к запуску веб-сайта (для Caddy, Nginx и Apache настраивали ранее) и так же git репозиторий (GitHub или Bitbucket) c кодом, который нужно «деплоить» в подготовленную директорию для сайта.
В данной статье будем использовать метод аутентификации на Git с помощью публичного SSH ключа.
Установим git, если ранее он не был установлен
$ sudo yum install git -y
Далее, сгенерируем SSH ключи, получаем root-права
$ sudo su
На целевом сервере переходим в домашнюю директорию
# cd ~/.ssh
И проверяем есть ли пара файлов с именем id_dsa — выводим список всех файлов в директории
# ls
Если их нету — необходимо сгенерировать. Команда для генерации ключей
# ssh-keygen -t rsa
Оставляем имя по-умолчанию (id_dsa), далее, система попросит ввести passphrase (оставляем пустым) и повторить ввод passphrase (тоже пустое)
В результате, в папке .ssh (внутри домашней директории) будет создана пара ключей — приватный и публичный (который с расширением .pub)
Распечатываем его (в нашем примере имя — gitkey.pub)
# cat ~/.ssh/id_dsa.pub
И копируем содержимое в буфер обмена для сохранения в настройках аутентификации репозитория по SSH
Давайте рассмотрим этот процесс на примере Bitbucket
Выбираем репозиторий на сайте Bitbucket, затем Repository settings — Access keys и жмем кнопку Add key
Label — даем название ключу
Key — вставляем наш публичный ключ из буфера и сохраняем — Add key
Возвращаемся к серверу, переходим к папке с проектами
# cd /var/www
И клонируем код из репозитория (в нашем примере имя репозитория domain-project) в рабочую папку для проекта (в нашем примере это папка domain-web)
Чтобы выписать сертификат, letsencrypt проверяет принадлежит ли вам домен, и делает это с помощью временных файлов, которые генерирует на сервере и проверяет их доступность
Так же нам понадобится комбинированный сертификат — cert + dhparam, который мы генерировали ранее (не забываем поменять your-domain.com на ваш домен в путях ниже)
Бонус: если вы внесли изменения в код проекта и слили в репозиторий, теперь очень просто подтянуть изменения на сервере. Примерный подход будет выглядеть так
Заходим под рутом
$ sudo su
Переходим в папку проекта
# cd /var/www/your-project-name
Переключаемся на мастер-ветку
# git checkout .
# git reset
Следующий шаг опциональный — не рекомендуется делать, если у вас не добавлены в гит-игнор все ресурсы, который могут на сервере отличаться от локальной машины (например папки vendor или uploads). Тут очищаются все файлы, которые не входят в структуру репозитория
Как альтернативу, ранее незыблемым, веб-серверам (Nginx, Apache), предлагаю использовать Caddy, который стал достаточно популярным, так как он гораздо легче разворачивается и конфигурируется, да и поддержка сертификатов тут «с коробки» (а это немаловажно в последние года, когда поисковики лучше ранжируют сайты с HTTPS, да и браузеры, ныне, показывают всякие бяки для HTTP сайтов рядом с урлом)
Подробно об установке Caddy на операционной системе CentOS можно посмотреть в официальной документации нашего облачного провайдера Digital Ocean (хостинг на котором мы настраивали ранее)