Esiste una soluzione per trasferire file di grandi dimensioni su una rete che è più veloce, ma altrettanto sicura di scp? [chiuso]

Question

Esiste una soluzione per trasferire file di grandi dimensioni su una rete che è più veloce, ma altrettanto sicura di scp? [chiuso]

#1 da (9 voti)

1

Sto postando questo qui piuttosto che unix / linux, perché l'interruttore principale sarebbe un livello di sicurezza deteriorato.

Mi chiedo se ci sono ( notevolmente ) soluzioni più veloci disponibili per il trasferimento di grandi quantità di dati tra host, rispetto a scp ? Tuttavia, non voglio compromettere gli aspetti di sicurezza di scp , quindi la risposta potrebbe essere solo " sfortuna ", che va bene.

Spero che esista anche un servizio che consente la saturazione delle pipe piena (o almeno quasi completa) durante il trasferimento dei dati. Forse una soluzione plausibile sarebbe quella di tar dei file in un catrame crittografato prima del trasferimento? Quindi potremmo essere liberi di trasferire utilizzando qualsiasi utility desideriamo?

file-encryption file-upload

posta MrDuk 07.07.2015 - 18:41

fonte

1 risposta

Leggi altre domande sui tag file-encryption file-upload

Keepass - password paranoia Perché il riempimento della pompa di benzina richiede una scansione rapida della carta di credito / debito?

score 9 · Accepted Answer

scp utilizza il protocollo SSH che è già in grado di trasferire sull'intera larghezza di banda consentita dalla rete locale, almeno su 100baseT ethernet. Per le reti gigabit, potresti dover smanettare un po ', ma in genere la CPU non è il collo di bottiglia.

Dato che non racconti molti dettagli sui tuoi problemi di prestazioni, posso solo azzardare ipotesi. Ciò che deve essere detto è il seguente:

La tua rete (i fili e le interfacce di rete) ha una larghezza di banda massima. Ad esempio, 100baseT ethernet gira a 100 Mbits / s ( bit , non byte), e c'è un po 'di overhead, quindi con tali cavi si possono raggiungere circa 10 o 11 MByte / s, non più . Se scp su un singolo file grande ti dà già una cifra comparabile, allora sei già veloce come puoi. Se la tua performance è notevolmente più lenta, dovresti esaminare i problemi relativi all'hardware e al driver.
Un'installazione normale e aggiornata di% co_de dovrebbe selezionare un algoritmo di crittografia ragionevolmente veloce (tipicamente AES-128), che può essere applicato in modo efficiente anche da PC non recenti (100 MByte / s sarebbero tipici ). È concepibile, attraverso strumenti obsoleti, configurazione errata o hardware anemico del secolo scorso, che la velocità di crittografia grezza sia il tuo problema. Per verificarlo, è consigliabile eseguire uno strumento di report sull'utilizzo della CPU (ad esempio scp su un sistema Linux) mentre si esegue il trasferimento, sia sul client che sul server, per verificare se la CPU si satura. Potresti anche voler eseguire il comando top con l'argomento scp per ottenere alcuni dettagli sull'algoritmo negoziato; cercare qualcosa che assomigli a:

-v

Se non si saturano sulla CPU, non ci si aspetta miglioramenti da una modifica del protocollo.
La compressione può o non può aiutare. debug1: kex: server->client aes128-ctr [email protected] none può comprimere i dati al volo; usa il flag scp per abilitarlo. La compressione può rendere più brevi alcuni dati, quindi consente di trasferirli più rapidamente, ma ciò comporta un costo in CPU, che può quindi diventare il collo di bottiglia. Big video, file mp3 e immagini jpg sono già compressi e solitamente non beneficiano della compressione extra di -C .
Un problema noto con scp è latenza , non quando si trasferisce un singolo file, ma quando si inviano molti file piccoli: scp tende ad attendere il riconoscimento della ricezione di ciascun file dal peer prima di procedere con il prossimo.

Se questo è il tuo caso, allora la soluzione è davvero usare un altro protocollo di trasferimento, ma comunque all'interno di un tunnel SSH. È possibile, infatti, convogliare un po 'di output scp ; è semplice come:

tar

Tuttavia, è possibile trovare rsync più facile da usare. Può invocare tar cf - somefiles | ssh theserver 'tar xf -' per te, quindi usi ancora il tunnel SSH (e quindi beneficia di tutta la sicurezza), ma sarà efficiente per l'invio di file, inclusa la compressione opzionale e le directory di "sincronizzazione" (evitando così l'invio di file che sono già sul lato opposto).