9

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

Редактировать: для ясности, несколько прыжков необходимы для доступа к удаленному компьютеру. Со своей машины я настроил VPN, где я могу получить доступ к 10.255.xx - это единственная машина, к которой я могу подключиться через VPN. После входа в .xx я могу подключиться к другим машинам - .yy, являясь одним из них.

С моей машины:

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 для возобновления передачи, но мне неясно, как это настроить. Это возможно?

4 ответа4

9

В некоторых версиях 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.

1

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

1

Используйте sftp вместо scp

В твоем случае:

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

Со страницы руководства sftp:

-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.
-1

Я не могу понять, в чем смысл ваших туннелей, поэтому вот как я бы решил вашу проблему:

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 вашего локального хоста.

Надеюсь, что это помогло.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .