Настройка безопасного SSH‑туннеля через Termux‑OpenSSH с поддержкой двухфакторной аутентификации и автоматическим ротационным управлением ключей

SSH‑туннель — один из самых практичных способов безопасно прокладывать защищённый канал между устройством и сервером. В сценариях, когда требуется доступ к внутренним сервисам, корректно настроенный туннель позволяет переносить трафик прозрачно и с шифрованием. В этой статье мы рассмотрим настройку безопасного SSH‑туннеля в Termux с использованием Termux‑OpenSSH, добавим двухфакторную аутентификацию и реализуем автоматическое ротационное управление ключами, чтобы снизить риски компрометации.

Материал ориентирован на администраторов и технических специалистов. Все шаги предполагают, что у вас есть доступ к серверу (например, по консоли/су) и возможность изменять конфигурации SSH.

Архитектура решения

Целевая схема:

Termux‑клиент генерирует/хранит ключи для SSH и подключаетcя к серверу через туннель.
SSH‑сервер защищается от перебора паролей и поддерживает 2FA (например, через TOTP или FIDO2/сертификаты — зависит от вашей инфраструктуры).
Ротация ключей проводится автоматически: клиент получает новый ключ, сервер принимает его только после обновления, а старый ключ удаляется по расписанию.

Важно: ротация ключей — не замена 2FA. Она дополняет защиту, сокращая время жизни потенциально скомпрометированных ключей.

Требования

Android‑устройство с Termux.
Сервер с установленным OpenSSH (или совместимым SSH‑демоном).
Доступ к настройке сервера: редактирование /etc/ssh/sshd_config и настройка модулей 2FA.
Учетная запись, для которой будет настраиваться доступ по ключам.

Установка Termux‑OpenSSH и базовой среды

Откройте Termux и обновите пакеты, затем установите OpenSSH‑компоненты:

pkg update -y
pkg upgrade -y
pkg install openssh termux-openssh -y

Проверьте доступность клиента:

ssh -V
ssh-keygen -V

Создайте каталог SSH на клиенте:

mkdir -p $HOME/.ssh
chmod 700 $HOME/.ssh

Генерация ключей для SSH и подготовка к ротации

Для автоматизированной ротации удобно разделять ключи по «поколениям». Например, id_rsa_1, id_rsa_2 или единый тип ключа с версионированием.

Рекомендуемый алгоритм для совместимости и практики — Ed25519. На стороне сервера должен быть включен прием данного типа ключей.

Сгенерируйте первый ключ‑пакет:

ssh-keygen -t ed25519 -f $HOME/.ssh/id_ed25519_1 -C "termux-ssh-tunnel-$(date +%Y%m%d)"

Установите права на приватный ключ:

chmod 600 $HOME/.ssh/id_ed25519_1

Публичный ключ используйте при добавлении на сервер (файл $HOME/.ssh/id_ed25519_1.pub).

Включение 2FA на SSH‑сервере (концептуально)

Для двухфакторной аутентификации на SSH есть несколько типовых подходов:

Модуль на основе TOTP (одноразовые коды из приложения аутентификатора).
Модуль на основе ключей FIDO2 (аппаратные ключи безопасности).
Другие корпоративные механизмы через PAM/плагины.

Наиболее универсальный путь в Linux — настройка через PAM с плагином 2FA (конкретный пакет зависит от дистрибутива и вашей политики безопасности). Ниже приведены шаги высокого уровня, а не привязка к конкретному пакету 2FA, чтобы сохранить применимость для разных систем.

Общий принцип: включите в /etc/pam.d/sshd модуль 2FA и убедитесь, что логин по SSH требует подтверждения второго фактора. После этого ограничьте доступ к SSH: запретите логины по паролю (в идеале) и оставьте только ключи + 2FA, либо ключи + 2FA при необходимости.

Минимально необходимая настройка sshd_config

Внесите изменения в серверный /etc/ssh/sshd_config. Включите безопасные базовые параметры:

sudo nano /etc/ssh/sshd_config

Пример безопасного профиля (подстраивайте под вашу среду):

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes

PermitRootLogin no
AllowTcpForwarding yes
GatewayPorts no

X11Forwarding no
PermitTunnel yes

UsePAM yes

# Ограничение алгоритмов при необходимости:
# Ciphers aes256-gcm@openssh.com, chacha20-poly1305@openssh.com
# KexAlgorithms curve25519-sha256, ... 
# MACs hmac-sha2-512, hmac-sha2-256

После правок проверьте конфигурацию и перезапустите SSH:

sudo sshd -t
sudo systemctl restart sshd || sudo service ssh restart

Проверка:

sudo systemctl status sshd || sudo service ssh status

Схема ключей на сервере: AuthorizedKeys и версия

Для упрощения ротации используйте подход, при котором сервер хранит ключи в отдельном include‑файле. Например:

Основной файл: /home/<user>/.ssh/authorized_keys
Или отдельный include‑файл (зависит от конфигурации SSH)

Минимально универсально: обновляйте authorized_keys (или список ключей) при ротации.

На сервере подготовьте домашний каталог пользователя и права:

sudo mkdir -p /home/<user>/.ssh
sudo chmod 700 /home/<user>/.ssh

Убедитесь, что authorized_keys существует и права корректные:

sudo touch /home/<user>/.ssh/authorized_keys
sudo chmod 600 /home/<user>/.ssh/authorized_keys
sudo chown -R <user>:<user> /home/<user>/.ssh

Добавление текущего ключа на сервер

Скопируйте публичный ключ с Termux на сервер. Варианты:

Ручное добавление через cat + вставка.
Передача по существующему защищённому каналу.

Ручной способ наглядный: откройте публичный ключ:

cat $HOME/.ssh/id_ed25519_1.pub

Вставьте его в конец /home/<user>/.ssh/authorized_keys на сервере.

Права и владелец обязательны, иначе SSH может игнорировать ключи.

Настройка безопасного SSH‑туннеля из Termux

Предположим, что у вас есть:

SSH‑сервер: server.example.com
Пользователь: <user>
Локальный сервис (например, на сервере): 127.0.0.1:8080 или localhost:8080
Вам нужен локальный проброс на Termux.

Команда туннелирования через локальную пересылку (local forwarding):

ssh -i $HOME/.ssh/id_ed25519_1 -o IdentitiesOnly=yes 
    -o ServerAliveInterval=60 -o ServerAliveCountMax=3 
    -N -L 127.0.0.1:18080:127.0.0.1:8080 
    <user>@server.example.com

Разберём параметры кратко:

-N — не выполнять удалённую команду, только туннель.
-L — локальная пересылка: Termux слушает 127.0.0.1:18080 и отправляет на сервер 127.0.0.1:8080.
ServerAliveInterval и ServerAliveCountMax — помогают удерживать соединение и быстрее выявлять обрывы.

Для проверки откройте локально на Termux, например:

curl -sS http://127.0.0.1:18080/ | head

Если 2FA настроена корректно, SSH потребует подтверждения второго фактора при входе.

Укрепление безопасности туннеля

Дополнительные практики:

Сервер: отключите устаревшие алгоритмы и разрешайте только современные шифры/ключи.
Клиент: включайте строгую проверку хоста, чтобы не принимать поддельные сервера.
Ограничьте аккаунту доступ только к нужным командам (если применимо) и храните ключи в минимальном наборе.

Пример включения строгой проверки хоста:

ssh -i $HOME/.ssh/id_ed25519_1 -o IdentitiesOnly=yes 
    -o StrictHostKeyChecking=yes 
    -o UserKnownHostsFile=$HOME/.ssh/known_hosts 
    -N -L 127.0.0.1:18080:127.0.0.1:8080 
    <user>@server.example.com

Если вы впервые подключаетесь к серверу, известный хост необходимо заранее добавить (один раз безопасно).

Автоматическая ротация ключей: подход без «опасных» обходов

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

Provisioning (выдача нового ключа): клиент генерирует новый ключ, отправляет публичную часть на сервер и активирует его.
Retire (вывод старого ключа): после успешного подтверждения подключения новым ключом старый ключ удаляется.

Если вы удалите старый ключ слишком рано, вы можете потерять доступ. Поэтому важно иметь «окно перекрытия», когда на сервере одновременно активны два ключа.

Вариант ротации через scheduled script на клиенте (Termux)

Ниже пример структуры. Логика подразумевает, что вы можете добавлять ключ на сервер существующим способом (например, при наличии текущего валидного ключа и корректной 2FA‑политики). В некоторых организациях добавление новых ключей выполняет отдельный администраторский процесс. Мы показываем рабочий шаблон.

1) Скрипт на Termux: генерировать новый ключ с версией, затем обновлять authorized_keys на сервере.

cat > $HOME/rotate_ssh_keys.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

SERVER_HOST="server.example.com"
SERVER_USER="<user>"
KEY_DIR="$HOME/.ssh"
CURRENT_KEY="$KEY_DIR/id_ed25519_current"
BACKUP_KEY="$KEY_DIR/id_ed25519_previous"

# Ведём ссылки “current/previous” для удобства
# При первом запуске current может отсутствовать — это нормально.

ts="$(date +%Y%m%d%H%M)"
NEW_KEY="$KEY_DIR/id_ed25519_$ts"
NEW_PUB="$NEW_KEY.pub"

# 1) Сохраняем предыдущий “current” как previous (если он существует)
if [ -L "$CURRENT_KEY" ] || [ -f "$CURRENT_KEY" ]; then
  mv -f "$CURRENT_KEY" "$BACKUP_KEY" 2>/dev/null || true
fi

# 2) Генерируем новый ключ
ssh-keygen -t ed25519 -f "$NEW_KEY" -C "termux-ssh-tunnel-$ts" -N "" >/dev/null

chmod 600 "$NEW_KEY"

# 3) Обновляем remote authorized_keys:
# ВАЖНО: добавление должно быть реализовано безопасно.
# Ниже — шаблон: вы добавляете NEW_PUB в authorized_keys на сервере,
# а затем удаляете старый ключ после успешной проверки.
#
# Адекватный production‑подход: использовать отдельную команду на сервере,
# ограниченную в sshd_config/ForceCommand, или управлять через deployment-процесс.
#
# Пример (шаблон) — добавим ключ:
ssh -i "$BACKUP_KEY" -o IdentitiesOnly=yes 
  "$SERVER_USER@$SERVER_HOST" 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && 
   grep -qxF $(printf '%q' "$(cat $NEW_PUB)") ~/.ssh/authorized_keys || 
   cat >> ~/.ssh/authorized_keys < ""$NEW_PUB"""

# 4) Переключаем “current” ссылку на новый ключ
ln -sf "$NEW_KEY" "$CURRENT_KEY"

echo "New key provisioned: $NEW_KEY"
EOF
chmod +x $HOME/rotate_ssh_keys.sh

Примечание: приведённый блок — шаблон. Команда вставки ключа на сервер должна корректно передавать содержимое публичного ключа и учитывать кавычки/экранирование. В реальной эксплуатации мы рекомендуем использовать управляемый механизм (например, скрипт на сервере, принимающий ключ через stdin/с ограничениями) и обязательно тестировать на стенде.

2) Проверка работоспособности новым ключом (активация “вперед”). Например, попытка поднять туннель:

$HOME/rotate_ssh_keys.sh
ssh -i $HOME/.ssh/id_ed25519_current -o IdentitiesOnly=yes 
  -N -L 127.0.0.1:18080:127.0.0.1:8080 
  <user>@server.example.com

3) Окончательная утилизация старого ключа — после того, как вы уверенно убедились, что новый ключ проходит и 2FA отрабатывает штатно. Обычно это делается следующим скриптом, либо той же логикой с дополнительным этапом.

Ротация: где лучше исполнять удаление старых ключей

Безопаснее всего, когда удаление старых ключей делает серверный контролируемый процесс (а не “слепой” клиент). Это позволяет:

ввести правила соответствия ключам по меткам/комментариям;
не рисковать блокировкой доступа при ошибках;
вести аудит (логирование событий и дат ротации).

Если вы хотите, мы можем предложить схему с ограниченной командой на сервере: клиент вызывает конкретный сценарий, который обновляет authorized_keys по заранее заданным правилам.

Частота ротации и политики

Практически разумные ориентиры:

Начните с 7–30 дней для пилота.
Увеличивайте частоту только после стабилизации процесса.
Обязательно документируйте процедуру отката (например, сохранение “previous” ключа на сервере на период перекрытия).

Тестирование и контроль качества

Перед включением в продакшн проверьте:

2FA с новым ключом проходит без ручных вмешательств сверх политики.
Туннель успешно поднимается и сервис доступен через 127.0.0.1 на Termux.
При отключении старого ключа доступ сохраняется.
Нет неожиданных ошибок в логах SSH сервера.

На сервере используйте журналы:

sudo journalctl -u sshd --since "1 hour ago" | tail -n 200
# или:
sudo grep -i "sshd" /var/log/auth.log | tail -n 200

Про локальную сеть и VPN (если требуется)

Если вам нужна только локальная сеть (например, для сервисов в пределах вашей инфраструктуры), можно использовать VPN‑сеть для организации адресного пространства и маршрутизации внутри локального сегмента. Однако SSH‑туннель при этом остаётся основным механизмом защищённого доступа к нужным портам и сервисам.

Мы не рассматриваем VPN как средство обхода ограничений; его применяют только для создания корректной локальной сети внутри согласованного периметра.

Заключение

Безопасный SSH‑туннель через Termux‑OpenSSH — это сочетание корректной сетевой топологии, строгих настроек sshd_config, включения двухфакторной аутентификации и дисциплины управления ключами. Реализация ротации с перекрытием (когда новый ключ активен до удаления старого) снижает риски блокировок и ускоряет реакцию на инциденты.

Если вам нужно внедрить эту схему под вашу инфраструктуру (выбор механизма 2FA, настройка серверных политик, безопасная автоматизация ротации и аудит доступа), команда РыбинскЛАБ выполнит настройку, аудит и сопровождение решения.