У нас около 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, который изначально поддерживается платформой.
Проблема, с которой я сталкиваюсь при повсеместном использовании одного и того же ключа 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.