SSH доступ к офисному хосту за маршрутизатором NAT

Question

Я хотел бы получить доступ к порту SSH моего офисного хоста Linux из дома. К сожалению, хост находится за NAT-маршрутизатором. Таким образом, IP-адрес не является общедоступным. Однако есть доступ к другому интернет-хосту (серверу), который, к сожалению, является только доступом без полномочий root. Спустя некоторое время поиска я не нахожу подходящего решения.

Следующая настройка:

Офисный ПК (linux, root-доступ) за NAT (IP не публичный), но полный доступ в Интернет.
Серверный ПК (linux, без рут-доступа) статический и публичный IP и полный доступ в интернет.
Домашний ПК (linux, root-доступ) за NAT (IP не публичный), но полный доступ в Интернет.

Возможные подключения: Офисный ПК -> Сервер <- Домашний ПК

Невозможно: Офисный ПК <-X- Сервер -X-> Домашний ПК

Ни Домашний ПК, ни Сервер не могут инициировать доступ к Офисному ПК. Но и офисный ПК, и домашний ПК могут инициировать подключения к серверу.

Обратный SSH-туннель невозможен: я попробовал метод, называемый обратным ssh-туннелем. К сожалению, для этого требуется, чтобы для GatewayPorts на сервере было установлено значение "да" в /etc /ssh /sshd_config, где у меня нет доступа с правами root.

В принципе это должно быть возможно:

0) На сервере я запускаю пользовательскую программу, которая прослушивает 2 порта (1 входящий, 1 исходящий)

1) На моем офисном ПК я запускаю другую программу, которая поддерживает соединение TCP открытым для исходящего порта на сервере.

2) Из дома я подключаюсь к входящему порту Сервера.

Там должно быть стандартное решение для этого там.

Какое самое быстрое и чистое решение для решения этой проблемы?

Фрэнк

score 27 · Accepted Answer · 2011-03-09T19:38:42

youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc

Потом:

you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc

you@homepc$ ssh youatwork@localhost -p 23456

Вы можете сделать следующее: на шаге 1 перенаправить удаленный порт с офисного ПК на сервер (в качестве примера используется 12345 , любой порт> 1024 должен делать). Теперь подключение к 12345 на сервере должно соединить вас с портом 22 на officepc.

На шаге 2 перенаправьте порт 23456 с домашней машины на сервер 12345 на сервере (откуда он перенаправляется на officepc:22, как настроено на шаге 1).

На шаге 3 вы подключаетесь к локальному порту 23456, используя логин вашего офисного ПК. Шаг 2 перенаправляется на порт 12345 на вашем сервере, а шаг 1 - на офисный ПК.

Обратите внимание, что я использую autossh для пересылок, так как это ssh-оболочка, которая автоматически переподключает туннель, если он отключен; однако обычный ssh также будет работать, если соединение не прерывается.

Возможна уязвимость: любой, кто может подключиться к localhost: 12345 на serverpc, теперь может подключиться к officepc: 22 и попытаться взломать его. (Обратите внимание, что если вы используете SSH-сервер, вы должны в любом случае защитить его от базовых защит, которые включены по умолчанию; я рекомендую по крайней мере отключить root-вход и отключить аутентификацию по паролю - см., Например, это)

Изменить: я подтвердил это с той же конфигурации, и он работает. GatewayPorts no влияет не только на порты, открытые для всего мира, но не на локальные туннели. Вот что представляют собой перенаправленные порты:

homepc:
  outgoing ssh to serverpc:22
  listening localhost:23456 forwarded through ssh tunnel
serverpc:
  listening ssh at *:22
  incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
  listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
  outgoing ssh to serverpc:22
  incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22

Итак, что касается сетевого стека, то это весь локальный трафик на соответствующих интерфейсах обратной связи (плюс ssh-соединения с serverpc); следовательно, GatewayPorts вообще не проверяется.

Существует, однако, директива AllowTcpForwarding: если это no , эта настройка завершится ошибкой, так как пересылка вообще не разрешена, даже через интерфейс обратной связи.

score 4 · Answer 2 · 2011-03-09T19:38:42

Установите Robo-TiTO на компьютер, к которому вы хотите получить удаленный доступ к SSH.

Это позволит вам получить доступ к SSH с помощью клиентских приложений Google Talk в любом месте.
Нет необходимости в общедоступном IP-адресе или специальных настройках.
Это бесплатно и с открытым исходным кодом, не платя никаких приложений приложений больше.
Не нужно открывать порт SSH (держите компьютер в безопасности).
Нет необходимости открывать туннелирование (например, VPN или что-то подобное)

Следующие инструкции по установке устарели, так как сайт переехал. Новый URL-адрес https://github.com/formigarafa/robotito

Я сделал скрипт (протестирован на моей Raspbian OS в Raspberry Pi), чтобы вы могли легко установить Robo-TiTO на Raspberry Pi, Debian или Ubuntu Box (дистрибутив пакетов Debian). это шаги, чтобы сделать вашу Linux-систему удаленной:

Откройте «Команду оболочки» или вы можете назвать ее «Терминал», перейти в свою домашнюю папку, скачать скрипт установщика командой:
```
$ wget https://opengateway.googlecode.com/files/robotito
```
после этого запустите скрипт, введя команду:
```
$ sudo ./robotito
```
а затем вы можете отредактировать файл credentials.rb из папки конфигурации Robo-TiTO, используя свою учетную запись GTalk, и сохранить его, нажав Ctrl+X и Y. По умолчанию используется нано-редактор.
запуск Robo-TiTO из папки Robo-TiTO по команде
```
$ cd robotito
$ ./jabbershd start
```
Теперь, когда это сделано, вы можете использовать SSH из любого клиента Google Talk. Не забудьте добавить учетную запись Robo-TiTO GTalk в свою учетную запись Google Talk и проверить ее в чате друг с другом перед использованием этой учетной записи.

score 4 · Answer 3 · 2011-03-09T19:38:42

Если вы можете подключиться к ssh к внутреннему серверу из дома и с внутреннего сервера на свой офисный компьютер Linux, то из дома вы можете использовать команду ssh ProxyCommand для бесшумного возврата через сервер на внутренний компьютер через nc (netcat)

# ~/.ssh/config on your home machine:
Host internalpc 
   ForwardAgent yes 
   ProxyCommand ssh user@server.example.com exec nc internal.pc.example.com %p

Затем вы просто ssh user@internalpc и вы молча пересылаетесь через сервер, не требуя открытия портов или туннелей на обоих концах.

score 3 · Answer 4 · 2011-03-09T19:38:42

Решение Писквора работает и приятно. Тем не менее, он удерживает открытыми терминалы с висящими оболочками входа в систему. Не очень круто.

Я всегда использовал этот небольшой скрипт, который я написал, чтобы подключиться к серверу и сохранить его подключенным, запустив его в cron:

#!/bin/bash
TARGET_HOST=${1:-myserver.example.com}
TARGET_PORT=${2:-7777}
TUNNEL_PORT=${3:-22}
T_USER="odin"

#Check that we have an active connection to the remote system
ACTIVE_PROCESS=`ps -ef | \
    grep "ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT" | \
    grep -v grep | \
    wc -l`
if [ $ACTIVE_PROCESS -lt 1 ]; then
    echo "`date` : establishing connection to $TARGET_HOST on port $TARGET_PORT"
    screen -m -d ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT > /dev/null
fi

Могу поспорить, что мы могли бы исправить решение Piskvor, используя более элегантный autossh рядом с, возможно, отдельным экраном или использовать аргументы -NT ssh, чтобы просто поддерживать соединение в фоновом режиме.

score 2 · Answer 5 · 2011-03-09T19:38:42

Мне кажется, вместо туннеля SSH вы должны попробовать VPN: тот тип, который работает с использованием внешнего сервера для прокси, например Hamachi . Есть и другие бесплатные программы, подобные этой, но Hamachi - моя любимая.

Сейчас выбран русский

SSH доступ к офисному хосту за маршрутизатором NAT

5 ответов5

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux ssh firewall nat ssh-tunnel.

Связанные

SSH доступ к офисному хосту за маршрутизатором NAT

5 ответов5

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux ssh firewall nat ssh-tunnel.

Связанные

Похожие