☰

SSH-туннель не работает

tag-icon • tag-icon macos ssh openssh ubuntu-server ssh-tunnel
SSH-туннель не работает

Я использую следующую команду для создания SSH-туннеля к моему серверу Ubuntu:

ssh -fNg -L 8888:127.0.0.1:22 -p 1000 username@server-address  -v

Затем я установил прокси-сервер OSX http и https на 127.0.0.1:8888

И я получил следующую ошибку:

SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2

Несоответствие протокола.

В чем проблема и как ее решить?

решение1

-L 8888:localhost:22 перенаправит ваш локальный порт 8888 на порт 22 сервера ssh. Пока не запущен сервер squid или другой прокси-сервер, это не будет работать.

SSH может предоставить прокси-сервер Socks, который можно использовать для просмотра через туннель SSH.

ssh -fNg -D 8888 -p 1000 username@server-address  -v

Просто настройте прокси-сервер после подключения:

localhost:8888

решение2

Вы пишете: «Я использую следующую команду для создания SSH-туннеля к моему серверу Ubuntu:

ssh -fNg -L 8888:127.0.0.1:22 -p 1000 имя_пользователя@адрес_сервера -v

Итак, вам понадобится SSH-сервер на порту 1000.

Итак, клиентская программа будет подключаться к порту 8888, и все, что она туда отправит, будет перенаправлено на порт 22 (22 — это порт, обычно используемый для ssh).

Думаю, если бы вы пытались создать туннель ssh внутри ssh, это имело бы смысл, хотя я не могу сходу придумать, нужна ли такая необходимость!

Затем я установил прокси-сервер OSX http и https на 127.0.0.1:8888"

Нет, у вас уже есть SSH, открывающий порт, прослушивающий порт 8888. Вы не можете позволить чему-либо другому прослушивать этот порт.

Если вы поместите http[s] proxy на порт 22 конечной машины (адрес сервера) и настроите свой веб-браузер на использование proxy 127.0.0.1:8888, то ваш веб-браузер сможет подключиться к порту 8888, и он будет перенаправлен на http proxy на порту 22 конечной машины. Когда вы это сделаете, -L 8888:127.0.0.1:22это означает, что вам нужно будет что-то прослушивать на порту 22 конечной машины. И вы можете захотеть изменить 22 на что-то более разумное, например 8080. Я не проверял, но думаю, что это сработает.

В качестве альтернативы, SSH также имеет опцию -D, которая действует как SOCKS-прокси, который может делать HTTP[s], но говорит веб-браузеру подключаться к SOCKS-прокси, а не к обычному HTTPS. Так что я полагаю, что, как сказал Дэвид, ssh -fNg -D 8888 -p 1000 username@server-address -v -fNg и -v, конечно, не являются существенными.

Связанный контент