Як я можу відновити велику передачу файлів scp при використанні переадресації портів?

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

Редагування: Щоб зрозуміти, для доступу до віддаленої машини потрібно кілька переходів. На своїй машині я встановив VPN, де я можу отримати доступ до 10.255.xx - це єдина машина, до якої я можу підключитися через VPN. Після входу в .xx я зможу підключитися до інших машин - .який один із таких.

З моєї машини:

ssh -L 4567:localhost:4567 me@10.255.x.x

Потім з цієї машини:

ssh -L 4567:localhost:22 me@10.255.y.y

Я можу тоді

scp -P 4567 me@localhost:/path/to/large/file.gz .

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

Я бачив кілька пропозицій використовувати rsync над ssh для відновлення передачі, але мені незрозуміло, як це налаштувати. Чи можливо це?

З деякими версіями scp (версія на комп’ютері-джерелі здається ключовою) для відновлення передачі буде достатньо лише повторного виконання команди scp. Але будьте обережні! Якщо ваша версія не підтримує часткові передачі, частковий файл буде просто перезаписаний.

Наступні комутатори rsync зручні для відновлення перерваної передачі, якщо scp не підтримує її:

     --append                append data onto shorter files
     --append-verify         like --append, but with old data in file checksum
 -e, --rsh=COMMAND           specify the remote shell to use
     --progress              show progress during transfer

Команда

rsync --append-verify --progress --rsh="ssh -p 4567" me@localhost:/path/to/large/file.gz .

повинен мати бажаний ефект. Зверніть увагу, що -pдля ssh повинен бути малий регістр.

Використовуйте sftp замість scp

У вашому випадку:

sftp -a -P 4567 me@localhost:/path/to/large/file.gz .

На сторінці sftp man:

-a      Attempt to continue interrupted downloads rather than overwriting existing partial or complete copies of files.  If the remote file contents differ from the partial local copy then the resultant file is likely to be corrupt.

rsync використовує ssh за замовчуванням, можливо, вам доведеться вказати точну команду ssh за допомогою перемикача rsync's -e. Він також має -partial, який повинен зберігати неповний файл навколо, щоб він міг відновити передачу.

Я не можу зрозуміти, у чому сенс твоїх тунелів, тож ось, як би я вирішив вирішити вашу проблему:

ssh -R $tunnelPort:localhost:$localSSHPort $remoteUser@$remoteHost -p $remoteSSHPort

це відкриває зворотний тунель від локальної машини (localhost) до віддаленої машини (remotehost). $ tunnelPort - порт, на якому тунель можна знайти на віддаленому хості. $ localSSHPort - порт, на якому працює локальний sshd, а $ remoteSSHPort - це місце, де слухає sshd віддаленого господаря.

Тепер, коли ви знаходитесь у (зворотньому!) Тунелі, ви можете більш-менш робити те, що запропонував Денніс:

rsync --apend-verify -az -e 'ssh -p $tunnelPort' /path/to/large/file $user@localhost:/destination

прапори -a та -z пояснюються на сторінці людини rsync, тому я не буду їх детальніше описувати. Зараз відбувається те, що, коли ви запускаєте rsync на віддаленому хості, як вище, він виштовхує всі дані в порт $ tunnelPort, який потім пересилається до sshd $ localSSHPort вашого локального господаря.

Сподіваюся, що це допомогло.