On Wed, Jun 23, 2010 at 03:50:09AM +0400, Evgeny Sinelnikov wrote:
> Что-то как-то порвалось сообщение.
> 
> 23 июня 2010 г. 3:32 пользователь Evgeny Sinelnikov <sin@altlinux.ru> написал:
> > 23 июня 2010 г. 3:08 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> >> On Wed, Jun 23, 2010 at 01:53:00AM +0300, Michael Shigorin wrote:
> >>> On Wed, Jun 23, 2010 at 01:44:00AM +0400, Dmitry V. Levin wrote:
> >>> > В Сизиф отправляется openssh-server-5.3p1-alt2, в котором по
> >>> > умолчанию аутентификация по паролю будет выключена для членов
> >>> > группы wheel.
> >>>
> >>> При обновлении умолчание изменится по сравнению с предыдущим,
> >>> если /etc/openssh/sshd_config не трогался?
> >>
> >> Да, конечно.
> >>
> >>> > Подробнее об этом см.
> >>> > https://bugzilla.altlinux.org/show_bug.cgi?id=17286
> >>>
> >>> По-моему, идея никуда не годится в качестве умолчания, которое
> >>> может самопроизвольно поменяться при обновлении дистрибутива
> >>> с потенциальным DoS.
> >>
> >> Я не верю, что кто-то ещё сознательно использует PasswordAuthentication,
> >> но на всякий случай я это изменение анонсировал.
> >>
> >> Лично я PasswordAuthentication на сервере использую исключительно тогда,
> >> когда мне нужно протестировать этот режим работы при подготовке новой
> >> версии openssh.
> >>
> >>> Как недефолтный вариант для control, в идеале связанный с control
> >>> sudo wheelonly а-ля slave alternatives -- да, было бы хорошо
> >>> и сам бы пользовался.
> >>>
> >>> Прошу ещё раз подумать.
> >>
> >> Я вообще собирался выключить PasswordAuthentication по умолчанию, и,
> >> если бы не наткнулся на компромиссный вариант, описанный в #17286,
> >> то так бы и сделал.
> >>
> 
> У не членов группы wheel тоже немало возможностей сделать плохо. Тем
> более, что пароли у таких "не рулящих" пользователей могут быть
> неудачно потерянными или даже плохими с большей степенью вероятности,
> чем у "рулящих". Как пример неудачной практики, имею опыт получения
> бота и усасывющего помегабайтный трафик с пятницы по вторник.
> 
> Ну, так что по поводу группы remote и политики "кому можно" думается?
> 
> Я думаю, что стоит добавить:
> а) политику "кому можно" по группе, например remote;
> б) политику по качеству пароля на auth.
> 
> Как сделать б) я пока не знаю (не пробовал достаточно активно, чтобы
> получилось), но тоже очень бы хотел.
> 
> Группа remote покрывает больше рабочих сценариев, чем просто "по
> ключам". Мало ли у кого ключи лежат, по старой памяти...
> 
> Я вижу такие сценарии:
> 1) Новый.
> - члены группы wheel "ходят" только по ключам;
> - остальные, как хотят.

Это ровно то, что реализовано в openssh-server-5.3p1-alt2.

> 2) Мой текущий.
> - "ходят" только члены группы remote;
> - остальные "не ходят".

Это просто AllowGroups remote.

> 3) Гибридный первый.
> - "ходят" только члены группы remote;
> - члены группы wheel "ходят" только по ключам и только, если они в
> группе remote;
> - остальные "не ходят".

Это просто AllowGroups remote в сочетании с реализованным в
openssh-server-5.3p1-alt2 отключением PasswordAuthentication для членов
группы wheel.

> 4) Гибридный второй.
> - "ходят" только члены группы remote и группы wheel, но последние
> только по ключам;
> - остальные "не ходят".

Это просто AllowGroups remote wheel в сочетании с реализованным в
openssh-server-5.3p1-alt2...

Собственно говоря, вы предлагаете по умолчанию сделать ещё и
AllowGroups имена_групп_в_которые_будут_входить_те_кого_можно_пускать?

Будет непросто придумать имена таких групп, которые бы устроили всех
заинтересованных.


-- 
ldv