[sisyphus] I: openssh-server-5.3p1-alt2: disabled PasswordAuthentication for "wheel" group members

[Evgeny Sinelnikov]

Что-то как-то порвалось сообщение.

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 "ходят" только по ключам;
- остальные, как хотят.
2) Мой текущий.
- "ходят" только члены группы remote;
- остальные "не ходят".
3) Гибридный первый.
- "ходят" только члены группы remote;
- члены группы wheel "ходят" только по ключам и только, если они в
группе remote;
- остальные "не ходят".
4) Гибридный второй.
- "ходят" только члены группы remote и группы wheel, но последние
только по ключам;
- остальные "не ходят".

Отвечаю сразу и на второе письмо:

23 июня 2010 г. 3:18 пользователь Dmitry V. Levin <ldv на altlinux.org> написал:
> On Wed, Jun 23, 2010 at 02:51:50AM +0400, Evgeny Sinelnikov wrote:
>> 23 июня 2010 г. 1:44 пользователь Dmitry V. Levin <ldv на altlinux.org> написал:
>> >
>> > В Сизиф отправляется openssh-server-5.3p1-alt2, в котором по умолчанию
>> > аутентификация по паролю будет выключена для членов группы wheel.
>> >
>> > Подробнее об этом см. https://bugzilla.altlinux.org/show_bug.cgi?id=17286
>>
>> А можно ли добавить в политики по умолчанию, для openssh, обратную
>> группу? Группу тех, кого пускают.
>
> Кого пускают, или у кого пароль спрашивают?

Кого не пускают кроме...
Сценарий 2.

> Для первого, вообще говоря, существует AllowUsers/AllowGroups.

Так по-лучше, но могут ли эти опции пускать только из этих групп, а
других не пускать?
 AllowGroupsOnly ?

> Суть анонсированного изменения в усилении действующей по умолчанию защиты
> "PermitRootLogin without-password": в дополнении к отключению возможности
> удалённого подбора пароля рута теперь отключается возможность удалённого
> подбора паролей пользователей, которые, будучи взломанными, открывали бы
> возможность прямого локального подбора пароля рута.
>

Хотелось бы  быть защищённым не только от "удалённого подбора паролей
пользователей, которые, будучи взломанными, открывали бы возможность
прямого локального подбора пароля рута", но и вообще от подбора
паролей не доверенных пользователей.

Кроме того, по группе, удобнее отслеживать и администрировать, тех кто
может "ходить" удалённо.

-- 
Sin (Sinelnikov Evgeny)