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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фрэнк

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, эта настройка не будет выполнена, поскольку пересылка вообще не разрешена, даже через интерфейс обратной связи.

Предостережения :

• Если вы используете autossh и последние ssh, вы можете использовать ssh ServerAliveIntervalи ServerAliveCountMaxдля поддержания туннеля. Autossh имеет встроенную проверку, но, очевидно, у него есть некоторые проблемы с Fedora. -M0отключает это и -oServerAliveInterval=20 -oServerAliveCountMax=3проверяет, установлено ли соединение - пробует каждые 20 секунд, если оно терпит неудачу 3 раза подряд, останавливает ssh (и autossh создает новое):

  autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  
  autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  

• может быть полезно перезапустить ssh-туннель, если переадресация завершается неудачно, используя -oExitOnForwardFailure=yes- если порт уже привязан, вы можете получить работающее соединение SSH, но не переадресованный туннель.

• ~/.ssh/configрекомендуется использовать для параметров (и портов), в противном случае командные строки становятся слишком многословными. Например:

  Host fwdserverpc
      Hostname serverpc
      User notroot
      ServerAliveInterval 20
      ServerAliveCountMax 3
      ExitOnForwardFailure yes
      LocalForward 23456 localhost:12345
  

Тогда вы можете использовать только псевдоним сервера:

    autossh -M0 fwdserverpc

Если вы можете подключиться к 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и молча перенаправляетесь через серверную машину, не требуется открывать порты или туннели с обеих сторон

Установите 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-систему удаленной:

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

   $ wget https://opengateway.googlecode.com/files/robotito
   

2. после этого запустите скрипт, введя команду:

   $ sudo ./robotito
   

3. а затем вы можете редактировать файл credentials.rbиз папки конфигурации Robo-TiTO, используя свою учетную запись GTalk, и сохранять его, нажимая Ctrl+ Xи Y. По умолчанию используется нано-редактор.

4. запуск Robo-TiTO из папки Robo-TiTO по команде

   $ cd robotito
   $ ./jabbershd start
   

5. Теперь, когда это сделано, вы можете использовать SSH из любого клиента Google Talk. Не забудьте добавить учетную запись Robo-TiTO GTalk в свою учетную запись Google Talk и проверить ее в чате друг с другом перед использованием этой учетной записи.

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

Я всегда использовал этот небольшой скрипт, который я написал, чтобы подключиться к серверу и сохранить его подключенным, запустив его в 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, чтобы просто поддерживать соединение в фоновом режиме.

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