Комментарии 6
Уже простите за занудство, но за ручную правку sshd_config нужно бить не только по рукам, но и по голове. Для пользовательских настроек существует папка sshd_config.d.
Ну и тащить iptables-persistentв Ubuntu 24.04 совсем моветон. Т.к. там изначально уже работает nftables. И простые правила nftables выглядят не страшнее правил iptables.
P.S. Сейчас все меняется очень быстро (впрочем как и всегда). Хорошие наработки двухлетней давности могут быть устаревшими (deprecated). А работать с этим "свеже-настроенным" наследием (legacy) придется пару лет. Пока дистрибутив не уйдет с поддержки.
Спасибо за обстоятельный комментарий, замечания справедливые.
От изменения части компонентов описанная стартовая конфигурация в целом никак не изменится. Зачастую самое тяжелое legacy – именно код, который будет запущен на сервере. Заметный разброс версий операционной системы появляется только из соображений совместимости.
Мы не говорим про ультрасовременный технологически перенасыщенный стартап, где самые современные решения зачастую применяются только ради самих технологий и шумихи.
Мы говорим про случай, когда нужно быстро запустить небольшой сервис в облаке. Опытный администратор всегда отдаст предпочтение уже проверенной конфигурации. Нет ничего криминального в том, что она будет построена на не самой актуальной базе.
Я не оправдываю использование неподдерживаемых компонентов — ПО надо обновлять своевременно. Однако даже у именитых российских и зарубежных вендоров есть решения, в том числе в области безопасности (!), под капотом которых можно с удивлением обнаружить Debian 7.
Объясните, в чём преимущества использования учётки admin со входом по SSH-ключу и запуск sudo без ввода пароля по сравнению с подключением с аналогичным ключом, но сразу под root'ом?
Я в курсе "хорошего тона" не пользоваться системой по умолчанию от имени привилегированного пользователя, чтобы ненароком не сломать что-то и не бояться оставлять терминал без присмотра, но когда в привычку входит перед каждой командой писать sudo, смысл этого трюка несколько теряется. Особенно это касается "рабочих" систем, на которых большая часть выполняемых действий требует прав рута.
По моему опыту, удобнее подключиться root'ом с ключом, обязательно защищённым паролем и опционально лежащим в ssh-агенте, выполнить нужные команды и отключиться. Ну или сначала зайти под кастомной учёткой с нетипичным логином, а потом набрать su -.
аудит линукса различает операции, сделанные от рута, и сделанные от юзера с повышением. если на сервере будет происходить что-то необычное, то легче будет разобраться, где канал утечки
сервером могут рулить несколько человек. персонифицированные учетные записи с персональными ключами явно лучше, чем одна общая учетка. Опять же - уволился кто-то - можно просто заблочить аккаунт
В качестве идеи для следующей статьи - как обойтись без fail2ban: рассказать про настройки с использованием новых openssh фич (Penalties).
Не дать угнать за 60 секунд: автоматизируем базовую настройку облачного сервера