¿Cómo puedo reanudar una transferencia de archivos scp grande cuando utilizo el reenvío de puertos?

Tengo una máquina a un par de saltos y necesito configurar el reenvío de puertos para transferir archivos.

Editar: para ser claros, se necesitan los múltiples saltos para acceder a la máquina remota. Desde mi máquina, configuré una VPN, donde puedo acceder a 10.255.xx, que es la única máquina a la que me puedo conectar a través de la VPN. Una vez que inicie sesión en .xx, puedo conectarme a otras máquinas .yy es una de esas.

De mi maquina:

ssh -L 4567:localhost:4567 [email protected]

Entonces de esa máquina:

ssh -L 4567:localhost:22 [email protected]

Entonces puedo

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

Dejé esto corriendo por la noche, solo para descubrir que la transferencia murió en algún momento.

He visto un par de sugerencias para usar rsync a través de ssh para reanudar la transferencia, pero no tengo claro cómo configurarlo. es posible?

Con algunas versiones de scp (la versión en la computadora fuente parece ser la clave), basta con volver a ejecutar el comando scp para reanudar la transferencia. ¡Pero ten cuidado! Si su versión no admite transferencias parciales, el archivo parcial simplemente se sobrescribirá.

Los siguientes modificadores rsync son útiles para reanudar una transferencia interrumpida si scp no lo admite:

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

El comando

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

debería tener el efecto deseado. Tenga en cuenta que el -pmodificador debe estar en minúsculas para ssh.

Use sftp en lugar de scp

En tu caso:

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

Desde la página de manual de 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 usa ssh por defecto, puede que tenga que especificar el comando ssh exacto usando el interruptor -e de rsync. También tiene un --partial que debe mantener el archivo incompleto para que pueda reanudar la transferencia.

Realmente no puedo ver cuál es el punto de sus túneles, así que así es como iría a resolver su problema:

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

esto abre un túnel inverso desde la máquina local (localhost) a la máquina remota (remotehost). $ tunnelPort es el puerto en el que se encuentra el túnel en remotehost. $ localSSHPort es el puerto en el que se ejecuta el sshd local y $ remoteSSHPort es donde escucha el sshd de remotehost.

Ahora que estás dentro del túnel (¡hacia atrás!) Puedes hacer más o menos lo que Dennis propuso:

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

Los indicadores -a y -z se explican en la página de manual de rsync, por lo que no los explicaré. Lo que sucede ahora es que cuando ejecuta rsync en remotehost como se indica arriba, empuja todos los datos al puerto $ tunnelPort que luego se reenvía al sshd $ localSSHPort de su localhost.

Espero que haya ayudado.