Nginx basic auth — аутентификация для сайта или папки сайта на Linux

Иногда возникает желание поставить аутентификацию (запаролить) сайт или же папку на сайте.

Например:

  • Для области администрирования
  • Проводятся работы по разработке и рано открывать область или функционал широкому кругу пользователей
  • Область, предназначенная только для разработки
  • Необходимо закрыть от индексирования (не через специальные файлы, а совсем)
  • Есть желание предоставлять доступ к области только для ограниченного круга лиц
  • Другие причины

Генерация аутентификационного файла

Такого рода аутентификация называется 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. При этом, можно закрыть как весь сайт, расположив строчки:

auth_basic "Restricted area";
auth_basic_user_file /etc/nginx/.htpasswd

На уровне server:

server {
    .…
    auth_basic "Restricted area";
    auth_basic_user_file /etc/nginx/.htpasswd
    ….
}

Так и на уровне какой то области (папки), в примере ниже в зоне «admin»:

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


После добавления в конфигурацию сайте — не забываем перезагрузить nginx.

Исключения для определенных IP

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

{
    …
    satisfy any;
    allow 11.22.33.44; # whitelisted IP 1
    allow 22.33.44.55; # whitelisted IP 2
    …
    deny all;
    auth_basic "Restricted area";
    auth_basic_user_file /etc/nginx/.htpasswd;
    …
}

Разворачиваем код сайта на Apache с HTTPS из репозитория на Git

Предположим у нас есть сконфигурированный сервер, готовый к запуску веб-сайта (для 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 settingsAccess keys и жмем кнопку Add key

Label — даем название ключу

Key — вставляем наш публичный ключ из буфера и сохраняем — Add key

Возвращаемся к серверу, переходим к папке с проектами

# cd /var/www

И клонируем код из репозитория (в нашем примере имя репозитория domain-project) в рабочую папку для проекта (в нашем примере это папка domain-web)

# sudo git clone git@bitbucket.org:your-user-name/domain-project.git domain-web 

Ссылку для клонирования репозитория в Bitbucket можно взять от сюда:

SourceClone — копируем код как показано ниже

И, назначаем необходимые права для системного пользователя apache

# chown apache:apache /var/www/domain-web/ -R
# chmod 775 /var/www/domain-web/ -R

Приступим к привязке бесплатного сертификата к нашему сайту

$ sudo su

Установим необходимые для SSL-шифрования пакет

# yum install mod_ssl openssl

Будем использовать наиболее известный сервис по генерации SSL-сертификатов — letsencrypt. Для этого установим Certbot

# yum install epel-release -y

(для AWS серверов команда выглядит следующим образом # amazon-linux-extras install epel -y )

# yum install certbot -y

Генерируем ключ Dh (для первой установки сертификата)

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Чтобы выписать сертификат, letsencrypt проверяет принадлежит ли вам домен, и делает это с помощью временных файлов, которые генерирует на сервере и проверяет их доступность

Создадим необходимую папку и представим права

# mkdir -p /var/lib/letsencrypt/.well-known
# chgrp apache /var/lib/letsencrypt
# chmod g+s /var/lib/letsencrypt

Подготовим конфиги для получения сертификатов — переходим в папку кончиков Apache

# cd /etc/httpd/conf.d

Создаем конфигурацию для проверки принадлежности домена (под letsencrypt)

# nano letsencrypt.conf

Вносим туда следующий код

Alias /.well-known/acme-challenge/ "/var/lib/letsencrypt/.well-known/acme-challenge/"

<Directory "/var/lib/letsencrypt/">

    AllowOverride None

    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

    Require method GET POST OPTIONS

</Directory>

И конфигурацию параметров SSL

# nano ssl-params.conf

Куда вносим следующий код

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

SSLHonorCipherOrder On

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Header always set X-Frame-Options DENY

Header always set X-Content-Type-Options nosniff

SSLCompression off

SSLUseStapling on

SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

SSLSessionTickets Off

Перезапускаем Apache

# systemctl restart httpd

Выписываем сертификат (вместо your-domain.com — указываем свое доменное имя)

# certbot certonly --agree-tos --email admin@your-domain.com --webroot -w /var/lib/letsencrypt/ -d your-domain.com

В результате успешной операции увидим поздравления:

Congratulations! Your certificate and chain have been saved at:

   /etc/letsencrypt/live/your-domain.com/fullchain.pem

Так же нам понадобится комбинированный сертификат — cert + dhparam, который мы генерировали ранее (не забываем поменять your-domain.com на ваш домен в путях ниже)

# cat /etc/letsencrypt/live/your-domain.com/cert.pem /etc/ssl/certs/dhparam.pem >/etc/letsencrypt/live/your-domain.com/cert.dh.pem

Финальный шаг — вносим изменения в файл конфигурации веб-сайта

# nano /etc/httpd/conf.d/andreyex.ru.conf

Вставляем такой конфиг (вместо your-domain.com — ваш домен, а your-domain — папочка вашего проекта)

<VirtualHost *:80>

 ServerName your-domain.com

 Redirect permanent / https://your-domain.com/

</VirtualHost>

<VirtualHost *:443>

  ServerName your-domain.com

  DocumentRoot /var/www/your-domain

  <Directory /var/www/your-domain>

   Options FollowSymLinks

   AllowOverride All

   Require all granted

  </Directory>

  SSLEngine On

  SSLCertificateFile /etc/letsencrypt/live/your-domain.com/cert.dh.pem

  SSLCertificateKeyFile /etc/letsencrypt/live/your-domain.com/privkey.pem

  SSLCertificateChainFile /etc/letsencrypt/live/your-domain.com/chain.pem

</VirtualHost>

Перезагружаем Apache

# systemctl restart httpd

Теперь ваш сайт будет доступен с https

Так как сертификат от letsencrypt будет действовать 90 дней, давайте, сделаем автоматическое возобновление сертификата

Открываем на редактирование расписание задач системы

# EDITOR=nano crontab -e

И, в конце вставляем следующую команду

0 3 */2 * * certbot renew --cert-name your-domain.com --renew-hook "cat /etc/letsencrypt/live/your-domain.com/cert.pem /etc/ssl/certs/dhparam.pem >/etc/letsencrypt/live/your-domain.com/cert.dh.pem && systemctl restart httpd"

Сохраняем (CTRL+O) и закрываем редактор (CTRL+X)

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

Заходим под рутом

$ sudo su

Переходим в папку проекта

# cd /var/www/your-project-name

Переключаемся на мастер-ветку

# git checkout .
# git reset

Следующий шаг опциональный — не рекомендуется делать, если у вас не добавлены в гит-игнор все ресурсы, который могут на сервере отличаться от локальной машины (например папки vendor или uploads). Тут очищаются все файлы, которые не входят в структуру репозитория

# git clean -d -f

забираем изменения из репозитория

# git pull

И назначаем необходимые права на папку проекта

# chown apache:apache /var/www/your-project-name/ -R
# chmod 775 /var/www/your-project-name/ -R

Можно пойти дальше и занести все эти команды в баш-скрипт, чтобы запускать все одним махом

# cd /var/www
# nano git-update-project.sh

Вставить необходимые команды, описанные выше, и сохранить

А запускаем скрипт следующим образом

$ sudo sh git-update-project.sh

Установка и настройка веб-сервера Caddy на Centos 7

Как альтернативу, ранее незыблемым, веб-серверам (Nginx, Apache), предлагаю использовать Caddy, который стал достаточно популярным, так как он гораздо легче разворачивается и конфигурируется, да и поддержка сертификатов тут «с коробки» (а это немаловажно в последние года, когда поисковики лучше ранжируют сайты с HTTPS, да и браузеры, ныне, показывают всякие бяки для HTTP сайтов рядом с урлом)

Подробно об установке Caddy на операционной системе CentOS можно посмотреть в официальной документации нашего облачного провайдера Digital Ocean (хостинг на котором мы настраивали ранее)

https://www.digitalocean.com/community/tutorials/how-to-host-a-website-with-caddy-on-centos-7

Но давайте опишу процесс ниже (и по-русски)

В одном из предыдущих туториалов мы использовали текстовый редактор vi, однако предлагаю поставить более удобный — nano

$ sudo yum install nano

Чтобы установить Caddy (не-коммерческая лицензия) запускаем

$ curl https://getcaddy.com | bash -s personal

Установка попросит ввести пароль для аккаунта операционной системы

Следующей командой можем проверить путь, куда был установлен Caddy:

$ which caddy

У меня это — /usr/local/bin/caddy

Далее, создадим пользователя, от имени которого будем работать с веб-сервером — caddy

$ sudo adduser -r -d /var/www -s /sbin/nologin caddy

Потребуется ввести пароль от аккаунта операционной системы

Создаем директорию для главного конфигурационного файла веб-сервера (Caddyfile)

$ sudo mkdir /etc/caddy

Назначаем необходимые права на директорию

$ sudo chown -R root:caddy /etc/caddy

Создаем конфигурационный файл Caddyfile

$ sudo touch /etc/caddy/Caddyfile

(чуть позже его отредактируем)

Создадим директорию для хранения SSL приватных ключей и сертификатов

$ sudo mkdir /etc/ssl/caddy

И необходимые права для этой директории

$ sudo chown -R caddy:root /etc/ssl/caddy
$ sudo chmod 0770 /etc/ssl/caddy

Также, нам нужна директория для хранения кода нашего блога (да и других будущих сайтов)

$ sudo mkdir /var/www

И необходимые права на эту директорию

$ sudo chown caddy:caddy /var/www

Теперь необходимо сконфигурировать веб-сервер Кэдди (Caddy), чтобы запускался автоматически с загрузкой системы как сервис

Скачиваем необходимый для этого файл из официального репозитория Caddy

$ sudo curl -s https://raw.githubusercontent.com/caddyserver/dist/master/init/caddy.service -o /etc/systemd/system/caddy.service

(потребуется ввод пароля для аккаунта операционной системы)

Необходимо внести мелкие изменения в скачанный файл — открываем caddy.service с помощью редактора nano (или другого любимого редактора)

$ sudo nano /etc/systemd/system/caddy.service

Находим секцию с установкой User и Group, как указано ниже

User=caddy

Group=caddy

Если User или Group отличный от caddy — меняем на caddy как в примере выше.

Сохраняем файл и закрываем (в nano редакторе это CTRL+O и CTRL+X соответсвенно)

Подбираем наш новый сервис системой:

$ sudo systemctl daemon-reload

Добавляем Caddy в автозагрузку

$ sudo systemctl enable caddy.service

И, удостоверившись, что он загружен и может быть запущен

$ sudo systemctl status caddy.service

Вывод будет примерно такой

● caddy.service - Caddy

   Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: disabled)

   Active: inactive (dead)

     Docs: https://caddyserver.com/docs/

Что говорит о том, что сервис загружен и доступен.

Последним этапом можно запустить веб-сервер Кэдди, например, командой

$ sudo systemctl start caddy

Но это будет сделано в любом случае в следующей статье, где мы установим WordPress