Защищенная оболочка SSH(Часть 1)Большинству нравится удобство работы с Berkeley r-командами (rsh, rcp, rlogin), обеспечивающими быстрый доступ между разными компьютерами. К сожалению, здесь есть проблемы безопасности, поскольку используются host names и IP-адреса secure. Проникновение в клиент позволяет взломать сервер, а то и не один. Если сконфигурировать свой портативный компьютер с IP-адресом "заслуживаюшей доверия" машины, то есть шансы представить его в качестве истинной системы. Для использования r-команд в безопасной манере, нужно усилить аутентификацию. Используя шифрование информационных каналов, пользователи сохраняют конфиденциальность, пароли скрываются от sniffers, и даже такие возвращаемые данные, как X соединения могут быть защищены. Вот для чего нужен Secure Shell (ssh). ssh был создан в качестве замены для r-команд (в форме ssh, scp и slogin), но с дополнительными возможносями сквозного шифрования, улучшенной аутентификации пользователей и хостов. ssh использует технологию RSA для пар открытых/астных ключей при аутентификации хостов. Для аутентификации пользователей есть ряд возможностей, включая Kerberos, SecureID и RSA. ssh поддерживает даже аутентификацию пользователей с помощью .rhosts если аутентификация хоста с помощью RSA проходит успешно. Обычно для установления доверительных отношений Unix требует, чтобы /etc/hosts.equiv и $HOME/.rhosts содержали имена или IP адреса удаленных хостов, которым доверяют локальные хосты. Далее r-команды расчитывают, что IP-адреса или трансляция имен в IP-адреса являются надежными. К сожалению защита, основанная на IP-адресах, является недостаточной, поэтому ssh использует RSA для аутентификации хостов. При установке ssh на хосте, генерируется пара ключей и записывается на хранение в каталоге /etc. К частному ключу имеет доступ только root, в то время как открытый ключ доступен всем. Эти ключи используются для аутентификации хостов друг другу при соединении. Открытый ключ локального хоста должен быть добавлен к файлу /etc/ssh_known_hosts на всех удаленных системах, к которым хочет обращаться данный хост c использованием .rhosts или hosts.equiv. Либо пользователь должен добавить открытый ключ удаленного хоста к своему файлу $HOME/.ssh/known_hosts на том удаленном хосте, к которому он хочет обращаться. Хост генерирует случайную строку и шифрует ее с помощью открытого ключа удаленного хоста. Если удаленный хост правильно расшифрует строку и вернет ее, то он считается аутентифицированным. Заставляя оба конца соединения проверять друг друга, ssh обеспечивает защиту от DNS, IP и routing spoofing. После аутентификации хостов можно аутентифицировать пользователей. Кроме аутентификации, ssh предоставляет несколько возможностей для шифрования. По умолчанию используется IDEA, но доступны и DES, 3DES, и blowfish. Клиент генерирует случайную строку для использования в качестве симметричного ключа и посылает на сервер, зашифровав с помощью открытого ключа сервера, так что подслушивающие не смогут получить ключ. Шифрование является автоматическим и сквозным, и оно происходит сразу после аутентификации хоста, но до пользовательской аутентификации. В результате, даже если пользователь должен должен вводить пароль, то он посылается по защищеному каналу. Для задействования шифрования не требуется какого-либо конфигурирования. Наоборот, для ее отмены необходима перекомпиляция. После установки сеанса связи ssh проверяет уствновку переменной среды DISPLAY и при ее наличии автоматически устанавливает X11 forwarding. Это делается путем создания псевдо сервера на удаленном хосте и указания его имени в удаленной переменной DISPLAY. В результате использование ssh в сочетании с X11 становится весьма удобным. Другим удобным свойством ssh является возможность соединять произвольные порты TCP по защищенным каналам. ssh поддерживает переадресацию локальных клиентских портов на вторую удаленную систему через защищенный канал на удаленный сервер,а также переадресацию портов с удаленного сервера на вторую локальную систему. Это проще объяснить на примере: Расмотрим три хоста X, Y и Z. Хост X является клиентом и устанавливает сеанс связи с сервером Y через ssh. Пусть порт 1999 на X установлен с переадресовкой на другой порт на удаленном сервере Z, скажем 23. Порт переадресуется по шифрованному каналу на Y, который затем посылает данные без шифрования на порт 23 хоста Z. Тем самым команда telnet localhost 1999 приведет к telnet-соединению с хостом Z, с пересылкой по шифрованному туннелю на Y. ssh -L 1999:Z:23 Y sleep 100 Команда sleep необходима, чтобы занять чем-то ssh на удаленной системе в ожидании Вашего соединения. После "пробуждения" ssh будет ожидать закрытия переадресованного порта, прежде чем завершиться самому. Пересылка портов с удаленного сервера приведет к тому, что порт на сервере Y, скажем 1080, будет переадресовываться на порт 80 хоста Z по шифрованному туннелю от хоста X. ssh -R 1080:Z:80 Y sleep 100 Это может рассматриваться как псевдо-посредние (pseudo proxy), или туннельный IP, и в то же время потенциальная "дыра" в брандмауэрах, пропускающих ssh. Хотя администратор брандмауэра может считать, что разрешены только соединения ssh, но потенциально, возможны любые соединения между локальной и удаленной системами. Для повышения безопасности ssh обеспечивает поддержку пакету Wietse Venema под названием tcp wrapper. Для управления соединениями как клиентские, так и серверные программы используют файлы /etc/hosts.allow и /etc/hosts.deny. Сервер использует wrappers для контроля за всеми входящими соединениями и портами, переадресуемыми через сервер. Клиеты ssh и slogin могут использовать wrappers для управления переадресацией портов с удаленного сервера. Это отсобенно важно, когда ssh пропускается через брандмауэр в ту или иную сторону. Записи sshdfwd-port# или sshdfwd-servicename в файле /etc/hosts.allow используются для управления переадресацией портов. Как ни кажeтся полезным использование ssh, не забывайте, что он не в состоянии решить все проблемы безопасности. Например, стандартный NFS остается столь же незащищенным, что и всегда, и может подвергаться подслушиванию (sniffing) и попыткам фальсификации IP-адресов хостов (spoofing). В то же время для обеспечения безопасных и удобных хост-регистраций ssh является весьма эффективным. Возможно, со временем, SKIP (Simple Key management for Internet Protocols) и сопутствующие протоколы займут место ssh, поскольку они являются более универсальными. Но пока ssh удерживает свои позиции.
Доступность sshssh свободно доступен для некоммерческого использования по адресу ftp://ftp.cs.hut.fi/pub/ssh.Если Вам нужна информация по коммерческим или не-Unix клиентам, посетите Datafellows по адресу http://www.Datafellows.com. Версии коммерческих клиентов для Windows 95/NT не обладают возможностью пересылки файлов и используют внутренний эмулятор терминала. Коммерческая Unix-версия не поддерживает шифр IDEA из-за патентных ограничений. Возможна загрузка пробных версий. Существует несколько бесплатных версий для Windows 95 и NT, но они не вполне стабильны или завершенны. Смотри http://guardian.htu.tuwien.ac.at/therapy/ssh и http://public.srce.hr/~cigaly/ssh. Есть версия для OS/2 для некоммерческого использования по адресу ftp://ftp.cs.hut.fi/pub/ssh/os2. Независимо разработанная версия для PalmPilot доступна по адресу http://www.isaac.cs.berkeley.edu/pilot.
ssh версии
ssh документация
Лучшая конференция новостей для ssh - это comp.security.ssh Чтобы подписаться, пошлите subscribe ssh в теле сообщения по адресу majordomo@clinet.fi Новости в области компьютерной безопасности
Об авторахПитер Гелвин (Peter Galvin) - главный технолог компании Corporate Technologies Inc., Стив Ачесон (Steve Acheson) - Ведущий Аналитик по Компьютерной Безопасности в фирме Cisco Systems |