Назад | Перейти на главную страницу

Управление ключами SSH

У нас около 2500 серверов Linux. У нас есть сервер Jumpstart, с которого мы можем подключиться по SSH к любому серверу для выполнения задач, связанных с системным администратором. Мы развернули единый закрытый ключ и развернули соответствующий открытый ключ на всех серверах, но это огромная угроза безопасности.

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

FreeIPA очень хорошо управляет ключами SSH. Я успешно использую его дома, но многие компании используют его в производственной среде (список рассылки freeipa-users гиперактивен). Это исходный проект бесплатного программного обеспечения, на котором основано решение Red Hat Identity Management. Разработчики Red Hat также модерируют и помогают в списке рассылки freeipa-users.

По сути, это служба, подобная Active Directory, для сред Unix / Linux. Он также может синхронизироваться с AD. Он имеет встроенные функции * nix, такие как автоматическое монтирование NFS, централизованные политики sudo и т. Д.

Каждый пользователь может добавить свой SSH-ключ в свой профиль FreeIPA. Затем sshd можно настроить для использования AuthorizedKeysCommand, предоставляемого пакетом sssd, который будет настроен для запроса сервера FreeIPA. В сочетании с политиками sudo вы получаете повышение привилегий и аудит (кто sudo'ed).

Поскольку это проект RedHat, это однострочный процесс для установки на Fedora или CentOS, но я успешно установил и настроил блоки debian в качестве клиентов FreeIPA. Я устанавливаю сервер аутентификации на Fedora Server, который изначально поддерживается платформой.

http://www.freeipa.org/page/Main_Page

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

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

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

Помимо обеспечения подотчетности, у вас также есть возможность определять детализированные политики управления доступом на основе ролей (RBAC).

Для 2500 хостов у вас уже может быть система управления конфигурацией, но вы можете использовать SaltStack если нет. У нас есть это для root auth:

user1auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user1

user2auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user2

Вам не нужно иметь закрытый ключ на хосте перехода. Просто используйте переадресацию агента при входе в систему: ssh -A root@host.

Есть и другие системы (например, Pupet, cfengine).

Большинство структур безопасности (например, HIPAA, PCI и т. Д.) Требуют одного ключа на человека-пользователя. Пользователи должны никогда делятся ключами не чаще, чем паролями.

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

Я работаю в Userify, который управляет ключами для вас в ваших командах и на всех ваших серверах и может даже взаимодействовать с Active Directory (Userify Enterprise), но есть и другие варианты, например SSH Universal Key Manager.

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

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

Важно иметь возможность централизованно управлять своими разрешениями SSH, децентрализовав при этом фактическую работу для большей надежности и контроля.

См. Также эту тему Slant: https://www.slant.co/topics/8010/~managers-for-ssh-keys

Копирование открытого ключа на все серверы, на которые вы входите, обычно происходит при использовании SSH. Если то, что вы сделали, это создать частную / открытую пару ключей на сервере jumpstart и скопировать общественный ключ к ~/.ssh/authorized_keys файл на хосте, на который вы хотите установить ssh, тогда это (частично) приемлемый способ защиты удаленного входа через ssh. Другие вещи, которые следует учитывать для дальнейшей безопасности ssh:

  • изменение /etc/ssh/sshd_config и установить PasswordAuthentication No и PubkeyAuthentication yes
  • изменение LogLevel в /etc/ssh/sshd_config к VERBOSE а затем контролировать /var/log/auth.log на наличие аномалий.
  • редактировать /etc/security/access.conf разрешить авторизацию пользователя только с определенного IP
  • редактировать /etc/pam.d/login и установить account required pam_access.so чтобы включить изменения, которые вы внесли в access.conf

Развертывание «разных ключей для каждого сервера» означает, что вам нужен другой общественный ключ в ~/.ssh/authorized_keys на каждом сервере. Причина этого мне неясна, но если нужно, я бы создал текстовый файл на сервере Jumpstart с хостом в каждой строке. Использовать for цикл для анализа файла и запуска ssh-keygen -f $line_from_file чтобы создать пару ключей для каждого хоста. Вы также можете использовать тот же for цикл для ssh на каждом хосте и добавьте pubkey в ~/.ssh/authorized_keys с помощью sed -i или что-то.

Попробуйте Бастильон - https://www.bastillion.io/

Простая установка, пользователи управляют своими собственными ключами SSH на основе профилей, которые им были назначены.

https://www.bastillion.io/docs/using/keymanagement/

(Раскрытие информации: это продукт, который я разработал. Он имеет открытый исходный код и бесплатный для использования в рамках AGPL, или вы можете купить коммерческую лицензию)

Если у вас нет бюджетных ограничений, выбирайте собственное решение, такое как Dell TPAM или Cyberark (мне не нравится ни одно из них)

В противном случае вы можете использовать один SSH-ключ для каждого пользователя с ssh-agent или gpg-agent.