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

33

Я хотел бы получить доступ к порту 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) Из дома я подключаюсь к входящему порту Сервера.

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

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

Фрэнк

Ritter
источник
1
можно ли подключить рабочий компьютер к домашней сети, чтобы настроить ssh-туннель? ru.gentoo-wiki.com/wiki/Autossh
Вы можете использовать FileZilla с sftp и переадресацией портов. Выезд: superuser.com/a/1286681/141314
Ноам Манос

Ответы:

31
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
Piskvor
источник
Я полагаю, что этот метод называется «обратный ssh-туннель». К сожалению, для этого необходимо, чтобы для GatewayPorts на сервере было установлено значение «да» в / etc / ssh / sshd_config. Этот сервер не имеет разрешенных портов шлюза, и у меня нет корневого доступа там.
3
@Frank: На самом деле, я так не думаю: GatewayPorts noограничивает открытые порты, чтобы они были доступны только через интерфейс обратной связи; обратите внимание, что на шаге 2 вы пересылаете по интерфейсу обратной связи (на самом деле, оба пересылки являются «только локальными»), так что это может сработать ( AllowTcpForwarding noв конфигурации sshd это может быть нарушено).
Писквор
3
@Frank: Да, подтвердил. Это работает даже с GatewayPorts no; отредактировал ответ. Обратите внимание, что есть другие директивы (такие как PermitOpenи AllowTcpForwarding), которые могут нарушить эту настройку: manpagez.com/man/5/sshd_config
Piskvor
1
Отличный ответ! Это работает, вы спасли мои выходные! Большое спасибо!!
1
моя версия autossh (Fedora Core) не может работать с терминала без -M. Я также связался с другим человеком, который испытал это. Вы правы, что в руководстве это помечено как необязательный аргумент. Хорошо, если это работает для многих людей, жаль, что не для всех.
Ярослав Никитенко
4

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

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

Установите 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 и проверить ее в чате друг с другом перед использованием этой учетной записи.

Ролли Маулана Авангга
источник
5
У меня есть серьезные проблемы с «Нет необходимости открывать SSH порт (держать ваш компьютер СОХРАНИТЬ )» - оболочка поверх трескотня бот , который вы предлагаете защищены, цитирую, CLIENT_PASSPHRASE = "logmein"в незашифрованном виде . Это буквально нулевая безопасность - вы делаете дыру размером с грузовик, чтобы каждый мог войти. В отличие от аутентификации с открытым ключом SSH: я аутентифицируюсь по безопасному каналу, используя учетные данные, которые никогда не пересекаются. Кто сейчас держит их компьютер в безопасности?
Писквор
@Piskvor, robotito будет запускать команды только из контактов из белого списка. github.com/formigarafa/robotito/blob/master/config/…
formigarafa
Я никогда не сталкиваюсь с какими-либо проблемами из-за аутентификации на основе белого списка. Если я не ошибаюсь, передача сообщений шифруется при использовании с GTalk. Так или иначе, я недавно изменил его, и теперь он использует одноразовый пароль от такого инструмента, как Google Authenticator или аналогичный, чтобы разрешить доступ.
Формигарафа
1
@formigarafa: (1) Если вы участвуете в разработке этого продукта, вы должны прямо указать это. Использование одного и того же имени недостаточно; большинство людей этого не заметят. (Вы можете упомянуть это в своем профиле .) (2) Когда вы редактируете сообщение, вы должны исправить это как можно больше. Например, попробуйте поймать опечатки типа «I'ts». И, если ссылка вышла из строя, не просто пометьте ее как мертвую ссылку; поместите новый URL в пост . Люди не должны копаться в комментариях, чтобы найти правильную информацию.
G-Man говорит: «Восстановите Монику»
@ G-Man, оригинальный ответ и редактирование были не мои. И у меня никогда не было намерения заставить его выглядеть как мой. Я заметил мертвую ссылку в ответе, я тоже не создал ссылку. Я действительно стремился увидеть его содержание и пытался следить за ним. К сожалению, я не смог найти ресурс. Я пометил как неработающую ссылку в надежде, что тот, кто напишет ответ, будет уведомлен об изменениях и попытается их исправить.
Формигарафа
3

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

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

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

djangofan
источник
1
Теперь, когда 5.0.0.0/8сети фактически назначены общедоступные IPv4-адреса, у Hamachi возникли проблемы (если Hamachi работает, вы не можете получить доступ к несколько случайной части Интернета). Кроме того, Hamachi больше не является бесплатным для использования.
Писквор