compiling.ru

Мультиплексирование подключения

Вы производите много подключений к похожим серверам? Возможно, вы не заметили, как тормозит подключение к оболочке. Если вы мультиплексируете подключение, то вам будет проще это отслеживать. Давайте проверим разницу между мультиплексированным подключением с использованием ключей SSH и немультиплексированным подключением с ключами SSH:

01        # Without multiplexing enabled:

02        $ time ssh symkat@symkat.com uptime

03        20:47:42 up 16 days,  1:13,  3 users,  load average: 0.00, 0.01, 0.00

04

05        real    0m1.215s

06        user    0m0.031s

07        sys 0m0.008s

08

09        # With multiplexing enabled:

10        $ time ssh symkat@symkat.com uptime

11        20:48:43 up 16 days,  1:14,  4 users,  load average: 0.00, 0.00, 0.00

12

13        real    0m0.174s

14        user    0m0.003s

15        sys 0m0.004s

Мы можем увидеть, что мультиплексированное подключение гораздо боле быстрое, в этом случае, в 7 раз быстрее немультиплексированного подключения. Все последующие подключения будут использовать тот же сокет для подключения к удаленному хосту. Это позволит нам экономить время, не требуя каждый раз первоначального шифрования, смены ключей и расчетов последующего подключения к серверу.

Для того чтобы задействовать мультиплексирование сделайте следующее:

$ mkdir –p ~/.ssh/connections

$ chmod 700 ~/.ssh/connections

Добавьте эти строки в ваш ~/.ssh/config файл:

ControlMaster auto

ControlPath ~/.ssh/connections/%r_%h_%p

Чтобы определенный хост не использовал мультиплексированное соединение, добавьте следующие строки в файл ~/.ssh/config:

Host YOUR_SERVER_OR_IP

MasterControl no

Есть специальные меры безопасности, которые нужно применять при таком подходе. Давайте рассмотрим, что же действительно происходит, когда мы подключаем второе соединение:

1          $ ssh -v -i /dev/null symkat@symkat.com

2          OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006

3          debug1: Reading configuration data /Users/symkat/.ssh/config

4          debug1: Reading configuration data /etc/ssh_config

5          debug1: Applying options for *

6          debug1: auto-mux: Trying existing master

7          Last login:

8          symkat@symkat:~$ exit

Как мы видим, реальной аутентификации не происходит. Это приводит к рискам безопасности при работе с непроверенным хостом, так как пользователь, имеющий право чтения и записи в сокет, может получить подключение без необходимости вводить пароль.

.

Ранее:   SSH: Полезные советы и хитрости

Далее:  SSH Pipe

Popularity: 2%

Похожие посты: