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


33

Я хотів би отримати доступ до ssh-порта мого офісу Linux Linux з дому. На жаль, хост знаходиться за NAT-роутером. Отже, IP-адреса не є загальнодоступною. Однак є доступ до іншого хоста в Інтернеті (Сервера), який, на жаль, має лише некореневий доступ. Через деякий час пошуку я не знаходжу підходящого рішення.

Наступне налаштування:

  • Офіційний ПК (Linux, root-доступ), що стоїть за NAT (IP не загальнодоступний), але повний доступ до Інтернету.
  • Серверний ПК (Linux, відсутність кореневого доступу) статичний та загальнодоступний IP та повний доступ до Інтернету.
  • Домашній ПК (Linux, кореневий доступ) за NAT (IP не загальнодоступний), але повний доступ до Інтернету.

Можливі з'єднання: Офісний ПК -> Сервер <- Домашній ПК

Не можливо: Office PC <-X- Сервер -X-> Домашній ПК

Ні Домашній ПК, ні Сервер не можуть ініціювати доступ до офісного ПК. Але і Office PC, і Домашній ПК можуть ініціювати з'єднання із Сервером.

Зворотний тунель SSH неможливий: я спробував метод, який називається зворотним ssh-тунелем. На жаль, це вимагає, щоб GatewayPorts на сервері встановлено "так" в / etc / ssh / sshd_config, де у мене немає кореневого доступу.

В принципі, це повинно бути можливо:

0) На сервері запускаю програму простору користувачів, яка прослуховує 2 порти (1 вхідний, 1 вихідний)

1) На своєму офісному ПК я запускаю іншу програму, яка підтримує TCP-з'єднання відкритим до вихідного порту на сервері.

2) З дому я підключаюся до вхідного порту Сервера.

Там має бути стандартне рішення для цього.

Яке найшвидше і найчистіше рішення для вирішення цього питання?

Френк


1
чи може робочий ПК підключитися до домашнього налаштування ssh тунелю? en.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, то все одно слід закріпити його над основними захистами, які за замовчуванням увімкнено; я рекомендую принаймні вимкнути кореневе вхід та відключити автентифікацію пароля - див., Наприклад, це )

Редагувати : я підтвердив це тим же конфігурацією, і він працює. 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-тунелем". На жаль, для 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

Якщо ви можете перейти до внутрішнього сервера з дому та від внутрішнього сервера до офісної машини 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
Дякую за вашу відповідь. На жаль, ні домашній ПК, ні сервер не можуть ініціювати доступ до офісного ПК. Але і Office PC, і Домашній ПК можуть ініціювати з'єднання із Сервером.

4

Встановіть Robo-TiTO на комп’ютер, до якого ви хочете віддалено отримати доступ до SSH.

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

Наступні інструкції щодо установки застаріли, оскільки сайт перемістився. Нова URL-адреса https://github.com/formigarafa/robotito

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

  1. Відкрийте команду Shell або ви можете її назвати терміналом, перейдіть до домашньої папки, Завантажте інсталяційний скрипт за командою:

    $ 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 або подібного, щоб дозволити доступ.
formigarafa

1
@formigarafa: (1) Якщо ви або брали участь у розробці цього продукту, ви повинні сказати це прямо. Використання однойменних назв недостатньо; більшість людей цього не помітять. (Ви можете згадати його у своєму профілі .) (2) Під час редагування публікації ви повинні виправити її наскільки це можливо. Наприклад, спробуйте зловити помилки типу "я". І якщо посилання знизилася, не позначайте її як мертву; помістити нову URL-адресу в допис . Люди не повинні копати коментарі, щоб знайти правильну інформацію.
G-Man каже: "Відновіть Моніку"

@ G-Man, оригінальна відповідь та редагування не були моїми. І я ніколи не мав наміру зробити так, щоб він виглядав як мій. Я помітив мертве посилання у відповіді, я також не створив посилання. Я насправді захотів побачити його зміст і намагався його слідкувати. На жаль, я не зміг знайти ресурс. Я позначив як мертве посилання на надію, що той, хто написав відповідь, отримає повідомлення про зміну і спробує виправити це.
formigarafa

3

Рішення Piskvor працює і приємно. Однак термінали тримають відкритими, щоб висіли оболонки для входу. Не дуже круто.

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


Дякую за компліменти :) Для моїх випадків використання мені регулярно потрібен доступ до оболонки, а також переадресація; плюс, я спробував показати мінімальний випадок тут (можна спростити вищезазначене на дві команди з прозорим хост-хостом SSH, але це вимагало б додаткової конфігурації на homepcкомп’ютері).
Пісквор

2

Як мені здається, замість тунелю SSH слід спробувати VPN: такий, який працює, використовуючи зовнішній сервер для проксі-сервера, наприклад, Hamachi . Існують і інші безкоштовні програмні засоби на кшталт цього, але Hamachi - мій фаворит.


1
Тепер, коли в 5.0.0.0/8мережі фактично призначені загальнодоступні адреси IPv4, Hamachi знаходиться в біді (якщо Hamachi працює, ви не можете отримати доступ до дещо випадкової частини Інтернету). Крім того, Hamachi вже не є безкоштовним у користуванні.
Пісквор
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.