[sisyphus] I: openssh-server-5.3p1-alt2: disabled PasswordAuthentication for "wheel" group members
Dmitry V. Levin
ldv на altlinux.org
Вт Июн 22 23:45:23 UTC 2010
On Wed, Jun 23, 2010 at 03:32:46AM +0400, Evgeny Sinelnikov wrote:
> 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;
У меня самый распространённый сценарий вида
PasswordAuthentication no
AllowGroups wheel users
(доступ имеют только члены групп wheel и users и только по ключам)
отличается от перечисленных вами.
Вообще, осмысленных сценариев может быть великое множество, я бы не пытался
засунуть их всех в конфиг.
Можно нарисовать какие-нибудь
control sshd-password-auth enabled|disabled|nonwheel
control sshd-allow-groups enabled|disabled|имя_группы
но я не уверен, что оно того стоит.
--
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : отсутствует
Тип : application/pgp-signature
Размер : 198 байтов
Описание: отсутствует
Url : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20100623/23d4b1d3/attachment.bin>
Подробная информация о списке рассылки Sisyphus