Вопрос или проблема
Я сталкиваюсь с проблемой подключения из терминала Cygwin к домашнему Raspberry Pi через SSH из-за HTTP-прокси. Раньше это работало, и я не знаю, что изменилось за последние несколько дней (возможно, фильтрация прокси?). Я всё ещё могу подключаться вне прокси-сети без corkscrew.
Конфигурация SSH-клиента следующая:
Host *
ServerAliveInterval 60
ProxyCommand /bin/corkscrew http.proxy.here 80 %h %p
Попытка подключения выдаёт следующее:
blx@proxyed-pc:~$ ssh [email protected] -v
OpenSSH_7.9p1, OpenSSL 1.0.2p 14 Aug 2018
debug1: Reading configuration data /home/blx/.ssh/config
debug1: /home/blx/.ssh/config line 1: Applying options for *
debug1: Executing proxy command: exec /bin/corkscrew http.proxy.here 80 my.home.ip 22
debug1: identity file /home/blx/.ssh/id_rsa type -1
debug1: identity file /home/blx/.ssh/id_rsa-cert type -1
debug1: identity file /home/blx/.ssh/id_dsa type -1
debug1: identity file /home/blx/.ssh/id_dsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ecdsa type 2
debug1: identity file /home/blx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ed25519 type -1
debug1: identity file /home/blx/.ssh/id_ed25519-cert type -1
debug1: identity file /home/blx/.ssh/id_xmss type -1
debug1: identity file /home/blx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
ssh_exchange_identification: Connection closed by remote host
На сервере /var/log/auth сообщает следующее:
Nov 26 13: 39:36 raspi sshd[19130]: debug1: Forked child 19699.
Nov 26 13: 39:36 raspi sshd[19699]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:36 raspi sshd[19699]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:36 raspi sshd[19699]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:36 raspi sshd[19699]: debug1: getpeername failed: Transport endpoint is not connected
Nov 26 13: 39:36 raspi sshd[19699]: debug1: ssh_remote_port failed
Похоже, что TCP-соединение сломано, но у меня нет этой проблемы, когда я пытаюсь подключиться напрямую через corkscrew (например, $corkscrew http.proxy.here 80 my.home.ip 22
):
Nov 26 13: 39:32 raspi sshd[19130]: debug1: Forked child 19698.
Nov 26 13: 39:32 raspi sshd[19698]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:32 raspi sshd[19698]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:32 raspi sshd[19698]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:32 raspi sshd[19698]: Connection from http.proxy.here port 28220 on 192.168.0.11 port 22
Nov 26 13: 39:32 raspi sshd[19698]: Did not receive identification string from http.proxy.here port 28220
Но затем конечно sshd не знает, что с этим делать…
Есть какие-нибудь советы? Так как я не думаю, что изменил что-то в своей настройке, я подозреваю, что возможно произошли изменения в фильтрации прокси, поставив меня в такую ситуацию, но я не могу быть уверенным. Я попробую обновить роутер и Pi, чтобы использовать порт 443, когда вернусь домой.
мы должны договориться, что нет намерения обходить какие-либо меры безопасности и что подключение таким образом не нарушает никаких договоров/соглашений, конечно. Псевдоюридическая оговорка сделана, если бы я был на вашем месте, я действительно попробовал бы переключить сервер на прослушивание SSH-соединений на порту 443 лучше, чем на каком-либо другом, если идет через веб-прокси.
Простые причины:
- Хотя коммуникации на порту 80 (обычный веб-трафик) не шифруются и в основном текстовые (при чтении страницы), порт 443 используется для SSL зашифрованных коммуникаций. Прокси не будет удивлен видеть коммуникации в бинарной форме через этот порт. Вам нужна бинарная связь для SSH, не как веб-страница.
- Вы не подвергаете свой сервер публичному обозрению (если у вас нет белого списка ip на другой стороне) с общепризнанным портом, как 22. Новый сервер в сети иногда остается необнаруженным даже менее чем 5 минут. Тогда кто-то откуда-то попытается войти через SSH, если увидят открытый порт 22. Порт 443 не добавляет больше безопасности, но по крайней мере он немного менее очевиден, чем 22.
Удачи!
Ответ или решение
Конечно, давайте разберем проблему соединения через SSH при использовании HTTP-прокси с Corkscrew.
Описание проблемы
Вы столкнулись с затруднениями при установлении SSH-соединения с Raspberry Pi из среды Cygwin, где ваш доступ ограничен HTTP-прокси. Ранее это работало, но недавние изменения, возможно, в политике фильтрации прокси, привели к сбоям. Использование Corkscrew создает туннель, позволяющий обойти некоторые ограничения прокси-сервера.
Анализ конфигурации клиента
Ваш файл конфигурации SSH на клиентской машине (Cygwin) настроен следующим образом:
Host *
ServerAliveInterval 60
ProxyCommand /bin/corkscrew http.proxy.here 80 %h %p
ProxyCommand
указывает SSH запускать Corkscrew для соединения с прокси. Corkscrew позволяет передавать TCP-соединения через HTTP-прокси, что делает его эффективным для SSH, не поддерживающем прямого туннелирования через HTTP.
Логи клиента
При использовании команды SSH отладочные сообщения показывают, что Corkscrew запускается корректно и пытается установить соединение с Raspberry Pi, но оно завершается ошибкой "Connection closed by remote host". Это может указывать на проблему аутентификации или ограничение по времени со стороны прокси.
Логи сервера
Логи сервера указывают на проблему с определением удаленного конца соединения:
debug1: getpeername failed: Transport endpoint is not connected
Сервер не может завершить аутентификацию, так как, похоже, прокси закрывает соединение прежде, чем обмен идентификаторами будет завершен.
Возможное решение
Изменение порта на 443
-
Обосновать необходимость изменения порта:
- Порт 443 обычно используется для HTTPS и поддерживает зашифрованные соединения, которые не вызывают подозрений у прокси.
- Переход на порт 443 может обойти ограничения вашего прокси на другие порты.
-
Обеспечьте безопасность:
- Избегайте использования стандартных портов, таких как 22, в целях безопасности, так как они являются мишенью для злоумышленников.
- Откройте порт 443 на маршрутизаторе и настойте SSH-сервер на работу на этом порте.
-
Тестирование:
- После изменения настроек повторите тестирование соединения с новой конфигурацией.
Предостережение
Убедитесь, что изменения соответствуют внутренним корпоративным политикам и вы не нарушаете никаких правил использования сети.
Оптимизация для SEO: описание сложности соединения через SSH при работе из защищенной сети, использование Corkscrew для обхода ограничений на уровне прокси, предложение изменения порта соединения для повышения эффективности взаимодействия за прокси.
С этими корректировками, надеюсь, вам удастся наладить стабильное соединение с вашим Raspberry Pi из-за прокси. Удачи в решении проблемы!