Можно ли пересылать ssh-запросы, поступающие через определенный порт, на другой компьютер?

StackOverflow https://stackoverflow.com/questions/45230

  •  09-06-2019
  •  | 
  •  

Вопрос

У меня небольшая локальная сеть.Только одна из машин доступна внешнему миру (это нелегко изменить).Я хотел бы иметь возможность настроить его так, чтобы запросы ssh, которые не поступают на стандартный порт, передавались на другой компьютер.Это возможно?Если да, то как?

Да, и все эти машины работают под управлением Ubuntu или OS X.

Это было полезно?

Решение

Другой способ — использовать ssh-туннелирование (которое происходит на стороне клиента).

Вы должны выполнить команду ssh следующим образом:

ssh -L 8022:myinsideserver:22 paul@myoutsideserver

Это подключает вас к машине, доступной снаружи (myoutsideserver), и создает туннель через это ssh-соединение к порту 22 (стандартный ssh-порт) на сервере, доступный только изнутри.

Затем вы должны выполнить еще одну ssh-команду, подобную этой (оставив первую подключенной):

ssh -p 8022 paul@localhost

Это соединение с портом 8022 на вашем локальном хосте затем будет туннелировано через первое ssh-соединение, которое приведет вас через myinsideserver.

Возможно, вам нужно что-то сделать на моем внешнем сервере, чтобы разрешить переадресацию порта ssh.Я сейчас это перепроверяю.

Редактировать

Хм.На странице руководства ssh говорится следующее:**Только суперпользователь может перенаправлять привилегированные порты.**

Для меня это означает, что первое ssh-соединение должно быть от имени пользователя root.Может быть, кто-то еще сможет это прояснить.

Похоже, права суперпользователя не требуются, пока перенаправленный порт (в данном случае 8022) не является привилегированным портом (например, 22).Спасибо за разъяснения Майк Стоун.

Другие советы

(В этом примере я предполагаю, что порт 2222 будет подключен к вашему внутреннему хосту.$externalip и $internalip — это IP-адреса или имена хостов видимого и внутреннего компьютера соответственно.)

У вас есть несколько вариантов, в зависимости от того, насколько постоянным вы хотите, чтобы прокси было:

  • Какой-то TCP-прокси.В Linux основная идея заключается в том, что до входящий пакет обработан, вы хотите изменить пункт назначения-т.е.предварительная маршрутизация NAT назначения:

    iptables -t nat -A PREROUTING -p tcp -i eth0 -d $externalip --dport 2222 --sport 1024:65535 -j DNAT --to $internalip:22

  • Использование SSH для временной переадресации портов.Отсюда у вас снова есть два варианта:

    • Прозрачный прокси, когда клиент думает, что ваш видимый хост (на порту 2222) — это обычный SSH-сервер, и не осознает, что он проходит через него.Хотя вы теряете некоторый детальный контроль, вы получаете удобство (особенно, если вы хотите использовать SSH для перенаправления VNC или X11 на весь путь к внутреннему хосту).

      • С внутренней машины: ssh -g -R 2222:localhost:22 $externalip
      • Затем из внешнего мира: ssh -p 2222 $externalip

      Обратите внимание, что «внутренние» и «внешние» машины не обязательно должны находиться в одной локальной сети.Таким образом вы можете переносить порт вперед по всему миру.

    • Сначала принудительный вход на внешний компьютер.Это настоящая «пересылка», а не «проксирование»;но основная идея такова:Вы заставляете людей входить на внешний компьютер (таким образом вы контролируете, кто и когда может войти в систему, и получаете журналы активности), и оттуда они могут SSH проникнуть внутрь.Это звучит как рутинная работа, но если вы настройте простые сценарии оболочки на внешнем компьютере с именами ваших внутренних хостов в сочетании с парами ключей SSH без пароля. тогда пользователю очень просто войти в систему.Так:

      • На внешней машине вы создаете простой скрипт, /usr/local/bin/internalhost который просто работает ssh $internalip
      • Из внешнего мира пользователи делают: ssh $externalip internalhost и как только они входят в систему на первой машине, они немедленно перенаправляются на внутреннюю.

      Еще одним преимуществом этого подхода является то, что у людей не возникает проблем с управлением ключами, поскольку запуск двух служб SSH на одном IP-адресе рассердит SSH-клиента.

К вашему сведению, если вы хотите подключиться к серверу по SSH и не хотите беспокоиться о ключах, сделайте это

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

В моей оболочке есть псевдоним «nossh», поэтому я могу просто сделать nossh somehost и он будет игнорировать все ключевые ошибки.Просто поймите, что при этом вы игнорируете информацию о безопасности, поэтому существует теоретический риск.

Большая часть этой информации взята из доклада, который я провел в Barcamp Bangkok, о причудливых трюках SSH.Ты можешь видеть мои слайды, но я рекомендую текстовая версия поскольку слайды S5 какие-то глючные.Ознакомьтесь с разделом «Переслать что угодно»:Простая переадресация портов» для информации.Также есть информация о создании прокси SOCKS5 с OpenSSH.Да, вы можете это сделать.OpenSSH в этом отношении великолепен.

(Наконец, если вы часто заходите во внутреннюю сеть, рассмотрите возможность настройки VPN.Звучит страшно, но OpenVPN довольно прост и работает на всех ОС.Я бы сказал, что это излишне только для SSH;но как только вы начнете переадресацию портов через переадресацию портов, чтобы запустить VNC, HTTP или другие вещи;или если вам нужно беспокоиться о большом количестве внутренних хостов, это может быть проще и удобнее в обслуживании.)

@Марк Бик

Я собирался это сказать, но ты меня опередил!В любом случае, я просто хотел добавить, что есть еще опция -R:

ssh -R 8022:myinsideserver:22 paul@myoutsideserver

Разница в том, к какой машине вы подключаетесь.Мой босс не так давно показал мне этот трюк, и это определенно очень приятно знать...мы находились за брандмауэром, и нам нужно было предоставить внешний доступ к машине...он обошел это с помощью ssh -R на другую машину, которая была доступна...затем соединения с этим компьютером перенаправлялись на компьютер за брандмауэром, поэтому вам нужно использовать -R или -L в зависимости от того, на каком компьютере вы находитесь и к которому подключаетесь по SSH.

Кроме того, я почти уверен, что вы можете использовать обычного пользователя, если порт, который вы перенаправляете (в данном случае порт 8022), не находится ниже ограниченного диапазона (который, я думаю, равен 1024, но я могу ошибаться) , потому что это «зарезервированные» порты.Не имеет значения, что вы перенаправляете его на «ограниченный» порт, потому что этот порт не открывается (машина просто передает трафик через туннель, она не знает туннеля), порт 8022 IS быть открытым и поэтому ограниченным как таковое.

РЕДАКТИРОВАТЬ:Просто помните, что туннель открыт только до тех пор, пока исходный ssh ​​остается открытым, поэтому, если истечет время ожидания или вы выйдете из него, туннель закроется.

Для этого вы можете использовать переадресацию портов.Посмотрите здесь:

http://portforward.com/help/portforwarding.htm

На этой странице есть инструкции о том, как настроить маршрутизатор на запрос переадресации портов:

http://www.portforward.com/english/routers/port_forwarding/routerindex.htm

В Ubuntu вы можете установить Поджигатель а затем использовать его Форвард Сервис функция перенаправления SSH-трафика с нестандартного порта на вашем компьютере с внешним доступом к порту 22 на компьютере внутри вашей сети.

В OS X вы можете редактировать /etc/nat/natd.plist файл, чтобы включить переадресацию портов.

Не возясь с правилами брандмауэра, вы можете настроить файл ~/.ssh/config.

Предположим, что 10.1.1.1 является системой «шлюза», а 10.1.1.2 — системой «клиент».

Host gateway
  Hostname 10.1.1.1 
  LocalForward 8022 10.1.1.2:22 

Host client
  Hostname localhost
  Port 8022

Вы можете открыть ssh-соединение со «шлюзом» через:

ssh gateway

В другом терминале откройте соединение с клиентом.

ssh client
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top