Enjoy! Сервер аутентификации Isolate в Open Source

[apro]

У нас 300 клиентов. Кому-то это «всего», а для нас — это почти 2000 серверов на обслуживании. Чтобы хранить, обновлять и управлять базой из 2000 паролей для 60 сотрудников, управлять доступом к ней и не объяснять каждый раз клиенту, что пароли к его серверам будут одновременно знать 60 человек, мы сделали сервер аутентификации и назвали его Isolate.

А можете пояснить в чём отличие от основанных на LDAP решениях, и почему приняли решение писать еще один сервис для аутентификации?

[apro]

Это не сервис аутентификации(в каком то смысле), этим тут занимается ОС (sudo и pam).

Хм.., вообще-то с ldap авторизация тоже возможна через pam и sudo

А разворачивать LDAP на 2к серверов разных клиентов

А зачем? ldap серверов конечно может быть (и нужно для отказоустойчивости) больше
одного, но зачем каждому, на всех 2000 серверах могут быть только клиенты
и нужно залить только конфиг. Причем клиенты штатные pam_ldap я думаю в каждый дистрибутив входит.

Но в общем вы ответили на мой вопрос, спасибо.

[XakRU]

при нештатных ситуациях аппаратный ключ сотрудника деактивируется на auth сервере, и он теряет доступ к клиентским серверам (к счастью, у нас таких ситуаций не было);

Как обстоят дела при потери сетевой связанности с сервером авторизации?
Кто после внештатных ситуаций восстанавливает работу сервера?
Что вы имеете в виду под внештатными ситуациями?

все SSH-сессии записываются — можно считать время, проведенное на серверах.

Централизованный сервер SYSLOG для сбора логов — решает эту задачу на отлично. Можно расширить функционал средствами audit, snoopy, grsec.

Чем плох вариант установки ключей пользователя на удаленной системе если управление уже осуществляется средствами ansible?
Ведь также средствами ansible можно управлять пользователями и их ключами.
Зачем знать рутовый пароль на сервере? SUDO — отметает необходимость знать рутовый пароль.

Закрытые ключи пользователей необходимо шифровать на локальных

Централизованная система аутентификации для linux не нова, Identity Management например.
Выпускать это в интернет — сомнительное предприятие, разве что в сегменте изолированной сети.

[XakRU]

Т.е. Вы написали гейт для себя, но слабо описано его применение и области где бы это было удобно, почему удобно, с чем сравнивать, какие альтернативы?
Ну не страшно если нуоутбук украли, закрытый ключ ведь зашифрован. Или у Вас нет практики шифрования закрытого ключа?

[XakRU]

Но вы ведь не предоставляете доступ клиенту к Вашему гейту? Логи находятся только у Вас на собственных серверах.

Журнал действий тогда честно было бы иметь и заказчику на своем сервере сислог.

[XakRU]

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

[LuckyRaul]

В чем отличие от готовых открытых решений? например sshkeybox? или vault?

Еще смотря видео и презентации думал увидеть какой-то продукт цельный, а тут оказался набор скриптов (рыбка на ножках очень в тему )

[LuckyRaul]

зато цельный продукт )

вот еще
https://github.com/aker-gateway/Aker
https://github.com/iamacarpet/ssh-bastion

другой подход на SSH CA
https://github.com/Netflix/bless

Вариантов реализации не так много. Либо CA сервер либо OTP прокси. Оба варианта кстати реализованны в Vault.

[grossws]

[~]$ g myproject aws-dev
Warning: Permanently added 3.3.3.100 (RSA) to the list of known hosts.
Warning: Permanently added 10.10.10.12 (RSA) to the list of known hosts.

Очень насторожило. Ваш гейт доверяет всем серверам без вопросов и и считает, что MItM — это байки?

[DuD]

Смотрели ли рынок на предмет готовых решений? Та же FreeIPA к примеру, почему не подошла?

[diafour]

поддерживаются CentOS 7, Ubuntu 16.04, Debian 9.

Также можно использовать функцию проброса порта в современных SSHD/SSH, но эта методика не рекомендуется, так как еще довольно много устаревших SSHD, которые не поддерживают эту функцию.

Непонятно. Можно подробнее про неподдерживаемый проброс порта?