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

Когда в 60—70-х гг. разрабатывались сетевые протоколы, в частности TCP/IP и основанные на нем telnet и rlogin, едва ли можно было предвидеть современные проблемы безопасности. Те, кто до сих пор пытаются получить доступ к удаленному компьютеру с помощью telnet, остаются с точки зрения безопасности на уровне 70-х гг.: имя пользователя и пароль передаются в виде открытого текста, а их перехват представляет собой детскую задачку для хакера, если ему удается получить доступ к одной из машин, через которые проходит трафик данных. Удобнее и даже немного защищеннее, чем telnet, «удаленный командный процессор» rsh в системах UNIX/Linux. Обычно, правда, там тоже требуется ввести имя пользователя и пароль, однако если каталог /home/goetz целевого компьютера содержит файл .rhosts, а он, в свою очередь, — строку вида

berlichingen goetz,

то пользователь goetz с компьютера berlichingen может входить в систему без пароля — т. е. пароль, по крайней мере, никто не в состоянии прочитать. Одновременно посредством rsh на целевом компьютере можно выполнять команды без ввода пароля.

Но тем не менее точек для атаки остается более чем достаточно. Так, ничего не стоит, к примеру, при помощи Knoppix CD подключить под именем berlichingen ноутбук, а, кроме того, все пакеты данных проходят по сети в виде открытого текста.

Современным уровнем считается Secure Shell SSH, предлагающий следующие функции:

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

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

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

ПРИМЕНЕНИЕ SSH

Использовать SSH с операционной системой Linux обычно достаточно просто: при помощи строки

ssh ll_mw

можно получить доступ к компьютеру ll_mw под текущим именем пользователя (или, соответственно, путем ввода строки ssh -l goetzvb ll_mw — под именем goetzvb). Как и при регистрации на консоли, демон SSH спрашивает пароль, после чего работу можно продолжить как обычно. Если нужны приложения Х, то доступ необходимо производить при помощи строки

ssh -Х ll_mw

(или внести запись ForwardX11 yes в $HOME/.ssh/config) — задавать переменные DISPLAY или команды xhost не потребуется. Этот метод можно порекомендовать как безопасный, поскольку без SSH хакеры могут вклиниться в поток (атака man-in-the-midlle) данных и отслеживать на локальном Х-сервере любые приложения. Немного сложнее подключить удаленную настольную систему. Под Suse Linux существует возможность графически войти в режиме «защиты от сбоев», получить доступ к удаленному компьютеру из xterm посредством SSH и запустить на нем команду kde&. Важным приложением SSH является копирование локальных файлов на другие компьютеры:

scp	my_file
remote_host:backup_
directory

Еще один пример приводится во врезке «Защищенное отображение через сеть»; там благодаря SSH команда выполняется удаленно. Наконец, строки

ssh -L
local _port:remote_host:remote_p
ort -N -f...

позволят создать зашифрованный туннель к удаленному компьютеру (а команда -R... возвращает к локальному компьютеру). Здесь SSH действует как VPN на фиксированный адрес порта (см. ssh(1)).

АУТЕНТИФИКАЦИЯ

Надежная аутентификация важна в той же мере, что и обеспечение конфиденциальности и целостности передаваемых данных. Стандартный метод связан с вводом пароля. Однако он утомляет своей длительностью и во многих случаях оказывается как непрактичным (к примеру, при автоматическом резервном копировании), так и рискованным. В качестве решения можно было бы привести так называемые методы идентификации на основании хоста, однако они недостаточно защищены от подделки IP-адреса. Поэтому наилучшим методом является применение цифровых подписей (аутентификация с открытым ключом). Необходимый для подписи личный ключ всегда остается на локальном компьютере и должен быть защищен трудно угадываемой фразой-паролем. Как это обычно происходит, описывается во врезке «Беспарольный вход с Open SSH для всех».

Сохраняющаяся необходимость ввода имени и пароля теоретически обусловлена содержанием конфигурационных файлов /etc/ssh/*config и $HOME/.ssh/config. Однако сам командный процессор ничего не сообщает о причинах, даже в режиме отладки (ssh -v -v -v) он остается верным правилу «каждая справка — подсказка хакеру». Возможные «подводные камни»:

  • обычно на сервере в /etc/ssh/sshd_config задано StrictModes yes, однако домашний и .ssh каталоги пользователя могут, например, описываться для своей группы;
  • стандартом является и CheckHostIP yes, однако клиент получает свой IP-адрес посредством DHCP;
  • вход на сервер с помощью коммерческой версии SSH не работает. Для этого формат открытого ключа должен быть сначала переведен в формат Ssh2 посредством ssh-keygen -e -t rsa.

В неясных случаях помогут только интерпретация конфигурационных файлов при помощи справочника Ssh и Sshd длиной примерно 2000 строк и утомительный поиск причины.

ПОВЫШЕНИЕ БЕЗОПАСНОСТИ

На практике слабым звеном являются секретные ключи. Из практических соображений их можно запретить защищать фразой-паролем, но тогда придется задуматься о переносе содержимого каталога $HOME/.ssh на дискету или флэш-память с интерфейсом USB и монтировании устройства на .ssh перед работой. Тем самым можно было бы получить ощутимую выгоду. Если указанные действия проделают все, администратор сможет на сервере в sshd_config установить PasswordAuthentication no и таким образом полностью запретить удаленный вход при помощи пароля. Ни один хакер не должен иметь возможности незаметно внести свой собственный открытый ключ в .ssh/authorized_keys. В этом случае Open SSH уже помочь не сможет. Рекомендация руководства — доступ только для владельца — должна по этой причине никогда не нарушаться.

Такие опции, как from=... в authorized_keys, определяют, с какого компьютера разрешен доступ. Имена машин можно подделать, однако взломщику необходимо об этом знать. Кроме того, и против мошенничества со стороны сервера можно кое-что предпринять. Каждый сервер при регистрации отправляет свой ключ хоста. Если он еще неизвестен, то после запроса добавляется к локальному файлу .ssh/known_hosts. Для проверки SSH показывает «слепок». Как правило, централизованный учет «слепков» (к примеру, при помощи ssh-keyscan или ssh-keygen -l) не представляет проблемы, но побуждает пользователя к критической проверке. В закрытых сетях может помочь центральный файл /etc/ssh/ssh_ known_hosts (вместе с опцией IgnoreUserKnownHosts yes в sshd_config).

Незаметная подмена SSH-демона Sshd, очевидно, наиболее привлекательна для хакеров. Такие инструменты, как Tripwire, позволят осуществить проверку и предотвратить опасность, однако гораздо проще регулярно выполнять в фоновом режиме небольшой сценарий для проверки целостности двоичных кодов и нескольких конфигурационных файлов при помощи md5sum.

ЗАКЛЮЧЕНИЕ

Компьютеры под управлением UNIX и Linux не должны разрешать доступ посредством таких ненадежных инструментов, как telnet или rlogin, когда имена и пароли передаются по сети в открытом виде. Если приложения предусматривают беспарольный вход в систему (или, соответственно, удаленное выполнение команд), то замена происходит практически незаметно для пользователя. В других случаях с незащищенными частными секретными ключами можно получить более высокую степень безопасности, которую при необходимости можно дополнительно повысить.

Рейнхард Вобст — независимый автор. С ним можно связаться по адресу: redaktion@lanline.awi.de

? AWi Verlag

Беспарольный вход с Open SSH для всех

Следующие действия могут быть осуществлены любым пользователем самостоятельно.

1. Создать при помощи команды ssh-keygen -t rsa пару ключей RSA. Эта команда автоматически создает каталог .ssh в домашнем каталоге с соответствующими правами доступа. В качестве фразы-пароля следует задать «нелогичное» предложение или, например, начальные и конечные буквы его слов (изменение при помощи ssh-keygen --p)

2. Созданный открытый ключ перенести на сервер(ы)

ssh my_server
Password: ...
mkdir .ssh
# начиная с этой строки удаленная работа
chmod 700 ssh
exit
cd .ssh
# начиная с этой строки снова локальная работа
scp id_rsa .pub my_server: .ssh/authorized_keys

При выполнении команды scp в последней строке также запрашивается ввод пароля. Во время следующей попытки доступа (ssh my_server) ssh уже запрашивает фразу-пароль для ключа RSA, если она не пуста.

Обычно фраза-пароль применяется для графического входа. Потом можно запустить агента SSH, который сохранит личный ключ в памяти. В Suse Linux проще всего это проделать следующим образом.

3. Локальное изменение строки usessh = no на usessh = yes в файле .xsession каталога Home (поиск ssh в тексте).

4. В файле .xinitrc после # Add your own lines here («введите собственные строки») вставьте ssh-add ~/.ssh/id_rsa. При следующем доступе перед запуском рабочего стола будет запрошен пароль RSA, после чего доступ будет проходить без ввода пароля. Подробности в ssh-agent(1).

«Подводный камень»: если доступ к компьютеру осуществляется с использованием протокола 1, необходимо дополнительно запустить ssh-keygen без аргументов, ввести такую же фразу-пароль, добавить на серверах протокола 1 сгенерированный ключ identity.pub в authorized_keys и записать в .xinitrc:

ssh-add ~/.ssh/id_rsa ~/.ssh/identity

Защищенное отображение через сеть

find src ( -name ?*.cc? -o -name ?*.h? )
 -print|cpio -oc|ssh
rechner2 cd $PWD ; cpio -idm

Эта команда переносит все исходные данные проекта С++ в аналогичный каталог на машине rechner2. Важно, что каждый файл не копируется в отдельности (что повлекло бы за собой очень большое количество служебных сигналов из-за аутентификации с открытым ключом), а все файлы упаковываются в архив и переносятся за одну операцию. $PWD в последней строке интерпретируется локальным командным процессором, последующая же точка с запятой игнорируется из-за предшествующих кавычек. Сценарий работает надежно лишь тогда, когда запускается не из корня (по причине вероятности некорректного задания владельцев). Кроме этого, необходимо написать cpio -o -H odc, если archiv_server совместим с SVR4 (а также cpio -idcm, если в качестве целевой системы используется HP-UX).

Как заставить применять Open SSH

Переход от telnet или, соответственно, rlogin/rsh (с паролем) к Open SSH происходит абсолютно прозрачно:

  • необходимо деактивировать службу telnet на сервере (in.telnetd, например, под Suse YaST при помощи редактора на уровне выполнения);
  • ввести на пользовательских компьютерах следующие команды: 
    cd usr/bin
mv telnet telnet.old
ln -s ssh telnet

С этого момента любой доступ по telnet будет происходить через SSH, возможно за исключением ввода имени пользователя. Аналогично следует поступить с rsh, rlogin и rcp. SSH-демон sshd входит в стандартный комплект всех распространенных дистрибутивов Linux.