previous up next index search
Previous: 6.5 Протокол SSL. Безопасный уровень соединителей    UP: 6 Сетевая безопасность
    Next: 6.7 Безопасность WEB-серверов

6.6 Безопасная оболочка (SSH)

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump или sniffer), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены “посторонние” машины. Для того чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа “безопасная оболочка” SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH использует для шифрования как открытый ключ, так и симметричные схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы как telnet, rlogin, rsh и rcp. Эта программа для ЭВМ, на которых установлена, шифрует также и сессии X Windows. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или HTTP. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты. Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата. В стандартный набор входит и программа безопасного удаленного копирования файлов SCP, заменяющая FTP. SSH по умолчанию использует порт 22.

Для формирования SSH-прокси на удаленном WEB-сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию –L:

SSH –L5678:www.pod.potol.com:80 www.pod.potol.com

Аргумент, следующий после флага опции -L имеет формат:

<локальный порт>:<удаленная ЭВМ>:<удаленный порт>.

Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду logout на удаленной ЭВМ. Общедоступную версию SSH можно найти по адресу: www.cs.hut.fi/ssh. Информацию о коммерческих версиях для Windows и Macintosh можно найти на сервере: www.datafellows.com/f-secure.

В версии OpenSSH была обнаружена уязвимость, которая позволяет повторять попытки подбора пароля практически неограниченное число раз, что сильно понижает надежность системы. Такая уязвимость присуща не всем версиям Linux, но расслабляться не следует. Лишний раз можно напомнить о необходимости использования надежных паролей (см. "How can enterprises stop the OpenSSH vulnerability?", Michael Cobb).


В последнее время остро встала проблема надежной аутентификации пользователей в сети. Здесь приходится найти компромисс между однозначным распознаванием пользователя и требованиями конфиденциальности.

Время от времени возникает проблема пересылки файла из одной машины в другую под управлением третьего компьютера (см. "How to copy a file from one server to another from a third with SSH", Jack Wallen, November 1, 2019). При решении данной задачи предполагается, что все компьютеры работают с ОС Linux и могут реализовать SSH-соединения. Предполагается также, что они могут идентифицировать друг друга посредством SSH-криптоключей.

Пусть Server A - 192.168.1.15; Server B - 192.168.1.160; Client C - 192.168.1.7

Процедура начинается с копирования ключей на сервер, что реализуется с помощью команды ssh-copy-id USER@IP. Операция выполняется из A в B, из A в C, из B в A, из B в C, из C в A и из C в B. Компьютеры А и B являются серверами, а С- клиентом. Далее выполняется команда:

scp USER@192.168.1.15:/home/USER/test.txt USER@192.168.1.160:/home/USER/test.txt

Далее вам будет нужен конфигурационный файл ~/.ssh/config

Открываем его посредством команды: nano ~/.ssh/config. Теперь нужно сконфигурировать SERVERA и SERVERB. Это можно сделать, например, следующим образом:

Host SERVERA
    HostName 192.168.1.16
    ControlMaster auto
    ControlPath ~/.ssh/ssh-%r@%h:%p
    ControlPersist 30m

Host SERVERB
    HostName 192.168.1.22
    ControlMaster auto
    ControlPath ~/.ssh/ssh-%r@%h:%p
    ControlPersist 30m

Закрываем и сохраняем файлы. Далее копируем тестовый файл с клиента C на сервер А с помощью команды:

scp test.txt USER@192.168.1.15:/home/USER/test.txt, где USER имя удаленного субъекта.

Наш файл test.txt теперь находится на Server A. Теперь копируем его с Server A на Server B посредством Client C. Для этого выполняем команду:

scp -3 USER@SERVERA:/home/USER/test.txt USER@SERVERB:/home/USER/test.txt, где USER - имя удаленного пользователя. Опция -3 указывает SCP направлять трафик через машину-инициатор (в данном случае Client C). Авторизация при этом производится в Client C.

Но можно было войти с клиента С в один из серверов (имея его пароль) и оттуда зупустить обмен SCP, при этом нужно знать пароль для сервера-адресата. Таким образом можно одной командой скопировать несколько файлов или даже содержимое всего каталога.

Previous: 6.5 Протокол SSL. Безопасный уровень соединителей    UP: 6 Сетевая безопасность
    Next: 6.7 Безопасность WEB-серверов