Да, существуют различия, когда localhost
и myserver.com
разрешают использование разных адресов (разных компьютеров).
Поскольку ваши примеры используют порт 22
который является стандартным портом для SSH, я изменил это число на 222
в своем ответе. Суть в том, чтобы определить разницу между SSH-соединением несущей (по умолчанию к порту 22
) и целью туннеля SSH.
Результат кажется одинаковым для них обоих.
Для ясности для будущих читателей: обе команды заставляют данные, вводимые localhost:2222
переходить к процессу, который прослушивает порт 222
(22
в исходном вопросе) на компьютере myserver.com
. Мы говорим о TCP-портах здесь.
1.
ssh -f -L 2222:myserver.com:222 localhost -N
С этой командой
- вам нужен SSH доступ к
localhost
;
- соединение SSH является локальным, поэтому любое шифрование, которое оно обеспечивает, является просто ненужной вычислительной работой;
- SSH-сервер передает данные на удаленный
myserver.com:222
точно так же, как он входит в локальный порт 2222
, поэтому на этом этапе дополнительное шифрование не выполняется (данные, поступающие в локальный порт 2222
могут быть зашифрованы заранее или нет, это независимая);
myserver.com
видит подключение к своему порту 222
как поступающее извне (от вашего локального хоста, который не является их localhost
), поэтому порт 222
не должен быть там заблокирован брандмауэром.
Если вы подключитесь напрямую к myserver.com:222
вместо localhost:2222
результат будет таким же, потому что myserver.com
не скажет разницы. Вот почему я считаю эту первую команду практически бесполезной. (Почему "почти"? - объясню в конце.)
2.
ssh -f -L 2222:localhost:222 myserver.com -N
В этом случае
- вам нужен SSH доступ к
myserver.com
;
- SSH-соединение идет на другую машину, все данные на этом этапе шифруются ;
- сервер SSH decrytps туннелированные данные и передает его в собственной
localhost
т.е. локально на одной машине;
myserver.com
видит подключение к своему порту 222
как исходящее от него (локально), и это должно проходить через брандмауэр, потому что редко блокируют локальные подключения; процесс прослушивания может даже прослушивать только интерфейс обратной связи.
Для меня совершенно ясно, что эта вторая команда является лучшей.
Один из сценариев, когда первая команда может быть полезна: если другому (третьему) компьютеру требуется доступ к myserver.com:222
и у него нет маршрута к нему, решение может быть связано с подключением к порту 2222
вашего localhost (который не является его localhost
). , Обратите внимание, что для команды -g
требуется ssh
(обратитесь к man ssh
чтобы узнать больше). Для этой цели вы можете использовать любую из двух команд, но если у вас нет доступа по SSH к myserver.com
то вторая команда не будет работать.
Ну, можно было бы построить туннель целиком с третьего компьютера. Команда будет:
ssh -f -L 2222:myserver.com:222 ssh-server -N
# then connect to their own localhost:2222
Очевидно, это требует SSH-доступа к ssh-server
(ваш localhost
). Но давайте предположим, что третий компьютер принадлежит вашему другу без SSH-доступа к ssh-server
. Вы (с доступом) можете построить для них туннель с помощью первой команды и опции -g
. Затем они должны подключиться к ssh-server:2222
.