System administration
ITSumma corporate blog
Server Administration
Comments 23
+2
У нас 300 клиентов. Кому-то это «всего», а для нас — это почти 2000 серверов на обслуживании. Чтобы хранить, обновлять и управлять базой из 2000 паролей для 60 сотрудников, управлять доступом к ней и не объяснять каждый раз клиенту, что пароли к его серверам будут одновременно знать 60 человек, мы сделали сервер аутентификации и назвали его Isolate.

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

0
А все очень просто )

Это не сервис аутентификации(в каком то смысле), этим тут занимается ОС (sudo и pam). При желании можно использовать совместно с LDAP ничего сложного под капотом нет. А разворачивать LDAP на 2к серверов разных клиентов и поддерживать довольно сложная задача, на это просто нет времени ( как я понял основной вопрос в этом )

Велосипед к моему приходу был, переделывал его и облагораживал как умел в последствии.

Аналогов не искал, потому что все привыкли к одной схеме и шоткатам, переучить команду довольно сложно))

Так же, в нашей реализации (внутренняя разработка) были сохранены все legacy функции и аргументы, так, чтоб команда не чувствовала дискомфорта.

p.s. если в двух словах, это логгер, точка входа для инженера и менеджер конфигураций ssh
+3
Это не сервис аутентификации(в каком то смысле), этим тут занимается ОС (sudo и pam).

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


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

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


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

+1
Я просто не с той ноги начал)

на 2к серверов которые админили до нас, бывает довольно сложно интегрировать новые схемы аутентификации, а в случае проблем с сетью, мы не сможем войти к клиенту, для нас удобнее механизм публичных ключей ssh на отрезке бастион->сервер клиента — за счет своей простоты. плюс мы никак не удерживаем клиента своими конфигами, обычно достаточно удалить нашего пользователя и агента мониторинга.
+1
при нештатных ситуациях аппаратный ключ сотрудника деактивируется на auth сервере, и он теряет доступ к клиентским серверам (к счастью, у нас таких ситуаций не было);

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

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

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

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

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

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

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

>что после внештатных ситуаций восстанавливает работу сервера?
Мы не храним у себя никаких состояний (кроме мониторинга), вход к клиенту по ключу. Никаких пакетов клиенту ставить нет необходимости.

>Что вы имеете в виду под внештатными ситуациями?

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

Так же важно, в нашем случае, поддерживать некий журнал действий на случай разрешения сложных ситуаций, ошибки со стороны админов бывают, мы не идеальны. Хорошо когда ошибку можно найти сразу или она сразу дала о себе знать, но когда это произошло на прошлой неделе и уже давно выветрилось из памяти, приходится грепать логи, хорошо когда они есть ))
0
Но вы ведь не предоставляете доступ клиенту к Вашему гейту? Логи находятся только у Вас на собственных серверах.

Журнал действий тогда честно было бы иметь и заказчику на своем сервере сислог.
0
Ну это уже можно решить на месте, те частный случай :)

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

ну и вот это упустил,

Это требует вмешательства в ПО клиента, в нашем же случае, логи падают в файл на диске и по опыту, данная связка очень надежна и проста.
0
но таким же образом можно ssh завернуть в функцию для дублирования потока в файл на диске без гейта.
0
По сути это комплекс небольших решений, там если посмотрите так и сделано ) Суть в том, что остается контроль за действиями админа. Тк у него нет полного доступа к приватному ключу.
+1
В чем отличие от готовых открытых решений? например sshkeybox? или vault?

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

Ну и отличия я просто не знаю, я увидел решение и просто собрал, тут из сложностей пожалуй только хранение информации о сервере и данных о прокси если необходим, при этом SUDO выполняет роль «крайнего» что нахожу очень удобным и надежным. Т.к за ним валидация тоже есть.
+1
зато цельный продукт )

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

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

Вариантов реализации не так много. Либо CA сервер либо OTP прокси. Оба варианта кстати реализованны в Vault.
0
У меня не было выбора) Не кастомное решение потребовало бы переучивать коллег ))
0
[~]$ 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 — это байки?

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

Тут это скорее для наглядности.
+1
Смотрели ли рынок на предмет готовых решений? Та же FreeIPA к примеру, почему не подошла?
0
поддерживаются CentOS 7, Ubuntu 16.04, Debian 9.

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

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

0
на ssh серверах в старых версиях, не везде работает

$ ssh -o ProxyCommand=«ssh -W %h:%p firewall.example.org» server2.example.org

https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts

у нас более универсальный вариант с netcat/nc используется
Only those users with full accounts are able to leave comments. , please.