Туннельное объединение в цепочку SSH

Я использовал Bitvise WinSSHD на нескольких серверах с этой целью. Это (удушье) стоит денег, ~ $99 / сервер, но это дает Вам большое разнообразие опций SFTP, включая способность импортировать ключи для устранения использования паролей для аутентификации.

Работы беспрепятственно с Mac, *отклоняют и клиенты Windows на основе моего опыта с ним до настоящего времени.

http://www.bitvise.com

HTH

0
задан 8 October 2013 в 08:42
1 ответ

With the solution from chrisjordan.ca, each connection is encrypted. Which means that each packet from A->E is encrypted & decrypted 4 times. It's also subject to multiple layers of ssh tunnel overhead, which can hurt performance above and beyond the CPU cost of encryption. See HPN SSH for information about the negative implications of sending your traffic over an ssh connection.

You are starting from some host before A, let's call it 0.

0-A traffic is encrypted by the first ssh, which creates a tunnel over the ssh connection. This tunnel drops out of ssh at A, and forwards any traffic without further encryption (at least, not by this particular SSH) to B.

0-B traffic is encrypted by the second ssh. This ssh traverses the first ssh's tunnel from 0-A, drops out of the tunnel, and then terminates at B. This ssh also creates a second tunnel. Traffic using that tunnel goes through the 0-B ssh connection, drops out of ssh at B, and is forwarded without further encryption to C.

0-C traffic, similarly, traverses the 0-B tunnel, then drops out, proceeds to C, where it terminates. It creates another tunnel.

Similarly, 0-D and finally 0-E traffic is all forwarded through progressively more ssh tunnels.

So what's the difference between that and the method you suggest?

1) you don't have multiple layers of encryption and tunneling, so your method should be faster. Potentially much faster.

2) On the other hand, your method requires that you trust each host along the way with the traffic that you are sending between 0 and E. The blog solution prevents that, because the innermost ssh connection encrypts all traffic between 0 and E.

3) similarly, the blog solution creates a transparent ssh connection between 0 and E, so you can do things like run scp/sftp from end to end.

If you are worried about the performance, but want to maintain the end-to-end encryption used between 0 and E, you could probably construct a tunnel, hop-by-hop, with individual ssh connections. Something like (untested):

0%  ssh -L6000:localhost:6000 A
A%  ssh -L6000:localhost:6000 B
B%  ssh -L6000:localhost:6000 C
C%  ssh -L6000:E:22 D

Then in a separate window...

0% ssh localhost:6000
E%
0
ответ дан 5 December 2019 в 14:50

Теги

Похожие вопросы