как вы управляете корневыми паролями серверов

Question

В нашей команде администрирования у каждого есть корневые пароли для всех клиентских серверов. Но что нам делать, если один из членов команды больше не работает с нами? У него все еще есть наши пароли, и мы должны изменить их все, каждый раз, когда кто-то покидает нас.

Теперь мы используем ключи ssh вместо паролей, но это бесполезно, если нам нужно использовать что-то отличное от ssh.

Answer 1

Системы, которые я использую, имеют политику sudo . то есть пароль root * (отключен), и люди должны использовать sudo для получения root-доступа. Затем вы можете отредактировать файл sudoers, чтобы предоставить / отменить доступ людей. Он очень детализирован, имеет много настроек, но имеет разумные значения по умолчанию, поэтому настройка займет у вас совсем немного времени.

Answer 2

Обычно я бы предложил следующее:

1. Используйте пустой пароль root.
2. Отключить телнет
3. Установить ssh для no-root-login (или для root-входа только с открытым ключом)
4. Отключите su для root, добавив его в начало / etc / suauth: 'root: ALL: DENY'
5. Включить безопасный tty для root-входа только на консоли (tty1-tty8)
6. Использовать sudo для обычного корневого доступа

Теперь, с этим параметром, все пользователи должны использовать sudo для удаленного администрирования, но когда система серьезно испорчена, охоты нет пароль root для разблокировки консоли.

РЕДАКТИРОВАТЬ: другие инструменты системного администрирования, которые предоставляют свои собственные логины, также должны быть отрегулированы.

Answer 3

Хотя рекомендуется использовать политику только для sudo, как предложил Крис, в зависимости от размера вашей системы, подход ldap также может быть полезен. Мы дополняем это файлом, который содержит все корневые пароли, но корневые пароли действительно длинные и не запоминающиеся. Хотя это может считаться недостатком безопасности, оно позволяет нам продолжать вход в систему, если сервер ldap не работает.

Answer 4

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

Answer 5

Достаточно сильный пароль пользователя root. Разные на каждой коробке. Нет удаленных учетных записей root и паролей для входа, только ключи.

Answer 6

В общем, если кто-то покидает нашу команду, мы не беспокоимся о смене корневых паролей. Либо они покинули компанию (и больше не имеют доступа к машинам, поскольку их VPN была аннулирована, как и их значок доступа к зданию, а также беспроводной доступ к сети), либо они находятся в другом отделе внутри компании. и обладаем профессионализмом, чтобы не связываться с окружающей средой.

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

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

Answer 7

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

Answer 8

SSH-ключи не имеют реальной альтернативы.

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

Иначе цикл for в bash или какое-либо действие clush будет достаточным.

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

Запустить службу кластеризованную. Не делайте хаков с учетной записью super-duper-service backdoor, чтобы всегда иметь доступ в случае, если что-то сломается (например, доступ администратора нарушен из-за неправильной конфигурации). Независимо от того, насколько вы контролируете доступ или изменения конфигурации, влияющие на эту учетную запись, это «просто плохо» (TM).

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

В общем : если вы используете программное обеспечение, не пригодное для использования с какой-либо интеграцией с Active Directory или LDAP, вы должны перепрыгнуть акулу и изменить пароли для них вручную.

Также очень приятна выделенная база данных для управления паролями, к которой могут обращаться только немногие избранные напрямую, и которая доступна только для чтения всем остальным. Не беспокойтесь о файлах Excel, им не хватает надлежащего управления правами. Работа с контролем версий в файлах .csv на самом деле не сокращает его даже после определенного порога.

Answer 9

Мы используем политику sudo only, где я работаю, но пароли root по-прежнему сохраняются. Пароли root доступны только избранным сотрудникам. У нас есть программа Password Manager Pro, которая хранит все наши пароли, а также может выполнять аудит паролей. Это позволяет нам вернуться назад и посмотреть, какие пароли были доступны для каких пользователей. Таким образом, мы можем изменять только те пароли, которые действительно должны быть изменены.

Answer 10

Если у вас есть доступ по ssh через ваши сертификаты, вы не можете войти через ssh и изменить пароль root с помощью passwd или sudo passwd, когда вам нужно сделать что-то еще, требующее пароль?