La radice di un sistema può accedere a dati non criptati quando si utilizza un doppio tunnel?

Prima di provare a scambiare prestazioni per sicurezza, suggerisco di misurare le prestazioni. Il sovraccarico per la crittografia SSH è lieve; aumenta la dimensione dei dati di meno dell'1% e l'utilizzo della CPU è basso a meno che non si abbia una CPU piuttosto debole o una rete piuttosto veloce (una CPU Core2 può tenere il passo con 10 MBytes / s SSH utilizzando meno del 15% di un singolo core ). Quindi è probabile che il metodo sicuro, con il doppio tunnel, non sia così costoso.

Inoltre, nel tuo secondo suggerimento, hai meno overhead di dimensioni, e anche meno overhead della CPU sul tuo sistema desktop (A), ma più overhead della CPU sul gateway (B), poiché quel gateway dovrebbe decodificare i dati da A e reencrypt per inviarlo a C. Dal momento che un gateway tende ad essere una risorsa condivisa, è probabile che la CPU libera sia più scarsa su B che A. Pertanto, se le prestazioni sono importanti (non credo, e dovrebbe essere comunque misurato), allora il metodo sicuro è anche il metodo migliore per prestazioni.

Come sottolinea @ Iszi, il tuo secondo metodo è anche insicuro, poiché consentirebbe al gateway di creare un Attacco MitM . Vorrei sottolineare che rende anche più difficile l'utilizzo di scp . Pertanto, dovresti utilizzare il metodo tunnel-in-tunnel: è più sicuro, più flessibile e potrebbe anche essere più veloce.

Se qualcuno ha accesso a B nello scenario indicato, potrebbe configurare un proxy per eseguire un attacco man-in-the-middle sulla connessione da A a C. Ciò consentirebbe loro di decrittografare qualsiasi traffico tra A e C, se non è altrimenti criptato a un livello più alto.

L'attaccante configurerebbe B per presentarsi ad A come C mentre usa la coppia di chiavi dell'attaccante. Quindi impersonerebbe allo stesso modo A a C, in modo che le informazioni possano essere passate attraverso B come se non stesse accadendo nulla di insolito tranne che l'attaccante possa ora annusare il traffico in B.

L'unico modo per rilevare questo sarebbe per A e / o C di avere copie preesistenti e verificate delle chiavi pubbliche degli altri. Quindi, quando l'attaccante salta a metà usando le sue chiavi, l'entità non attendibile può essere riconosciuta e la connessione rifiutata.

Sì, è possibile che l'utente root su B esegua il snoop del traffico, anche se non dici esattamente quale sistema operativo è. Su Linux, questo potrebbe includere il programma ttysnoop o usare un debugger contro sshd.

Ho usato molto tunnel-in-a-tunnel (oltre a SSH su PPP su SSH, che è ancora un altro livello), e non ha necessariamente un serio carico di prestazioni o di latenza. Ovviamente, c'è un sovraccarico alcuni , ma non più della solita variabilità di una connessione.

Considera il caso peggiore per un singolo personaggio. In Telnet che verrebbe inviato come frame Ethernet con un carico utile di 46 byte (20 byte intestazione IP, 20 byte intestazione TCP, 1 byte di dati, ma lo standard Ethernet richiede 46 byte di carico utile minimo, 42 in un ambiente VLAN). In SSH sarebbe un carico utile di 68 byte ("La dimensione minima di un pacchetto è 16 (o la dimensione del blocco di cifratura, qualunque sia maggiore) byte (più 'mac').", RFC 4253 ); Vedo 92 byte che guardano una connessione reale con Wireshark. In SSH-over-SSH c'è il sovraccarico del telegramma SSH; Vedo un carico utile di 140 byte.

L'invio di molti dati, SSH utilizza frame (su TCP, quindi non limitato dalla dimensione del pacchetto) fino a 32k byte, quindi l'overhead del doppio tunneling è trascurabile. Mi ci vogliono 20 secondi per trasferire un file 2M su una VM a cui posso accedere direttamente tramite un tunnel SSH o tramite SSH. Se I dd un file di testo 36k, richiede circa 84 pacchetti quasi tutti i 1380 byte lunghi da inviare da una sessione ssh "semplice".

Infine, il comando esatto che hai dato,

ssh user@B ssh user@C

probabilmente non farà quello che ti aspetti; questo secondo "ssh" probabilmente darà il messaggio "Lo pseudo-terminale non verrà assegnato perché stdin non è un terminale", e otterrai una shell che non ti chiede di inserire o supportare la modifica da riga di comando. Invece prova

ssh user@B -t ssh user@C

Si noti inoltre che questo potrebbe effettivamente portare a più piccoli pacchetti (= overhead dell'header TCP e ritardo reale) se l'host B non può tenere il passo con i dati che vi entrano.