¿Existe una solución para transferir archivos grandes a través de una red que sea más rápida, pero tan segura como scp? [cerrado]

Question

¿Existe una solución para transferir archivos grandes a través de una red que sea más rápida, pero tan segura como scp? [cerrado]

#1 de Tom Leek (9 votos)

1

Estoy publicando esto aquí en lugar de Unix / Linux, porque el principal factor de ruptura aquí sería una capa de seguridad deteriorada.

Me pregunto si hay ( notablemente ) soluciones más rápidas disponibles para transferir grandes cantidades de datos entre hosts, en comparación con scp . Sin embargo, no quiero comprometer los aspectos de seguridad de scp , por lo que la respuesta aquí podría ser " tenacidad", lo cual está bien.

Espero que exista algún servicio, sin embargo, que permita una saturación total (o al menos casi total) de la tubería al transferir datos. ¿Tal vez una solución plausible sería tar los archivos en un tar encriptado antes de transferir? ¿Entonces podríamos ser libres de transferir usando la utilidad que deseemos?

file-encryption file-upload

pregunta MrDuk 07.07.2015 - 18:41
fuente

1 respuesta

9

scp usa el protocolo SSH que ya está en condiciones de transferir al ancho de banda completo permitido por la red local, al menos en 100baseT ethernet. Para redes de gigabits, es posible que tenga que juguetear un poco, pero generalmente la CPU no es el cuello de botella.

Ya que no dices muchos detalles sobre tus problemas de rendimiento, solo puedo plantear hipótesis. Lo que hay que decir es lo siguiente:

Su red (los cables y las interfaces de red) tienen un ancho de banda máximo. Por ejemplo, 100baseT Ethernet se ejecuta a 100 Mbits / s ( bits , no bytes), y hay un poco de sobrecarga, por lo que con tales cables puede alcanzar aproximadamente 10 u 11 MBytes / s, no más . Si scp en un solo archivo grande ya te da una cifra comparable, entonces ya eres lo más rápido que puedes ir. Si su rendimiento es notablemente más lento, debe investigar los problemas de hardware y controladores.

Una instalación normal y actualizada de scp debe seleccionar un algoritmo de cifrado razonablemente rápido (normalmente AES-128), que se pueda aplicar de manera eficiente incluso en una PC no tan reciente (100 MBytes / s sería típico ). Es concebible, a través de herramientas obsoletas, configuraciones erróneas o hardware anémico del siglo anterior, que la velocidad de cifrado sin formato es su problema. Para probar eso, es posible que desee ejecutar una herramienta de informe de uso de la CPU (por ejemplo, top en un sistema Linux) mientras realiza la transferencia, tanto en el cliente como en el servidor, para ver si la CPU se satura. También es posible que desee ejecutar el comando scp con el argumento -v para obtener algunos detalles sobre el algoritmo negociado; busca algo que se parece a:

debug1: kex: server->client aes128-ctr [email protected] none

Si no saturas en la CPU, entonces no tienes ninguna mejora que esperar de un cambio de protocolo.

Compresión puede o no ayudar. scp puede comprimir los datos sobre la marcha; use el indicador -C para habilitarlo. La compresión puede hacer que algunos datos sean más cortos, por lo tanto, permitir que se transfieran más rápido, pero esto tiene un costo en la CPU, que luego puede convertirse en el cuello de botella. Los videos grandes, los archivos mp3 y las imágenes jpg ya están comprimidos y, por lo general, no se benefician de la compresión adicional en scp .

Un problema conocido con scp es latencia , no cuando se transfiere un solo archivo, sino cuando se envían muchos archivos pequeños: scp tiende a esperar un reconocimiento de recepción de cada archivo desde el Mira antes de continuar con el siguiente.

Si ese es su caso, entonces la solución es utilizar otro protocolo de transferencia, pero aún dentro de un túnel SSH. Puede, de hecho, canalizar una salida tar ; es tan simple como:

tar cf - somefiles | ssh theserver 'tar xf -'

Sin embargo, puede encontrar rsync más fácil de usar. Puede invocar ssh por usted, por lo que aún usa el túnel SSH (y, por lo tanto, se beneficia de todas las bondades de seguridad), pero será eficaz para enviar archivos, incluidos los directorios opcionales de compresión y "sincronización" (es decir, evitar el envío de archivos que ya están en el otro lado).

respondido por el Tom Leek 07.07.2015 - 20:19
fuente

Lea otras preguntas en las etiquetas file-encryption file-upload

¿La técnica del "SHA-1 malicioso" permitió a la NSA insertar una puerta trasera en el SHA-1? error de intentos de inicio de sesión lógica

score 9 · Accepted Answer

scp usa el protocolo SSH que ya está en condiciones de transferir al ancho de banda completo permitido por la red local, al menos en 100baseT ethernet. Para redes de gigabits, es posible que tenga que juguetear un poco, pero generalmente la CPU no es el cuello de botella.

Ya que no dices muchos detalles sobre tus problemas de rendimiento, solo puedo plantear hipótesis. Lo que hay que decir es lo siguiente:

Su red (los cables y las interfaces de red) tienen un ancho de banda máximo. Por ejemplo, 100baseT Ethernet se ejecuta a 100 Mbits / s ( bits , no bytes), y hay un poco de sobrecarga, por lo que con tales cables puede alcanzar aproximadamente 10 u 11 MBytes / s, no más . Si scp en un solo archivo grande ya te da una cifra comparable, entonces ya eres lo más rápido que puedes ir. Si su rendimiento es notablemente más lento, debe investigar los problemas de hardware y controladores.
Una instalación normal y actualizada de scp debe seleccionar un algoritmo de cifrado razonablemente rápido (normalmente AES-128), que se pueda aplicar de manera eficiente incluso en una PC no tan reciente (100 MBytes / s sería típico ). Es concebible, a través de herramientas obsoletas, configuraciones erróneas o hardware anémico del siglo anterior, que la velocidad de cifrado sin formato es su problema. Para probar eso, es posible que desee ejecutar una herramienta de informe de uso de la CPU (por ejemplo, top en un sistema Linux) mientras realiza la transferencia, tanto en el cliente como en el servidor, para ver si la CPU se satura. También es posible que desee ejecutar el comando scp con el argumento -v para obtener algunos detalles sobre el algoritmo negociado; busca algo que se parece a:

debug1: kex: server->client aes128-ctr [email protected] none

Si no saturas en la CPU, entonces no tienes ninguna mejora que esperar de un cambio de protocolo.
Compresión puede o no ayudar. scp puede comprimir los datos sobre la marcha; use el indicador -C para habilitarlo. La compresión puede hacer que algunos datos sean más cortos, por lo tanto, permitir que se transfieran más rápido, pero esto tiene un costo en la CPU, que luego puede convertirse en el cuello de botella. Los videos grandes, los archivos mp3 y las imágenes jpg ya están comprimidos y, por lo general, no se benefician de la compresión adicional en scp .
Un problema conocido con scp es latencia , no cuando se transfiere un solo archivo, sino cuando se envían muchos archivos pequeños: scp tiende a esperar un reconocimiento de recepción de cada archivo desde el Mira antes de continuar con el siguiente.

Si ese es su caso, entonces la solución es utilizar otro protocolo de transferencia, pero aún dentro de un túnel SSH. Puede, de hecho, canalizar una salida tar ; es tan simple como:

tar cf - somefiles | ssh theserver 'tar xf -'

Sin embargo, puede encontrar rsync más fácil de usar. Puede invocar ssh por usted, por lo que aún usa el túnel SSH (y, por lo tanto, se beneficia de todas las bondades de seguridad), pero será eficaz para enviar archivos, incluidos los directorios opcionales de compresión y "sincronización" (es decir, evitar el envío de archivos que ya están en el otro lado).