Компания IBM
Опубликован: 01.02.2008 | Доступ: свободный | Студентов: 540 / 20 | Оценка: 4.60 / 4.40 | Длительность: 43:55:00
Специальности: Разработчик аппаратуры
Лекция 9:

Безопасность кластера

Устранение неполадок аутентификации и шифрования сообщений

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

  1. Перейдите в SMIT HACMP Cluster Security (Безопасность кластера HACMP): выполните smit cm_config_security.
  2. Выберите Configure Message Authentication Mode and Key Management (Конфигурирование режима аутентификации сообщений и управления ключами).
  3. Выберите Configure Message Authentication Mode (Конфигурирование режима аутентификации сообщений).
  4. В разделе Message Authentication Mode (Режим аутентификации сообщений) выберите None.
  5. Установите в поле Enable Encryption (Включить шифрование) значение No (Нет).
  6. Нажмите Enter.
  7. Выполните синхронизацию кластера.

Проверка текущих параметров аутентификации сообщений

Текущие параметры аутентификации и шифрования сообщений можно проверить следующим образом:

  1. Запустите smit hacmp.
  2. Выберите Extended Configuration (Расширенное конфигурирование).
  3. Выберите Extended Topology Configuration (Расширенное конфигурирование топологии).
    Проверка параметров аутентификации сообщений

    Рис. 9.4. Проверка параметров аутентификации сообщений
  4. Выберите Show HACMP Topology (Отображение топологии HACMP).
  5. Выберите Show Cluster Definition (Отображение определения кластера). Нажмите Enter для вывода параметров определения кластера (рис. 9.4).

Защищенное удаленное выполнение команд в HACMP

Примечание. Хотя использование Secure Shell (SSH) в кластере HACMP не является обязательным, этот метод защиты удаленного выполнения команд является очень популярным в современных сетевых средах.

Скрипты запуска и остановки приложений, настраиваемые скрипты обработки событий и прочие скрипты могут требовать выполнения команд на удаленных узлах. Для этой цели все еще можно использовать rsh, однако это небезопасно, так как при этом аутентификация основана на файле .rhosts. Мы настоятельно рекомендуем использовать Secure Shell (SSH). Кроме того, функционирование DLPAR также требует применения SSH.

SSH и Secure Socket Layer (SSL) совместно обеспечивают аутентификацию, конфиденциальность и целостность данных. Аутентификация SSH основана на инфраструктуре открытых-закрытых ключей1Более распространен термин "Public Key Infrastructure, PKI" (инфраструктура открытых ключей), наличие закрытого (private) ключа подразумевается. , тогда как SSL осуществляет шифрование сетевого трафика.

SSH содержит следующие утилиты, заменяющие классические r-команды:

ssh защищенная удаленная оболочка, подобная rsh или rlogin;
scp защищенное удаленное копирование, подобное rcp;
sftp утилита зашифрованной передачи файлов, подобная ftp.

Установка SSH

Весьма удобно, что IBM поставляет SSH и все его компоненты вместе с AIX. Ниже приведен список требуемых компонентов.

rpm.rte поддержка rpm-пакетов; автоматически устанавливается вместе с базовым программным обеспечением AIX.
perl автоматически устанавливается вместе с базовым программным обеспечением AIX.
openssl.rpm поддержка Open Source Secure Socket Layer (AIX Toolbox for Linux Applications CD).
openssh.base.client команды клиента Open Source Secure Shell (AIX Expansion Pack).
openssh.base.server сервер Open Source Secure Shell (AIX Expansion Pack).
openssh.msg.* каталог сообщений для SSH (AIX Expansion Pack).
openssh.man.* документация (man pages) для Secure Shell (AIX Expansion Pack).
openssh.license оpen Source License для SSH (AIX Expansion Pack).
prngd.rpm генератор случайных чисел, необходимый только в AIX 5.1 и 5.2. (AIX Toolbox for Linux Applications CD).

Другой вариант состоит в том, чтобы скопировать наиболее актуальные пакеты из Интернета:

  • OpenSSL с сайта IBM AIX Toolbox for Linux Applications (требует процедуры регистрации продолжительностью в несколько минут): http://www6.software.ibm.com/dl/aixtbx/aixtbx-p
  • OpenSSH для AIX: http://www.sourceforge.net/projects/openssh-aix В нашем тесте мы использовали openssl-0.9.6m-1 и openssh.3.8.0.53. Установка состоит из следующих этапов:
    1. Убедитесь в том, что установлен rpm.rte: lslpp -l rpm.rte.
    2. Убедитесь в том, что установлен Perl: lslpp -l perl.rte.
    3. При использовании AIX 5.1 или 5.2 следует установить Prngd с диска AIX Toolbox for Linux Applications CD через SMIT.
    4. Установите OpenSSL. Можно применять smit install_latest для его установки с диска AIX Toolbox for Linux Applications CD. В противном случае следует использовать команду rpm:
      rpm -i openssl-0.9.6m-1.aix5.1.ppc.rpm
    5. Используйте smit install_latest для установки openssh.base, файла лицензии и соответствующих языковых наборов файлов.
    6. Запустите демон SSH: startsrc -s sshd.

Настройка SSH для удаленного выполнения команд без пароля

Некоторые скрипты могут требовать использования SSH и SCP в конфигурации без применения паролей. В этом случае SSH использует пары открытых и закрытых ключей для аутентификации. Закрытый ключ хранится на локальном хосте, тогда как открытый ключ пересылается на удаленные узлы и добавляются в их базу данных авторизованных ключей.

При выполнении команды SSH (например, ssh node2 date ) коммуникация подписывается с использованием закрытого или секретного ключа узла-источника. Эту подпись можно дешифровать только с применением открытого ключа узла-источника. Если узел-получатель может успешно дешифровать подпись, это подтверждает подлинность узла-отправителя.

Для настройки удаленного выполнения команд через SSH без паролей следует выполнить следующие действия на всех узлах кластера:

  1. Выполнить вход в систему под требуемой учетной записью.
  2. Сгенерировать пару ключей аутентификации:
    ssh-keygen -t rsa -f ~/.ssh/node1
    Нажмите Enter для ввода пароля-фразы из нескольких слов. Эта команда генерирует два файла:
    • ~/.ssh/node1: файл секретного ключа;
    • ~/.ssh/node1.pub: файл открытого ключа.
  3. Переименуйте файл секретного ключа, назначив ему имя identity:
    mv ~/.ssh/node1 ~/.ssh/identity
  4. Добавьте открытый ключ в файл authorized_keys на локальном узле, чтобы SSH мог работать на локальном хосте ( localhost ):
    cat ~/.ssh/node1.pub >> ~/.ssh/authorized_keys
  5. Скопируйте свой открытый ключ на все остальные узлы:
    scp ~/.ssh/node1.pub nodeX:~/.ssh/node1.pub
    Повторите эту команду для каждого узла в кластере.
  6. Добавьте открытый ключ узла node1 в файл authorized_keys на удаленных узлах:
    ssh nodeX "cat ~/.ssh/node1.pub >> ~/.ssh/authorized_keys"
    Повторите эту команду для всех узлов в кластере.
  7. Повторите действия пп. 1–6 на всех узлах.

Теперь SSH должен работать на всех узлах не запрашивая пароль.

Важно! Будьте осторожны с файлами закрытого и открытого ключа: это ключи к вашей системе. Если какой-либо неавторизованный пользователь получит файлы, он сможет подключиться к вашей системе.

Дополнительные сведения об OpenSSL и OpenSSH можно найти в Интернете:

Динар Валеев
Динар Валеев
Россия
Lichodedov Andrej
Lichodedov Andrej
Литва