Security


Общие принципы

Unix и вирусы

Когда заходит речь о компьютерной безопасности, то первым делом вспоминаются вирусы. И здесь у Unix есть огромное преимущество перед Dos/Windows: в Unix вирусов не существует.

Основная причина этого заключается в ограничении прав доступа: в Unix у программ просто нет возможности писать что угодно, куда угодно и когда угодно, что является необходимым условием для существования и распространения вирусов. Даже если какой-нибудь пользователь случайно и подхватит некую "зловредную" программу, то обычно максимум, что она сможет сделать -- это испортить файлы самого пользователя, на операционную систему же это никак не повлияет.

Кроме того, хотя во многих Unix и существуют некоторые "дыры" в защите, разнообразие систем делает создание программ, использующих эти дыры, крайне трудоемкой задачей. Даже разные версии/дистрибутивы Linux на одной и той же платформе Intel x86 могут отличаться столь сильно, что "нехорошая" программа попросту зайдет в тупик и не сможет ничего сделать.

В принципе, в Unix могут существовать "черви" -- программы, самостоятельно распространяющиеся по сети и заражающие компьютеры. Однако их разработка является не менее трудоемкой задачей, и количество известных червей крайне мало.

Даже знаменитый "Червь Морриса", который в ноябре 1988 года поразил большое количество систем в США, заражал лишь компьютеры двух типов. В настоящее же время многообразие систем несравненно выше, а таких огромных дыр в защите, какие существовали в конце 80-х, практически не осталось. (Подробно почитать про Червь Морриса можно по адресу http://www.msnbc.com/news/209745.asp.)

Таким образом, большинство атак на Unix-системы производится не автоматическими средствами, а требует участия человека.

Безопасность в Unix

Технические аспекты


С точки зрения пользователя, нарушение безопасности может принимать одну из трех форм:

  • Чтение приватных данных.
  • Изменение и фальсификация приватных данных.
  • Помехи в работе.

Под "приватными данными" понимаются как файлы в компьютерах, так и электронная корреспонденция.

Нарушение безопасности всегда происходит по одной из двух причин. Первая -- несовершенство программных средств. Вторая -- ошибки человека.

С технической точки зрения, нарушение безопасности может включать:

  • "Подглядывание" информации, передаваемой по сети (sniffing).
  • "Подделка" информации, передаваемой по сети (spoofing).
  • Помехи в работе различных подсистем ОС (т.н. "DOS-атаки" -- сокращение от "Denial Of Service", дословно "отказ в обслуживании").
  • Приведение ОС в неработоспособное состояние -- завешивание или перезагрузка.
  • Взлом пользователького эккаунта.
  • Получение прав одного из специальных псевдопользователей ("bin", "daemon", "mail" и т.д.). Например, права "mail" дают возможность читать почту любого пользователя.
  • Получение прав пользователя "root".

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

Атаки могут проводиться одним из трех основных способов:

  • По сети (как из локальной сети организации, так и через Internet).
  • При помощи т.н. "троянских коней" -- программ, в которые кроме (а то и вместо) нужной функциональности заложен код, выполняющий несанкционированные действия.
  • Пользователями, зарегистрированными на компьютере -- при этом возможностей намного выше, чем при атаке через сеть.

При взломе в подавляющем числе случаев используется один и тот же прием -- программе, исполняющейся с высокими привилегиями, "скармливаются" такие данные, на которые она не рассчитана, и она или просто "падает" (получается DOS-атака), или исполняет код, "подсунутый" взломщиком.

Причем в качестве такой уязвимой программы может выступать и ядро. Например, в конце 1997-го/начале 1998-го года весьма популярны были атаки, основанные на посылке машине-жертве "неправильного" IP-пакета, так что система просто "падала замертво" (именно на этом принципе была основана программа WinNuke).

Хорошую возможность взлома дает физический доступ к компьютеру. Например, достаточно загрузить свой экземпляр системы с дискеты и с правами пользователя "root" делать все, что заблагорассудится. Хотя большинство современных BIOS дают возможность отключить загрузку с дискеты (а изменение настроек самого BIOS закрыть паролем), остается еще возможность переставить жесткий диск в другой компьютер. Впрочем, защититься от "отверточного" взлома очень трудно, и это совсем отдельная тема.

После успешного взлома злоумышленник обычно модифицирует системные файлы (например, подменяет некоторые программы своими). Обнаружить такую замену зачастую можно, регулярно выполняя команду "rpm -ya" и анализируя ее результаты.

Меры предосторожности


Основные меры предосторожности, которые следует соблюдать, достаточно просты и диктуются здравым смыслом (вести себя аккуратно, не вступать в беспорядочные связи):

  • Выбирать пароли, которые нельзя угадать или подобрать. Лучше всего пароли, состоящие из 8 символов, среди которых встречаются и маленькие и заглавные буквы, и иные символы (цифры и знаки препинания). Не следует в качестве пароля использовать русское слово, набранное на латинском регистре (например, "остолоп!" -> "jcnjkjg!").
  • Никогда не записывать пароли (на бумаге или в файле) и не передавать их по сети в открытом виде (в частности, не пользоваться telnet и неанонимным ftp).
  • Никогда не работать как пользователь "root". При необходимости выполнить некую работу, требующую привилегий супервизора (добавление/удаление ПО и пользователей, просмотр закрытых log-файлов и т.д.) следует временно получить их при помощи команды "su", а по завершении этой работы немедленно выйти "из под" супервизора. При необходимости наличия прав супервизора в течение продолжительного времени лучше всего открыть отдельное окно, в котором выполнить "su", а не переключаться все время между обычным пользователем и "root".
  • Постараться никогда не "превращаться" в супервизора при входе на компьютер по сети, а делать это только с локального терминала. Еще лучше -- не пользоваться "su" из-под X-Window, а только с консоли.
  • Никогда не устанавливать ПО, полученное из непроверенных источников. В частности, следует с большим подозрением относиться к программам, поставляемым без исходных текстов.
  • При установке ПО, требующего для работы прав "root", следует проверить, реально ли требуются такие права, и если да, то лучше воздержаться от использования этого ПО. Сюда относится как необходимость запуска из-под пользователя "root", так и наличие у исполняемых файлов флажка смены идентификатора пользователя (setuid) или группы (setgid).
  • Никогда не устанавливать ПО "просто так", "на всякий случай". Ведь чем больше установлено программ, тем выше вероятность, что в какой-нибудь из них найдется "дыра". В основном это относится к сетевому ПО.
  • Следить за появлением обновленных и исправленных версий ПО, в особенности -- ядра. В последнее время одна из основных причин появления новых версий -- исправление ошибок в security. В RedHat Linux обновленные версии доступны по адресу ftp://updates.redhat.com/, на зеркалах дистрибутива они располагаются в поддиректории updates/ (например, для RedHat 5.2 в ИЯФ это будет директория ftp://rdist.inp.nsk.su/pub/Linux/redhat-5.2/updates/). В этой директории всегда есть файл 00README.errata, содержащий комментарии к обновлениям. Html-версии файлов errata доступны по адресу http://www.redhat.com/support/docs/rhl/.
  • По возможности ограничить доступ к компьютеру по сети. В частности, ограничить набор компьютеров, с которых разрешен доступ, и уменьшить до минимума количество сетевых сервисов. Так, вместо ftp, telnet и rlogin/rsh/rcp следует пользоваться пакетом ssh.

При обнаружении случаев взлома надо не пытаться разобраться самостоятельно, а немедленно связаться с компетентным персоналом. В частности, в ИЯФ следует обращаться в ОВС.

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

Где можно брать дополнительную информацию

Хорошим стартовым пособием является глава 23 книги "UNIX: руководство системного администратора".

Кроме того, многое можно почерпнуть из Internet -- см. к примеру, раздел Computers & Internet -> Security and Encryption -> Unix в Web-директории Yahoo!.


Локальная безопасность

Что такое "локальный взлом"

Под локальным взломом понимается несанкционированные действия (получение прав "root", нарушение работы системы и т.д.), проведенные "из под" обычного непривилегированного пользователя.

При этом не следует считать всех зарегистрированных в системе пользователей потенциальными злоумышленниками -- зачастую взлом "снаружи" проводится в два этапа: сначала получаются права обычного пользователя (к примеру, путем похищения пароля), а затем уже эксплуатируется какая-нибудь локальная "дырка".

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

SUID-ные программы: что это такое и как их искать

Что это такое


Обычно вместо громоздкого термина "программа с флагом смены идентификатора пользователя" используется "сетъюидная программа" или "сюидная программа" (калька с английского "suid program") -- этот термин мы и будем употреблять далее.

Сюидная программа -- это программа, которая исполняется с правами (uid) не запустившего ее пользователя, а того, кому принадлежит файл программы. Реже используется смена идентификатора группы ("эсгидная программа" -- "sgid program").

Внешне сюидная программа отличается тем, что в правах доступа, показываемых командой "ls -l", вместо символа "x" в правах владельца стоит "s":

bobby:~% ls -l /usr/X11R6/bin/nxterm
-rws--x--x   1 root     root       127668 Aug  4  1998 /usr/X11R6/bin/nxterm
bobby:~% _

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

Примерами сюидных программ являются rlogin (права нужны для создания сокета с номером порта < 1024), passwd (для записи в файл /etc/passwd или для чтения/записи /etc/shadow), xterm/nxterm (для получения устройства виртуального терминала), x11amp (для получения realtime-приоритета).

Вообще говоря, в настоящее время сюидность считается одной из самых неудачных (или, по крайней мере, самых неудачно реализованных) концепций в Unix. Программ, которым реально требуется сюидность, не так уж много -- в типичной установке из дистрибутива RedHat 5.2 их около полусотни.

Замечание
Возникает вопрос: если сюидность -- неудачная концепция, то как же надо было делать? Ответ -- т.н. "capabilities", или отдельные права на выполнение отдельных операций (вместо "всемогущего" root). Концепция "capabilities" введена стандартом POSIX.1e и поддерживается в ядрах Linux начиная с 2.2. Документация на эту тему есть по адресу

http://www.kernel.org/pub/linux/libs/security/linux-privs/
зеркало в России --

http://www.ru.kernel.org/pub/linux/libs/security/linux-privs/

Одно из применений сюидности при взломе -- непосредственно после взлома создать root-сюидную программу, позволяющую интерактивно вводить команды (на эту роль хорошо подходит любой shell), или же запускающую shell с правами "root".

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

Как установить и удалить атрибут setuid


Поскольку атрибут setuid входит в права доступа файла, то для манипуляций с ним используется команда chmod. Для установки этого атрибута служит команда

chmod u+s файл
(избегайте этого!), а для удаления --

chmod u-s файл

Атрибут setgid отличается тем, что символ "s" отображается вместо "x" в правах доступа группы, а не владельца:

bobby:~% ls -l /usr/bin/man
-rwxr-sr-x   1 root     man         31756 Sep  5  1998 /usr/bin/man
bobby:~% _

Для его установки/удаления команде chmod указывается "g+s" и "g-s" соответственно.

Замечание
Семантика атрибута "s" при неустановленном атрибуте "x", а также атрибута "s" на директории существенно отличается, и эти случаи мы рассматривать не будем.

Поиск сюидных программ


Для поиска имеющихся на диске сюидных программ используется команда find.

Команда

find / -type f -perm -u+s
найдет все файлы с установленным флагом setuid. Чтобы включить в список также файлы с атрибутом setgid, следует воспользоваться командой

find / -type f '(' -perm -u+s -o -perm -g+s ')'

Чтобы сразу выдать листинг найденных файлов, подойдет команда

find / -type f '(' -perm -u+s -o -perm -g+s ')' -exec ls -ld '{}' ';'

Поиск сюидных программ следует выполнять, естественно, как пользователь "root".


Безопасность в сетях

Риски при использовании компьютерных сетей

Риск для безопасности, связанный с использованием компьютерных сетей, в основном сводится к трем факторам:

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

Первые две проблемы в основном могут быть решены путем использования пакета ssh вместо ftp, telnet и rlogin/rsh/rcp, а на третьей мы остановимся чуть подробнее.

Подсистемы, наиболее подверженные взлому

Хотя в принципе "дыра" может обнаружиться в любой сетевой программе, исторически наиболее подверженными взлому являются подсистемы FTP, NFS, Samba (сеть MS-Windows), Sendmail (электронная почта) и NIS/NIS+ (Network Information System, она же YP -- "yellow pages", сетевая информационная система от фирмы Sun).

Самое простое решение -- не использовать эти системы, не всегда доступно. Если от FTP еще можно отказаться (а от NIS/NIS+ просто надо отказаться), то с остальными сложнее.

Для пакета Sendmail существует несколько аналогов, но отсутствие (точнее, необнаруженность) в них дыр объясняются в значительной степени их меньшей распространенностью.

Для NFS же реальной альтернативы попросту нет, и если сетевая файловая система реально нужна, то с риском приходится мириться. Собственно, с NFS связаны две проблемы. Первая -- собственно дыры в реализации. Вторая -- то, что авторизация выполняется по IP-адресам, и если злоумышленник установит для своего компьютера адрес доверенной машины, то в то время, когда та выключена (а при небольшой сноровке -- даже когда включена), он может получить доступ к экспортируемым ресурсам.

Использование же Samba-сервера на большинстве машин попросту ни к чему. Реально он требуется лишь на компьютерах, являющихся серверами для Windows-машин, а в таких случаях следует доверять заботу о серверах квалифицированным системным администраторам -- правильная настройка Samba в любом случае дело непростое.

Замечание
Вообще говоря, система разделения ресурсов в Windows -- Netbios или SMB, весьма неудачна как по своей концепции, так и по реализации. Поэтому долгое время SMB являлась у хакеров излюбленным способом взлома Windows-машин, пока пальму первенства не отобрали еще более кривой пакет IIS (Internet Information Server) и программа ICQ (взлом через IIS или ICQ даже считается "неспортивным").

При реальной необходимости использования указанных систем остается два способа поддержания безопасности. Первый -- постоянное отслеживание новых версий. Второй -- ограничение доступа по сети.

Ограничение доступа

Ограничение доступа по NFS рассмотрено в разделе "Сетевая файловая система NFS". Отметим лишь, что следует давать доступ как можно меньшему количеству машин, и при возможности -- доступ только на чтение, а не на чтение/запись.

Ограничение доступа к таким подсистемам, как ftp, finger, telnet, talk и т.д. осуществляется пакетом tcp-wrappers (программа tcpd).

При проверке разрешения на доступ tcpd просматривает файлы /etc/hosts.allow и /etc/hosts.deny и (вольный перевод фрагмента man-страницы):

  • Доступ дается, если требуемый сервис разрешен запрашивающему компьютеру в файле /etc/hosts.allow.
  • Иначе, в доступе будет отказано, если требуемый сервис запрещен запрашивающему компьютеру в файле /etc/hosts.deny.
  • В любом другом случае доступ разрешается.

Изначально /etc/hosts.allow и /etc/hosts.deny пусты, что означает "доступ разрешен всем и ко всему".

Язык описания правил доступа довольно гибкий, поэтому мы лишь приведем пример простейшего содержания файлов конфигурации для случая, когда доступ ко всем сервисам дается компьютерам Tom и Jerry из домена example.net, компьютеру Cathy разрешается finger, а всем остальным запрещено все.

Файл /etc/hosts.allow:

#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#

ALL:            Tom.example.net Jerry.example.net
in.fingerd:     Cathy.example.net

Файл /etc/hosts.deny:

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!

ALL:            ALL

Имена компьютеров следует указывать полные -- с именем домена.

Если при такой конфигурации с компьютера VeryBad попробовать запустить на нашу машину finger или telnet, то доступ ему будет закрыт:

verybad:~% finger @bobby
[bobby.example.net]

verybad:~% telnet bobby
Trying 192.168.100.15 ...
Connected to 192.168.100.15.
Escape character is '^]'.
Connection closed by foreign host.
verybad:~% _

Подробное описание файлов /etc/hosts.allow и /etc/hosts.deny можно найти в man-странице hosts_access(5).


Пакет ssh

Что такое ssh

Назначение ssh


Ssh -- это программа для удаленного входа в другой компьютер через сеть, удаленного исполнения команд и копирования файлов между компьютерами. "Ssh" расшифровывается как "Secure Shell". Ssh обеспечивает надежную авторизацию и безопасную передачу данных по открытым каналам связи. Ssh предназначена для замены программ rlogin, rsh, rcp и telnet.

При использовании программ telnet, rlogin и ftp есть две проблемы, связанные с безопасностью.

  • Во-первых, все данные передаются по сети в открытом виде, так что кто угодно, имеющий физический доступ к этой сети (попросту компьютер, к ней подключенный) может эти данные перехватить. Причем открытым текстом передаются и пароли.
  • Во-вторых, авторизация на основе паролей (telnet и ftp) и IP-адресов (rlogin) является крайне слабой.

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

Как ssh работает


Для того, чтобы объяснить принцип работы Ssh, воспользуемся аналогией со шпионской деятельностью (благо, общего очень много) на примере известного героя Штирлица.

Представим себе, что Штирлицу ("Юстас") надо передать в Центр ("Алекс") некое сообщение, но старый шифр раскрыт. Что делать? Самый очевидный ответ -- организовать где-нибудь встречу для передачи Юстасу нового шифра ("договориться о новом коде"). Но что, если это невозможно, и единственный канал связи -- открытый? Казалось бы, безвыходная ситуация.

Однако сравнительно недавно, в середине 1970-х, математиками был открыт алгоритм RSA, позволяющий использовать в криптографии так называемые "публичные ключи". Идея заключается в том, что есть два криптоключа -- один для зашифровки, а другой для расшифровки. Ключ для зашифровки называется "публичным ключом", поскольку может быть свободно передан любому и не является секретным. Ключ же для расшифровки является секретным и называется "приватным ключом".

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

Таким образом, если бы действие "Семнадцати мгновений весны" происходило в наше время, то Алексу достаточно было бы открытым текстом отправить Юстасу новый публичный ключ, и Мюллеру и компании осталось бы только рвать на себе волосы.

Замечание
Возможность кого угодно обмениваться надежно шифрованной информацией сильно не понравилась правительству США. Поэтому оно заняло, мягко говоря, дурацкую позицию в отношении ПО для криптографии, приведшую, в частности, к тому, что есть два варианта Ssh -- международный "i" (international) и американский "us". В США (и некоторых других странах) разрешается использовать только версию "us", содержащую меньше возможностей. (Реально ситуация чуть сложнее, но это не принципиально.)

Установка ssh

Пакет Ssh был создан в Технологическом Университете Хельсинки и его домашняя страница расположена по адресу

http://www.ssh.fi/sshprotocols2/
а исходные тексты доступны по адресу

ftp://ftp.cs.hut.fi/pub/ssh/
зеркало в Новосибирске --

ftp://sunsite.nstu.ru/pub/mirrors/ftp.cs.hut.fi/ssh/

Существует два варианта Ssh: версия 1 и версия 2, именуемых обычно ssh1 и ssh2. Хотя ssh2 является более продвинутым вариантом, более распространен пока ssh1, на нем мы и сосредоточимся.

На момент написания этих строк последней в семействе ssh1 является версия 1.2.27. Хотя можно взять исходные тексты по указанному выше адресу и самостоятельно собрать пакет, лучше воспользоваться готовыми .rpm-файлами.

Наиболее распространенным rpm-дистрибутивом Ssh является набор из четырех пакетов, собираемых в Чехии. В ИЯФ они доступны в директории

ftp://rdist.inp.nsk.su/pub/Linux/security/i386/
или по NFS в директории

/net/rdist/dist/security/i386/
это пакеты ssh, ssh-clients, ssh-server и ssh-extras, все с суффиксом -1.2.27-2i.i386.rpm.

Однако эти пакеты не устанавливаются в RedHat 5.2, поскольку требуют слишком новых версий библиотек. Поэтому можно воспользоваться rpm-пакетом сборки SibLUG (Siberian Linux Users Group), доступным по адресу

ftp://sunsite.nstu.ru/pub/linux/install/siblug/RH5.x/i386/

Собственно пакет Ssh состоит из трех компонентов: сервер (sshd), клиентские программы (ssh, slogin, scp) и нескольких служебных программ. Пакет ssh-1.2.27-1.i386.rpm от SibLUG содержит их все.

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

Использование ssh

Программы ssh, slogin и scp используются точно так же, как и rsh, rlogin и rcp. Отличия заключаются, во-первых, в том, для беспарольного входа файла .rhosts на удаленном компьютере недостаточно, а во-вторых, даже команды "ssh <команда>" и "rcp" при отсутствии беспарольного входа просто спросят пароль.

Кроме того, scp, в отличие от rcp, еще и показывает процент сделанной работы по мере копирования.

При первом запуске ssh создаст директорию ~/.ssh, а при первом входе на конкретный компьютер запросит подтверждение, действительно ли вы этого хотите (поскольку компьютер отсутствует в списке известных машин):

bobby:~% ssh jerry
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'jerry' added to the list of known hosts.
Creating random seed file ~/.ssh/random_seed.  This may take a while.
ivanov@jerry's password: набираем пароль
Last login: Tue May 25 09:19:18 1999 from bobby.inp.nsk.su
jerry:~% _

При повторном запуске потребуется лишь ввести пароль:

bobby:~% ssh jerry
ivanov@jerry's password: набираем пароль
Last login: Tue May 25 15:49:25 1999 from bobby.inp.nsk.su
jerry:~% _

Два замечания. Во-первых, в ответ на вопрос "yes/no" надо набрать "yes" (на не "y"). Во-вторых, для ssh "jerry" и "jerry.inp.nsk.su" -- разные компьютеры, и если теперь набрать команду "ssh jerry.inp.nsk.su", то вопрос, действительно ли мы хотим зайти на указанный компьютер, будет задан вновь.

Настройка ssh

Файлы конфигурации


У пакета Ssh есть два "комплекта" файлов конфигурации: общесистемные в директории /etc/ или, в некоторых версиях, /etc/ssh/, и персональные для каждого пользователя, хранящиеся в директории ~/.ssh/.

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

В персональных настройках часть файлов должна иметь права на чтение только пользователем, а часть может (но не обязательно) быть доступна всем. Лучше всего сделать всю директорию ~/.ssh доступной только для себя командой

chmod -R og-rwx ~/.ssh

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

Настройка беспарольного входа


Для того, чтобы получить возможность использовать ssh, slogin и scp без ввода пароля, надо создать пару персональных криптоключей (публичный и приватный) и положить их в нужные файлы.

Поскольку процедура эта не слишком интуитивно-понятная, а в документации на Ssh "пошаговые" инструкции на эту тему отсутствуют (это прямо записано как "надо бы сделать" в файле TODO), приведем детальное описание требуемых шагов.

Последовательность действий тут следующая:

  1. Создать ключи при помощи команды ssh-keygen.
  2. Положить приватный ключ в ~/.ssh/identity (по умолчанию ssh-keygen сделает это сам).
  3. Добавить публичный ключ в файл ~/.ssh/authorized_keys на том компьютере, вход на который должен происходить без пароля.

Для генерации пары ключей достаточно запустить команду ssh-keygen:

bobby:~% ssh-keygen
Initializing random number generator...
Generating p:  ........++ (distance 124)
Generating q:  ......................++ (distance 328)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key (/home/ivanov/.ssh/identity):<Enter>
Enter passphrase: <Enter>
Enter the same passphrase again: <Enter>
Your identification has been saved in /home/ivanov/.ssh/identity.
Your public key is:
1024 33 12913738256340298710059171689915842154375256914824221671871874357756
3659626759215847653490823781603860082037425573246549608512317229841156397014
4924521593039853737665394617676169185262964253571771338998219867068779128524
3669389707472603577041589530866646165573655919196199244485490121992336959595
2072162398963 ivanov@bobby.inp.nsk.su
Your public key has been saved in /home/ivanov/.ssh/identity.pub
bobby:~% _

Обратите внимание, что ssh-keygen просит ввести "ключевую фразу" (passphrase). Ключевая фраза позволяет повысить степень безопасности -- если она есть, то при входе на удаленный компьютер обязательно надо будет ее ввести (т.е. это как бы пароль в дополнение к ключу), так что даже если кто-то сможет похитить ваш приватный ключ (файл ~/.ssh/identity), этого будет недостаточно для входа.

Если же нужен именно беспарольный вход, то ключевую фразу следует оставить пустой (просто нажав <Enter>).

Поскольку ssh-keygen автоматически создал файл ~/.ssh/identity, осталось лишь добавить публичный ключ в файл ~/.ssh/authorized_keys на удаленном компьютере.

Файл ~/.ssh/authorized_keys представляет собой список публичных ключей, обладателям которых разрешен доступ, по одному ключу на каждой строке. Причем строки эти довольно длинные, так что если модифицировать файл при помощи текстового редактора, то следует предварительно отключить автоматический перенос слов (word-wrapping).

Публичный ключ ssh-keygen помещает в ~/.ssh/identity.pub, так что лучше всего скопировать его в какой-нибудь временный файл на удаленном компьютере при помощи scp, а затем "дописать" содержимое к authorized_keys при помощи cat:

bobby:~% scp  ~/.ssh/identity.pub jerry:
identity.pub              |          0 KB |   0.3 kB/s | ETA: 00:00:00 | 100%

bobby:~% ssh jerry
ivanov@jerry's password: набираем пароль
Last login: Tue May 25 16:11:03 1999 from bobby.inp.nsk.su
jerry:~% cat identity.pub >>.ssh/authorized_keys
jerry:~% exit
Connection to jerry closed.
bobby:~% ssh jerry
Last login: Tue May 25 16:11:45 1999 from bobby.inp.nsk.su
jerry:~% _

Обратите внимание, что при перенаправлении вывода команды cat следует указывать двойной символ ">", а не одинарный, чтобы содержимое identity.pub было добавлено к authorized_keys, а не заменило его.

Файл .rhosts


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

Настройка ssh-клиента под Windows

Где взять


Первоначально одним из сдерживающих факторов в распространении Ssh было отсутствие свободно распространяемых ssh-клиентов под Windows.

В настоящее же время имеется ssh-plugin ("дополнение") к пакету TeraTerm Pro, под названием TTSSH.

Домашняя страница TeraTerm Pro --

http://hp.vector.co.jp/authors/VA002416/teraterm.html
а TTSSH --

http://www.zip.com.au/~roca/download.html

В ИЯФ и TeraTerm Pro, и дополнение к нему доступны в директории

ftp://ftp.inp.nsk.su/pub/Crypt/ssh/TeraTerm/

Несколько слов о TeraTerm Pro


Пакет TeraTerm Pro создан в Японии и является свободно распространяемым. Это эмулятор терминала для Windows95/NT, есть также версия для Windows 3.1 (но TTSSH для 3.1 отсутствует).

Одной из отличительных особенностей является поддержка русского языка -- прямо при установке программа позволяет выбрать русский язык. При этом программа автоматически "догадывается", что на клиентской машине (Windows) используется набор символов Windows-1251, а на сервере -- koi8-r, и автоматически производит перекодировку.

Это свойство вместе с поддержкой ssh делают TeraTerm Pro практически лучшей программой-эмулятором терминала для России.

И TeraTerm Pro, и TTSSH доступны в исходных текстах.

Установка и настройка TTSSH


Первым делом надо установить TeraTerm Pro. Данный процесс стандартен для Windows -- надо просто распаковать .zip-файл и запустить программу setup.exe. По завершении процесса установки в меню [Пуск] -> Программы появится меню "TeraTerm Pro".

Затем нужно распаковать содержимое файла ttssh.zip в директорию, куда установлен TeraTerm Pro -- обычно это C:\Program Files\TTERMPRO. При этом в директории появится файл ttssh.exe, который и следует запускать.

Поскольку ttssh.exe доступен только прямо в директории, для удобствы следует поместить ярлык на него в меню. Если же запускать просто ttermpro.exe, то будет прежняя функциональность TeraTerm Pro -- без ssh.

При запуске TTSSH в окне "New connection" появляется дополнительный пункт -- "SSH".

Окно открытия соединения TTSSH

При выборе варианта "SSH" появится дополнительное окно, в котором указывается имя пользователя и тип авторизации.

Окно авторизации TTSSH

В частности, для беспарольного входа надо выбрать вариант "Use RSA key to log in" и указать файл, в котором содержится приватный ключ -- этот файл можно просто скопировать из ~/.ssh/identity.

Чтобы каждый раз не вводить заново имя пользователя, стоит один раз произвести настройку при помощи пункта "SSH Authentication" из меню Setup, и затем сохранить ее командой Setup -> Save setup.

Окно настройки авторизации TTSSH

Предупреждение
Механизмы защиты данных в Windows95 отсутствуют, поэтому файл, содержащий приватный ключ, может легко быть похищен (в том числе через сеть). WindowsNT в этом плане не многим лучше.

Поэтому при работе с TTSSH лучше воздержаться от использования беспарольного входа.


Практические задания
  1. Найти на диске все файлы с установленным флагом смены идентификатора пользователя и/или группы и записать этот список в файл.
  2. Установить пакет ssh, дистрибутив доступен по адресу

    /net/class/home/teachers/bolkhov/ssh-1.2.27-1.i386.rpm
  3. Зайти на компьютер соседа при помощи ssh.
  4. Настроить беспарольный вход на компьютер соседа.

----------------------------------------

© 1999 Дмитрий Болховитянов