SCP через підключення шлюзу SSH

Мій макет мережі приблизно такий:

Тепер Аліса має доступ до шлюзу SSH (лише шлюз відтепер) з:

ssh alice@external.ip

і файл авторизованих ключів на шлюзі виглядає приблизно так

#/home/Alice/.ssh/authorized_keys
command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost

тому, коли Аліса намагається підключитися до шлюзу за допомогою свого приватного ключа, вона насправді підключається до веб-сервера (шлюз ПК може з’єднатись із веб-сервером за допомогою безкористувацького приватного ключа, щоб він залишався прозорим).

Питання

1. Як я можу налаштувати це так, щоб Аліса змогла також робити речі на веб-сервері?

2. Я знаю, що це робить окремий зв'язок, але чи є спосіб, щоб це працювало як звичайний ssh, щоб навіть щось подібне -R12345:localhost:22працювало?

Якщо ви хочете отримати доступ до ssh-сервера за іншим ssh-сервером, просто використовуйте "ProxyCommand". Приклад: додати до .ssh / config

Host Alice  
   User myLoginAtAlice # optional 
   ProxyCommand ssh -o Compression=no gateway netcat -w 90 %h %p
   ServerAliveInterval 30
   Compression yes

Host gateway
   HostName gateway.public.ip
   User myLoginAtTheGateway # optional 
   Compression yes

Тоді ви можете просто "ssh Alice" або "rsync" або "scp" безпосередньо, використовуючи "Alice" як ім'я хоста. Магія прихована для клієнта.

Це дозволяє швидко налаштувати свій ssh ​​у разі зміни топології / конфігурації мережі та просто змінити .ssh / config, замість того, щоб змінювати кожен сценарій.

Пояснення: ssh використовує команду, задану як команда проксі, як транспорт, а не пряме з'єднання TCP. Netcat - це мережевий інструмент, який (серед мільйонів інших функцій) просто перенаправляє свій stdin / stdout на вказаний віддалений хост. Отже, "ssh шлюз nc sshserver 22" підключає вас до ssh-сервера цієї машини. % h - ім'я хоста,% p - порт. Така настройка дозволяє вказати "Port N" для зміни порту без зміни лінії ProxyCommand.

Я активую компресію на кінцевий комп'ютер і відключаю зовнішнє стиснення, оскільки стиснення зашифрованих або стислих даних більше не зменшує обсяг даних. Зрозуміло, будь-яке зі налаштуваннями стиснення також необов'язково.

У мене була точно така ж проблема, як ця, але я змусив її працювати, не змінюючи докорінно все.

Все, що я зробив, - це додати $ SSH_ORIGINAL_COMMAND до шлюзу санкціонованих_кейтів, щоб пропустити через що-небудь по ланцюгу до остаточного сервера.

Отже це:

#/home/Alice/.ssh/authorized_keys
command="ssh -t alice@web" ssh-rsa ABCD...E== alice@somehost

Стає:

#/home/Alice/.ssh/authorized_keys
command="ssh -q -t alice@web $SSH_ORIGINAL_COMMAND" ssh-rsa ABCD...E== alice@somehost

-Q використовується для придушення закритого зв'язку з'єднання з машини кінцевої точки, щоб воно не закінчувалося на локальному виході, якщо використовується переадресація локально.

Потім можна використовувати scp так:

scp localFileName alice@exernal.ip:/path/on/end/point/remoteFileName

У цьому є додаткова перевага - дозволити користувачам передавати команди за допомогою команд серверу кінцевих точок і отримувати результат назад у своєму локальному сеансі, щоб вони могли перенаправляти їх у файл або передавати їх іншій програмі.

Наприклад:

ssh -t alice@external.ip "ls -l" > tmp

Це працює, тому що, здається, sshd заповнює змінну середовища $ SSH_ORIGINAL_COMMAND з та командою, вказаною клієнтом ssh, але я не впевнений, чому це дивом дозволяє scp пройти до машини кінцевої точки, а також команд.

На жаль, переадресація портів не допоможе скопіювати файли безпосередньо з робочої станції Аліси на веб-сервер за допомогою scp. У цій публікації SO я пояснив, чому ssh (і scp, оскільки він використовує ті самі механізми аутентифікації), не працюватимуть для переадресації портів, використовуючи ssh.

Можливістю було б встановити VPN-сервер на машині, яка зараз діє як шлюз SSH, підключитися до нього, а потім мати прямий доступ до будь-якої машини за брандмауером.