Приветствую!
В этот раз мы будем выполнять базовую настройка сервера Linux на примере дистрибутива Debian 12.
Присоединяйтесь к нашему каналу: t.me/r4ven_me и чату: t.me/r4ven_me_chat в Telegram.
Предисловие
Продолжаем тему администрирования Linux сервера. В прошлые разы мы:
Сегодня мы выполним начальную настройку сервера Debian версии 12 перед его дальнейшей эксплуатацией.
ДИСКЛЕЙМЕР
Дорогие читатели, прошу обратить ваше внимание на тот факт, что материалы на моём сайте носят рекомендательный характер. Все действия вы выполняете на свой страх и риск. Всегда делайте бэкапы важных файлов, перед настройкой виртуалок делайте снапшоты, а перед внесением изменений на продуктивных серверах всегда тестируйте их локально на собственных виртуальных машинах. Спасибо за понимание.
Иван Чёрный
Данная инструкция актуальна для настройки как виртуальных серверов, созданных, например в VirtualBox локально или у хостеров, например Virtual Private Server (VPS), так и для классических железных (bare-metal) серверов.
Если сервер установлен в VirtualBox
Создание снимка системы
Если вы настраиваете локальный виртуальный сервер, то рекомендую перед началом выполнить создание снимка системы (snapshot). Например, чтобы такое сделать в VirtualBox, нужно нажать на меню виртуальной машины:
Выбрать раздел «Снимки», нажать «Создать», указать имя и описание и нажать «Ок»:
Всё, снимок состояния создан.
Имейте в виду, что снимки состояния виртуальных машин — это не полноценная резервная копия. Это фиксация гипервизором текущего состояния машины, по сути журнал изменений, с помощью которого можно быстро откатиться на нужную точку. Хранить длительное время снимки не рекомендуется, т.к. по мере внесения изменений в ВМ, созданные снимки будут увеличиваться в размерах и ощутимо грузить хостовую систему и саму ВМ. Поэтому снапшоты рекомендуется делать перед внесением значительных изменений в системе, в качестве подстраховки. А после выполнения работ и всех проверок работоспособности — их желательно удалить.
Для восстановления, нужно выключить машину, зайти в раздел управления снимками, выбрать нужный и нажать «Восстановить»:
Создание виртуального интерфейса хоста
Для удобства связи с сервером, установленного в VirtualBox давайте создадим виртуальный сетевой интерфейс на хост системе, через который мы будем взаимодействовать с нашей ВМ, как будто мы в одной сети.
Для этого нажимаем «Файл» —> «Менеджер сетей хоста» и затем на кнопку «Создать»:
Выполним команду ip a (выводит список сетевых интерфейсов) в терминале хостовой системы, и увидим наш виртуальный интерфейс.
Теперь заходим в сетевые настройки нашей ВМ, далее «Адаптер 2» (первый не трогаем, иначе пропадет доступ в интернет), включаем его и выбираем тип подключения: «Виртуальный адаптер хоста» (виртуальный адаптер выберется автоматически) и затем «Ок»:
Запускаем ВМ. Выполним в ней ip a и узнаем имя нового интерфейса на нашем сервере. На данный момент интерфейс не активен. Чтобы его поднять выполняем:
ip link set enp0s8 up
dhclient enp0s8
Где enp0s8 имя нового сетевого интерфейса. У вас оно может быть другим.
Теперь настроим «автоподнятие» данного интерфейса при старте системы. Открываем на редактирование файл настроек сетевых интерфейсов для Debian:
vi /etc/network/interfaces
И добавляем ниже настроек основного интерфейса, настройки дополнительного. Можно просто скопировать, заменив только имя интерфейса. В моем случае это выглядит так:
Сохраняем и перезапускам ВМ:
reboot
Проверяем:
ip a
После перезапуска VirtualBox почему-то назначает следующий по списку IP (был 101, стал 102), но не будем вдаваться в нюансы работы данного гипервизора. Главное у нас есть IP адрес, который напрямую доступен из хостовой системы. В моем случае это: 192.168.56.102
Проверим связь с ВМ на хостовой машине, а также доступ в интернет у ВМ:
# на клиенте
ping -c3 192.168.56.102
# на сервере
ping -c3 google.com
Как видно, прямая связь хоста с ВМ есть, у ВМ доступ в интернет есть — можем продолжать
Чтобы можно было пользователем root подключится по SSH к ВМ с использованием пароля, необходимо изменить дефолтные значения, запрещающие это. Ниже в статье мы вновь выключим этот параметр.
sed -i 's/^#PermitRootLogin.*/PermitRootLogin\ yes/' /etc/ssh/sshd_config
sshd -t
systemctl restart sshd
После чего проверьте подключение SSH:
ssh root@192.168.56.102
Начальная настройка сервера Debian
Вводные данные, используемые в этой статье:
В данной статье, я подразумеваю, что у вас есть root доступ к серверу, так как начало настройки будет выполняться от его имени.
Открываем консоль нашей ВМ и первым делом..
Смена пароля пользователя root
Выполняем:
passwd
и дважды указываем новый пароль:
Теперь можем для удобства подключиться к серверу по SSH и продолжить настройку уже в терминале:
ssh root@192.168.56.102
Установка необходимых утилит
Теперь обновим кэш пакетов, обновим сами пакеты и установим некоторые полезные утилиты, для дальнейшей работы с сервером:
apt update && apt upgrade -y
apt install -y sudo ufw zsh software-properties-common neovim curl wget git mc fzf
Описание устанавливаемых пакетов:
Добавление нового пользователя
Если у вас уже существует локальный пользователь — можете пропустить данный шаг.
Если вы при установке Debian 12 или настройке ВМ, например, в случае VPS, не создали нового пользователя системы, то создаём:
useradd -m -G sudo -s /bin/bash ivan
passwd ivan
Где в первой команде:
- -m — ключ, который указывает на необходимость создать домашний каталог пользователя (по умолчанию в папке /home);
- ivan — это имя нового пользователя, задайте своё;
- -G sudo — ключ указывающий, добавить нового пользователя в перечисленные группы (в данном случае одна — группа sudo);
- -s /bin/bash — параметр, задающий оболочку по умолчанию, для пользователя. Я указал этот параметр для демонстрации. Если его не задать, по умолчанию пользователю назначится оболочка bash.
А командой passwd мы задаём новому пользователю пароль. По умолчанию у новых пользователей он отсутствует/отключён.
Настройка SSH на клиентском хосте
Постулатами безопасности рекомендуется не работать в Linux-based системах от имени пользователя root напрямую. Подключение под этим пользователем к удалённым серверам обычно отключают. Что и сделаем мы, но чуть позже, а пока настроим подключение с авторизацией по SSH ключу от имени ранее созданного нами пользователя.
Обратите внимание, шаги этого пункты выполняются на пользовательской системе, т.е. не на сервере.
Пару слов, про тип генерируемых ключей. Для генерации ключей используется утилита ssh-keygen, которая по умолчанию создаёт ключи типа RSA. Это довольно старый, созданный еще в 1977 году криптографический алгоритм, но который всё еще очень популярный, т.к. поддерживается большинством систем. Подробнее про него можно почитать на википедии.
Сами разработчики протокола SSH рекомендуют использовать ключи более современного алгоритма шифрования — EdDSA, а именно ed25519. Данный алгоритм основан на эллиптических кривых. Подробнее также на вики. Как утверждается, он является более безопасным и лучше оптимизирован по скорости работы. Его мы и будем использовать.
И так, на нашей desktop системе открываем терминал и генерируем новые ключи (если вы не делали этого ранее):
test -e ~/.ssh || mkdir -v $HOME/.ssh/ && chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
Командой test -e ~/.ssh || mkdir $HOME/.ssh/ && chmod 700 ~/.ssh мы проверили наличие директории файлов SSH, и если такая директория отсутствует — создаём её и выставляем правильные права.
Подробнее про механизм перенаправления и операторы управления выполнением команд можно почитать тут: Контроль выполнения команд: операторы «&&», «||», «;» и «&».
Во время генерации у вас запросят ключевую фразу для шифрования самого файла ключа. Если её задать, то при каждой авторизации с помощью данного ключа система будет запрашивать у вас пароль для расшифровки файла-ключа.
По-хорошему, нужно пароль задать, но тогда пропадает смысл «безпарольной» авторизации на удаленных системах. Тут все зависит от уровня вашей паранойи и места, с которого вы будете подключаться. Если это ваши личные проекты, то для удобства пароль можно не задавать. В этом примере я не буду задавать пароль. Для этого дважды кликаем Enter на запрос парольной фразы для ключа.
Существуют и альтернативные решения, позволяющие зашифровать файл-ключ, но при этом не вводить пароль каждый раз для его расшифровки — это использование утилиты ssh-agent. Но это тема для отдельной заметки)
После генерации в директории ~/.ssh появятся два файла:
- id_ed25519 — приватный ключ, который нельзя никому сообщать;
- id_ed25519.pub — публичный ключ, который не страшно и потерять.
Проверяем:
ls -l ~/.ssh/id_ed*
Теперь копируем наш публичный SSH ключ для входа на наш сервер специальной командой:
ssh-copy-id -i $HOME/.ssh/id_ed25519.pub ivan@192.168.56.102
Не забудьте подставить свои имя пользователя и ip адрес сервера.
При выполнении система запросит пароль нашего пользователя на сервере.
После отработки команды, в домашней директории пользователя на нашем сервере появится файл ~/.ssh/authorized_keys, где будет прописан наш публичный ключ с клиентской машины. Можем это проверить:
- На клиентской машине:
cat ~/.ssh/id_ed25519.pub
- На сервере:
cat /home/ivan/.ssh/authorized_keys
По сути, мы могли и вручную добавить этот ключ/набор символов в файл ~/.ssh/authorized_keys, но утилита сама всё делает + выставляет корректные права на файлы.
Обратите внимание, что права на чувствительные файлы SSH должны быть выставлены исключительно для владельца файлов. А именно:700 для директорий, в т.ч. ~/.ssh
600 для файлов, в т.ч. ~/.ssh/authorized_keys
Иначе система просто не позволит вам ими воспользоваться.
Теперь пробуем подключится к серверу с помощью SSH ключа:
ssh ivan@192.168.56.102
Как видим, пароль больше не запрашивается.
Теперь, успешно подключившись к серверу под новым пользователем, продолжаем настройку.
Прежде чем продолжить, хотел бы осветить еще один нюанс. С целью обеспечения большей безопасности и предотвращении нежелательных последствий — работать в консоли Linux рекомендуется от имени обычного пользователя, но у которого есть возможность выполнять команды от имени суперпользователя root.
Другими словами: подключение к системе, выполнение типичных задач, не требующих привилегий и пр. необходимо выполнять от имени обычного юзера. А при необходимости провести более серьезные манипуляции, например, внести какие-то изменения в настройки системы — то использовать команду sudo, при этом не переходя в учётную запись root.Таким образом повышается общая безопасность и уменьшается вероятность что-то случайно сломать. Конечно временами так бывает не удобно, и никто не запрещает вам просто перейти в root. Не забывайте, что сказанное выше — это рекомендация, которой просто желательно следовать.
Настройка текстового редактора по умолчанию
Читатели моих предыдущих статей уже знают, что в качестве консольного текстового редактора я предпочитаю Vim/Neovim. Если интересно узнать что это такое и почему мой выбор пал именно на него, то прошу к прочтению статьи про Vim/Neovim. Если что, мой конфиг Neovim, по мере настройки, будет дополняться в репе на GitHub.
Чтобы задать в косноли сервера редактора по умолчанию выполним команду:
echo 'SELECTED_EDITOR="/usr/bin/nvim"' > ~/.selected_editor
Создать такой файл можно также и для рута, чтобы везде были одинаковые настройки:
echo 'SELECTED_EDITOR="/usr/bin/nvim"' | sudo tee ~/.selected_editor
Вы вероятно заметили, что для выполнения той же операции, но для пользователя root мы использовали немного другую команду.
Дело в том, что если выполнить: sudo echo 'SELECTED_EDITOR="/usr/bin/nvim"' > /root/.selected_editor — то мы получим ошибку. В случае второй команды — ошибки не будет:
Особенность в том, что хоть и команда echo выполняется через sudo, но перенаправление вывода, перехватываемое оператором > выполняется все еще от обычного пользователя, поэтому мы получаем Permission denied.
В случае второй команды, наоборот: сперва выводим желаемый текст, а затем с помощью команды tee, запускаемой через sudo мы перенаправляем вывод от имени суперпользователя. В реальной практике часто можно встретить такой нюанс в работе механизма привилегий в Linux.
Команда tee — читает стандартный ввод и записывает его в указанный файл и параллельно передает на стандартный вывод.
Подробнее про стандартные ввод/вывод можно почитать в отдельной моей статье: Командная строка Linux, вывод и чтение содержимого: команды echo, cat, less.
Отключение IPv6
Не буду вдаваться в подробности, зачем нужно отключать IPv6, если он не используется. Оставлю это на самостоятельное изучение. Покажу лишь, как это делается в Linux.
Открываем на редактирование системный конфиг:
sudo nvim /etc/sysctl.conf
И в конец файла добавляем следующие строки:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
Для перечитывания конфига выполняем:
sudo sysctl -p
Настройка фаервола UFW
На каждом сервере я обязательно активирую и настраиваю сетевой экран. В ОС на базе Linux в состав ядра входит модуль Netfilter, который отвечает за обработку сетевых пакетов. Управляет этим модулем утилита iptables или ее современная версия nftables. Данные утилиты являются низкоуровневыми и их настройка это отдельная тема. Для deb based дистрибутивов существует более простоя и интуитивно понятная утилита управления фаерволом — ufw. В rpm дистрибутивах есть аналогичная программа — firewallcmd. Но так как у нас Debian 12, я использую ufw (установили её на шаге установки пакетов). Выполним базовую настройку защиты сети.
Отключаем IPv6 в UFW. Открываем на редактирование файл конфигурации ufw:
sudo nvim /etc/default/ufw
Меняем строку IPV6=yes на no :
IPV6=no
Далее открываем доступп извне к портам SSH:
sudo ufw allow 22/tcp
sudo ufw allow 27244/tcp
Где:
27244 — нестандартный порт для подключения по SSH, который мы зададим ниже в настройках SSH сервера. Стандартные порты сервисов по возможности рекомендуется менять. Т.к. они обычно сканируются ботами.
22-й же мы открыли, дабы избежать разрыва соединения и потери связи с сервером. На этом шаге будьте осторожны!
Включаем и перезапускам ufw:
sudo ufw enable && sudo systemctl restart ufw
Нас предупредят, что активация фаервола может дропнуть текущее SSH соединения. Но если вы корректно добавили правило для открытия порта 22 TCP, то все должно быть в порядке.
Если после выполнения команды вы остались на связи, то мои поздравления, продолжаем.
Посмотреть существующие правила в UFW можно так:
sudo ufw status verbose
Тут мы видим, что у нас «открыты» два порта для доступа из вне. Обратите внимание на 3-ю строку — это политика обработки пакетов по умолчанию
Т.е.
- все входящие соединения (кроме прописанных правил) отбрасывать;
- исходящие разрешены;
- маршрутизация между интерфейсами отключена.
Изменение hostname сервера и правка файла hosts
Чтобы изменить hostname нашей системы открываем на редактирование соответствующий файл:
sudo nvim /etc/hostname
Я задам такой:
r4ven-test
Также добавим наш новый hostname в файл hosts (в Linux данный файл выполняет ту же функцию, что и в Windows):
sudo nvim /etc/hosts
Добавляем:
127.0.0.1 r4ven-test
Создание swap в файле (опционально)
Если swap файл у вас отсутствует, его рекомендуется создать. swap файл может быть как отдельным разделом, так и простым файлом. Даёшь больше виртуальности!
Проверим наличие активного swap в системе:
free -m
Создание и запуск:
# создаём файл размеров 1GB
sudo fallocate -l 1G /swap
# выставляем права на чтение-запись только для владельца (root)
sudo chmod 600 /swap
# создаём swap из файла
sudo mkswap /swap
# активируем его
sudo swapon /swap
Вновь проверяем:
free -m
Мы создали swap файл и запустили его вручную. Но при перезапуске сервера он сам не запуститься. Для этого нужно добавить его в специальный файл, где перечислены файловые системы, которые монтируются при запуске системы — /etc/fstab:
echo "/swap none swap sw 0 0" | sudo tee -a /etc/fstab
Ключ -a для команды tee обязателен! Он указывает tee выполнить добавление в конец файла, а не перезаписать его.
Проверим на всякий случай fstab:
cat /etc/fstab
Пожалуйста, будьте внимательны. Добавляйте swap файл в автозагрузку, только если его создание и активация прошли успешно. Если это не так, то при следующем перезапуске системы, есть риск, что система попросту не загрузится.
Установка и настройка locales и timezone
В каждой системе есть такая сущность, как «локаль» — другими словами локализация. По умолчанию, если во время установки Debian 12, не выбрать иное, устанавливается локаль C.UTF-8 UTF-8. Давайте установим рекомендуемую английскую: en_US.UTF-8 UTF-8 и добавим русскую: ru_RU.UTF-8 UTF-8 локали. Делается это так:
# установка пакета локалей
sudo apt install -y locales
# интерактивная настройка локали
sudo dpkg-reconfigure locales
С помощью клавиши Space (пробел) ставим галочку на en_US.UTF-8 UTF-8 (обязательно) и вторую на нужную вам (в моём случае это ru_RU.UTF-8 UTF-8) локаль. Далее клавишей Tab переводим курсор на кнопку <Ok> нажимаем Enter.
Далее выбираем основную локаль, именно она будет использоваться для отображения системной информации. Английский текст меня не пугает (особенно с переводчиком), поэтому я оставлю en_US.UTF-8:
К слову у меня есть небольшая заметка на крутой переводчик: Crow Translate — Самый удобный переводчик текста.
Клавишей Tab переводим курсор на <Ok> и жмём Enter. Пара секунд и локали сгенерированы:
Теперь зададим часовой пояс для нашего сервера такой командой:
sudo timedatectl set-timezone Europe/Moscow
Список всех доступных таймзон можно посмотреть командой:
timedatectl list-timezones
Ротация системных журналов
По умолчанию в Debian GNU/Linux настроено журналирование системных событий без ограничений на количество хранимых файлов. Дабы в будущем не обнаружить полностью забитый диск журналами системы, рекомендуется задать ограничения.
В Debian 12 за инициализацию системы, в т.ч. и журналирование, отвечает программа systemd. Управления журналами выполняется определенной кутилитой из пакета systemd – journald. Ограничить количество логов с её помощью можно:
- по времени хранения;
- по размеру.
Для этого отредактируйте конфиг службы журналирования:
sudo nvim /etc/systemd/journald.conf
Где SystemMaxUse=800M – ограничение по размеру хранимых журналов, а MaxFileSec=2week – по времени.
Количество дней и размер выбирайте по вашим потребностям, ну или предпочтениям.
Не забываем сохраниться и перезапустить службу:
sudo systemctl restart systemd-journald
Если вы оказались в ситуации, когда журналы уже скопились, очистить их можно специальными командами.
По времени:
sudo journalctl --vacuum-time=15d
По размеру:
sudo journalctl --vacuum-size=800M
Настройка SSH сервера
Открываем файл конфигурации SSH сервера:
sudo nvim /etc/ssh/sshd_config
И устанавливаем следующие параметры:
# меняем стандартный порт подключения
Port 27244
# включаем использование только IPv4
AddressFamily inet
# отключаем возможность подключаться под пользователем root
PermitRootLogin no
# явно разрешаем подключения по ключу
PubkeyAuthentication yes
# отключаем подключения по паролю
PasswordAuthentication no
# отключаем авторизацию с помощью подсистемы PAM
UsePAM no
# опционально, разрешаем подключение только указанным пользователям
AllowUsers ivan
Внимание!
Пожалуйста, будьте осторожны с настройками SSH сервера. Демонстрируемая мной конфигурация сильно ограничивает возможности подключения к серверу. Разрешая подключения лишь по SSH ключам и только для указанных пользователей.Если что-то настроить неверно, вы можете потерять доступ к своему серверу. Помните, что данная статья носит рекомендательный характер. Все действия вы выполняете на свой страх и риск.
В целом, файл конфигурации неплохо документирован комментариями разработчиков. Настройка не должна вызвать трудностей.
Выполним проверку корректности конфигурационного файла специальной командой:
sudo sshd -t
Вот пример, если конфиг не прошел проверку:
Система говорит нам, что указан недопустимый параметр на строке 15. Исправим, затем вновь:
sudo sshd -t
И если вывод пустой, значит проверка прошла. Перезапускаем сервер SSH:
sudo systemctl restart sshd
Если вы везунчик и вас не дропнуло, то теперь, не отключаясь от текущей сессии SSH, откройте новое окно или вкладку терминала и попробуйте подключится к серверу. Не забывайте, что мы изменили порт подключения SSH со стандартного 22 на 27244. Чтобы команде ssh указать другой порт используется ключ -p:
ssh ivan@192.168.56.102 -p 27244
Если авторизация проходит успешно, я вас поздравляю. Если нет поговорим об этом потом, вернитесь в соседнюю сессию и проверьте, что вы сделали не так. Не закрывайте эту резервную сессию, пока не добьётесь других успешных авторизаций.
Закрытие 22-го порта в UFW
Теперь можно смело закрыть 22-й порт в ufw. Чтобы удалить правило, нужно перед командой добавления правила вставить слово delete:
sudo ufw delete allow 22/tcp
sudo ufw reload
sudo ufw status verbose
Итоговая перезагрузка
После проведения всех проверок, выполняем профилактический перезапуск сервера Debian 12, чтобы убедиться, что мы все настроили корректно:
sudo reboot
Через некоторое время пробуем вновь подключится к серверу:
ssh ivan@192.168.56.102 -p 27244
Ура, это маленькая победа) Как видим и hostname обновился.
Теперь можно, например, настроить Zshell по моей статье или еще что-нибудь.
Послесловие
Ну вот, мы выполнили начальную базовую настройку Linux сервера Debian 12. В дальнейшем на основе такой конфигурации я буду выполнять установку и настройку различного серверного ПО и, конечно, писать статьи об этом.
Так что подписывайтесь на нашу телегу, чтобы не пропустить новые материалы. Спасибо, что читаете, пингвины (:
Материалы по теме
Мои ссылки:
- Мой основной сайт - r4ven.me
- Мой телеграм - t.me/r4ven_me