Централизованное управление учетными записями на серверах

Выразите пожалуйста ваши предложения, может использовать LDAP как в AD? Или хрень? Есть еще какие то предложения?

Вы, собственно говоря, сами ответили на свой вопрос ;). LDAP как раз и предназначен для таких вещей. Как вариант, можно и полноценный AD развернуть на базе Samba4, если потом планируется те же учетные записи использовать на машинах с Windows. Ну и просто для полноты картины, NIS+ от Sun. Но это скорее историческую ценность имеет, сейчас неактуально.

Посмотрел несколько продуктов, такие как Samba4, OpenLDAP, FreeIPA, смотрел демки, функционала там слишком много, нет ли чего по проще?

Основная задача, давать пользователям доступ к SSH на сервере и обределенные права для групп и все.

это задача именно для OpenLDAP.

Если есть AD, используй AD. Если есть ldap, используй ldap. Ничего нет, бери freeipa.

Сервера подключать по realmd.

AD нет, это сервера в датацентре. А доступы по SSH нужны разработчикам, надоело скриптом создавать пользователей по отдельности на каждом сервере.

Тогда бери freeipa и не парь мозг. Можешь, конечно, взять голый openldap, но потом тебе захочется керберос аутентификацию, rbac и прочие фишечки freeipa. И ты постепенно превратишь openldap во freeipa на коленке, что, конечно, увлекательно и познавательно, но выйдет криво и бессмысленно.

Тебе не нужен LDAP. Реально, не твой масштаб. Напиши примитивный ansible-playbook и получи результат за пол процента от времени, потребного на возню с LDAP.

Я счас такую хрень велосипежу. :-) Как NIS, только поновее и менее замороченной в настройке. Через полгодика думаю уже будет на что посмотреть, но дедлайн «хоть что-то рабочее» - к началу января.

Если у тебя вся проблема в том, что ты создаешь учетки руками на серверах, то взял бы просто ansible, через него можно удобно рулить учетками на серверах. А по времени написать плейбук и завернуть туда пользователей - 1 час, при условии, что ты даже не видел ансибл никогда.

pssh

Составь формальный план учётных записей и используй какой-нибудь ansible

NIS/YP + kerberos. Заодно и хоумы можно будет по NFS.

Было бы круто потом посмотреть, что вышло ))) Если не забудешь, напиши плиз, СПАСИБО!!!

Перестать править конфиги ручками и ввести репозитарий конфигов/разработки, откуда лить все через оркестрацию. 60 ссш учеток - проходной дом.

С Ansible никогда не работал, но слышал. Не могли бы посоветовать или дать наводку, где с этим можно более подробно разобраться?

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

NIS/YP + kerberos. Заодно и хоумы можно будет по NFS.

Я такую схему (правда, без kerberos) применял в далеком 1999 г. Но советовать NIS в 2017... Сейчас, после появления Samba4, гораздо логичнее строить все на AD. Очень простое управление, гибкие настройки. Плюс в качестве бонуса прозрачная интеграция в сеть Windows-машин.

Заодно и хоумы можно будет по NFS.

Это можно делать при любой схеме авторизации - хоть NIS, хоть LDAP, хоть AD. Другой вопрос, что автору темы это ненужно ;).

А что плохого в kerberized NIS? Уж всяко проще и вменяемее самбы.

Есть ещё некий «облачный» userify.

Уж всяко проще и вменяемее самбы.

И чем же проще? Как минимум, масштабируются любые LDAP-схемы (в том числе Samba) лучше, чем NIS. В частности, в отличие от LDAP, NIS поддерживает только плоские (одноуровневые) конфигурации, нет иерархии поддоменов. Все машины должны иметь одинаковую конфигурацию. Сравните с LDAP, где вы можете для любой машины задать свои собственные параметры. Нагрузка на сеть - копирование NIS-карт на все машины при любом редактировании.

В общем, всерьез обсуждать в 2017(!) году NIS как альтернативу LDAP, IMHO, все равно, что вместо SMTP рассматривать UUCP в качестве основного почтового протокола. Такой же анахронизм...

Не надо про 2017 - сейчас модно сидеть в вконтактике и ничего не знать. В конфигурации ТС даже обычный NIS всё потянет не напрягаясь. А kerberized NIS по гибкости вряд ли уступит LDAP. А рулить LDAP современные мозги не могут - ломаются быстро. А NIS + krb - 5 минут и готово. А с OU и полчими DN пущай kerberos мучается. А наша картинка ровная и красивая.

http://docs.ansible.com/ansible/latest/intro_getting_started.html

дать наводку

https://letsclearitup.com.ua/debian/dobavlenie-uchetnyih-zapisey-s-pomoshhyu-...

внезапно: http://docs.ansible.com/ansible/latest/intro.html

ansible прямой как полено, на уровне «взять описание серверов, групп и пользователей из файла, создать означенных пользователей на тех серверах» можно разобраться за пару часов.

В конфигурации ТС даже обычный NIS всё потянет не напрягаясь.

Согласен, потянет. Правда, только при одном условии - все серверы одинаковы. А если это не так? Если на разные серверы надо разных пользователей пускать? Ну и кто знает, через какое-то время потребуется масштабирование и что дальше? Все сначала переделывать?

А kerberized NIS по гибкости вряд ли уступит LDAP.

И каким же образом kerberos гибкости добавляет? Проблемы защиты, да, решает. Но гибкость-то откуда? Я бы еще понял, если бы Вы про NIS+ писали, хотя и там до LDAP по гибкости далеко.

А рулить LDAP современные мозги не могут - ломаются быстро.

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

По той же Samba, например, отличная документация имеется. Разобраться там с нуля несложно.

Правда, только при одном условии - все серверы одинаковы.

Домены же.

Да и не надо преуменьшать гибкость NIS - стоит таки почитать.

Для централизованного управления доступом по ssh достаточно openldap без всего.

Если смущает ldap сложностью, можно использовать mysql в качестве источника данных о пользователях.

ОК, идея хорошая, но самому писать скрипты и прочее, это простите хрень.

Есть ли какие то уже готовые централизованные, быстро масштабируемые решения?

Домены же.

Домены - это NIS+ ;). В NIS никаких доменов не было.

Да и не надо преуменьшать гибкость NIS - стоит таки почитать.

Я в свое время активно пользовался этой технологией, так что знаю, о чем говорю ;). Просто всему свое время - то, что отлично работало в 90-х годах, сейчас выглядит анахронизмом ;).

Определитесь с целью, потом ищите иструменты.

Инструментов полно, но

функционала там слишком много, нет ли чего по проще?

вас же это не устраивает.

Поэтому ищу такое решение которое упростит задачу в разы.

Именно про это и разговор. Поправить job/playbook в гите или идти и править на сервере...

Заодно и история правок есть, и понятный конечный конфиг сервера. А не сборная солянка, в которой непонятно какие версии какого конфига сейчас находятся.

Поэтому ищу такое решение которое упростит задачу в разы.

Какую задачу, создать пользователей на N серверах?

#!/bin/bash

username=«$1»
password=«$2»
for server in `cat ./server.list`
do
ssh you@$server useradd $1
ssh you@$server passwd $1 $2
done


Нужно еще проще?

Как же в NIS без доменов? Там всё есть. А анахронизмом выглядит потому, что не переусложнённое ушибленное на всю голову asn.1 непотребство.

Как же в NIS без доменов? Там всё есть.

Прошу прощения, неудачно выразился - имел ввиду иерархию поддоменов, как в DNS. Такого в NIS нет. А то, о чем Вы говорите, проблемы не решает - фактически, 2 домена NIS являются полностью изолированными со своими настройками. Т. е. если Вам надо, чтобы 20 пользователей имели доступ на все серверы, а еще по 10 пользователей были бы на каждом сервере уникальными, то средствами NIS Вы эту проблему не решите - уникальных пользователей придется добавлять отдельно на каждый сервер. Я уж не говорю про более сложные конфигурации, когда серверы объединяются в группы.

Нормальная иерархия доменов появилась только в NIS+, но это уже совсем другая история...

А анахронизмом выглядит потому, что не переусложнённое ушибленное на всю голову asn.1 непотребство.

В свое время это было очень продвинутое решение.

//Serge10

Нужно еще проще?

Вы не поняли, имелось в виду проще в использовании, а не проще в написании.

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

Использовать вышеуказанный скрипт для создания пользователей на нескольких серверах предельно просто, проще просто некуда. Но на самом деле это идиотизм, что я и пытаюсь донести до автора.

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

что затраты на внедрять/поддерживать для него минимальные.

По сравнению с чем, по сравнению со скриптом выше? :)

Собственно, я потому и ратую за ansible, что затраты на внедрять/поддерживать для него минимальные.

А чтобы пользователю сменить себе пароль, надо плейбук отредактировать?

По сравнению с чем, по сравнению со скриптом выше? :)

А Вы допишите скрипт до вменяемого состояния, и увидете насколько он разрастётся и сколько с ним возни.

Никто не хранит пароли в текстовом виде. Для этого есть Ansible vault.

FreeIPA уже советовали?

Никто не хранит пароли в текстовом виде.

Пароль, хэш, vault - какая разница? Для того, чтобы сменить пароль пользователю надо обратиться к администратору?

Пароль, хэш, vault - какая разница?

Пароль нельзя хранить в репозитории, а vault — можно.

Для того, чтобы сменить пароль пользователю надо обратиться к администратору?

Да.

В таком случае «затраты на внедрять/поддерживать для него» отнюдь не минимальные. А если пользователей много, то близки к неприемлемым.

А удобство, как пользователей, так и администратора, и близко не сопоставимо с freeipa.

Мы всё ещё обсуждаем вопрос автора о создании/удаленнии пользователей для шести десятков программистов на нескольких серверах или плавно и незаметно перешли к вопросу управления персоналом мегакорпорации с десятком географически распределённых филиалов?

P.S. Уточню, я ни в коем случае не против ldap. Хорошая вещь на своём месте. Но чтобы выгоды от её использования начали превышать затраты от её использования нужно перерасти некоторый предел. Автор, вот, ещё не перерос.

Мы всё ещё обсуждаем вопрос автора о создании/удаленнии пользователей для шести десятков программистов на нескольких серверах

Да. В мегакорпорации управлять учётками ансиблом просто не получится.

60 пользователей уже не так уж мало. Конечно, если они аморфные существа, далёкие от компов и им дали логин/пароль, они его наклеили на монитор и относятся к нему как к неприкасаемому сакральному знанию, то проблем с ансиблом не будет.

Но я так понял, речь идёт о разработчиках. А значит это люди, которым может многое понадобится, включая разграничение доступа, снапшоты серверов, смена паролей и ещё куча всего непредсказуемого. И делать это всё админу руками (ансиблом) не имеет смысла, т.к. в ipa это всё может делаться вообще без участия админа. Мне бы было стыдно предлагать пользователям такое решение.

А главное, что 60 быстро вырастет до 100, а кол-во серверов до небес, и придётся переделывать.

Freeipa разворачивается просто, по-крайней мере, если речь о запросах ТС'а. Управление учётками и серверами тоже ничего сложного не представляет.

ИМХО, лучше сразу брать правильное решение, чем наворачивать костылей.

Но чтобы выгоды от её использования начали превышать затраты от её использования нужно перерасти некоторый предел. Автор, вот, ещё не перерос.

Удобство LDAP проявляется уже на десятке машин и пользователей. Предел, если он и есть, находится на уровне 2-3 компьютеров, IMHO.

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

Полностью согласен с Вами.