10.08.2026 16:19
goduni 36 19000 Источник

Доброго времени суток, читатели!

Хочу представить вам unissh – современный, простой опенсорсный SSH клиент с selfhosted zero-knowledge сервером для синхронизации данных.

главный экран
главный экран

Заранее предупреждаю, что проект – чистый вайбкод на расте + таури, но мы с друзьями старались его хорошо протестировать.

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

Первой, и наверное основной причиной стало то, что я лично не смог найти нормальных кроссплатформенных ssh клиентов с синхронизацией данных между устройствами. Моя личная потребность на протяжении наверно уже десятка лет, заключается в том, что мне очень удобно иметь доступ к серверам и с телефона, и с ноутбука. Идея всегда носить с собой макбук, мне не слишком нравится ;)

Существующие решения с поддержкой синхронизации предлагают что-то из приведенного ниже:

  1. синхронизация данных через iCloud (работает только для устройств из экосистемы Apple)

  2. синхронизацию данных через внешние файлохранилища (например GitHub, гугл диск и прочие подобные решения)

  3. сомнительный дизайн с моей точки зрения (я считаю это довольно важным нюансом)

  4. отсутствие шифрования данных

  5. отсутствие возможности экспортировать собственные данные без подписки

Я считаю, что нейронки должны нести в том числе и какую-то пользу для большого количества людей. Поэтому, решая собственную проблему – я выбрал навайбкодить свой собственный SSH клиент и сервер с веб-панелькой к нему, чисто для синхронизации волтов между устройствами.

И вот, спустя два месяца разработки рад представить вам результаты вайбкуколдинга:

Возможности клиента

  1. Кроссплатформенность – Windows, macOS, Linux, iOS, Android

  2. Терминалы – сплитование вкладок в разных вариациях, дублирование, переименовывание и прочие базовые фичи

  3. SFTP – для работы с загрузкой / выгрузкой файлов с серверов; в настройках можно менять еще количество активных подключений для SFTP, если вы работаете с сотнями и тысячами файлов; также есть базовый текстовый редактор внутри

  4. Два режима массового выполнения команд:

    1. Broadcast – открытие множества ссш сессий к выбранным серверам и наблюдение за выводом команд

    2. Fleet exec – от первого варианта отличается тем, что команды просто посылаются на сервер и показывается exit code с каждого сервера

  5. Секреты – SSH-ключи, пароли для серверов, идентичности, заметки; также поддерживается импорт из ~/.ssh/config; имеются истории версий у секретов

  6. SSH-туннели (Local, Remote, Dynamic)

  7. Запись сессий в asciicast v2 формат

  8. Сниппеты – вы всегда можете создать необходимые вам сниппеты для быстрого их выполнения на сервере

  9. Гибкая кастомизация интерфейса и поддержка множества тем и их светлых / темных вариаций, и возможность создавать свои собственные темы. Сейчас из дефолтных тем приложений: Mono, Nebula, Barbie (да, барби тема ;) и также несколько тем для терминала

  10. Поддержка подключения к множеству серверов для синхронизации, когда у вас например есть личный сервер с вашими личными волтами, а есть сервер компании / команды и рабочие волты

Архитектура проекта

Общее кроссплатформенное ядро (rust-core) – это workspace из девяти крейтов, в котором живет вся крипта, волты на SQLCipher, SSH-стек (russh), встроенный in-memory ssh-агент и логика синхронизации. Клиенты подключаются к ядру через UniFFI, а веб-панелька для администраторов сервера – вообще через это же ядро, просто скомпилированное в wasm. Важное замечание: крипта и SSH не переписываются под каждую платформу. Клиент на iOS, десктопный клиент и админка в браузере дергают один и тот же код. Меньше возможностей для ошибок у слоп-машин ;)

Клиенты – Tauri v2 + React, один кодбейс на все пять платформ (macOS, Windows, Linux, iOS, Android). Клиент по сути тонкий: UI, xterm.js для терминала, а все чувствительное за FFI-границей в ядре.

Сервер – маленький бинарь на Rust (axum + sqlx, SQLite или PostgreSQL на выбор), который нужен только если вы хотите синхронизацию между устройствами или командную работу.

Главное про сервер: он ничего не знает

Сервер – это тупое хранилище шифроблобов с логикой членства и версий. Все данные шифруются на устройстве до отправки: ключи выводятся из Secret Key (это ваш Emergency Kit, как в 1Password) + пароля через Argon2id. Сервер хранит ciphertext, проверяет Ed25519-подписи записей и раздает дельты другим устройствам, но не выполняет никакой криптографии над содержимым. Он физически не может расшифровать волт, выписать себе доступ или подделать запись. Максимум, на что способен скомпрометированный сервер – не отдать или задержать данные.

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

Отдельно порадовало, как получилось решить онбординг нового устройства: заходите с нового девайса через escrow sign-in (хэндл + пароль (при наличии) + Secret Key) – кейсет восстанавливается и расшифровывается прямо на устройстве, до сервера он не доезжает. Аккаунт один на все устройства, поэтому если коллеги выдали вам доступ к волту – он работает сразу везде. При этом у каждого девайса свой id, так что потерянный телефон можно отозвать отдельно, не убивая аккаунт.

Zero-knowledge не означает «сервер не видит ничего». Метаданные видны по дизайну: айди волтов и элементов, версии, tombstone’ы, публичные ключи участников, роли, sync-цели, размеры блобов и тайминги синхронизации. Не видит имен, содержимого, ключей волтов, элементов и приватных ключей. Тоесть скомпрометированный сервер узнает, что у вас 3 волта и 47 элементов, которые вы обновляли вчера в полночь, но не что в них.

И второе: не все гарантии криптографические, часть – server-trusted, то есть держится на корректном поведении сервера. Прежде всего это отзыв доступа: когда вы выкидываете участника, немедленный «отлуп» ему обеспечивает сервер. Криптографический отзыв тоже есть – через ротацию ключа волта и epoch floors на клиентах, но это следующая линия обороны, а не мгновенная.

Мы стараемся явно разделять эти два класса гарантий в документации, а полный разбор есть в репозитории в THREAT_MODEL.md и server/README.md.

Безопасность

Мы с слопусом не переизобретаем собственную криптографию – все построено на проверенной базе: RustCrypto, hpke, SQLCipher, Argon2id для вывода ключей, Ed25519 (verify_strict) для подписей.

Волты zero-knowledge: все содержимое шифруется на клиенте до отправки. На диске волт лежит в SQLCipher, а внутри per-item ключи, которые под per-vault ключом: компрометация одного элемента не раскрывает соседние, а сервер хранит только шифрованный текст, служебные метаданные и не выполняет никакой криптографии над содержимым.

Секреты не размазываются по памяти и диску: они зануляются после использования (zeroize), плейнтекст приватных ключей никогда не пишется на диск самим приложением, только через явный экспорт в менюшке секретов. Страницы памяти с ключами по возможности лочатся через mlock, чтобы не уехать в своп. Secret Key хранится только в системном кейчейне / Secure Enclave. Из приятных мелочей – настраиваемая авто-очистка буфера обмена после копирования пароля.

Секретная граница закрыта контрактом и тестом: секреты выходят из ядра только при вашем явном вызове: показать пароль или заметку, экспортировать ключ, сделать зашифрованный бэкап. Этот список зафиксирован в одном месте – тестом, который поименно перечисляет все методы, которые возвращают секреты и проверяет их type-gating вживую: попросить пароль у элемента-заметки или экспортировать ключ, который на самом деле пароль – ошибка. Новый метод, возвращающий секреты, обязан быть внесен в этот список явно – так поверхность утечки остается обозримой и не разрастается втихую. Туда честно внесен даже листинг сниппетов – с комментарием, что в сохраненных командах регулярно живут токены и хостнеймы.

Хост-ключи пинятся, классический TOFU: при первом подключении ключ хоста запоминается, и если он вдруг поменялся – соединение принудительно останавливается и вам показывается HostKeyMismatch с возможностью принять новый хост-ключ.

Целостность можно проверить локально: в ядре есть возможность проверки подписей по всем версиям записей, включая историю и tombstone’ы, — и check_consistency для структурной проверки базы.

Транспорт только TLS 1.3: либо in-process rustls, либо Caddy, либо ваш собственный reverse proxy.

Про неподписанные бинарники: я честно пока так и не придумал, что можно с этим сделать, поэтому релизы не подписаны сертификатами Apple/Microsoft и при первом запуске ОС на вас ругнется.

Вместо сертификата у каждого релиза три механизма проверки:

  1. файл SHA256SUMS по всем артефактам

  2. minisign-подпись поверх него – публичный ключ лежит в SECURITY.md, так что подмену чексумм прямо на странице релиза можно обнаружить

  3. SLSA-провенанс через GitHub attestations: команда gh attestation verify <файл> --repo goduni/unissh доказывает, что артефакт собран публичным CI из публичного коммита, а не у меня на коленке

Автообновления десктопного клиента проверяются отдельным Ed25519-ключом, вшитым в приложение. Ключ, подписывающий «что вы скачали руками», намеренно не совпадает с ключом, авторизующим «что исполнится на вашей машине без спроса» – сливать эти два радиуса поражения в один было бы плохой идеей.

Ну а самый базовый путь никто не отменял – собрать все из исходников и доверять только своему компилятору.

Селфхостим сервер за пять минут

Напомню еще раз: сервер опционален и совершенно необязателен. Клиент из коробки работает в локальном режиме, и если синхронизация вам не нужна – можно вообще ничего не поднимать и дальше этот раздел не читать ;)

Но мы-то с вами помним, ради чего все затевалось – синхронизация для телефона и ноутбука, поэтому поднимаем.

Самый быстрый способ поднять сервер:

curl -O https://raw.githubusercontent.com/goduni/unissh/main/compose.prod.yml
curl -o .env https://raw.githubusercontent.com/goduni/unissh/main/deploy/.env.example

# в .env вписать UNISSH_DOMAIN=ssh.example.com
docker compose -f compose.prod.yml up -d

В компоузе в том числе есть Caddy – он сам сходит за сертификатом в Let’s Encrypt, сам терминирует TLS и сам же раздает веб-админку.

Если у вас нет домена, и поднимаете в локалке: UNISSH_TLS_DIRECTIVE="tls internal" и Caddy выпишет самоподписанный серт.

База по умолчанию – SQLite в докер-вольюме, и для личного пользования этого хватит с запасом. Захотелось посерьезнее – Postgres включается парой строк в .env. Наружу торчат только 80/443, сервер бежит non-root на read-only rootfs, метрики и внутренний порт остаются внутри compose-сети. Есть надежды на то, что за такой деплой перед безопасниками (при их наличии) не будет стыдно ;)

Знаете эти прекрасные квесты «создайте первого админа через переменную окружения, потом удалите ее, потом поменяйте пароль»? Так вот, тут этого нет, но есть немного другой ;)

Сервер печатает в логи одноразовый setup code:

docker compose logs server 2>&1 | grep -i "setup code"

Открываете клиент или админку, вводите адрес своего сервера и этот код – теперь вы владелец инстанса. Если вам требуется кого-то пригласить в пространство, то это уже через инвайт-ссылки (или прикручиваете корпоративный SSO через OIDC, если у вас все серьезно) – код им уже не нужен. Автоматизируете деплой ансиблами-терраформами? Код можно запинить детерминированно через UNISSH__SETUP__CODE.

Проверить, что все ожило: curl -k https://your-domain/healthz

Админ-панель сервера

Веб-панель – SPA, внутри которой крутится то же самое Rust-ядро, что и в клиентах, только скомпилированное в wasm. Тоесть вся крипта выполняется у вас в браузере: заходите по хэндлу + паролю (при его наличии) + Secret Key, кейсет восстанавливается и расшифровывается прямо на странице и до сервера не доезжает. Кнопка Lock – и он вычищается из памяти. Никаких «импортируйте файлик с ключом» (но справедливости ради, мне пришлось над этим поработать, так как такое реально было): новый браузер подтверждается QR-кодом с уже доверенного устройства, как в мессенджерах.

Внутри же пространства, участники, устройства и сессии, инвайты, волты с грантами, аудит. Есть опциональный ops-токен для break-glass сценариев, но он открывает только инфраструктурные ручки и не расшифровывает ровным счетом ничего.

По поводу бэкапов подсвечу: если вы восстановили сервер из старого снапшота, клиенты это заметят и откажутся синкаться с ошибкой TransportRollback – пока вы явно не поднимете версию через seq-bump. А еще старый restore может воскресить удаленный элемент. Это не баги, а anti-rollback защита делает свою работу. Но лучше узнать про нее из README, а не во время аварии ;)

Вместо заключения

Два месяца назад я просто хотел SSH-клиент, который не заставляет выбирать между удобно, безопасно и не платить подписку за доступ к собственным серверам. Теперь он у меня есть – и у вас тоже, если захотите.

Что я могу сказать: нейронки уже дозрели до того, чтобы за пару месяцев вечерами собрать кроссплатформенный клиент, сервер и админку, но все еще требуется человек, который хоть немного разбирается в делах, которое он решает нейронкой. Особенно необходимо уметь задавать неудобные вопросы, чтобы нейронка могла решать проблемы обнаруженные этими неудобными вопросами.

Проект полностью открыт под двойной лицензией MIT / Apache-2.0. Никакой платной версии, облачной подписки или энтерпрайз-фич за деньги нет и не планируется: это тулза, которую я делал для себя, а сервер вы и так сами поднимаете.

Буду рад, если вы потестируете клиент – все пять платформ лежит в релизах, сервер поднимается за пять минут из готовых образов или по инструкции выше.

По поводу найденных багов, пожеланий и всего такого – пишите в issues, либо в чатик проекта в телеграме. Уязвимости – не в ишьюсы, а в идеале на uni@goduni.me. Я серьезно: проект написан нейронкой, внешнего аудита криптографии не было, и каждый человек, который внимательно посмотрит в исходники, поможет сделать его лучше. Особенно приглашаю тех, кто в комментариях уже готовит тезис «вайбкоду нельзя доверять секреты» – вот вам открытый код, THREAT_MODEL.md и почта для репортов.

Ближайшие планы – собрать ваш фидбек, в надежде на то, что оно пригодится в том числе не мне одному, и допиливать согласно вашим пожеланиям.

Ссылки:

Спасибо, что дочитали! Буду рад вашим звездочкам на репозитории, комментариям и обратной связи!

Комментарии (36)


  1. firegurafiku
    10.08.2026 19:09
    #30318298

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

    А внутренний аудит был? Вы сами посмотрели внимательно исходники и можете подписаться своим именем, что там всё в порядке, без дисклеймера “ну там нейронка писала”?

    Особенно приглашаю тех, кто в комментариях уже готовит тезис «вайбкоду нельзя доверять секреты» – вот вам открытый код, THREAT_MODEL.md и почта для репортов.

    Вам не кажется, что это работает немного не так? Вы выдвигаете тезис “вайбкоду можно доверять секреты”, вам его, в первую очередь, и доказывать.


    1. Luis2
      10.08.2026 19:09
      #30319416

      Конечно был аудит, чатгпт два раза спросили оставил ли он бэкдоры, нейронка мамой поклялась


      1. Wesha
        10.08.2026 19:09
        #30321720

        нейронка мамой поклялась

        Элизой?


    1. goduni Автор
      10.08.2026 19:09
      #30320304

      про первый вопрос, честно – нет. внутреннего аудита в том смысле, в котором это слово имеет право употребляться, независимая построчная вычитка криптографии человеком, который в ней разбирается – не было. и подписаться своим именем без дисклеймера я не могу; дисклеймер в статье стоит не для красоты, а потому что это ровно то, за что я могу отвечать. с моей человеческой стороны были требования, неудобные вопросы к слопусу клодусу, +-полтора месяца почти ежедневного использования на собственных серверах и функциональное тестирование, но это не относится именно к аудиту безопасности

      вы правы насчет бремени доказательства, и спорить не стану, но тезис «вайбкоду можно доверять секреты» я не выдвигал, и лично доказать его не смог бы – оно либо есть и так, либо оно накапливается в процессе использования / анализа и подобных процессах. мой тезис скромнее: вот код, threat model и воспроизводимая сборка – любой сможет проверить это самостоятельно. это не доказательство корректности, это условия, при которых мою некорректность может обнаружить кто угодно. согласен, что финальный абзац статьи прозвучал как «докажите, что я неправ» – это неудачная формулировка, имелось в виду приглашение к проверке, а не перекладывание бремени доказательства

      и дополнительный факт – клиентом можно пользоваться не доверяя ему секреты, но без синхронизации и используя системный ссш-агент


  1. Andreas_Fogel
    10.08.2026 19:09
    #30318476

    Я так и не понял зачем мне приложение, если есть терминал. Может вы знали о Remmina?


    1. goduni Автор
      10.08.2026 19:09
      #30319946

      подобных клиентов существует множество, но есть проблема в том, что они так или иначе не совпадали с тем, что я хотел:

      1) настоящая кроссплатформенность (макос, винда, линукс + айос и андроид)
      2) хороший (для меня) дизайн
      3) возможность синхронизации без платной подписки, и в идеале не через костыли по типу отдельных гистов / гугл доков и прочего
      4) иметь возможность хорошо организовать сервера, если их становятся минимум десятки

      я не спорю, что оно надо не всем, но личные предпочтения и выбор все еще остаются вашими


      1. Kuddesnik
        10.08.2026 19:09
        #30320064

        Вот тут если вы топите за 4 пункт, то в клиенте не помешало бы это так же реализовать.
        Например было бы неплохо завезти поиск в пункте "Все хосты", например для того чтобы найти нужный хост и отредактировать его настройки.

        Я вообще без негатива, но в UI очень много проблем которые мешают в работе.


        1. goduni Автор
          10.08.2026 19:09
          #30320212

          спасибо за фидбек, да, сделаю. другим пожеланиям / замечаниям буду рад


      1. Arenoros
        10.08.2026 19:09
        #30321426

        почти по тем же причинам навайбкодил себе похожее но до ума доводить нет сил и времени, но у меня была ещё потребность реализовать "автоматизацию" установки и настройки всяких приложух, а заниматься ансиблом или что там для этого есть мне сильно в падлу


  1. griha_shershen
    10.08.2026 19:09
    #30318586

    Зачем это нужно когда есть банально termius в котором твои данные хоть и хранятся на сервере, но шифрованы по ключу который ты хранишь локально(много английских слов)?


    1. Wesha
      10.08.2026 19:09
      #30318618

      Непонятно, зачем хранить ключ на носителе, когда его можно хранить в мозгу (много английских слов)


      1. randomsimplenumber
        10.08.2026 19:09
        #30318632

        Хороший годный 4096 битный ключ сложно хранить в мозгу. Разве что для уникумов что число Пи с любого места цитируют..


        1. Wesha
          10.08.2026 19:09
          #30318834

          Хороший годный 4096 битный ключ сложно хранить в мозгу.

          А зачем Вам хранить в мозгу «хороший годный 4096-битный ключ»? Чем Вас верно батарея лошадь скрепка не устраивает? Вы аж кюшать не смогёте, если Ваше SSL‑ соединение, по которому Вы качаете фотки котиков, сломают не за 100500, а всего‑то за 5000 лет?

          (И не надо мне про «эксперты говорят, что надо так»: продавцы менеджеров паролей лопат что угодно скажут, лишь бы продать свою лопату; приведите конкретный случай, когда иначе ну никак невозможно.)


          1. randomsimplenumber
            10.08.2026 19:09
            #30318916

            Можно по разному конечно. В том числе и без запоминания 100500 разных паролей.


          1. Forden
            10.08.2026 19:09
            #30319218

            Проблема в том, что брутфорсом SSH серверов занимается не 1 бот, а десятки/сотни тысяч, 24/7/365. Поэтому 5000 лет это мягко говоря, оптимистичная оценка.

            Да и в целом, рекомендую ознакомиться с атакой "Harvest now, decrypt later" (https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later).


            1. Wesha
              10.08.2026 19:09
              #30321768

              брутфорсом SSH серверов занимается не 1 бот, а десятки/сотни тысяч, 24/7/365.

              Ну где же они, где? Ко мне за последнюю неделю никто так и не постучался (я логи только что проверил).

              Harvest now, decrypt later

              Данные имеют свойство устаревать. Кроме того, поголовное внедрение SSL создало проблему фильтрации мусора («Где лучше всего спрятать гальку? На галечном пляже!»)


          1. kenomimi
            10.08.2026 19:09
            #30319238

            Аппаратный ключ неизвлекаем программно, и не ходит по каналам связи, угнать его можно только физически украв. Пароль у вас угнать очень несложно, даже перебирать его не надо - зашли браузером на связку, или посмотрели файл в телеге, и привет. Та же история с парольными менеджерами, где трой тырит зашифрованную базу, и пароль от нее - все пароли оказываются разом у злоумышленника... С учетом того, что сейчас 0-day уязвимости умеет искать нейросеть, теперь это уже не эксклюзивное дело спецслужб с топ-блекхатами, теперь искать и юзать дыры каждый школьник может.


          1. Void-Cowboy
            10.08.2026 19:09
            #30320056

            в чем-то я с вами согласен, но реальность такова что любой публичный IP тут же попадает под атаку ботов. Я замерял - в среднем о 4 запросов на секунду с подбором пароля (и это с включенным фаилбаном и прочим, без ограничений я думаю было бы еще печальнее)


            1. Wesha
              10.08.2026 19:09
              #30321782

              реальность такова что любой публичный IP тут же попадает под атаку ботов. Я замерял - в среднем о 4 запросов на секунду с подбором пароля (и это с включенным фаилбаном и прочим, без ограничений я думаю было бы еще печальнее)

              Ваш sshd всё ещё слушает порт 22? Тогда боты уже идут к Вам!

              Посмотрел свои логи — за последнюю неделю никто ко мне не стучался (дальше смотреть было лень).


    1. poige
      10.08.2026 19:09
      #30318660

      банально termius

      к слову сказать, эмуляция терминала в оном сделана как раз довольно анально — рендеринг лютое дно по скорости. Впрочем, я его последний раз лет 5 назад смотрел, если не больше, в теории могли уже приличное что-то притащить.

      И вот тут вопрос, кстати, а в данном проекте собственно терминал на каком движке?


      1. Luis2
        10.08.2026 19:09
        #30319450

        В статье написано про xterm.js для терминала, классика для всех электрон-подобных поделок


      1. goduni Автор
        10.08.2026 19:09
        #30319968

        xterm.js + можно включить gpu-рендеринг

        рендеринг на мой взгляд выглядит хорошо в том числе, когда в терминал выводится огромное количество текста постоянно


    1. goduni Автор
      10.08.2026 19:09
      #30319958

      я лично пользовался термиусом очень много лет

      для синхронизации у него требуется подписка 10$/мес, и честно говоря, я вообще не помню никаких упоминаний локального ключа и мало представляю, как оно работает, если там достаточно входа с своего аккаунта даже без наличия второго устройства

      ну и экспортировать данные без подписки оттуда – довольно сомнительный экспериенс)


  1. sha256man
    10.08.2026 19:09
    #30318624

    >внешнего аудита криптографии не было, и каждый человек, который внимательно посмотрит в исходники, поможет сделать его лучше

    очень наивное мнение, что аудит безопасности делается так. вон, в linux последнее время кучу застарелых приколов нашли, а туда "тысячи глаз" таки реально смотрели, годами. только нифига не видели.


    1. goduni Автор
      10.08.2026 19:09
      #30319974

      не удивлюсь кстати, если не смотрели

      но в любом случае я рад любому хорошему фидбеку


  1. teoritty
    10.08.2026 19:09
    #30318774

    Отбросив моменты типа "это решает мою боль здесь и сейчас", и "это все нейрослоп, я не при делах", что модель безопасности и угроз держится на простых обещаниях, поговорим предметно из того что прям кричит и бросается в глаза.
    1. Переизобретение Termius почти 1 в 1.
    2. Уже гниющая архитектура и код. Слои текут, GOD объекты растут как на дрожжах, так что при текущем подходе проект очень скоро станет неподдерживаемым нейрослопом, либо цена поддержки проекта будет улетать в небеса за счет бесконечного перемалывания тонны спагетти-кода. И это все дал беглый просмотр кодовой базы за 10 минут. Что там будет, если начать вчитываться страшно представить.
    3. Иллюзия безопасности по памяти. Чтоб юзер увидел секрет ядро должно передать его в JS фронта, где просто априори нет никаких mlock или как-то гарантированно занулить память.
    4. Утечка мастер-токена в логи: Сервер печатает в логи одноразовый setup code. И это по сути дырень в ИБ, поскольку в корпоративной среде логи пылесосятся каким-нибудь агрегатором логов, доступ к которому уже имеет сильно больше постороннего народа, что повышает поверхность атаки, а для комплаенса это критично до ужаса. И уж не будем забывать что это просто само по себе нарушает принцип эфимерности и изоляции инит-секретов при деплое, что в случае компрометации логов превращает всю вашу чудесную безопасность в тыкву. Метаданные в сервере в ту же топку. Это не бьется с моделью "сервер ничего не знает".
    5. Secure Enclave заявлен как универсальное решение, хотя это аппаратный модуль исключительно устройств маркируемых огрызком. На винде же это Windows Hello + TPM, на линуксах вообще нет ничего подобного, на сколько мне известно. И смешивать это все обзывая "Secure Enclave" априори не правильно.
    6. "запись сессий в asciicast v2 формат" и ни слова про безопасность. Попахивает кейлоггером с мутной системой сбора.
    7. russh. Почему? Чем обоснован выбор?

    Так много вопросов и так мало ответов. Спасибо, у меня всё.


    1. goduni Автор
      10.08.2026 19:09
      #30320192

      привет! спасибо за большой фидбек

      1) да, по сути, клиенты сами по себе совпадают, но есть несколько отличий: проект полностью бесплатный и полностью опенсорсный, и для организации синхронизации достаточно поднять лишь свой сервер для синхронизации

      2) ффи фасад действительно большой, но это чисто фасад для клиента, но я подумаю, как это можно улучшить

      3) такое есть, но это только при сценариях того, что пользователь просматривает / экспортирует секрет, а в основном пути (ссш-подключения) оно через жс не проходит

      а если сервер требует какого либо интерактивного ввода (пароль / 2фа), то оно все равно проходит через интерфейс

      4) это не мастер-токен, это одноразовый бутстрап-токен, который по сути живет всего несколько минут до момента того, как администратор инстанса его введет в панельке. его можно задать еще через энв в UNISSH__SETUP__CODE, чтобы он не генерировался случайным образом. в случае с энвом на данный момент, он попадет в логи, но я запишу и исправлю это. но даже если его украдут до момента инициализации инстанса и инициализируют его, то максимум, что получит злоумышленник – это пустой инстанс в который все равно врядли попадут данные

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

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

      7) наиболее зрелая и живая реализация протокола, которую и я и клод отдельно друг от друга смогли найти; позволяет использовать только его на все 5 платформ


  1. lopej
    10.08.2026 19:09
    #30318776

    Ну то есть дополнительный слой над ssh-agent.

    Отдельно порадовало, как получилось решить онбординг нового устройства: заходите с нового девайса через escrow sign-in (хэндл + пароль (при наличии) + Secret Key) – кейсет восстанавливается и расшифровывается прямо на устройстве, до сервера он не доезжает.

    Сепаратли лайк, бикоз онбординг нью девайс: джойнимся с нью девайса через escrow sign-in (хэндл + пассворд (если пресент) + сикрет кей) – кейсет ресторивается и декриптуется прямо на девайсе, до сервера у него пинг инвалид.


    1. Wesha
      10.08.2026 19:09
      #30318874

      Прекрасно жить в свободных Штатах при обеспеченных харчах,
      При службе, при больших зарплатах, автомобилях и домах!
      Здесь лишь одно немного грустно: язык не тот. Не как в Москве.
      Не говорят они по-русски, хоть кол теши на голове!
      Но к трудностям такого сорта любой из нас уже привык.
      Мы спикаем по-русски гордо, мы кипаем родной язык.
      Мы соль не спилаем на раны, подругу киссаем взасос,
      На службе ранаем программы, когда реквестает наш босс.
      Мы дринкаем сухие вина, энджоем собственный уют,
      Мы лихо драйваем машины, берём хайвей (когда дают).
      Когда окьюрится возможность, возьмем э фью денёчков офф,
      Махнем в апстейт по бездорожью, в лесу напикаем грибов,
      Накукаем такой закуски, какой не видел целый свет!
      Дринкнём как следует, по-русски! Факнём жену на склоне лет!
      А то — возьмём большой вакейшен, допустим, парочку недель,
      В Париже, в дистрикте старейшем себе забукаем отель.
      А там — и Рим не за горами, Мадрид, Берлин, едрёна мать!
      Мы будем шопать в Амстердаме! Мы будем в Праге ланчевать!
      При наших, при больших зарплатах нам вся Европа — по плечу!
      Ах, хорошо в Юнайтед Штатах! Эх, травеляй, куда хочу!
      Аппрочает весенний вечер, даркеет — прямо на ходу.
      Стихают речи, гаснут свечи, и Пушкин спинает в гробу...


  1. Aleksandr_Lar
    10.08.2026 19:09
    #30319162

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

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

    Потом, большой недостаток: моде не следуете. Где у вас статический анализ исходных кодов? А это, между прочим, простой и автоматизируемый минимум. В глубинные ужасы фаззинга и прочих исследований лазить не будем, но вот статику сильно советую.


    1. goduni Автор
      10.08.2026 19:09
      #30320198

      привет! спасибо за замечание, записал, обязательно добавлю


  1. Luis2
    10.08.2026 19:09
    #30319390

    Пока вы будете поднимать свой селфхост сервер на расте, я просто закину конфиг ssh в гитлаб. Бесплатно, сердито и работает с любого утюга)


    1. goduni Автор
      10.08.2026 19:09
      #30320210

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

      лично мне вместо развлечений с гитами / гугл доками и прочими вещами, проще поднять свой собственный сервер за несколько минут


  1. enkill
    10.08.2026 19:09
    #30322008

    Удобный ssh клиент, а точнее, удобный фасад - это и правда боль. Я много лет юзал secureCRT, но на ноуте у меня сейчас линух и я решил поискать альтернативы. Оказалось, что это тот ещё геморрой. По удобству, близкому у секуре, я не нашел ничего, у сожалению. Моя основная проблема в количестве хостов. У меня около 600 сохранённых сессий, плюс пара проксей, которые прокидыают ssh туннели. И вот на линухе я так и не смог найти ничего подобного. Из плюсов хотя бы то, что секура есть в виде deb пакета и она из под wine запускается) termius вроде выглядит норм, но я с ним уже успел повозиться. На некоторых коммутаторах зависали telnet сессии или вводились символы как будто коммутатор на Марсе , с com портами тоже приколы были. В общем, не думал я, что переезд на линух в этом плане будет таким болезненным)


    1. Kuddesnik
      10.08.2026 19:09
      #30322274

      Не пробовали Tabby? Когда переехал на Linux сначала долго пользовался Remmina, но в какой-то момент что-то пошло не так. После этого открыл для себя tabby, из того что понравилось это соединения и настройки самой софтины в одном конфиге который удобно бекапить.


  1. adn_dev
    10.08.2026 19:09
    #30323338

    О, Taury уже нормально поддерживает ios? Наконец-то)