У меня есть несколько установок со специализированной структурой базы данных (Intersystems Caché), которая содержит собственный сервер Telnet, работающий на порту 23. Хотя продукт работает на Windows Server 2008, AIX и Linux (в частности, RedHat Enterprise Linux), поддерживаемые мной установки используют исключительно ОС Windows Server 2008. В настоящее время это единственная поддерживаемая система командной строки для продукта; SSH или любая другая форма зашифрованного интерфейса не поддерживается. Интерфейс Telnet - в зависимости от размера объекта - может обслуживать до нескольких сотен пользователей / сеансов одновременно. Мне не нравится эта незашифрованная связь, и я хотел бы настроить внешнюю (по отношению к фреймворку) систему на сервере, чтобы разрешить шифрование.
Что я хотел бы сделать, так это ограничить telnet-порт Caché для прослушивания порта 23 исключительно на localhost (127.0.0.1) и настроить сервер SSH-демона на самом сервере, чтобы отвечать на все запросы из сети в целом на порт 22 и пересылать их запрашивает порт 23 на локальном хосте, тем самым разрешая для продукта шифрованный обмен данными из командной строки, даже если он не поддерживает его напрямую.
Я исследовал это в течение нескольких дней как с помощью стандартного поиска в Google (и я довольно хорошо говорю с Google), так и здесь, на serverfault / stackoverflow, но безуспешно. Все примеры, которые я нашел, либо 1) выполняют прямую переадресацию портов без шифрования для многих пользователей / сеансов, либо 2) описывают только, как выполнять переадресацию / туннелирование портов SSH для одного пользователя / сеанса.
Согласно пункту 2 выше, попытка настроить сотни отдельных перенаправляемых туннелей SSH была бы административным кошмаром; Мне нужно серверное решение на одном порту, которое будет обрабатывать несколько сеансов и пользователей. Для исследования, которое я провел, настройка демона сервера OpenSSH на сервере Windows кажется лучшим вариантом (и я попытался - безуспешно - настроить sshd_config для поддержки этого сценария), но если есть лучший вариант, я открыт для все предложения.
Я также рассматривал возможность создания небольшой виртуальной машины Linux для выполнения перевода, но на этих объектах нет никого, кто разбирается в администрировании Linux, и у нас все еще есть несколько объектов, которые запускают продукт в физической (не виртуальной) среде, поэтому вторичный Linux виртуальное решение не принесет пользы этим сайтам.
** Я забыл упомянуть: поскольку приложение на основе Caché имеет свою собственную систему безопасности вне самого сервера Windows, многие отдельные пользователи приложения не имеют учетных данных для входа на сервер на основе Windows. SSH-туннель (-ы) не должен пытаться запустить оболочку на самом сервере, он должен только шифровать / дешифровать на лету и создавать туннель к порту Telnet. Надеюсь, я достаточно хорошо это объяснил; Если нет, дайте мне знать, и я постараюсь объяснить это более четко.
Любая помощь будет принята с благодарностью. Спасибо за ваше время!
Поскольку вы в первую очередь, похоже, сосредоточены на зашифрованном сеансе telnet, я предлагаю альтернативу использовать такой инструмент, как станнель. Stunnel - это прокси-сервер TLS, который позволяет добавлять TLS / SSL поверх простых протоколов TCP (например, telnet). Вы получаете все преимущества шифрования и аутентификации с помощью сертификатов.
Проблема с stunnel заключается в том, что не так много клиентов Telnet с поддержкой TLS. Один из способов решить эту проблему - установить stunnel и на клиентские машины. Stunnel может работать в любом направлении. Он может добавлять или удалять TLS. Таким образом, ваши клиенты могут подключаться к своему локальному экземпляру stunnel с помощью своего клиента telnet. Их локальный экземпляр stunnel построит туннель TLS к вашему серверу, который будет устанавливать соединение с сервером базы данных.