The OpenNET Project
 
Поиск (ключи):    ПРОГРАММЫ СТАТЬИ СОВЕТЫ ФОРУМ
  WIKI НОВОСТИ (+) MAN'ы ДОКУМЕНТАЦИЯ

Аутентификация на SSH сервере с использованием ключей (ssh auth pam)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: ssh, auth, pam,  (найти похожие документы)
From: Михаил Сгибнев <mixa(@).dreamcatcher.ru> Date: 2006-09-13 16:35:46 Subject: Аутентификация на SSH сервере с использованием ключей
by Brian Hatch

Перевод: Сгибнев Михаил

OpenSSH кроме паролей поддерживает еще несколько методов аутентификации. Он может быть сконфигурирован на использование методов PAM (Pluggable authentication modules), протокола Challenge/Response, Kerberos, аутентификации по доверенным хостам и такая экзотика как ключи X509. Но самым популярным является метод Identity/Pubkey.

Целью использования идентификации Identity/Pubkey является исключение использования статических паролей. Вместо того, чтобы каждый раз набирать пароли, которые могут быть перехвачены кейлоггером или просто подсмотрены, у нас на диске имеется пара ключей, которые и используются для проверки подлинности. Ваша учетная запись на сервере SSH имеет список Identities/Pubkeys, которому можно доверять и если Вы сможете доказать, что у вас есть и публичный и приватный ключ, то доступ будет предоставлен без запроса пароля.

Вот некоторые из положительных моментов этого типа аутентификации: В этой статье мы рассмотрим методу создания ключей и конфигурирование учетной записи.

Создание Identity/Pubkey

В оригинальной реализации SSHv1 Вы могли создать Identity, которое было парой RSA публичного и приватного ключей. В SSHv2 формат этих ключей был изменен, стали поддерживаться ключи RSA и DSA, и эта аутентификация была переименована в Pubkey. В контексте данной статьи эти обозначения будут использоваться взаимозаменяемо, так как реализуют идентичные функции.

С помощью утилиты ssh-keygen создадим необходимые ключи: Обратите внимание, что 'ssh-rsa...xahria@mydesktop' это одна строка, а не несколько.

Как Вы могли убедиться, ssh-keygen создал два файла: id_rsa и id_rsa.pub. В первом файле хранится приватный ключ, защищенный кодовой фразой, введенной Вами при создании, НИКОМУ не давайте копаться в этом файле. Второй файл - Ваш публичный ключ, он не содержит никаких тайн и может быть доступен любому встречному-поперечному. В случае утраты он может быть восстановлен из приватного ключа.

Типы ключей SSH

При создании ключей Вы указывали опцию -t rsa. Этим параметром мы указываем тип создаваемых ключей. Также возможно создать ключи rsa1, rsa или dsa. Рассмотрим их отличия:

Тип
Аргумент
Имя по умолчанию
Протокол
Пример заголовка
RSA1
-t rsa1
identity
SSH 1 protocol only
1024 35 118118225938285...
RSA
-t rsa
id_rsa
SSH 2 protocol only
ssh-dss AAAAB3nzaC1kc3M...
DSA
-t dsa
id_dsa
SSH 2 protocol only
ssh-rsa AAAAB3NzaC1yc2E...


Вы можете изменить имя файла с помощью опции -f filename. Если Вы не определили имя файла, то ключи будут записаны в каталог $HOME/.ssh/ с именем, принятым по умолчанию для данного типа ключа.

Разрешение Identity/Pubkey аутентификации на сервере

После того, как мы создали ключи, необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации - Pubkey или Identity, установив следующие настройки в sshd_config: Приведенные выше значения разрешают аутентификацию Identity/Pubkey для протокола SSH версии 1 и 2, и проверяют наличие публичных ключей в файле $HOME/.ssh/authorized_keys.

Проверьте наличие этих строк в файле конфигурации sshd_config (обычно он находится в каталоге /etc/ssh/), при необходимости добавьте и перезапустите сервис.

Содержимое файла authorized_keys

Файл authorized_keys просто содержит список ключей, по одному в строке. В него мы и пропишем ключ, сгенерированный нами на своей машине. Прядок действий следующий: копируем публичный ключ RSA на сервер, используя scp или любой другой способ. Создаем файл authorized_keys, если каталога .ssh не существует - создаем. Добавляем публичный ключ RSA в файл authorized_keys. Проверяем, устанавливаем права доступа и выходим.

Пришла пора проверить. что мы наваяли: Ваш SSH клиент будет сначала пробовать пройти аутентификацию по Pubkey/Identity, в случае неудачи - идентификацию по паролю. Он будет искать три имени файлов, заданных по умолчанию, если Вы не указали айл ключа явно и передаст его серверу.

Рассмотрим процесс подключения по разделениям: Все это проходит незаметно для пользователя. Если Вы хотите наблюдать за фазами соединения, то используйте ключ -v: Для наглядности, в этом примере мы вводим неправильное кодовое слово для дешифровки приватного ключа. Также Вы можете заметить, что были найдены файлы identity и id_rsa, хотя они могут использоваться только с SSHv2.

Выбор ключей

Если Вы имеете один ключ для каждого типа, то вы можете использовать стандартные имена файлов и ssh-клиент самостоятельно найдет их и использует, но может так случиться, что Вы используете для аутентификации разные файлы: Определить используемый ключ можно с помощью опции -i private_key_file: Следущая опция создаст в Вашем ~/.ssh/config указание на отображение еспользуемого ключа: Обратите внимание, что переменная config всегда равна IdentityFile, независимо от того, используется Pubkey или Identity.

Безопасность кодовой фразы

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

authorized_keys2

Старые версии OpenSSH использовали два различных публичных ключа для доступа к серверу - authorized_keys для Identities (SSHv1) и authorized_keys2 для Pubkeys (SSHv2). Позже было решено, что это глупо и теперь используется один файл для ключей всех типов, но при отсутствии подходящего ключа будет проверен и authorized_keys2. Более поздние версии OpenSSH могут вполне прекратить поддерживать authorized_keys2 вовсе.

Чтобы не думать об этом ограничении, создадим жесткую ссылку authorized_keys2 на файл authorized_keys. Так мы удовлетворим потребности любой версии OpenSSH.

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ RSS ]
 
  • 1, gentoid, 15:45, 30/05/2009 [ответить] [смотреть все]
  • +/
    Просто и понятно.
     
  • 2, debianid, 14:50, 10/01/2010 [ответить] [смотреть все]
  • +/
    Спасибо!
     
  • 3, sorron, 22:37, 17/05/2010 [ответить] [смотреть все]
  • +/
    В первой таблице неправильно проставлены два последних примера заголовка
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



    Закажите подписки на Mandriva Enterprise Server 5 и Mandriva 2010 Powerpack

    Подписки на Mandriva Enterprise Server 5 и Mandriva 2010 Powerpack включают получение обновлений и технической поддержки.

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

    Mandriva Enterprise Server 5 (MES 5) - это надежный и производительный дистрибутив GNU/Linux для корпоративного сервера. В MES 5 интегрированы серверные разработки программистов Mandriva, а также ведущие свободные серверные приложения, которые помогут настроить и поддерживать необходимые вам серверы.

    Mandriva 2010 Powerpack - это идеальный вариант для перехода на Linux новых пользователей в офисе и дома. В то же время, Mandriva 2010 Powerpack полностью удовлетворяет запросы опытных пользователей и администраторов.

    Более подробно познакомиться с подписками вы можете здесь: http://www.linuxcenter.ru/shop/licence/mandriva/


      Закладки на сайте
      Проследить за страницей
    Created 1996-2010 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    RUNNet TopList