Stfw.RuНастройка SSH
🕛 08.07.2009, 11:15
Из протоколов, обеспечивающих защиту передаваемых данных, среди пользователей Linux наиболее популярен SSH (Secure Shell - защищенная оболочка). Данные, предназначенные для передачи по сети посредством данного протокола, шифруются. Очевидно, что шифрованные данные могут быть перехвачены на маршрутизаторе или в локальной сети, но технология, позволяющая декодировать их, в настоящее время отсутствует. (Теоретически достаточно мощный компьютер способен справиться с задачей расшифровки информации, но для этого ему потребуется очень много времени. Кроме того, компьютеры необходимой мощности встречаются достаточно редко, и получить доступ к ним очень трудно.)В последнее время серверы SSH используются все чаще, но они еще не стали универсальным инструментом взаимодействия. Подобно другим серверам удаленной регистрации, настройка SSH производится достаточно просто, но, чтобы установить требуемую конфигурацию системы, надо знать назначение опций, указываемых при запуске сервера, и структуру конфигурационных файлов.
В 2001 году бурно обсуждался вопрос использования названия SSH в качестве нл^ч торговой марки. Не исключено, что в ближайшее время протокол SSH и од-на из его реализаций (OpenSSH) изменят свое название. Что же касается коммерческого продукта, реализующего этот протокол (SSH), то он и далее будет поставляться под тем же названием. На момент написания данной книги этот вопрос еще не был решен, поэтому я использую здесь названия, указанные на Web-узлах соответствующих продуктов. Изменения, скорее всего, будут относиться к названию пакета и не затронут название программ, содержащихся в его составе.
Программное обеспечение для поддержки SSH
Существуют два основных пакета SSH, предназначенных для работы в системе Linux: коммерческий продукт SSH (http: //www. ssh. com/products/ssh/), разработанный компанией SSH, и пакет OpenSSH, распространяемый в исходных кодах (http: //www.openssh.org). Пакет OpenSSH входит в состав многих версий Linux, в частности, Caldera 3.1, Debian 2.2, Mandrake 8.1, Red Hat 7.2, Slackware 7.0 и SuSE 7.3. Если версия пакета, поставляемая в составе операционной системы, вас не устраивает, вы можете обратиться на Web-узел OpenSSH. (Перед использованием коммерческой версии SSH необходимо ознакомиться с лицензионным соглашением.) Далее в этой главе я буду использовать термин SSH для обозначения любой реализации данного протокола. Проект OpenSSH имеет непосредственное отношение к операционной системе ндЧ^ OpenBSD. Двоичные коды OpenSSH различаются для разных систем. В документе http: //www.openssh.org/portable . html содержится информация об использовании OpenSSH в системах, отличных от OpenBSD, в том числе в различных версиях Linux. При желании вы можете скопировать с сервера исходные коды данного продукта и скомпилировать их самостоятельно.
В декабре 2001 года была создана версия 3.1 продукта SSH. В том же месяце был выпущен пакет OpenSSH 3.O.2. В версиях 3.0.x этих продуктов поддерживался приблизительно одинаковый набор возможностей и использовалась одна и та же технология кодирования. В версии 3.1 SSH была добавлена поддержка PKI (Public Key Infrastructure - инфраструктура открытого ключа), позволяющая использовать для идентификации участников взаимодействия сертификаты, реализована возможность аппаратной идентификации, а также включены другие дополнительные средства. Продукт SSH несколько опережает по своему развитию OpenSSH; это вполне объяснимо, так как протокол SSH был разработан компанией SSH.
Программы SSH и OpenSSH могут взаимодействовать между собой, поэтому, организуя обмен по протоколу SSH, не слишком важно, какой тип клиента и сервера используется на компьютерах. Существуют незначительные несоответствия между конкретными версиями пакетов, которые нетрудно учесть. Протокол SSH разработан так, что компьютеры, на которых установлено программное обеспечение, поддерживающее различные версии SSH, могут использовать средства, присутствующие в обеих версиях. Например, если на одном компьютере поддерживается SSH 2, а на другом - SSH 3, они могут взаимодействовать по протоколу SSH 2.
В большинстве случаев пакет OpenSSH поставляется в виде нескольких файлов. Наиболее важными являются openssh, поддерживающий'базовые средства SSH, а также
openssh-client и openssh-server, которые реализуют соответственно клиентскую программу и сервер.
Протокол SSH распространен не так широко как Telnet, поэтому вам необходимо специально установить клиентские программы SSH на компьютеры ваших пользователей. Такие программы существуют для различных операционных систем. Информация о бесплатно распространяемых клиентах SSH находится на сервере http: //www. freessh. org. Поддержку SSH обеспечивают также многие коммерческие терминальные программы, ориентированные на работу в системах Windows и MacOS. Инсталлировать клиент SSH нетрудно; сложнее доставить эти программы на все компьютеры и научить пользователей работать с ними.
Возможности SSH
Основное отличие SSH от большинства протоколов удаленной регистрации заключается в том, что SSH обеспечивает шифрование передаваемых данных. Кроме того, данный протокол поддерживает перенаправление, или туннелирование, сетевых портов между клиентом и сервером. Это значит, что посредством SSH-соединения могут передаваться пакеты других протоколов. Возможна конфигурация, при которой SSH-соединение будет автоматически использоваться для обмена данными по некоторому протоколу, например, такое взаимодействие реализовано для X Window. (Подробно вопрос установления соединений средствами X Window будет рассмотрен в главе 14.) Затратив определенные усилия для настройки системы, можно реализовать туннелирование сообщений любого протокола посредством защищенного соединения. Вы можете даже использовать средства РРР для создания сетевого интерфейса, предполагающего туннелирование средствами SSH. В результате можно получить виртуальную частную сеть (VPN - Virtual Private Network). Необходимые действия по настройке такой сети описаны в документе VPN HOWTO (http-.//www. linuxdoc . org/HOWTO/VPN-HOWTO.html).
Заслуживает внимания еще одна возможность протокола SSH - непосредственная реализация инструментов, не связанных с регистрацией в системе. В частности, в состав пакета SSH входит программа под названием scp, которая используется для копирования файла с одного компьютера на другой. Формат вызова этой команды приведен ниже.
scp [[пользователь!]узел!:]имя_файла! \ [[пользователь2]узел2:]имя_файла2]
Вызов scp очень похож на вызов программы гср, реализующей r-команду, с помощью которой осуществляется копирование файлов. Программа scp создана для замены гср. В отличие от гср и многих других инструментов передачи файлов (например, FTP), scp копирует данные в зашифрованном виде, кроме того, она шифрует имя пользователя и пароль. Такую программу удобно использовать для передачи важных данных по сетям, в которых не гарантируется защита информации.
Дополнительные интерактивные возможности при передаче файлов обеспечивает программа sftp, которая работает подобно традиционной программе ftp, но защищает содержимое файлов и регистрационные данные посредством кодирования. Некоторые FTP-клиенты с графическим интерфейсом, например gFTP (http: //gftp. seul. org), также поддерживают передачу данных на базе SSH. Таким образом, средства SSH, по сути, дублируют функции Telnet и FTP.
Стандартный сервер SSH (программа sshd) поддерживает как работу SSH-клиента (в системе Linux это программа ssh), так и обмен данными с программами scp и sftp.
Этот сервер также обеспечивает туннелирование портов. Весь трафик проходит через стандартный SSH-порт 22.
Опции, используемые при запуске сервера SSH
Независимо от того, какую реализацию протокола SSH вы используете, сервер обычно запускается с помощью сценария SysV. Запуск сервера может осуществляться также посредством суперсервера, но такая возможность используется крайне редко. Дело в том, что запуск старых версий сервера происходил с большой задержкой, так как некоторые операции, выполняемые при запуске, создавали большую нагрузку на процессор. Если сервер выполняется на современном оборудовании, задержка практически не заметна, поэтому при желании вы можете сконфигурировать sshd для запуска посредством суперсервера. При этом необходимо указывать опцию -i, назначение которой будет рассмотрено ниже.
При вызове сервера SSH могут быть заданы различные опции, изменяющие поведение программы. Опции, предусмотренные в пакете OpenSSH 3.0.2, перечислены ниже.
- -d. В обычных условиях сервер выполняется в режиме демона. Данная опция задает режим отладки, при котором сервер выполняется в качестве задачи переднего плана, поддерживает лишь одно соединение и выводит дополнительную отладочную информацию. Указывая дополнительные опции -d (sshd поддерживает до трех символов d), вы можете задать вывод дополнительных сведений о работе программы.
- -D. Эта опция отменяет режим демона, но, в отличие от опции -d, она не переводит сервер в режим отладки.
- -е. Данная опция указывает на то, что сообщения об ошибках, генерируемые sshd, не должны записываться в файл протокола, а должны выводиться в стандартный поток ошибок.
- -f конфигурационный_файл. В качестве конфигурационного файла сервер обычно использует /etc/ssh/sshd_config, но с помощью данной опции вы можете указать другой файл.
- -i. Данная опция сообщает программе о том, что программа была запущена посредством суперсервера (inetd или xinetd). Если для запуска sshd используется суперсервер, надо обязательно указывать данную опцию.
- -р порт. Эта опция задает порт для сервера. По умолчанию используется порт 22.
- -q. Данная опция подавляет протоколирование. (Обычно в файл протокола записывается информация об установлении соединения, выполнении аутентификации и разрыве соединения.)
- -4. По умолчанию sshd поддерживает соединения с компьютерами, адреса которых соответствуют либо протоколу IPv4, либо протоколу IPv6. Данная опция указывает на то, что sshd должен устанавливать соединения только с клиентами, имеющими адреса IPv4.
- -6, Данная опция разрешает установление соединений только с клиентами, имеющими адреса IPv6.
При запуске sshd могут задаваться и другие опции, большинство из которых определяют особенности кодирования данных. Дополнительную информацию об этих опциях можно получить на страницах справочной системы, посвященных sshd.
Перед первым запуском sshd необходимо сгенерировать файлы, содержащие ключи кодирования. При выполнении алгоритма SSH эти ключи используются для идентификации участников взаимодействия и кодирования данных. В большинстве случаев в сценариях SysV, осуществляющих запуск сервера, предусмотрен код, который поверяет наличие файлов с ключами кодирования и при необходимости генерирует их. Если в вашей системе подобный код отсутствует, вы можете использовать для генерации файлов следующие команды:
# ssh-keygen -q -t rsal -f /etc/ssh/ssh_host_key -C " -N "
# ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C ' ' -N "
# ssh-keygerl -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C " -N ' '
Каждая из приведенных выше команд генерирует два ключа: закрытый, или личный, ключ (private key), используемый только на сервере, и открытый, или общий, ключ (public key). Открытый ключ передается клиенту, чтобы он мог кодировать данные, передавая их на сервер. Закрытый и открытый ключи помещаются в файлы, имена которых отличаются друг от друга лишь тем, что к имени файла с открытым ключом добавляется суффикс . pub. Перед вызовом этих команд необходимо проверить наличие шести файлов: (ssh_host_key, ssh_host_key.pub, ssh_host_rsa_key, ssh_host_rsa_key.pub, ssh_host_dsa_key и ssh_host_dsa_key.pub (обычно эти файлы размещаются в каталоге /etc/ssh). Если вы измените существующие ключи, вам придется переконфигурировать клиентские программы, настроенные на работу со старыми ключами. Поэтому ключи следует изменять только в том случае, когда это действительно необходимо.
Редактирование файла sshd_config
Работой сервера sshd управляет файл sshd_config, который обычно находится в каталоге /etc/ssh. (He следует путать файл sshd_config с конфигурационным файлом клиента ssh_config, который размещается в том же каталоге.) В файле sshd_config указываются опции и их значения. Каждая опция задается в отдельной строке в следующем формате: Опция значение
Подобно другим конфигурационным файлам, строка, начинающаяся с символа #, содержит комментарии. Многие опции в файле sshd_conf 1ддублируют опции командной строки, которые указываются при вызове sshd, но некоторые из опций могут присутствовать только в конфигурационном файле. Конфигурация, установленная по умолчанию, чаще всего обеспечивает нормальную работу сервера, но иногда приходится изменять значения некоторых опций, например PermitRootLogin. Наиболее важные из опций, содержащихся в файле sshd_config, приведены ниже.
- Port. Данная опция позволяет задать порт для сервера. По умолчанию используется порт 22.
- HostKey. Эта опция сообщает серверу о том, где следует искать ключи кодирования. Ключи кодирования содержатся в файлах, которые должны быть сгенерированы перед первым запуском программы. Примером такого файла является /etc/ssh/ssh_host_key. При настройке сервера можно указать несколько файлов с ключами.
KeyRegenerationlnterval. При установлении соединения участники SSH-вза-имодействия ведут переговоры об использовании ключей кодирования, а затем время от времени договариваются о замене ключей. Периодическая замена ключей уменьшает опасность повреждения системы в случае, если по каким-либо причинам ключ будет расшифрован. (Обратите внимание на то, что здесь речь идет о ключах, сгенерированных в дополнение к ключам, которые создаются перед первым запуском программы. Ключи, сформированные в процессе переговоров, никогда не записываются на диск.) Данная опция задает время (в секундах) использования сгенерированных ключей. По истечении этого времени формируются новые ключи.
PermitRootLogin. В большинстве случаев при инсталляции пакета устанавливается значение yes данной опции. По умолчанию sshd позволяет пользователю root регистрироваться на сервере. Безопаснее, однако, задать для этой опции значение по, так как в этом случае злоумышленник, пытающийся незаконно проникнуть в систему, должен знать два пароля (пароль обычного пользователя и пароль root). Значение по опции PermitRootLogin не исключает возможность удаленного администрирования системы, но для этого вам придется сначала зарегистрироваться как обычный пользователь, а затем получить привилегии root с помощью команды su.
IgnoreRhosts. По умолчанию устанавливается значение yes данной опции, в результате чего сервер sshd игнорирует файл ~/.rhosts. Если опция IgnoreRhosts имеет значение по и если значение опции RhostsAuthenticationравно yes, sshd, подобно rlogind, будет поддерживать аутентификацию по принципу доверия. Установка значения по опции IgnoreRhosts создает реальную опасность для системы.
RhostsAuthentication. Для поддержки аутентификации по принципу доверия
сервер SSH использует две опции: IgnoreRhosts и RhostsAuthentication.
Опция
RhostsAuthentication разрешает работу с узлами, пользующимися доверием.
Желательно установить для данной опции значение по.
RSAAuthentication. В версии 1 протокола SSH был предусмотрен метод аутентификации с применением открытого ключа, при котором пароль не передавался по сети. Вместо этого использовались открытый ключ и фраза пароля. Для того чтобы разрешить данный способ аутентификации, надо установить значение yes опции RSAAuthentication (это значение принимается по умолчанию).
PubkeyAuthentication. Данная опция выполняет те же действия, что и опция RSAAuthentication, но применяется при работе с версией 2 протокола SSH.
PasswordAuthentication. Значение yes данной опции позволяет пользователям регистрироваться, вводя пароль в ответ на приглашение. Этот способ аутентификации широко используется в настоящее время, поэтому желательно принять значение опции PasswordAuthentication, установленное по умолчанию.
- XII Forwarding. Как было сказано ранее, протокол SSH может быть использован для туннелирования Х-соединений. Чтобы это стало возможным, соответствующая конфигурация должна быть установлена как для сервера, так и для клиентской программы. Значение yes опции XllForwarding указывает на то, что сервер SSH должен перенаправлять соединения X Window. Опция аналогичного назначения предусмотрена и для клиента SSH. Имя этой опции - ForwardXll; она указывается в файле/etc/ssh/ssh_config.
При настройке сервера SSH могут быть использованы дополнительные опции. Одни из них определяют альтернативные способы аутентификации, другие уточняют действие перечисленных выше опций, а третьи задают детали функционирования сервера. После установки пакета, реализующего SSH-взаимодействие, внимательно просмотрите конфигурационный файл, который поставляется в составе пакета, и выясните, подходит ли вам конфигурация, установленная по умолчанию. Дополнительную информацию о назначении опций можно найти на страницах справочной системы, посвященных sshd.
Аутентификация при SSH-взаимодеиствии
В процессе обмена сервер и клиент SSH используют различные способы кодирования передаваемых данных. Упрощенно это выглядит так. Участники взаимодействия договариваются о временном использовании метода кодирования с помощью открытого ключа. Ключ представляет собой достаточно большое число и применяется для шифрования информации, передаваемой по сети. При получении данных система декодирует их с помощью закрытого ключа. Такой способ кодирования используется для передачи другого типа ключа, называемого секретным ключом. Секретный ключ используется в другом методе шифрования и обеспечивает более высокое быстродействие по сравнению с кодированием посредством открытого и закрытого ключей. По завершении передачи секретного ключа компьютеры, обменивающиеся по протоколу SSH, начинают использовать для кодирования данных секретный ключ. Помимо передачи секретного ключа, открытый и закрытый ключи применяются также при аутентификации; идентификатор пользователя, зашифрованный с помощью закрытого ключа, позволяет убедиться в том, что пользователь - именно тот, за кого он себя выдает.
Действия, выполняемые при SSH-аутентификации
В протоколе SSH предусмотрено несколько способов аутентификации пользователей. Детали процесса аутентификации различаются в зависимости от версии протокола. В общих чертах алгоритм аутентификации выглядит следующим образом.
1. Клиент предпринимает попытку аутентификации, основанной на принципе доверия, однако в большинстве случаев значения опций RhostsAuthentication и IgnoreRhosts запрещают этот способ аутентификации. Если же попытка оказывается успешной, клиент получает доступ к ресурсам сервера; при этом пользователю не приходится указывать имя и пароль.
2. Клиент пытается использовать способ аутентификации, представляющий собой сочетание принципа доверия и RSA-аутентификации. В большинстве случаев такая попытка тоже не имеет успеха.
3. Клиент пытается использовать RSA-аутентификацию, которая предполагает передачу специального файла. Если такой файл присутствует на сервере и если последующие действия в рамках этого метода оказывается успешными, пользователь получает доступ к системе. В зависимости от конфигурации, от пользователя может потребоваться ввод фразы пароля. Для того чтобы этот метод мог быть использован, и клиент, и сервер должны быть настроены соответствующим образом.
4. Если все предшествующие попытки аутентификации окончились неудачей, пользователь должен ввести пароль. Этот пароль передается серверу в закодированном виде и применяется для аутентификации пользователя.
Сервер хранит файлы, содержащие ключи, в каталоге /etc/ssh и применяет их при работе со всеми пользователями. SSH-клиенты получают открытые ключи от серверов и могут использовать их для аутентификации этих серверов. Открытые ключи хранятся в каталоге ~/.ssh, и за их поддержку отвечает пользователь. При первом обращении клиента к серверу по протоколу SSH клиентская программа оповещает пользователя о том, что в файл записан новый ключ. (Конфигурация программы может быть установлена так, что для выполнения этого действия потребуется подтверждение пользователя.) Если сервер изменит ключ, ssh отобразит предупреждающее сообщение, которое выглядит следующим образом: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@g@@@@@@@@@@@@@@@@@@@@@@@@@@g@@@@@@@@@@@@@@@g@@@@@@g@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Клиент может отображать дополнительную информацию в составе сообщения, но в любом случае соединение с сервером не устанавливается. Если пользователь согласен работать с новыми ключами, он должен удалить запись, соответствующую серверу, из файла ~/.ssh/known_hosts или ~/. ssh/known_hosts2 (имя файла зависит от версии протокола).
В отличие от telnetd, sshd не передает управление программе /bin/login; вместо этого sshd самостоятельно осуществляет регистрацию пользователя. (Если вы хотите, чтобы sshd использовала программу login, необходимо задать соответствующее значение опции UseLogin в файле sshd_config.) Таким образом, sshd можно рассматривать как сочетание программ telnetd и login. Исключив программу login из процесса регистрации, sshd получает возможность выполнять аутентификацию с помощью открытого ключа.
Ключи для автоматической регистрации и повышения безопасности системы
Пользователи могут генерировать ключи и использовать их для регистрации на сервере. Эти ключи хранятся на клиентской машине в каталоге ~/ . ssh. Как известно, по умолчанию при аутентификации на сервере SSH пользователь должен задавать пароль. Если вы передадите открытый ключ на сервер, то будете избавлены от необходимости указывать пароль при регистрации. Для повышения уровня защиты при регистрации с помощью открытого ключа может также быть предусмотрен ввод специальной фразы пароля; это еще больше усложнит процедуру незаконного проникновения в систему. Чтобы аутентификация с помощью открытого ключа стала возможной, выполните следующие действия.
1. Зарегистрируйтесь на компьютере, выполняющем роль клиента при SSH-обмене.
2. Введите команду генерации ключей, соответствующих версии 2 SSH. Эта команда приведена ниже; для ее выполнения потребуется несколько секунд.
$ ssh-keygen -q -t rsa -f ~/. ssh/id_rsa -C ' ' -N "
Если вы не укажете опцию -N ' ', утилита ssh-keygen запросит фразу пароля. Если перед,нажатием клавиши <Enter> вы введете какие-либо символы, вам придется указывать их при каждом соединении с сервером. С точки зрения пользователя использование фразы пароля при регистрации принципиально не отличается от указания пароля.
3. Скопируйте файл ~/id_rsa.pub в свой рабочий каталог на сервере. (Этот файл содержит открытый ключ. Его имя отличается от имени файла, которое вы задали при вызове предыдущей команды, суффиксом .pub.) Для копирования можно использовать команду scp.
$ scp ~/.ssh/id_rsa.pub server:.ssh/id_rsa.client
4. Зарегистрируйтесь на сервере. Для этого вы можете использовать ssh, но вам придется ввести пароль.
5. Сделайте каталог ~/ . ssh текущим. Если вы выведете список файлов, то увидите, что в этом каталоге присутствует файл id_rsa. client.
6. Добавьте открытый ключ в файл authorized_keys2. Это можно сделать с помощью следующей команды:
$ cat id_rsa.client » authorized_keys2
С этого момента вы можете устанавливать соединение с сервером, используя протокол SSH 2. Если вы не указали фразу пароля, при регистрации вам не придется вводить какие-либо идентификационные данные. Опция -2 указывает SSH-клиенту на то, что взаимодействие должно осуществляться с использованием версии 2 протокола SSH.
$ ssh -2 server
ВНИМАНИЕ Если вы применяете открытый ключ для аутентификации, необходимо принять f меры для того, чтобы закрытый ключ не стал доступен посторонним. Если злоумышленник сможет получить ваш закрытый ключ, он сможет обращаться к серверу под вашим именем. В протоколе SSH ключ.связывается с определенным IP-адресом, и регистрироваться с помощью открытого ключа можно только с одного компьютера, но тот, кто пытается проникнуть в систему, сумеет без труда обойти это ограничение (именно поэтому защита rlogind не соответствует современным требованиям). Применение фразы пароля повысит уровень защиты, так как, чтобы проникнуть в систему, надо не только получить в свое распоряжение открытый ключ, но и узнать нужную фразу. Однако, если при каждой регистрации на сервере пользователю придется вводить идентификационные данные (в частности, фразу пароля), работа посредством протокола SSH будет гораздо менее удобной.
Для того чтобы обеспечить RSА-аутентификацию при использовании протокола SSH 1, ваши действия должны несколько отличаться от приведенных выше. Новая процедура и процедуры, описанные ранее, имеют следующие отличия.
- В п. 2 вместо -t rsa -f ~/.ssh/id_rsa следует указать -t rsal -f ~/. ssh/identity. При этом будет сгенерирована пара ключей RSA по соглашениям версии 1. Аналогичным образом надо изменить имена файлов на других стадиях процедуры.
- В п. 6 открытый ключ изidentity .pub копируется не вauthorized_keys2, а в файл authorized_keys.
- При установлении соединения, вызывая ssh, не надо указывать опцию -2.
Обе описанные здесь процедуры предполагают, что сервер сконфигурирован для выполнения аутентификации с помощью открытого ключа. Как вы уже знаете, для этой цели используются опции RSAAuthentication(версия 1) и PubkeyAuthentication (версия 2), задаваемые в конфигурационном файле /etc/ssh/sshd_config.
Заметьте, что пользоваться SSH-соединением можно, не настраивая программы для аутентификации с помощью открытого ключа. Подобная аутентификация лишь исключает необходимость ввода пароля либо обеспечивает дополнительную степень защиты за счет использования фразы пароля.
Применение ssh-agent
SSH-аутентификацию можно также организовать с помощью инструмента, который называется ssh-agent. Программа ssh-agent осуществляет управление SSH-ключа-ми так, что фразу пароля приходится вводить лишь один раз. Для того чтобы работа с ssh-agent стала возможной, выполните следующие действия.
1. Создайте закрытый и открытый ключи, выполнив описанную выше процедуру, и скопируйте открытый ключ в свой рабочий каталог на сервере SSH. При вызове ssh-keygen не следует задавать опцию -N '', чтобы закрытый ключ был защищен фразой пароля.
2. На компьютере, на котором выполняется клиентская программа SSH, задайте команду ssh-agent /bin/bash, и она запустит на выполнение программу ssh-agent и новую оболочку Bash. В результате ssh-agent будет контролировать все процессы, порожденные новой оболочкой. (При необходимости вы можете использовать вместо Bash другую оболочку.)
3. Чтобы добавить RSA-ключ SSH к кэшу ключей ssh-agent, вызовите команду ssh-add~/. ssh/id_rsa. (При использовании версии 1 SSH задавать ~/ . ssh/ id_rsa не следует.) Если ключ защищен фразой пароля, ssh-add запросит ее.
С этого момента вы можете обращаться к серверу SSH с помощью SSH-клиента; причем вам не придется вводить ни пароль, ни фразу пароля. Программа ssh-agent хранит ключи в памяти и устанавливает переменные окружения так, что клиент SSH взаимодействует с ssh-agent и получает значения ключей. Доступ к ключам имеют только программы, являющиеся дочерними по отношению к ssh-agent, но если ssh-agent запускает новую оболочку, то все программы, вызванные из этой оболочки, в том числе ssh, также становятся дочерними для ssh-agent.
Если вам необходимо установить одно соединение, данный подход не оправдывает себя, так как перед вызовом ssh вам необходимо запустить ssh-agent и включить ключи
в кэш посредством ssh-add, кроме того, придется один раз ввести фразу пароля. Применение ssh-agent позволит сэкономить время в том случае, если вы регистрируетесь на нескольких компьютерах с помощью одного ключа либо если вам часто приходится повторно регистрироваться на одном компьютере. Существует несколько способов, позволяющих упростить работу с ssh-agent.
- Вы можете внести изменения в файл /etc/passwd так, чтобы оболочка вызывалась посредством ssh-agent. Например, если в /etc/passwd указана оболочка /bin/bash, вы можете задать в соответствующем поле /usr/bin/ssh-agent /bin/bash. (При необходимости вы можете изменить путь к ssh-agent или использовать другую оболочку.) После этого вам не придется вручную задавать команду ssh-agent /bin/bash; достаточно будет зарегистрироваться в системе, ввести ssh-add ~/ . ssh/id_rsa и использовать ssh для регистрации на удаленном компьютере. Данный подход применим только в том случае, когда регистрация в системе осуществляется в текстовом режиме. Если вы используете графическую среду, то для каждого нового окна xterm будет создаваться новое окружение ssh-agent, что приведет к непроизводительному расходу ресурсов.
- Если вы регистрируетесь в текстовом режиме и запускаете X Window с помощью startx, вы можете вместо этой команды задать ssh-agent startx. При этом ssh-agent становится родительской программой по отношению ко всем процессам X Window и может предоставлять им информацию о ключах.
- Если вы используете инструменты регистрации с графическим интерфейсом, вам надо сохранить файл .xsession (или другой файл аналогичного назначения) под именем . xsession-nosshagent, а затем создать новый файл . xsession, включив в него единственную команду ssh-agent ~/ . xsession-nosshagent. В результате ssh-agent станет родительской программой для всех процессов X Window, и вам не придется повторно вводить ключи, добавленные в кэш программой ssh-add, даже если вы будете запускать клиент SSH из различных окон.
После запуска ssh-agent и указания ключей вы можете просмотреть введенные ключи, задав команду ssh-add -1. Для удаления ключей надо использовать команду ssh-add -d. Если после вызова ssh-add -d вы захотите установить SSH-соедине-ние, вам придется повторно ввести ключ (или указать пароль).
Одно из преимуществ использования ssh-agent состоит в том, что для взаимодействия с различными серверами SSH вам надо лишь скопировать открытый ключ на каждый сервер. Устанавливая соединение с несколькими серверами, вы можете использовать один и тот же открытый ключ и программу ssh-agent. Если вы предпочитаете применять различные ключи для работы с разными серверами, вам придется хранить ключи в отдельных файлах и при загрузке каждого из них вводить соответствующую фразу пароля. Если вам понадобится установить соединение с компьютером, на котором отсутствует открытый ключ, вам придется ввести пароль так же, как вы это делаете при обычном обращении без использования ssh-agent.
Сервер удаленной регистрации позволяет пользователям запускать программы и вызывать команды из оболочки во время работы на удаленном компьютере. Такой режим работы очень удобен для пользователя, но, поддерживая средства удаленной регистрации, приходится принимать дополнительные меры по обеспечению безопасности системы.
Наиболее часто в системе Linux используются серверы удаленной регистрации rlogind, Telnet и SSH. Из них наилучшую защиту обеспечивают средства SSH, поэтому именно их желательно использовать для установления соединения с Internet. (Существуют также разновидности Telnet, реализующие повышенный уровень защиты, но они применяются чрезвычайно редко.) Использование rlogind и Telnet оправдано в небольших локальных сетях, полностью контролируемых системными администраторами. В средах, в которых могут предприниматься попытки взлома систем, особенно в Internet, применять эти серверы не рекомендуется, так как их средства защиты не отвечают современным требованиям. Все три сервера достаточно просты в настройке. Если конфигурация, предложенная по умолчанию, не устраивает вас, вы можете без труда установить нужные параметры, изменяя значения опций. В особенности это относится к серверу SSH, в котором реализовано несколько механизмов аутентификации.