Як виконувати scp з другим віддаленим хостом


83

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

Мережі дозволяють підключення лише до віддаленого2 хосту з віддаленого1 хоста. Крім того, ні віддалений хост, ні віддалений хост не можуть scp перенести на мою локальну машину.

Чи є щось на зразок:

scp user1@remote1:user2@remote2:file .

Перше вікно:, ssh remote1потім scp remot2:file ..

Друга оболонка: scp remote1:file .

Перше вікно: rm file; logout

Я міг би написати сценарій для виконання всіх цих кроків, але якщо є прямий спосіб, я скоріше скористався ним.

Дякую.

EDIT: Я думаю щось на зразок відкриття SSH-тунелів, але мене бентежить, яке значення де поставити.

На даний момент для доступу remote1я маю наступне $HOME/.ssh/configна своїй локальній машині.

Host remote1
   User     user1
   Hostname localhost
   Port     45678

Після ввімкнення remote1для доступу remote2це стандартний локальний DNS і порт 22. Що слід надіти remote1та / або змінити localhost?

Відповіді:


95

Я не знаю жодного способу скопіювати файл безпосередньо однією командою, але якщо ви можете погодитися запустити екземпляр SSH у фоновому режимі, щоб просто тримати тунель переадресації портів відкритим, тоді ви можете скопіювати файл однією командою.

Подобається це:

# First, open the tunnel
ssh -L 1234:remote2:22 -p 45678 user1@remote1
# Then, use the tunnel to copy the file directly from remote2
scp -P 1234 user2@localhost:file .

Зверніть увагу, що ви підключаєтесь як user2@localhostу фактичній scpкоманді, оскільки саме на порту 1234 на localhost перший sshекземпляр прослуховує прямі підключення remote2. Зауважте також, що вам не потрібно запускати першу команду для кожної наступної копії файлу; Ви можете просто залишити його запущеним.


1
Дякую, здається, це близько того, що мені потрібно. Отже, я створив тунель, відбиток пальця відповідає такому на сервері, але у мене є помилка "Дозвіл відхилено (публічний ключ)". Думаю, мені потрібно запитати у моєї мережі / sysadmin, чому вона не працює.
Данозавр

3
Дякую! Мені довелося перейти -p 45678на, -p 22оскільки мій віддалений1 SSH слухає порт 22
Монтаро,

Мені також довелося використовувати -p 22замість -p 45678. Також scp -P 1234 ...не працює для мене. Я отримую ssh: connect to host localhost port 1234: Connection refused. Коли я намагався з scp -P 22 ...цим, це працює, але він копіює файл, remote 1а не на моєму локальному комп'ютері ( remote2).
грішник

Будь-який інструмент інтерфейсу для того самого?
ExploringApple

70

Подвійний ssh

Навіть у складному випадку ви можете обробляти передачу файлів за допомогою одного командного рядка, просто за допомогою ssh;-)
І це корисно, якщо remote1не вдається підключитися до localhost:

ssh user1@remote1 'ssh user2@remote2 "cat file"' > file

tar

Але ви втрачаєте властивості файлу (право власності, дозволи ...).

Однак tarваш друг зберігати такі властивості файлу:

ssh user1@remote1 'ssh user2@remote2 "cd path2; tar c file"' | tar x

Ви також можете стиснути, щоб зменшити пропускну здатність мережі:

ssh user1@remote1 'ssh user2@remote2 "cd path2; tar cj file"' | tar xj

А tarтакож дозволяє передавати рекурсивний каталог через базові ssh:

ssh user1@remote1 'ssh user2@remote2 "cd path2; tar cj ."' | tar xj

ionice

Якщо файл величезний , і ви не хочете турбувати інші важливі мережеві додатки, ви можете пропустити мережу пропускного обмеження наданого scpі rsyncінструменти (наприклад ,scp -l 1024 user@remote:file , не використовує більше 1 Мбіт / секунду).

Але обхідний шлях використовується ioniceдля збереження одного командного рядка:

ionice -c2 -n7 ssh u1@remote1 'ionice -c2 -n7 ssh u2@remote2 "cat file"' > file

Примітка: ioniceможливо, недоступний у старих дистрибутивах.


Дякую за опис, але я думаю, що рішення Dolda2000 простіше. Це було те, що я намагався, але не міг цього зрозуміти.
Данозавр

5
Це вражаюче хороша відповідь і заслуговує на більшу кількість голосів. Крім того, це набагато простіше, ніж прийнята відповідь, на мій погляд.
Рік Сміт-Унна

2
Я згоден, що це краще рішення, ніж прийнята відповідь. Таким чином, з'єднання автоматично очищається.
Даг

Дякую, дуже гарна відповідь! А як щодо іншого, копіювання з локального на віддалений?
DomTomCat

31

Це зробить фокус:

scp -o 'Host remote2' -o 'ProxyCommand ssh user@remote1 nc %h %p' \ 
    user@remote2:path/to/file .

Щоб безпосередньо SCP-файл з хосту remote2, додайте два варіанти ( Hostі ProxyCommand) у свій файл ~ / .ssh / config (див. Також цю відповідь на суперкористувачі). Тоді ви можете запустити:

scp user@remote2:path/to/file .

з вашої локальної машини, не думаючи про це remote1.


Гарний підхід! Хоча -o 'Host remote2', здається, це не потрібно насправді під час запуску з командного рядка (тобто скопіювати один раз, не торкаючись ~ / .ssh / config)
Майк

Те ж саме. Це працює для мене без -o 'Host remote2'. Дякую.
grešnik

7

З openssh версії 7.3 і вище це легко. Використовуйте параметр ProxyJump у файлі конфігурації.

# Add to ~/.ssh/config 
Host bastion
    Hostname bastion.client.com
    User userForBastion
    IdentityFile ~/.ssh/bastion.pem

Host appMachine
    Hostname appMachine.internal.com
    User bastion
    ProxyJump bastion                   # openssh 7.3 version new feature ProxyJump
    IdentityFile ~/.ssh/appMachine.pem. #no need to copy pem file to bastion host  

Команди для запуску для входу або копіювання

ssh appMachine   # no need to specify any tunnel. 
scp helloWorld.txt appMachine:.   # copy without intermediate jumphost/bastion host copy.** 

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

Примітка. Scp , схоже, зараз не підтримує прапор "-J". (Мені не вдалося знайти на сторінках керівництва. Однак вище scp працює з налаштуванням конфігураційного файлу)


1
Немає необхідності додавати сервер бастіону до конфігураційного файлу, якщо він використовується лише для проксінгу (тобто не відрізняється від IdentityFile тощо), просто додайте ProxyJump bastion.client.com до розділу appMachine.
Томер Коен

1

У новій опції scpдодано нещодавно саме ту саму роботу, яка є дуже зручною -3.

TL; DR Для поточного хосту, який вже встановив автентифікацію у файлах конфігурації ssh, просто виконайте:

scp -3 remote1:file remote2:file

Ваш scp повинні бути з останніх версій.

Усі інші згадані методи вимагають налаштування автентифікації з віддаленого1 на віддалений2 або навпаки, що не завжди є гарною ідеєю.
Аргумент -3означає, що ви хочете перемістити файли з двох віддалених хостів, використовуючи поточного хоста як посередника, і цей хост фактично виконує аутентифікацію обох віддалених хостів, тому вони не повинні мати доступу один до одного.
Вам просто потрібно налаштувати автентифікацію у файлах конфігурації ssh, що є досить простим та добре задокументованим, а потім просто запустити команду в TL; DR

Джерелом цієї відповіді є https://superuser.com/a/686527/713762


0

Ця конфігурація добре працює для мене:

Host jump
   User username
   Hostname jumphost.yourorg.intranet
Host production
   User username
   Hostname production.yourorg.intranet
   ProxyCommand ssh -q -W %h:%p jump

Потім команда

scp myfile production:~

Копіює myfile у виробничу машину.


0

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

Подібно до того, як у вас є три способи використання tarдля копіювання з віддаленого хоста на локальний, наступне працює для локального хосту на віддалене хост-копіювання в подвійних ssh-ситуаціях: (запустіть їх у каталозі, звідки потрібно скопіювати файли, інакше використовуйте fullpath / ім'я файлу)

Передача одного файлу без стиснення:

tar c filename |  ssh user1@remote1 'ssh -Y user2@remote2 "path2 && tar x"'

Передача одного файлу зі стисненням:

tar cj filename |  ssh user1@remote1 'ssh -Y user2@remote2 "path2 && tar xj"'

Рекурсивна передача каталогів:

tar cj . |  ssh user1@remote1 'ssh -Y user2@remote2 "path2 && tar xj"'

Тут && заважає виконанню команди, якщо перша половина команди не працює - наприклад, якщо каталог відсутній або є помилка в іменах джерела / пункту призначення.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.