Слабая защищенность r-команд представляет угрозу безопасности системы. Этими командами нельзя пользоваться для обеспечения защищенного удаленного доступа, даже учитывая все аспекты, описанные в предшествующем разделе.
В лучшем случае доступ посредством r-команд можно предоставлять только доверенным системам защищенной локальной сети. Причина кроется в том, что доверие r-команд основывается на убежденности в четком соответствии IP-адреса совершенно определенному компьютеру. Обычно так и есть. Однако злоумышленник способен исказить данные DNS и подменить адрес IP либо данные маршрутизации с целью доставки информации в другую сеть, таким образом обойдя механизмы проверки подлинности, используемые в r-командах.
Альтернативой такому удаленному доступу является защищенный интерпретатор команд. Защищенный интерпретатор заменяет стандартные r-команды более защищенными вариантами, задействующими шифрование и более совершенный механизм проверки подлинности. Последний позволяет гарантировать, что доверенный узел действительно является таковым. Методы шифрования на основе открытых ключей реализуют проверку подлинности пакетов сетевого потока. Защищенный интерпретатор команд не только безопасен, но и легок в применении.
В настоящее время широкое распространение получили два варианта защищенного интерпретатора команд: коммерческий продукт SSH Secure Shell и продукт с открытым исходным кодом - OpenSSH. OpenSSH входит в состав различных вариантов Unix и Linux, а оба продукта - как коммерческий, так и бесплатный - доступны для загрузки из сети Интернет на случай, бели » вашей системе нет никакого. Примеры этого раздела созданы с применени ем OpenSSH, но базовые функции обоих вариантов интерпретатора по существу одинаковы.
Основные компоненты защищенного интерпретатора команд:
sshd - Демон защищенного интерпретатора команд обрабатывает входящие SSH-соединения. sshd следует запускать в процессе загрузки системы - ю загрузочного сценария, но не при помощи inetd.conf. При каждом запуске sshd генерирует ключ шифрования, поэтому его запуск может быть слишком долгим для inetd.conf. На системе, принимающей SSH-соединения, должен работать демон sshd.
ssh - Пользовательская команда для защищенного интерпретатора команд. Ко манда ssh заменяет rsh и rlogin. Она позволяет передать команду удален ной системе либо провести сеанс работы с удаленной системой безопас ным способом. Команда создает исходящие соединения, обращенные к удаленному демону защищенного интерпретатора команд. Система-клиент для работы с SSH-соединением должна иметь доступ к команде ssh.
scp - Команда scp (secure сору) является заменой команды rep.
ssh-keygen - Генерирует открытый и закрытый ключи шифрования, используемые для защищенной передачи данных.
sftp - Вариант клиента FTP, работающий через защищенное соединение. Когда ssh-клиент обращается к серверу sshd, они обмениваются открытыми ключами. Системы сравнивают полученные ключи с ключами, хранимыми в файлах /etc/ssh_known_hosts и .ssh/known_hosts (в исходном каталоге пользователя). Если ключ не найден или изменился, пользователю предлагается подтвердить прием ключа:
> ssh horseshoe Host key not found from the lis t of known hosts. Are you sure you want to continue connecting (yes/по)? yes Host 'horseshoe' added to the lis t of known hosts. craig's password: Watts.Watt. Last login: Thu Sep 25 15:01:32 1997 from rodent Linux 2.0.0. /usr/X11/bin/xauth: creating new authority file /home/craig/.Xauthority
Если ключ обнаружен в одном из файлов либо принят пользователем, клиент использует его для шифрования случайным образом сгенерированного ключа сеанса. Ключ сеанса передается серверу, и обе системы используют итот ключ для шифрования данных до конца текущего сеанса SSH.
Клиент проходит проверку подлинности, если он упомянут в файле hosts.equiv, shost.equiv, пользовательском файле .rhosts либо файле .shosts. Такой механизм проверки подлинности схож с тем, что используется r-командами, а формат файлов shost.equiv и .shosts совпадает с форматом их r-эквивалентов. Обратите внимание, что в приведенном выше примере пользователю было предложено набрать пароль. Если клиент не упомянут в одном из файлов, включается механизм парольной аутентификации. Как можно видеть, пароль отображается открытым текстом. Однако не стоит беспокоиться о краже пароля, поскольку SSH шифрует его, прежде чем передать второй стороне.
В целях аутентификации пользователь может задействовать протокол двустороннего обмена открытыми ключами. Прежде всего, необходимо сгенерировать открытый и закрытый ключи шифрования:
> ssh-keygen Initializing random number generator... Generating p: ++ (distance 616) Generating q: ++ (distance 244) Computing the keys... Testing the keys.. . Key generation complete. Enter fil e in which to save the key (/home/craig/.ssh/identity): Enter passphrase: Pdky&tiaj. Enter the same passphrase again: Pdky&tiaj. Your identification has been saved in /home/craig/.ssh/identity. Your public key is: 1024 35 158564823484025855320901702005057103023948197170850159592181522 craig@horseshoe Your public key has been saved in /home/craig/.ssh/identity.pub
Команда ssh-keygen создает ключи. Наберите пароль (или «ключевую фразу») не менее 10 символов длиной. При выборе легко запоминаемого пароля воспользуйтесь приведенными ранее правилами. Если вы забудете ключевую фразу, никто не сможет ее восстановить.
Создав ключи на клиентской системе, скопируйте открытый ключ на сервер. В исходном каталоге клиента ключ хранится в файле .ssh/identity.pub.
Скопируйте его в подкаталог .ssh/authorized_keys своего исходного каталога на сервере. Теперь при обращении к системе посредством ssh пользователю предлагается набрать ключевую фразу:
> ssh horseshoe Enter passphrase for RS A key 'craig@horseshoe': Pdky&tiaj. Last login: Thu Sep 25 17:11:51 2001
