Сетевая служба SSH в ОС Linux

Служба W:[SSH] предназначена для организации безопасного (secure) доступа к сеансу командного интерпретатора (shell) удаленных сетевых узлов. Изначально разрабатывалась как замена небезопасным R-утилитам W:[Rlogin], W:[Rsh] и протоколу сетевого алфавитно-цифрового терминала W: [telnet].

При сетевом взаимодействии в «открытой» публичной сети, такой как Интернет, «безопасность» обычно понимают как конфиденциальность (плюс целостность) передаваемых данных и аутентичность (подлинность) взаимодействующих сторон.

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

Сеансовый ключ устанавливается обеими взаимодействующими сторонами при помощи асимметричного алгоритма открытого согласования ключей (W:[протокол Диффи —Хеллмана]), использующего две пары дополнительных ключей. Обе стороны взаимодействия случайным образом выбирают закрытые ключи и на их основе вычисляют парные открытые ключи, которыми публично обмениваются. Общий (сеансовый) ключ вычисляется каждой стороной на основе своего закрытого ключа и чужого открытого ключа, что не может повторить третья сторона, т. к. может подслушать только передачу открытых ключей и не владеет закрытыми ключами участников взаимодействия. Обратная задача вычисления закрытых ключей на основе открытых ключей практически не решаема, на чем и основывается вся асимметричная криптография.

При активном вмешательстве третьей, стороны во взаимодействие путем перехвата и подмены сообщений согласования ключей, злоумышленник может выдавать себя за другую сторону каждому из участников взаимодействия, став посредником, см. W:[MITM] (man in the middle).

В этом случае взаимодействующие стороны согласуют свои сеансовые ключи со злоумышленником предполагая, что согласовали их с подлинным участником взаимодействия. Как следствие, все передаваемые данные «естественным» образом станут доступными злоумышленнику, причем наличие посредника никак не будет обнаружено.

Обеспечение подлинности (аутентичности) взаимодействующих сторон в протоколе SSH основывается на аутентификации сервера клиентом при помощи асимметричных алгоритмов цифровой подписи с использованием закрытого и открытого ключей сервера. Закрытый ключ используется для подписывания сообщений, а парный ему открытый ключ — для проверки подписи, корректность которой удостоверяет в том, что сообщение было сгенерировано подлинным владельцем закрытого ключа.

В сообщение протокола Диффи — Хеллмана сервер добавляет свой открытый ключ цифровой подписи (так называемый host key), а само сообщение подписывает закрытым ключом. Клиент извлекает этот открытый ключ Из сообщения и с помощью проверки корректности его цифровой подписи удостоверяется в  подлинности владельца вложенного ключа. Остается только убедиться, что владельцем вложенного ключа и является целевой сервер.

В примере из листинга ниже иллюстрируется первое присоединение к SSH-серверу grex.org (162.202.67.158), в результате чего был получен открытый ключ алгоритма W:[ECDSA], который, возможно, действительно принадлежит этому серверу, а не злоумышленнику посередине соединения.

Единственный способ это проверить — заранее знать действительный открытый ключ SSH-сервера grex.org и побитно сверить его с присланным ключом, что достаточно затруднительно сделать человеку. Поэтому на практике сверяют короткие хэш-суммы действительного и присланного ключей, называемые «отпечатками пальца» (fingerprint), совпадение которых гарантирует совпадение ключей. При этом подобрать другой ключ с такой же хэш-суммой практически невозможно.

Хэш-суммы открытых ключей SSH-серверов заранее известны и открыто публикуются, например для grex.org — на Web-странице http://grex.cyberspace.org/faq.xhtnl#sshfinger. После ручной сверки ключа О при первом подключении он сохраняется в файле ~/.ssh/known_hosts для автоматической сверки при последующих подключениях.

Первое присоединение к SSH-серверу

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

При этом на стороне сервера используется псевдотерминал  и эмулируется терминальный вход в систему, считающийся сетевым.

Выполнение отдельной команды

Кроме интерактивного сетевого входа, SSH позволяет удаленно выполнять отдельные команды, при этом псевдотерминал не используется, а терминальный вход не эмулируется. Вместо этого стандартные потоки ввода-вывода STDIN, STDOUT и STDERR выполняемой команды просто перенаправляются через сетевое соединение ssh-клиенту.

Это зачастую используется для удаленного копирования файлов. Например, в листинге ниже при помощи архиватора tar создается сжатый архив каталога /usr/src/sys на удаленном узле grex.org, а результат перенаправляется в локальный файл openbsd-kernel-source.tgz.

Копирование при помощи ssh

Аутентификация пользовательского сеанса по паролю имеет некоторое неудобство — необходимость вводить пароль заново при; каждом новом соединении SSH. Кроме того, пароль передается внутри соединения SSH, поэтому существует угроза подбора пароля злоумышленником.

Более прогрессивный способ аутентификации пользователя основан на использовании асимметричных алгоритмов цифровой подписи (аналогично аутентификации сервера в протоколе Дйффи — Хеллмана) и ключей пользователя.

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

В листинге ниже иллюстрируется процедура применения ключей аутентификации пользователя. Сначала при помощи команды ssh-keygen генерируется закрытый (private) W:[RSA]-icni04 в локальном файле ~/.ssh/td_rsa и парный ему открытый (public) ключ в локальном файле ~/.ssh/id_rsa.pub.

Закрытый ключ защищается (шифруется) от несанкционированного использования парольной фразой (passphrase), которая в отличие от пароля никогда по сети не передается, а лишь обеспечивает доступ к самому ключу. Нужно заметить, что использование пустой парольной фразы (как в примере) потенциально небезопасно, т. к. в случае кражи или разглашения ключей ими может воспользоваться любая третья сторона.

Затем при помощи команды ssh-copy-id открытый ключ регистрируется на удаленном сервере grex.org в файле ~/.ssh/authortzed_keys, что происходит с предъявлением пароля. Последующие SSH-соединения аутентифицируются парой ключей, в результате отпадает необходимость вводить пароль. Появляется необходимость вводить парольную фразу, но в примере она (непозволительно) пустая.

Доступ по ключу

Использовать зашифрованные парольными фразами ключи и одновременно не вводить парольную фразу при каждом подключении позволяет SSH-агент ssh—agent, который удерживает в оперативной памяти расшифрованные единожды закрытые ключи пользователя и генерирует с их помощью цифровые подписи по запросу.

Листинг ниже иллюстрирует аутентификацию пользователя по ключу, защищенному парольной фразой, а затем передачу этого расшифрованного ключа агенту при помощи команды ssh-add, что позволяет избавиться от необходимости ввода парольной фразы ключа все время, пока запущен процесс ssh-agent (обычно — до окончания сеанса).

Наличие SSH-агента, запущенного в сеансе пользователя, обнаруживают две переменные окружения — SSH_AGENT_PID и SSH_AUTH_SOCK, содержащие соответственно PID агента и имя локального сокета для связи с ним.

SSH-агент

Протокол SSH получил широкое распространение далеко за рамками своего изначального предназначения. Кроме непосредственного удаленного доступа, он используется другими командами для своих нужд. Например, команды scp и sftp используют ssh для безопасного сетевого копирования файлов, команда rsync — для сетевой синхронизации (копирование изменившихся) файлов.

Все эти (и другие, подобные им) команды используют ssh для запуска некоторой «серверной» программы на удаленном узле (в частности scp и rsync запускают сами себя, a sftp запускает sftp-server)л с которой и взаимодействуют через защищенное соединение.

Копирование файлов поверх SSH

Как оказывается на практике, использование «файловой» надстройки sftp-server для безопасного доступа к дереву каталогов удаленных узлов имеет достаточно широкое распространение. В частности, терминальный файловый менеджер mc, W:[MidnightCommander], тоже является SSH:sftp-клиентом.

Более того, при помощи FUSE-файловых систем sshfs или gvfs, файлы SSHisftp-cepвepoв могут быть смонтированы в дерево каталогов так, что вообще любые программы смогут ими воспользоваться.