Протокол для удаленного последовательного порта с аутентификацией и шифрованием

Я хочу сделать серийный порт доступным по сети. RFC-2217 предоставляет расширения для Telnet для передачи дополнительной информации о последовательном порте, такой как скорость, бит данных, стоповые биты и аппаратные линии подтверждения связи.

Однако я хочу, чтобы он не был свободно доступен никому в сети, поэтому я хочу сделать проверку подлинности и шифрование. Telnet слабо аутентифицирован и не обеспечивает шифрование. SSH обычно предпочтительнее Telnet.

Есть ли какой-либо протокол, который позволяет осуществлять последовательный порт через SSH, подобно RFC-2217?

Я понимаю, что одним из вариантов может быть туннель Telnet + RFC-2217 через туннель SSH. Это технически достижимо, хотя на практике это немного неудобно.

Zeroconf

Другой вопрос: как можно рекламировать такой порт с помощью Zeroconf DNS-SD? Например. как можно было разрешить серийный порт Telnet + RFC-2217, который туннелируется через SSH, с помощью Zeroconf? (простой Telnet + RFC-2217 может быть объявлен как _telnetcpcd._tcp из того, что я могу сказать.)

Ответ 1

То, что вы хотите, - это защищенное последовательное подключение по локальной сети.

Причина, по которой вы не можете найти бесплатный проект, который делает это просто: большинство проектов с открытым исходным кодом отделяют безопасность транспортного уровня от протокола (по уважительным причинам). Вместо того, чтобы повторно изобретать колесо для каждого приложения, вы можете просто повторно использовать компонент безопасности (в этом случае SSH) и применить его к вашему незащищенному протоколу (например, RFC-2217).

Просто используйте SSH-туннель или stunnel для защиты соединения. Для клиентов Windows вы можете использовать com2com и для систем * nix что-то вроде ttyd.

com2com, например, даже не требует запуска вручную после первоначальной настройки, поэтому ваши пользователи должны установить туннель SSH (например, через PuTTY).

com2com
socat, используя pty и openssl-listen, вы можете в значительной степени сделать то, что хотите (немного противоречит тому, что я написал выше потому что он действительно реализует безопасность транспортного уровня)

Ответ 2

Я не уверен, что SSH-туннелирование так же неудобно, как вы думаете:

-W хост: порт
Просит, чтобы стандартный ввод и вывод на клиенте отправлялся на хост на порту по защищенному каналу. Использует -N, -T, ExitOnForwardFailure и ClearAllForwardings и работает только с версией протокола 2.

Здесь какое туннелирование выглядит как короткий SMTP-сеанс (набранный жирным шрифтом):

$ ssh -W mail.server.com:25 [email protected]
220 mail.server.com ESMTP 
Postfix
ehlo foo.com
250-mail.server.com
250-PIPELINING
250-SIZE
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye

Нет отдельной настройки туннеля, а затем подключения к этому порту, только входящий поток и вывод из процесса ssh.

Ответ 3

SSH предоставляет "запрос псевдотерминала" с "псевдо терминальные терминальные режимы" . Он обеспечивает настройку скорости передачи, бит, четности, конфигурации стоповых бит. Можно установить PARMRK для получения ошибок кадрирования и нарушения условий. Тем не менее, похоже, что в протоколе SSH в настоящее время отсутствуют какие-либо команды для установки условия прерывания или для установки аппаратных линий модема DTR и RTS или для получения аппаратных линий модема DSR, CTS, DCD и RING.

См: