|
2.10, пох (?), 12:02, 24/06/2016 [^] [^^] [^^^] [ответить] [↓] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +2 +/– |
+1
Первая же мысль при прочтении - "мы почти уже изобрели собственный kerberos, только через задницу, на значительно более сложной и менее надежной openssl'ской базе и отдельный - со всеми вытекающими в виде необходимости поддерживать и обслуживать еще один аутентификационный сервис исключительно для ssh-доступа"
(плюс еще и прокси. Очередной то ли spof, то ли не s, но требующий от пользователя вовремя понять что не так и сделать нетривиальные ручные движения, не как полезная дополнительная возможность, а как идиотское требование)
| |
|
|
|
3.25, www2 (??), 18:07, 24/06/2016 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> pam_ldap - это наоборот для джыдаев, у которых всегда-всегда доступна связь со
> ldap'ом
RADIUS и TACACS никто не боится использовать, а чем LDAP хуже? Или RADIUS и TACACS в тех же условиях будет доступен, а LDAP - нет?
Когда нет связи с LDAP'ом, нужно чинить в первую очередь связь и LDAP. По-моему, это очевидно.
| |
|
|
1.16, Аноним (-), 13:10, 24/06/2016 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +2 +/– |
> Помимо проверки сертификата при каждом входе обязательно применяется двухфакторная аутентификация, требующая подтвердить намерение входа альтернативным путём.
> Не допускается прямое обращение к конечным узлам, для доступа требуется подключение только через специальный прокси.
> Поддержка функций аудита и повторения типовых операций - содержимое SSH-сеансов может записываться и при необходимости воспроизводиться на других хостах;
> Режим совместного решения проблем, при котором несколько человек могут совместно использовать один сеанс SSH;
> Поддержка блокировки доступа после нескольких неудачных попыток входа;
Неплохо, все требования PCI DSS из коробки.
| |
1.21, Sampan (ok), 16:49, 24/06/2016 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +2 +/– |
Полностью согласен, что ребята изобретают велосипед под названием "Kerberos".
Но, кажется, они не совсем идиоты. Ключевые слова: "требующая подтвердить намерение входа альтернативным путём (поддерживается Google Apps ..."
Мало Google про меня знает. Ему еще надо все мои аккаунты на кластерах! Уже не достаточно того, что на каждых 4-х из 5-ти топ сайтов (и в рунете тоже!) используются скрипты из googleapis.com, googletagservices.com, googletagmanager.com, googleadservices.com, googlesyndication.com, google-analytics.com, им еще нужно в мою постель залезть.
Вывод: этот Teleport - фтопку. А по списку google*\.com - Privoxy нам в помощь!
| |
1.30, XoRe (ok), 11:05, 25/06/2016 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +6 +/– |
Похоже кто-то превратил дипломную в коммерческий проект.
> двухфакторная аутентификация, требующая подтвердить намерение входа с другого устройства
> (поддерживается Google Apps и клиенты OAuth2).
Авторизация на внутренних серверах с помощью сервисов гугла - это вообще песня.
А если на узлах закрыт доступ в интернет?
> Вместо применяемой в OpenSSH аутентификации по ключам, чтобы избежать необходимости копирования ключа каждого пользователя на узлы
Т.е. про ssh agent они не слышали.
> - Поддержка обратного туннелирования для подключения к кластерам, ограждённым межсетевым экраном;
Про встроенное в ssh туннелирование они, походу, тоже не в курсе.
> - Возможность определения меток для разделения доступа к разным узлам кластера;
Как и про sshd.conf
> - Поддержка блокировки доступа после нескольких неудачных попыток входа;
Как и про настройки pam.
> - Узлы подключаются к кластеру через определение статичестких или генерацию динамических токенов, которые при желании можно отозвать для запрета входа на данный узел;
Как и про настройку ssh через pupper/chef/salt/...
> - Успешно пройден аудит безопасности кода, заказанный в независимой проверяющей компании;
Ну, есть и позитивные моменты.
| |
|