Как я могу возобновить передачу большого файла scp при использовании переадресации портов?

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

Редактировать: для ясности, несколько прыжков необходимы для доступа к удаленному компьютеру. Со своей машины я настроил 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 для возобновления передачи, но мне неясно, как это настроить. Это возможно?

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

-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 с помощью ключа -e rsync. Он также имеет --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 вашего локального хоста.

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