Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 37
Что-то я так и смог придумать вменяемого юскейса. Довод "процесс висит даже когда не нужен" очевидно высосан из пальца
Здравствуйте! Спасибо за комментарий, попробую ответить.
Если рассмотреть socket activation более широко, то это возможность прозрачно для пользователя запустить сетевой сервис ровно в тот момент, когда он действительно понадобился (редко используемый веб-сервер или, например, тяжеловесный сервер LLM).
Если говорить конкретно про SSH-туннелирование, то сегодня это наиболее надёжный способ выхода в мировой интернет. Подход on-demand позволяет не светить постоянным туннелем круглосуточно (появился трафик — туннель мгновенно поднялся и сам закрылся при простое).
Погодите, а разве в современной убунте не сокет за ссш отвечает? Там, вроде как, и так не процесс висит. Или я не правильно понял?
Ну так, сокет то кто-то должен открывать и читать... вот демон sshd этим и занимается. А он вполне себе процесс
Нет, там как раз systemd сокет открывает и ждет подключения.
Starting with 24.04 LTS (actually with 22.10) sshd management has changed; it is now controlled via socket activation in systemd. This is a shift from the traditional service-only model used in Ubuntu 22.04 and earlier.
New Debian based systems are moving towards systemd socket activation for SSH. In other words, the sshd.service is no longer enabled and started directly. Instead, ssh.socket is enabled and listens on TCP port 22.
When a connection comes in, it triggers ssh.service, which runs the SSH (/usr/sbin/sshd) daemon on demand.
Любой узел что светит в интернет постоянно сканируется, значит сервис останавливаться просто не будет. Какой смысл в таком решении?
Тут другой юзкейс. Ставишь себе локально и когда тебе нужна панель управления твоей CMS на удаленном хосте, где все закрыто кроме ssh, открываешь в браузере условный localhost:10201 и автоматически поднимается туннель до удаленного хоста и открывается страничка, без дополнительной писанины в терминале. Маленькая приятная автоматизация.
Здравствуйте! Всё так, спасибо за понимание кейса.
Чтобы открыть в браузере localhost:10201 всё равно придётся запустить команду ssh -L , поэтому не вижу разницы
Вручную команду запускать не нужно. Systemd сам дежурит на порту 10201. Как только браузер к нему обращается systemd автоматически поднимает ssh-туннель и передаёт ему это соединение. В этом и заключается главная фишка.
Ну если на Линуксе то да, просто он редко у кого на десктопе стоит, да и systemd не сказать чтобы сильно популярен, поэтому я почему-то подумал что вы про удалённый сервер говорите
Не понимаю. Если systemd не популярен, то что тогда?
По вашему кроме systemd нет других систем инициализации или что?
Есть, конечно. Но утверждение, что systemd не популярен, звучит очень странно. Большинство массовых дистрибутивов идёт с systemd.
Например, данные https://commandlinux.com/statistics/systemd-vs-init-usage-statistics-across-distributions/
Опередили меня с вопросом. Надо еще докручивать что-то для отделения полезного трафика от всего мусора. Речь же про "любой" пакет. Надо еще фильтровать.
Здравствуйте! Вы подняли хороший вопрос. Если выставить сокет наружу, "кто-нибудь" действительно не даст сервису уснуть. Но тут речь скорее о локальной прослушке, поэтому внешний мусор до него просто не долетит.
Раньше это делал inetd без всякого systemdа, просто в конфиге указывался порт и программа, которую дергать когда на этот порт устанавливается соединение.
Он и сейчас так же точно работает, только по умолчанию теперь не установлен, не модно.
Я думал я один про это помню )) Кстати, в emmbed'ах до сих пор используется частенько.
Не нашёл элегантного решения — написал своё.
В 1997 году я купил первую большую книгу по администтрированию Unix/Linux. В предисловии было написано: "Unix система старше вас, поэтому ваша задача наверняка уже решалась. Читайте документацию."
А автор изобрел велосипед )
Здравствуйте! Цитата из книги отличная, но мне кажется, мы рассматриваем технологию в немного разных контекстах) В ответе на самый первый комментарий под статьёй я постарался подробнее раскрыть и широту применимости этого подхода, и конкретную проблему, которую он решает сегодня.
Здравствуйте! Совершенно верно, inetd - прародитель этого подхода.
xinetd - более функциональная реинкарнация "старого" inetd, и более простой вариант для embedded, где может не быть systemd. Да, всё уже придумано до нас.
Ещё есть старый добрый knock - knock. Когда файрвол открывает нужные порты только если клиент правильно постучался в нужной последовательности в другие порты. И при этом порт нужного сервиса открывается не для всех подряд а только для того ip, который постучался. Поэтому сканеры не обнаружат сервис даже если порт открыт и используется. А у вас если я правильно понимаю сервис и порт если поднимаются и открываются, то абсолютно для всех входящих ip?
Для этих целей давно придумали inetd. Но и особенности этого подхода тоже никуда не делись.
Самая главная - безопасность сервиса будет зависеть от безопасности systemd/inetd. И если inetd это небольшая программа, давно изученная вдоль и поперёк, то systemd это огромный (чтобы не сказать монстрообразный) и активно развивающийся проект.
Я бы не советовал выставлять открытый им порт в интернет...
Мне кажется, у вас, как и у многих (и я в их числе), возникло представление, что задача решается на сервере, в то время, как автор описывает способ автоподнятия туннеля до сервера по первому «стуку» в порт на локальной машине, и вследствие этого ни о каких сервисах открывающих порты наружу, речи не идёт.
Речь о том, что вот нужен туннель до сервера допустим по FTP - клиент стучится на локальный адрес и порт, а система это видит и поднимает туннель, соединяя его с портом, куда постучали.
Тут явно напрашивается шуточка "зумеры изобрели дозвон" - но если так - это замечательно, на самом деле. Очень актуально.
(да, я тоже так понял что речь о сервере, а не о клиентской машине)
Тогда вот еще "из старого": как раз во времена интернетов по модему, с дозвонами и прочим подобным, активно использовалась программа pppd, она умела с помощью другой программы chat дозваниваться до провайдера, устанавливать соединение и т.д., причем умела делать это и "по запросу": открываем, скажем, браузер, пишем адрес - и pppd видя что нужен интернет - сама дозванивалась.
Но у нее была еще не особо известная фича: ей в общем-то всё равно что запускать, chat с модемом или ssh туннель, какой-то скрипт, или даже тупо nc, по которому потом можно пустить PPP и таким образом поднять IP-канал.
Единственно что - тут надо разделять трафик, которому канал не нужен, и тот, для которого нужен. Навскидку не вспомню, надо будет подумать, чисто ради интереса на всякий случай...
Трюк хороший, но мне мне кажется обычно лишние миллисекунды на поднятие соединения при первом обращении к сокету хуже, чем лишние занятые килобайты RAM от постоянно запущенного ssh клиента.
systemd переизобрели inetd?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SSH по требованию: что умеет socket activation и почему я перестал держать туннели открытыми