Если --password опущен, сервер запрашивает пароль для входа в USSH при запуске.
При интерактивном запуске сервер спрашивает, следует ли установить его как службу systemd. Ответьте n, чтобы запустить его обычным образом. Используйте --no-systemd-prompt, чтобы пропустить этот вопрос.
Клиент запрашивает пароль в интерактивном режиме, как SSH.
Клиент сохраняет первый увиденный открытый ключ X25519 сервера в ~/.ussh_known_hosts.json.
Если позже этот ключ изменится, клиент прерывает работу с ошибкой несовпадения TOFU, а не молча доверяет новому ключу.
Если вы намеренно сменили ключ хоста сервера, запустите клиент с --regen-key, чтобы разрешить замену сохранённого ключа TOFU после интерактивного подтверждения.
Под USSH протокол USTPS использует читаемые ASCII управляющие строки, такие как ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE:, а также бинарные DATA-кадры UPACK (UPAK).
ACK и NACK остаются открытым текстом для удобства отладки, но они аутентифицируются меткой HMAC для каждой сессии, чтобы предотвратить атаки с подделкой управляющих сообщений ACK/NACK.
USSH наследует от транспорта USTPS предел полезной нагрузки в 900 байт на DATA-полезную нагрузку UPACK.
USSH не определяет второй уровень фрагментации ниже USTPS.
Поведение MTU, PMTU, nonce, обработка дубликатов и обработка устаревших пакетов наследуются от USTPS.
Автоматическая миграция сети/пути удалена.
Если клиент меняет сеть и его исходный IP:port изменяется, текущая сессия USSH должна закрыться, и пользователь должен чисто переподключиться.
Реализация миграции была удалена, потому что она вызывала практические проблемы с надёжностью и безопасностью:
Транспортное рукопожатие
USSH наследует то же рукопожатие с retry-токеном USTPS, что и USTP-Secure.
Сервер сначала отправляет клиенту вызов с retry-токеном и метаданными сессии.
Клиент должен вернуть этот токен до того, как зашифрованная сессия USSH будет принята.
Это же рукопожатие также согласовывает конечный AEAD-шифр и то, включён ли USTPS Congestion (on или off).
Retry-токен — это только доказательство достижимости перед созданием сессии.
Это не ключ сессии, не пакетный nonce и не замена позже выводимому сессионному ключу AEAD.
повторяющиеся штормы миграции при быстрой смене путей NAT или мобильных сетей
сессии, которые выглядели восстановленными, но переставали доставлять данные терминала
длительные периоды тишины, прежде чем клиент замечал, что путь мёртв
неоднозначность между реальным роуминг-клиентом и поддельными пакетами, заявляющими о существующей сессии
состояние восстановления, которое могло оставить терминал зависшим вместо чистого переподключения
Текущее поведение намеренно проще: проверять клиента на текущем IP:port, привязывать сессию к этой конечной точке и переподключаться, если конечная точка меняется.
USSH наследует опциональный USTPS Congestion от транспорта.
Сторона сервера: --congestion-control auto|on|off
Сторона клиента: --congestion-control on|off
При серверном auto USSH следует запросу клиента. При серверном on или off сервер принудительно задаёт конечный режим.
Сам USTP-Secure остаётся неупорядоченным.
USSH не превращает транспорт в упорядоченный TCP-подобный канал.
USSH только собирает логический байтовый поток stdout перед записью в терминал.
USSH также может сохранять порядок на уровне приложения для фрагментов ввода/вывода оболочки там, где PTY ожидает связного поведения байтового потока.
Такая сборка существует потому, что вывод интерактивной оболочки — это непрерывный байтовый поток, и отрисовка байтов терминала в порядке их необработанного поступления может повредить большие выводы, такие как ls, find или журналы компилятора.
Это означает, что USTP-Secure по-прежнему избегает блокировки головы очереди (Head-of-Line) на транспортном уровне, а USSH восстанавливает только порядок уровня приложения, необходимый для отрисовки терминала.
Полезные нагрузки шифруются пофайлово с помощью AEAD.
Статический PSK не используется.
Каждый клиент получает отдельный эфемерный сессионный ключ AEAD через X25519.
Пароль используется для аутентификации USSH после установления защищённой сессии.
Сервер запускает настоящую оболочку на базе PTY на машине, где выполняется ussh_server.py.
Клиент отправляет байты stdin и отображает байты stdout.
Сервер поддерживает несколько клиентов: по одной оболочке/сессии на клиента.
Если --cipher задан на сервере, сервер использует именно этот шифр.
Если --cipher опущен или установлен в auto, сервер использует шифр, запрошенный клиентом.
Клиенты отклоняют неожиданное согласование шифра.
TOFU (Trust On First Use — доверие при первом использовании) включено на клиенте для обнаружения неожиданных изменений ключа сервера после первого подключения.
По умолчанию сервер хранит постоянный ключ хоста X25519 в ~/.ussh_host_key, чтобы TOFU оставался стабильным при переподключениях и перезапусках.
Обычный перезапуск сервера не меняет ключ хоста.
Используйте --regen-key на сервере только тогда, когда вы намеренно хотите сменить этот ключ хоста.
Записи TOFU хранятся отдельно для каждого <peer-ip-or-domain>:<peer-port>, поэтому другой сервер на другом адресе/порту рассматривается как другая идентичность хоста.
x1colegal/ussh
