|
Professor Seleznov
|
TL;DR
После перехода на macOS я не нашёл SSH-клиент, который закрывает мой ежедневный сценарий так же удобно, как WinSSHTerm.
Устал от постоянных компромиссов, сформулировал требования, собрал свой клиент и выложил код в open source.
Репозиторий
Контекст
Если работаешь с несколькими серверами, почти любой SSH-клиент «как-то» подходит.
Если работаешь с десятками и сотнями хостов каждый день, важны уже не фичи на слайде, а скорость и предсказуемость:
- насколько быстро находишь нужный хост;
- сколько действий до подключения;
- насколько удобно держать в порядке структуру окружений;
- как приложение ведёт себя после месяца активного использования.
На Windows меня в этом плане долго выручал WinSSHTerm.
После перехода на macOS я рассчитывал найти аналог за один вечер. Не вышло.
Что не устроило в существующих решениях
Я не искал «идеал». Я искал инструмент, который не мешает работать.
Проблемы повторялись от клиента к клиенту:
- Слишком длинный путь до сессии
Главный сценарий должен быть быстрым, но часто он утопал в лишних кликах.
- Слабая организация большого пула хостов
Когда у тебя много окружений и проектов, без нормальных групп, тегов и поиска всё превращается в хаос.
- Перегруженный интерфейс
Красивые панели и «богатый UI» часто ухудшали то, ради чего приложение открывается: подключение и работа.
- Неудобная переносимость настроек
Хотелось прозрачной конфигурации, которую легко хранить, переносить и версионировать.
Через несколько недель тестов я поймал себя на мысли: я трачу больше времени на борьбу с инструментом, чем на решение задач.
Почему решил писать своё
Причина не в том, что «все вокруг сделали плохо».
Причина в том, что у меня был конкретный набор требований под конкретную ежедневную нагрузку.
Я сел и формализовал, что именно считаю обязательным:
- старт и подключение максимально быстро;
- поиск по имени/IP/тегам;
- структура групп по окружениям и проектам;
- горячие клавиши для частых операций;
- предсказуемое хранение конфигурации;
- минимум визуального шума;
- стабильное поведение при большом списке хостов.
После этого стало понятно: проще собрать свой инструмент, чем бесконечно адаптироваться к чужим компромиссам.
Принципы, на которых строил клиент
1) Local-first
Основной сценарий должен работать быстро и без сетевых зависимостей.
Данные о хостах и сессиях доступны локально, UI не ждёт «внешних сервисов», чтобы открыть список.
2) Быстрее к подключению
Любая функция оценивается вопросом: ускоряет ли она путь до активной сессии?
Если нет — в бэклог.
3) Предсказуемость важнее «магии»
Лучше чуть меньше «авто-умностей», но понятная и контролируемая логика.
4) Конфиг как актив
Конфигурация должна быть:
- читаемой человеком;
- пригодной для бэкапа;
- переносимой между машинами;
- удобной для Git.
Архитектура (высокоуровнево)
Я разделил приложение на несколько независимых слоёв:
- UI Layer
Список хостов, поиск, фильтры, карточка сессии, быстрые действия.
- Session Layer
Жизненный цикл SSH-сессий: запуск, реконнект, завершение, статус.
- Config Layer
Чтение/валидация/миграции конфигурации (хосты, группы, теги, пресеты).
- Storage Layer
Локальное хранилище для служебных данных (например, recent/favorites/history).
- Integration Layer
Взаимодействие с системным SSH и окружением macOS.
Это позволило не смешивать UI-логику с подключениями и не ломать всё при изменении формата настроек.
Модель данных, которая реально помогает
Сначала пробовал упрощённую модель «список хостов».
Быстро стало ясно: при росте инфраструктуры нужна нормальная структура.
Базовые сущности:
- Host
Имя, адрес, порт, пользователь, auth-параметры, метаданные.
- Group
Логическая группировка (например, prod, staging, clients/*).
- Tag
Поперечные срезы (k8s, db, critical, legacy).
- Profile
Переиспользуемые параметры подключения.
- SessionPreset
Преднастройки поведения сессии.
Именно сочетание group + tags + search дало на практике наибольший выигрыш по скорости.
UX-решения, которые дали максимальный эффект
- Фокус на поиске по умолчанию
Открываешь клиент — сразу можешь печатать и фильтровать.
- Быстрые действия с клавиатуры
Чем меньше переключений «клавиатура/мышь», тем быстрее рабочий цикл.
- Последние и избранные хосты
Частые подключения должны быть в 1 действие.
- Минимум модальных окон
Модалки тормозят поток. Использовал их только там, где без них хуже.
- Стабильная информационная иерархия
Один и тот же тип информации всегда в одном месте.
Безопасность и эксплуатация
Я отдельно заложил базовые вещи, которые часто откладывают «на потом»:
- не хранить приватные ключи внутри приложения;
- использовать системные механизмы SSH;
- явно показывать, к какому хосту/окружению идёт подключение;
- избегать опасных дефолтов;
- логировать только то, что нужно для диагностики, без утечек чувствительных данных.
Это не делает клиент «абсолютно безопасным» (так не бывает), но убирает типичные ошибки класса «удобно, но рискованно».
Что оказалось сложнее всего
- Отказаться от лишних фич
Добавить кнопку легко, убрать лишнее сложно.
- Удержать баланс простоты и гибкости
Сделать «и просто, и мощно» без комбайна — это итерации, не один дизайн.
- Довести до удобства мелкие детали
Самые «невидимые» штуки (фокус, порядок табов, клавиатурные сценарии) решают больше, чем крупные фичи.
Что в итоге получил
Главное изменение не в том, что «появился ещё один SSH-клиент».
Главное — исчезло ежедневное трение:
- быстрее нахожу нужные узлы;
- меньше ошибаюсь при переключении окружений;
- не трачу внимание на интерфейс;
- не борюсь с конфигами при переносе/бэкапе.
Если коротко: инструмент перестал быть частью проблемы и снова стал частью решения.
Roadmap
Следующие шаги у проекта:
- Улучшение bulk-операций для больших парков хостов.
- Расширение импорта/экспорта конфигов.
- Более гибкие фильтры и сохранённые представления.
- Полировка UX для long-run сценариев (часы ежедневной работы).
- Дополнительные проверки безопасности в настройках по умолчанию.
Для тех, кто в похожей ситуации
Если вас тоже не устраивают готовые решения на macOS, рекомендую начать не с кода, а с чек-листа ежедневной боли.
Когда требования сформулированы честно, становится понятно: искать дальше или писать своё.
В моём случае ответ оказался вторым.
Репозиторий-Источник
|
