 | Безопасная оболочка (SSH)
Клиент и сервер
Почти каждая Linux-машина (да и большинство других опреационных систем) должны иметь клиента безопасной оболочки (SSH). Часто используется версия OpenSSH, но также иногда применяют и других совместимых SSH клиентов. SSH клиент является необходимым для соединения, большие проблемы с безопасностью возникают при неправильной настройке SSH-сервера.
Поскольку клиент запускает соединение с сервером, ему часто приходится доверять серверу. Просто наличие SSH-клиента не дает никакого доступа внутрь машины; следовательно, это не может представлять опасности.
Настройка сервера тоже не особенно сложная; демон сервера был разработан содержащим и реализующим хорошую схему безопасности. Но, очевидно, именно сервер разделяет ресурсы с клиентами, основываясь на запросах от клиентов, которым сервер решает доверять.
Протокол SSH имеет две версии, версию 1 и версию 2. В современных системах всегда предпочтительным является использования протокола версии 2, но, вообще говоря, как клиент, так и сервер поддерживают обратную совместимость с версией 1 (если только если это не отключено конфигурационными опциями). Это позволяет соединяться с все реже и реже встречающимся системами версии 1.
Протоколам версий 1 и 2 соответствуют несколько различные конфигурационные файлы. В протоколе версии 1 клиент сначала создает с помощью ssh-keygen пару ключей RSA, и хранит закрытый ключ в $HOME/.ssh/identity, а открытый ключ -- в $HOME/.ssh/identity.pub. Точно такой же identity.pub должен быть добавлен к удаленным файлам $HOME/.ssh/authorized_keys.
Очевидно, здесь присутствует проблема яйца и курицы: как можно скопировать файл на удаленную систему, до получения доступа к ней? К счастью, SSH также поддерживает метод аварийной идентификации, состоящий в отправке зашифрованных на лету паролей, которые вычисляются посредством обычного контроля входа на удаленную систему (таких как существует ли учетная запись пользователя, и введен ли правильный пароль).
Протокол 2 поддерживает как ключи RSA, так и DSA, но RSA-идентификация немного улучшена по сравнению с протоколом 1. В протолоке 2, закрытые ключи хранятся в $HOME/.ssh/id_rsa и $HOME/.ssh/id_dsa. Протокол 2 также поддерживает некоторое количество алгоритмов экстра конфиденциальности и целостности: AES, 3DES, Blowfish, CAST128, HMAC-MD5, HMAC-SHA1, и так далее. Сервер можно настроить как на предпочтительные алгоритмы, так и задать проядок использования аварийных режимов.
Общие конфигурационные опции, в отличие от ключа, содержатся у клиента в /etc/ssh/ssh_config (или, если это доступно, в /$HOME/.ssh/config). Параметры клиента можно также настроить с помощью опции
-o; часто используемой опцией является -X или -x, для включения или выключения переадресации X11. Если она активирована, порт X11 тунеллируется через SSH, чтобы осуществлять шифрованные X11 соединения.
Утилиты, подобные scp также используют похожий порт для переадреации через по SSH. Пусть, например, я работаю за локальной машиной, и я могу запустить увидеть на дисплее X11 приложение, которое работает только удаленно (в этом случае -- на сервере в локальной подсети):
Listing 11. запуск удаленного приложения X11
$ which gedit # на локальной системе отсутствует
$ ssh -X dqm@192.168.2.2
Password:
Linux averatec 2.6.10-5-386 #1 Mon Oct 10 11:15:41 UTC 2005 i686 GNU/Linux
No mail.
Last login: Thu Feb 23 03:51:15 2006 from 192.168.2.101
dqm@averatec:~$ gedit &
|
Настройка сервера
Демон sshd, что особенно характерно для версии OpenSSH, включает безопасные шифрованные соединения между двумя ненадежными хостами по небезопасной сети. Основной sshd сервер обычно запускается во время инициализации системы и ждет сигнала от подключений пользователей, запуская новый экземпляр демона для каждого пользовательского соединения. Отделенные демоны осуществляют обмен ключами, шифрование, идентификацию, выполнение команд и обмен данными.
Сервер sshd поддерживает большое разнообразие опций командной строки, но обычно настраивается файлом /etc/ssh/sshd_config. Также используется некоторое число других конфигурационных файлов. Например, файлы контроля доступом /etc/hosts.allow и /etc/hosts.deny являются предпочтительными. Ключи хранятся похожим образом на стороне клиента, в /etc/ssh/ssh_host_key (протокол 1), /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key, а открытые ключи -- в /etc/ssh/ssh_host_dsa_key.pub и подобных. Также, на клиенте, для генерации ключей используется ssh-keygen. Обратитесь к man-страницам для sshd и ssh-keygen за деталями конфигурационных файлов и копирования сгенерированных ключей в соответствующие файлы.
Множество конфигурационных опций имеется в /etc/ssh/sshd_config, а значения по умолчанию, вообще говоря, чувствительны (и ощутимо безопаснее). Стоит упомянуть несколько опций:
-
AllowTcpForwarding включает или выключает переадресацию портов, и по умолчанию выставлено "YES".
-
Ciphers управляет списком и порядком шифровательных алгоритмов, которые будут использовться.
-
AllowUsers и AllowGroups принимают шаблоны ввода и позволяет контролировать, какие пользователи могут сделать попытку в дальнейшей идентификации.
-
DenyGroups и DenyUsers действуют. как и следовало ожидать, симметрично.
-
PermitRootLogin позволяет пользователю root подключаться через SSH.
-
Protocol позволяет указать, принимаются ли оба типа протоколов (и, если нет, (какой из них).
-
TCPKeepAlive хороша, если у вас иногда обрываются SSH-соединения. Сообщение "keepalive" рассылается, чтобы проверить соединения, если опция включена. Но это может вызвать рассоединение, если при маршрутизации происходят редкие ошибки.
SSH тунеллирование
OpenSSH позволяет создать туннель для инкапсулирования других протоколов в шифрованном SSH-канале. Эта возможность включается на сервере sshd по умолчанию, но может быть отключена опциями командной строки или конфигурационными файлами. Полагая, что эта возможность включена, клиенты могут легко эмулировать любой порт/протокол, который пожелают, и использовать его для соединения. Например, для создания туннеля для telnet:
Listing 12. Прокладка туннеля для telnet
% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
% telnet localhost 5023
|
Конечно же, этот пример бессмысленный, поскольку командная оболочка SSH делает то же в качестве оболочки shell. Однако можно создавать соединения POP3, HTTP, SMTP, FTP, X11, и по любому другому протоколу аналогичным образом. Основная идея состоит в том, что определенные порты локального хоста ведут себя так будто это есть удаленная служба с реальными коммуникационными пакетами, гуляющими в SSH соединении в зашифрованном виде.
Опции, которые мы использовали в примере, таковы:
-
-2 (использовать протокол 2),
-
-N (нет команды/только туннель),
-
-f (SSH фоновым), и
-
-L, (описать туннель как "localport:remotehost:remoteport").
Также указывается сервер и имя пользователя.
| |
