Comments 21
а почему автор считает, что сервер по умолчанию будет на чем то отличном от венды?
а вдруг на вендовсе сервере каком нить?
Если уж меняем рут на что-то другое, то есть смысл указать рандомное имя, а не админ. Остальное на удивление ёмко и по делу. Спасибо!
Если у вас mkdir -p ~/.ssh таки выполнится - вы потом долго будете дебажить, почему вход по ключу не работает. Права на директорию и файл должны быть 0700 и 0600 соответственно.
Двухфакторный вход при логине по ключу не имеет большого смысла, и будет очень сильно усложнять жизнь впоследствии. Хотите тут безопасности - используйте аппаратное хранилище ключей.
ufw с docker дружатся, мягко говоря, неочевидно. Да и в целом, у nftables на удивление простой и приятный синтаксис, так что лишний уровень абстракции в виде ufw не особо что упрощает, а когда захочется подкрутить что-то посложнее - наоборот, мешает.
Эта проблема впоследствии решается Ansible. Например, у меня он сам после работы CI/CD ходит и выдирает из .env'ов и docker-compose.yml'ов значения, которые потом прописывает в ufw allow.
Но сразу говорю, что мой совет из разряда "проблема воробьёв решается пушкой". Юзать Ansible на этапе, когда это твой первый сервер в жизни — это лютый оверкилл.
Я лично до использования Ansible дорос самостоятельно, просто потому что личных серверов уже за два десятка перевалило.
Ну про Ansible я не стал писать ровно по этой же причине, что для первого сервера пока рановато. Хотя, с другой стороны, это очень сильно дисциплинирует записывать (и тем самым документировать) все свои настройки. Ну и в случае переноса на новый сервер разворачивать всё там одной командой (ну почти одной, юзера-то создать и SSH настроить придётся руками - разговор про Cloud-Init и тем более Terraform у нас тоже впереди...)
Но с firewall'ом и тут, на мой взгляд, ufw только добавляет сложности. Хоть для него и есть community.general.ufw, но для чистого nftables куда удобнее сделать каталог /etc/nftables.conf.d/, куда Ansible'ом класть по шаблону файлик для каждого сервиса. А что-то более или менее сложное без ручной магии с /etc/ufw/before.rules всё равно не настроить, и вот тут уже начинаются чреватые ошибками костыли.
KbdInteractiveAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication это на самом деле алиас для KbdInteractiveAuthentication. То есть эти две штуки это одно и то же, но ChallengeResponseAuthentication позже могут и выкинуть на фиг.
KbdInteractiveAuthentication=yes на самом деле делает возможным вход по паролю, так что последующая PasswordAuthentication=no становится бесполезной и дает вам только иллюзию безопасности.
Выданный вам начальный рутовый пароль вообще-то надо сразу поменять на свой. Просто потому что ломать пароль вам все равно будут из-за KbdInteractiveAuthentication=yes а изначальный пароль скорее всего а) простой и б) еще часто посылается клиенту по электронной почте и, таким образом, тихо-мирно ждет своего часа.
Про права доступа на файлы authorized_keys уже написали комментом выше.
Нет никакого упоминания о том, что надо на первом коннекте по ssh сверить слепок серверного ключа. А то вдруг у вас там с самого начала MitM, а вы и не в курсе.
Так и подмывает спросить, а когда будут советы по настройке сервера от уборщицы, которая полы мыла в машинном зале?
Фронтендер не должен заниматься настройкой сервера.
Ufw — какое-то очень странное поделие, которое генерит правила в стиле iptables, а затем скармливает их ему, притом что iptables уже довольно давно является устаревшим и по сути ещё раз преобразует правила уже в формат nftables. И я вот не помню, нужно ли в ufw отдельно разрешать исходящий трафик.
Есть сомнения в необходимости использования двухфакторной аутентификации при использовании SSH ключей.
Почему бы не использовать ключи на эллептических кривых? Как для SSH, так и для Web сервера.
Fail2ban для SSH сомнительное решение. Если отключили вход по паролю, то в целом подбор паролей ботами только логи засирает. Но эти боты прекрасно распознают настройки fail2ban, и долбятся с разных IP. И тут либо белые списки, либо knok-knok (или как там оно называется, когда чтобы порт тебе открыли, надо постучаться на какие-то другие порты в определённой последовательности).
История про работу из под root тоже уже порядком достала. Если ты один админишь машину, то проще сразу под рутом логиниться по ключу. Всё равно первой командой после логина будет sudo -i. Ну или будешь ко всем командам приписывать sudo в начале. А вся эта история с безопасностью — это когда пишут правила для sudo, кому какие команды можно выполнять и под какими пользователями. Но тут надо ооочень грамотно подходить к вопросу, т.к. методов подняться до рута в этом случае ну очень много.
По правам на каталог ~/.ssh уже сказали.
Фронтендер не должен заниматься настройкой сервера.
Вот меня всегда поражает этот корпоративный снобизм. Конечно, если фронтэндер решил запилить свой проект, он должен взять кредит на многомиллионов, нанять бэкэндера, архитектора, пару аналитиков, девопса, девсекопса, тестировщика, маркетолога, бухгалтера, финансиста, юриста, водителя и секретаршу, - чтобы не дай Бог не сделать чужую работу... и поняв, что MVP не взлетел, подавать на личное банкротство :)
Снобизм? Ну так советы от этого фронтендера такие себе. Работать, конечно, будет, но больше смахивает на то, что человек где-то что-то услышал, но толком не разобрался что это и для чего.
Ну и если это не страничка визитка, то подразумевается ещё и бекенд. Его тоже фронтендер писать будет? И тоже советы тут будет давать?
Ведь, одно дело пилить проект для себя, а другое дело советы раздавать. Я вот немножко программирую на Си, Питон, JS, Bash... Но как-то советы раздовать по этому поводу мне хватает компетенции не раздавать, т.к. я прекрасно понимаю, что программист из меня паршивый.
Насчёт того, что с написанием гайдов для Хабра автор поторопился, я полностью согласен, ему тут по делу накидали даже относительно того, что он описал (а это только самая база и верхушка айсберга) Но стремление познавать смежные области я только поддерживаю. Когда сам разберёшься - уже и делегировать другим будет проще осознанно, если до этого дойдёт.
Перестаньте править sshd_config! Это файл системных настроек. Который может быть затерт при обновлении системы. Для пользовательских настроек есть каталог sshd_config.d.
Зачем RSA ключи для новых систем в 2025 году? Они скорее понадобятся для старых систем и старого оборудования. Для остального есть ed25519.
Зачем ufw в новом сервере в 2025 году? Debian12, Ubuntu 22.04-24.04 используют nftables.
ИМХО. Из-за отсутствия поддержки nftables в Docker, лучше перейти на Podman. Правда проскакивала информация, что новую версию Docker переведут на nftables. Но срок пока не определен.
Перестаньте править sshd_config! Это файл системных настроек. Который может быть затерт при обновлении системы. Для пользовательских настроек есть каталог sshd_config.d.
Все дистрибутивы, с которыми я сталкивался, в случае, если конфиг изменён пользователем, при обновлении в интерактивном режиме спрашивали, перезаписать ли его (по умолчанию предлагая оставить), в unattended режиме - молча оставляли пользовательскую версию. А вот если конфиг не менять - его правда молча перезапишет, и не факт, что очередное обновление не добавит каких-то новых дефолтных настроек, которые надо бы переопределить.
Из-за отсутствия поддержки nftables в Docker, лучше перейти на Podman.
Ну на самом деле docker с nftables работает, он вызывает iptables-nft, который транслирует правила в формат nftables. Беда в том, что если потом хочется добавить свои правила и перезапустить nftables - всё это автомагическое творчество docker'а сбрасывается. С podman ровно та же история, не заметил практической разницы. В общем, если есть автоматическая настройка правил nftables, например через Ansible, и что-то не вполне тривиальное, - то проще docker'у в настройках запретить создавать правила, вручную определять его сети и задавать правила для них.
Спасибо за статью!
Дополнительно можно обратить внимание на автоматические обновления безопасности для дистрибутива (например, с помощью unattended-upgrades в Ubuntu), чтобы своевременно получать патчи уязвимостей. Также не лишним будет настроить мониторинг (например, Netdata или Prometheus + Grafana) — так можно быстро реагировать на рост нагрузки или подозрительную активность. В остальном, для первого развёртывания fullstack-проекта этого гида более чем достаточно!
Ctrl+O– сохранить файл.
Мне кажется, в nano для сохранения используется Ctrl+S
Базовая настройка, под определенные нужды. Нет ничего плохого или хорошего в этом, просто гайд для людей которые чего то недопонимают. (Люди которые понимают, им он в принципе не нужен, те люди которые не понимают, не набив шишек не поймут). К сожалению, не нашел тут тип OS, на сколько понял что то Дебиан подобное (Вероятнее всего убунту). Так же видел комментарий по поводу Windows server, вообще проект и на IIS можно запилить, а вот стоит ли, это уже другой вопрос. Считаю , то что статья должна быть продолжением чего то изначального, если был посыл показать, как проще настроить свой сервер (локальный само собой).
Как настроить свой первый сервер: инструкция от фронтендера