SSH по требованию: что умеет socket activation и почему я перестал держать туннели открытыми

Привет, Хабр! К написанию статьи меня подтолкнуло знакомство с механизмом socket activation в Linux, на который я случайно наткнулся и не смог пройти мимо. Технология старая, но заслуживает большого внимания, а моя статья раскрывает одно из множества потенциальных практических применений.

Говоря кратко, socket activation позволяет не держать сервис запущенным постоянно. Вместо этого systemd держит открытым только сокет, а как только на него прилетает TCP-пакет, мгновенно поднимает нужный процесс, передавая ему входящее соединение (файловый дескриптор). Для пользователя всё выглядит прозрачно: пакет ушёл и дошёл куда нужно, даже если целевой сервис изначально не был запущен.

В качестве примера использования в статье я опишу SSH-туннель по требованию, который поднимается в момент первого обращения и гасится сам, когда трафик затихает.

Кстати, короткоживущий туннель оставляет куда меньше следов в сетевом трафике, чем постоянное соединение, что может быть полезно в некоторых ситуациях (вы знаете, в каких), где желательно избежать паттерна долгого keepalive.

А теперь о реализованной задаче.

Задача банальная, а готового решения нет

Нужно прокинуть порт с удалённого сервера на локальную машину, но так, чтобы туннель не висел постоянно. База данных, админка, любой иной сервис, где туннелирование по SSH разумно — без разницы.

Что я перепробовал:

• ssh -L работает до первого дисконнекта, закрыл крышку ноутбука — туннель умер, открыл — поднимай туннель руками снова.

• autossh или bash + cron плодят зомби-процессы и держат соединение, которое висит круглосуточно, хотя реально нужно лишь периодически.

• WireGuard, OpenVPN и другие полноценные VPN — часто это просто излишество.

Не нашёл элегантного решения — написал своё.

Почему не хотелось тащить что-то новое

Главный ориентир в моей карьере — технический прагматизм. Я не люблю плодить точки отказа и дополнительные сущности, которые нужно поддерживать (зачем тащить что-то лишнее в систему, если базовые инструменты Linux умеют всё из коробки?) bash, OpenSSH и systemd умеют всё необходимое. Надо только правильно их скомбинировать.

Готовую утилиту, реализующую этот подход, я выложил на GitHub в виде проекта ondemand-ssh-tunnel.

Как это работает

Я взял то, что уже есть в любом современном дистрибутиве Linux, — systemd. А конкретно — механизм socket activation.

Жизненный цикл соединения

[systemd слушает порт] -> [Входящий TCP-запрос] -> [systemd будит сервис]         ↑                                                  ↓[Сервис убивается]                                 [SSH-туннель поднят]         ↑                                                  ↓[Таймаут бездействия]  <-----------------------    [Трафик проксируется]

Давайте взглянем на сокет

Файл: ssh-odt@.socket:

[Unit]Description=On-Demand SSH Tunnel Socket (%i)[Socket]ListenStream=@LISTEN_ADDRESS@:@LISTEN_PORT@FreeBind=yesReusePort=yesAccept=noTriggerLimitIntervalSec=10sTriggerLimitBurst=5000MaxConnections=20000Backlog=2048[Install]WantedBy=sockets.target

Разберём каждую строку:

ListenStream=@LISTEN_ADDRESS@:@LISTEN_PORT@ Адрес и порт, которые systemd будет слушать. Подставляются из конфига при установке. Именно сюда прилетает первый пакет, который будит туннель.

FreeBind=yes Позволяет сокету подняться, даже если указанный адрес ещё не назначен интерфейсу. Полезно при старте системы — сокет не упадёт, если сеть ещё не поднялась.

ReusePort=yes Разрешает нескольким сокетам слушать один порт. На практике это ускоряет перезапуск — новый сокет поднимается до того, как старый окончательно закрылся.

Accept=no Ключевой параметр socket activation. При no systemd передаёт сокет целиком в сервис… Так как сам клиент ssh не умеет напрямую работать с такими сокетами, мы будем использовать прослойку systemd-socket-proxyd (о ней — в разборе .service файла).

TriggerLimitIntervalSec=10s и TriggerLimitBurst=5000 Защита от шторма соединений. Если за 10 секунд прилетит больше 5000 активаций — systemd притормозит. На практике это никогда не срабатывает, но без этого параметра при DDoS сервис будет перезапускаться в петле.

MaxConnections=20000 Максимум одновременных соединений на сокет. Для локального проброса порта это потолок, который вы никогда не достигнете — но явно лучше, чем системный лимит по умолчанию.

Backlog=2048 Размер очереди TCP-соединений, ожидающих принятия. Пока сервис поднимается, входящие пакеты не теряются — они ждут в этой очереди.

WantedBy=sockets.target Сокет запускается вместе с остальными сокетами системы — до того, как поднимутся обычные сервисы. Туннель будет доступен с первых секунд после загрузки.

«Капкан» расставлен

Сейчас systemd висит на порту и ждёт первого TCP-пакета.

Что происходит дальше? Как только пакет прилетает, systemd автоматически ищет .service-файл с точно таким же именем (в нашем случае это ssh-odt@.service) и запускает его, передавая ему управление.

И вот здесь кроется главная хитрость. Обычный консольный клиент ssh не умеет напрямую подхватывать открытые сокеты от systemd, и если мы просто укажем запуск ssh в сервисе, то ничего не сработает, а трафик потеряется.

Чтобы подружить их, мы используем прослойку — systemd-socket-proxyd. Эта утилита из комплекта systemd берёт трафик из нашего сокета и проксирует его на локальный порт, который уже держит поднятый SSH-туннель.

Как выглядит наш сервис

Чтобы не городить сложную логику прямо в unit-файле, я написал bash-скрипт, который поднимает и сам SSH-туннель, и systemd-socket-proxyd. Вызов этого скрипта мы положим в наш сервис.

Взглянем для начала на файл ssh-odt@.service:

[Unit]Description=On-Demand SSH Tunnel Service (%i)After=network-online.targetWants=network-online.targetRequires=ssh-odt@%i.socketBindsTo=ssh-odt@%i.socket[Service]Type=simpleUser=rootStandardOutput=journalStandardError=journalExecStart=/usr/local/bin/ssh-odt.sh %iExecStopPost=/bin/sh -c 'sleep 1; systemctl start ssh-odt@%i.socket 2>/dev/null || true'SuccessExitStatus=0 1 255Restart=on-failureRestartSec=2sTimeoutStartSec=60sTimeoutStopSec=15sKillMode=mixedKillSignal=SIGTERMSendSIGKILL=yesLimitNOFILE=102400LimitNPROC=4096PrivateTmp=no

Отмечу наиболее важные моменты, без которых всё может работать не так как хотелось бы, а результат не достигнут:

BindsTo=ssh-odt@%i.socket Жестко привязывает жизнь сервиса к сокету. Если падает сокет, падает и сервис.

SuccessExitStatus=0 1 255 SSH иногда завершается с кодом 255 при дисконнектах или таймаутах. Мы говорим systemd, что это нормальная ситуация, чтобы сервис не помечался как failed (красным в логах).

ExecStopPost=… — Это главная фишка самовосстановления! Когда наш скрипт (и туннель) завершает работу по таймауту бездействия, эта строчка через секунду заново активирует сокет, который снова готов ловить новые пакеты. Без этой строчки туннель отработает только один раз.

Разберём логику вызываемого скрипта

Я не буду приводить весь скрипт с проверками переменных и логированием (полный код можно посмотреть под спойлером ниже). Разберём только три ключевых механизма, на которых всё держится.

Поднятие самого SSH-туннеля

Мы используем стандартный клиент ssh, но с обвесом из полезных флагов, чтобы он работал как надёжный демон.

# ...SSH_OPTS=(    -N # Не выполнять удаленные команды, нужен только проброс портов    -o "ExitOnForwardFailure=yes" # Упасть, если порт на той стороне занят    -o "ServerAliveInterval=15"   # Защита от зависания TCP-сессии    -o "ControlMaster=yes"        # Мультиплексирование для быстрого закрытия    -o "ControlPath=${CONTROL_SOCKET}")/usr/bin/ssh "${SSH_OPTS[@]}" \    -L "${TUNNEL_BIND_ADDRESS}:${TUNNEL_LOCAL_PORT}:${TARGET_HOST}:${TARGET_PORT}" \    "${REMOTE_USER}@${REMOTE_HOST}" &SSH_PID=$! # Запоминаем PID туннеля

Запуск прокси-прослойки

Туннель поднят и слушает локальный порт, например, 18443 (на самом деле любой свободный, так как это для внутреннего использования). Теперь нужно передать в него трафик из сокета, который открыл systemd.

# Важный нюанс: systemd передает файловые дескрипторы сокета процессу через # переменную $LISTEN_PID. Так как наш bash-скрипт является родителем, # мы должны явно подменить $LISTEN_PID на PID самого proxyd, иначе он не подхватит сокет!LISTEN_PID=$BASHPID /usr/lib/systemd/systemd-socket-proxyd \    "${TUNNEL_BIND_ADDRESS}:${TUNNEL_LOCAL_PORT}" &PROXY_PID=$!

Мониторинг бездействия

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

while true; do    sleep "${CHECK_INTERVAL}"    CURRENT_CONNECTIONS=$(ss -tn state established \        "( sport = :${LISTEN_PORT} or dport = :${LISTEN_PORT} )" 2>/dev/null \        | tail -n +2 | wc -l)    if [[ "${CURRENT_CONNECTIONS}" -gt 0 ]]; then        IDLE_COUNT=0 # Трафик есть, сбрасываем таймер    else        IDLE_COUNT=$((IDLE_COUNT + CHECK_INTERVAL))        if [[ "${IDLE_COUNT}" -ge "${IDLE_TIMEOUT}" ]]; then            break # Лимит достигнут — выходим, trap cleanup убьет процессы        fi    fidone

Полный код

#!/usr/bin/env bash## ssh-odt.sh — On-Demand SSH TCP tunnel entrypoint.# Launched by systemd socket activation (ssh-odt@<instance>.service).## Usage: ssh-odt.sh <instance-name>#set -euo pipefail# --- Instance resolution ---readonly INSTANCE="${1:?Usage: $0 <instance-name>}"readonly CONFIG_DIR="/etc/ssh-odt.d"readonly CONFIG_FILE="${CONFIG_DIR}/${INSTANCE}.conf"if [[ ! -f "${CONFIG_FILE}" ]]; then    echo "[$(date)] [${INSTANCE}] ERROR: config not found: ${CONFIG_FILE}" >&2    exit 1fi# shellcheck source=/dev/nullsource "${CONFIG_FILE}"# --- Configuration defaults ---: "${REMOTE_HOST:?REMOTE_HOST is required in ${CONFIG_FILE}}": "${REMOTE_USER:=root}": "${REMOTE_PORT:=22}": "${TARGET_HOST:=127.0.0.1}": "${TARGET_PORT:=443}": "${TUNNEL_BIND_ADDRESS:=127.0.0.1}": "${TUNNEL_LOCAL_PORT:=18443}": "${LISTEN_PORT:=8443}": "${SSH_KEY_PATH:=/root/.ssh/id_rsa}": "${IDLE_TIMEOUT:=120}": "${CHECK_INTERVAL:=10}": "${KNOWN_HOSTS_PATH:=/root/.ssh/known_hosts}": "${CONTROL_SOCKET_PATH:=/run/ssh-odt-${INSTANCE}-control}": "${PID_FILE_PATH:=/run/ssh-odt-${INSTANCE}.pid}": "${ACTIVITY_FILE_PATH:=/run/ssh-odt-${INSTANCE}-activity}"# --- Logging helpers ---log()     { echo "[$(date)] [${INSTANCE}] $*"; }log_err() { echo "[$(date)] [${INSTANCE}] ERROR: $*" >&2; }# --- Derived aliases ---readonly SSH_DIR="$(dirname "${KNOWN_HOSTS_PATH}")"readonly KNOWN_HOSTS="${KNOWN_HOSTS_PATH}"readonly CONTROL_SOCKET="${CONTROL_SOCKET_PATH}"readonly PID_FILE="${PID_FILE_PATH}"readonly ACTIVITY_FILE="${ACTIVITY_FILE_PATH}"# Track exit code across trap handler (EXIT trap fires on every exit path).EXIT_CODE=0mkdir -p "${SSH_DIR}"chmod 700 "${SSH_DIR}"# Pre-load host key if absent.if ! ssh-keygen -F "${REMOTE_HOST}" -f "${KNOWN_HOSTS}" >/dev/null 2>&1; then    log "Adding host key for ${REMOTE_HOST}..."    ssh-keyscan -H -p "${REMOTE_PORT}" "${REMOTE_HOST}" >> "${KNOWN_HOSTS}" 2>/dev/null || truefi# --- Cleanup handler ---cleanup() {    log "Cleaning up..."    ssh -S "${CONTROL_SOCKET}" -O exit dummy 2>/dev/null || true    [[ -n "${PROXY_PID:-}" ]] && kill "${PROXY_PID}" 2>/dev/null || true    rm -f "${PID_FILE}" "${ACTIVITY_FILE}" "${CONTROL_SOCKET}"    exit "${EXIT_CODE}"}trap cleanup SIGTERM SIGINT SIGHUP EXIT# Grace period for socket activation handoff.sleep 0.5# --- SSH options ---SSH_OPTS=(    -N    -o "BatchMode=yes"    -o "StrictHostKeyChecking=accept-new"    -o "UserKnownHostsFile=${KNOWN_HOSTS}"    -o "ServerAliveInterval=15"    -o "ServerAliveCountMax=3"    -o "TCPKeepAlive=yes"    -o "ExitOnForwardFailure=yes"    -o "ConnectTimeout=30"    -o "ControlMaster=yes"    -o "ControlPath=${CONTROL_SOCKET}"    -p "${REMOTE_PORT}")[[ -f "${SSH_KEY_PATH}" ]] && SSH_OPTS+=(-i "${SSH_KEY_PATH}")# --- Start SSH tunnel ---log "Starting tunnel: ${TUNNEL_BIND_ADDRESS}:${TUNNEL_LOCAL_PORT} -> ${REMOTE_HOST} -> ${TARGET_HOST}:${TARGET_PORT}"/usr/bin/ssh "${SSH_OPTS[@]}" \    -L "${TUNNEL_BIND_ADDRESS}:${TUNNEL_LOCAL_PORT}:${TARGET_HOST}:${TARGET_PORT}" \    "${REMOTE_USER}@${REMOTE_HOST}" &SSH_PID=$!echo "${SSH_PID}" > "${PID_FILE}"sleep 2if ! kill -0 "${SSH_PID}" 2>/dev/null; then    log_err "SSH process failed to start"    EXIT_CODE=1    exit 1fi# --- Start systemd-socket-proxyd ---log "Starting socket proxy -> ${TUNNEL_BIND_ADDRESS}:${TUNNEL_LOCAL_PORT}"LISTEN_PID=$BASHPID /usr/lib/systemd/systemd-socket-proxyd "${TUNNEL_BIND_ADDRESS}:${TUNNEL_LOCAL_PORT}" &PROXY_PID=$!log "Tunnel active (ssh=${SSH_PID}, proxy=${PROXY_PID})"touch "${ACTIVITY_FILE}"# --- Idle-timeout monitor ---IDLE_COUNT=0while true; do    sleep "${CHECK_INTERVAL}"    if ! kill -0 "${SSH_PID}" 2>/dev/null; then        log "SSH process exited unexpectedly"        break    fi    if ! kill -0 "${PROXY_PID}" 2>/dev/null; then        log "Proxy process exited unexpectedly"        break    fi    CURRENT_CONNECTIONS=$(ss -tn state established \        "( sport = :${LISTEN_PORT} or dport = :${LISTEN_PORT} )" 2>/dev/null \        | tail -n +2 | wc -l)    if [[ "${CURRENT_CONNECTIONS}" -gt 0 ]]; then        [[ "${IDLE_COUNT}" -gt 0 ]] && \            log "Activity detected (${CURRENT_CONNECTIONS} conn), idle timer reset"        IDLE_COUNT=0        touch "${ACTIVITY_FILE}"    else        IDLE_COUNT=$((IDLE_COUNT + CHECK_INTERVAL))        if [[ "${IDLE_COUNT}" -ge "${IDLE_TIMEOUT}" ]]; then            log "Idle timeout (${IDLE_TIMEOUT}s) reached — shutting down"            break        fi    fidonelog "Tunnel exiting"

Что это даёт на практике

Мульти-инстанс: несколько туннелей независимо

В реальных проектах прокидывать нужно не один порт. В версии 2.0 добавлена поддержка нескольких независимых туннелей.

Установка и настройка

# 1. Создаём конфигурационный файл в /etc/ssh-odt.dsudo bash install.sh install nyc3-sql-3306# 2. Правим конфигурационный файл# /etc/ssh-odt.d/nyc3-sql-3306.confREMOTE_HOST=relay.example.comLISTEN_PORT=3306TARGET_PORT=3306TUNNEL_LOCAL_PORT=13306# 3. Применяем — скрипт валидирует конфигурационный файл, рендерит юниты и запускает сокетsudo bash install.sh install nyc3-sql-3306

Каждый инстанс полностью изолирован: свой процесс, свой таймер бездействия, свой сокет. Если упадёт один — остальные продолжат работать как ни в чём не бывало. Важно отметить, что первая и последняя команда — это не опечатки, первая команда создаёт конфиг, последняя его использует.

Почему этого не было раньше?

Честно — не знаю… Может, мы привыкли решать проблемы добавлением новых абстракций, а не использованием того, что уже есть под рукой, а может я сам придумал велосипед, поэтому туннель по требованию был никому и не нужен.

Для защищённого TCP-форварда не нужен VPN. Для поддержания туннеля не нужен отдельный демон. Достаточно bash, OpenSSH и systemd — инструментов, проверенных десятилетиями, которые уже лежат в вашей ОС.

Итого

• Автоматический перезапуск при следующем обращении к сокету после разрыва

• Автоотключение по таймауту бездействия

• Мульти-инстанс: настройте столько портов и их целей, сколько хотите

• Никаких новых зависимостей — только systemd и OpenSSH

GitHub (MIT)