Я пытаюсь получить подход удаленного доступа (с открытым исходным кодом), работающий с использованием openssh и tightvnc, который имеет дело с NAT, который позволяет кому-то удаленно подключаться к моему серверу, а затем позволяет мне возвращаться к их машине по vnc без необходимости возиться с их брандмауэром и позволяет мне использовать статический адрес WAN в будущем. Я пытался сделать это маленькими шагами, чтобы справиться с неизвестными (для меня, много :). Казалось бы, другие заставили это работать, но я в тупике.
Во-первых, у меня на ноутбуке работает обратный SSH без пароля между двумя виртуальными машинами Windows 10 (hyperv) (т. Е. Я еще не пытаюсь иметь дело с переадресацией портов на моем брандмауэре или статическом WAN-адресе), но не могу получить vcn для работы через обратный туннель ssh, хотя он работает просто с использованием IP-адреса локальной сети вместо localhost для обратного ssh.
Мне интересно, ошибочен ли мой общий подход или нет. Это:
Машина A / человек A (требуется помощь)
в настоящее время win10 vm
клиент ssh (родной на win10)
сервер tightvnc
Машина B / человек B (роль службы поддержки)
в настоящее время win10 vm (в настоящее время та же локальная сеть, что и машина A)
ssh server (необязательно надстройка win10)
клиент tightvnc
Идея заключалась бы в том, что человек A на машине A запускает сервер VNC на машине A и подключается через обратный ssh к машине B (пока все хорошо). В этот момент человек B на машине B может вернуться по VNC к машине A и помочь.
Мое предположение, что может быть проблемой, - использовать обратный ssh из A-> B (я тоже пробовал параметр -L вместо -R), а затем использовать tightvnc для доступа к машине A обратно из B. После запуска сервера vnc на машине A пример начальной команды ssh, которую я должен был выполнить от A до B:
ssh -R 5902: localhost: 5901 пользователь @ lanaddressMachineB -i ~ / .ssh / id_rsa -vv
Эта часть работает. Сервер vnc на A имеет порт 5902 (я включил и выключил петлевую проверку, пробовал прослушивать сервер). Я надеюсь, что это похоже на то, что я не понимаю, какой локальный хост или что-то в этом роде.
Ошибка, которую я получаю на машине B, пытаясь вернуть vnc на машину A через туннель ssh, используя «localhost :: 5902», - «соединение было корректно закрыто». Соединение vnc работает, если я просто использую lanip сервера vnc на A из B.
Нет ничего в "tviewer.log" ни на клиенте, ни на сервере. Я пробовал изменить некоторые настройки в sshd_config (например, AllowAgentForwarding yes) безрезультатно.
В мой дизайн ошибочный или работоспособный? Это тот способ, которым я настраиваю вещи, и можно ли решить эту проблему, возможно, используя другую команду ssh?
В: нужен ли мне ssh-сервер на обеих машинах (я надеюсь избежать этого, поскольку мне придется устанавливать его на чужие машины)?
Я знаю, что для всего этого есть различные платные и некоторые бесплатные варианты, но я надеюсь, что это будет работать.
Спасибо.
Вы упомянули, что сервер VNC на «Машине A» работает на порту 5902, и вы также пытаетесь подключиться к порту 5902 (localhost: 5902) на «Машине B», чтобы добраться до VNC «Машины A». Пример, который вы привели:
ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
Неправильно. Для того, что вы делаете, вы должны использовать:
ssh -R 5902:localhost:5902 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
Первый параметр для -R - это порт, который будет прослушиваться sshd на удаленной стороне (SSH-сервер), а третий параметр - это порт, к которому будет подключаться SSH-клиент на локальной стороне, когда кто-то подключается к порт 1-го параметра на удаленной стороне. Как вы это описываете, вы хотите 5902 для обоих.
После того, как вы это исправите, я не вижу причин, почему это не сработает.
Мы столкнулись с чем-то похожим при работе с переадресацией портов SSH в Windows. Взгляните на вывод netstat, что подтверждает, что TightVNC прослушивает порт 5901:
PS C:\WINDOWS\system32> netstat -an | findstr 5901
TCP 0.0.0.0:5901 0.0.0.0:0 LISTENING
PS C:\WINDOWS\system32>
Сравните это с прослушивающими сокетами для встроенной службы удаленного рабочего стола (я исключил сокеты UDP, которые не имеют отношения к этому обсуждению):
PS C:\WINDOWS\system32> netstat -an | findstr 3389 | findstr /V UDP
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP [::]:3389 [::]:0 LISTENING
PS C:\WINDOWS\system32>
Сервис TightVNC, похоже, не реализует розетки с двойным стеком (IPv4 + IPv6). Это прискорбно, потому что запуск клиента SSH с одним -v отобразит следующие сообщения, когда TightVNC попытается подключиться в обратном направлении через туннель RemoteForward:
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 3 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 5901, originator 127.0.0.1 port 50132
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connected to localhost port 5900
debug1: channel 1: free: 127.0.0.1, nchannels 2
Линия, которая имеет значение, connect_next, который показывает, что клиент OpenSSH пытается использовать IPv6 и только IPv6 при проксировании соединения.
Мне не удалось найти никаких параметров в настройках TightVNC для привязки IPv4 + IPv6, но это не имеет значения, потому что есть простой обходной путь. Вместо этого:
ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
попробуй это:
ssh -R 5902:127.0.0.1:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
Чтобы еще больше запутать ситуацию, можно ввести localhost::5902 в клиенте TightVNC. Это потому, что прослушиватель OpenSSH на MachineB (порт 5902) является двойным стеком:
PS C:\WINDOWS\system32> netstat -an | findstr 5902
TCP 127.0.0.1:5902 0.0.0.0:0 LISTENING
TCP [::1]:5902 [::]:0 LISTENING
PS C:\WINDOWS\system32>
ОБНОВИТЬ: Прочитав ваш ответ, я хотел бы убедиться, что мы находимся на одной странице с точки зрения номеров портов. Команды в моем ответе предполагают следующее:
-R 5902:127.0.0.1:5901localhost::5902В частности, я думаю, что вы могли запускать сервер TightVNC на порту 5902, несмотря на несоответствие между этим и спецификацией RemoteForward.