From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 Date: Wed, 23 Jun 2010 10:53:37 +0300 From: Michael Shigorin To: ALT Linux Sisyphus mailing list Message-ID: <20100623075337.GC14081@osdn.org.ua> Mail-Followup-To: ALT Linux Sisyphus mailing list References: <20100622214400.GA22145@wo.int.altlinux.org> <20100622225300.GZ14081@osdn.org.ua> <20100622230857.GB18232@wo.int.altlinux.org> <20100622234523.GG18232@wo.int.altlinux.org> <20100622214400.GA22145@wo.int.altlinux.org> <20100622225300.GZ14081@osdn.org.ua> <20100622230857.GB18232@wo.int.altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100623004703.GE15539@wo.int.altlinux.org> <20100622234523.GG18232@wo.int.altlinux.org> <20100622230857.GB18232@wo.int.altlinux.org> User-Agent: Mutt/1.4.2.1i Subject: Re: [sisyphus] I: openssh-server-5.3p1-alt2: disabled PasswordAuthentication for "wheel" group members X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shigorin@gmail.com, ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 07:53:41 -0000 Archived-At: List-Archive: List-Post: --- краткая версия --- On Wed, Jun 23, 2010 at 03:45:23AM +0400, Dmitry V. Levin wrote: > Можно нарисовать какие-нибудь > control sshd-password-auth enabled|disabled|nonwheel > control sshd-allow-groups enabled|disabled|имя_группы > но я не уверен, что оно того стоит. Стоит. Это local policy decision, а такие вещи нельзя решать за местного администратора, можно только дать ему ручки в руки и объяснить, почему напрягались и делали именно так. сперва образование, потом технология. Иначе с ишака на истребитель и носом в землю, как на югах бывало. --- традиционное долгое нытьё --- On Wed, Jun 23, 2010 at 03:08:57AM +0400, Dmitry V. Levin wrote: > > > В Сизиф отправляется openssh-server-5.3p1-alt2, в котором по > > > умолчанию аутентификация по паролю будет выключена для членов > > > группы wheel. > > При обновлении умолчание изменится по сравнению с предыдущим, > > если /etc/openssh/sshd_config не трогался? > Да, конечно. Хм, тогда не понял -- до обновления: # rpm -V openssh-server # После: root@pad ~ # rpm -q --lastchange openssh-server * Wed Jun 23 2010 Dmitry V. Levin 5.3p1-alt2 - Enabled sftp by default. - /etc/pam.d/sshd: Changed to use common-login. - sshd_config: Disabled PasswordAuthentication for "wheel" group members (imz@; closes: #17286). root@pad ~ # vim /etc/openssh/sshd_config.rpmnew root@pad ~ # fgrep wheel /etc/pam.d/sshd* /etc/openssh/sshd_config* /etc/openssh/sshd_config.rpmnew:Match Group wheel Почему образовался .rpmnew? :) > > > Подробнее об этом см. > > > https://bugzilla.altlinux.org/show_bug.cgi?id=17286 > > По-моему, идея никуда не годится в качестве умолчания, которое > > может самопроизвольно поменяться при обновлении дистрибутива > > с потенциальным DoS. > Я не верю, что кто-то ещё сознательно использует PasswordAuthentication, А спросить на всякий случай в sysadmins@ -- сложно? > но на всякий случай я это изменение анонсировал. И на том спасибо. > Лично я PasswordAuthentication на сервере использую > исключительно тогда, когда мне нужно протестировать этот режим > работы при подготовке новой версии openssh. > > Прошу ещё раз подумать. > Я вообще собирался выключить PasswordAuthentication по > умолчанию, и, если бы не наткнулся на компромиссный вариант, > описанный в #17286, то так бы и сделал. Дим, у меня в третий раз ощущение, что с дистрибутивом, где _так_ делаются _такие_ решения, мне не по дороге. Пожалуйста, подумай ещё раз -- это LDV Linux или ALT Linux. И для кого/чего делаются дистрибутивы, помимо обобщения своих собственных задач. Давай сделаем метарубильник в виде control security ldv, который повернёт стопку гаек в закрученное до упора положение. В частности, если примешь -- могу попробовать нарисовать control для обсуждаемого поведения, но в качестве умолчания настаиваю на возможности использовать парольную авторизацию -- или же написать _сперва_ на всех углах, что в альте и это не работает во имя блага пользователя, которого он обычно не осознаёт. On Wed, Jun 23, 2010 at 03:45:23AM +0400, Dmitry V. Levin wrote: > У меня самый распространённый сценарий вида > PasswordAuthentication no > AllowGroups wheel users > (доступ имеют только члены групп wheel и users и только по ключам) > отличается от перечисленных вами. > > Вообще, осмысленных сценариев может быть великое множество, > я бы не пытался засунуть их всех в конфиг. Ну твой я бы подумал взять на вооружение, только лучше не явочным порядком, а всё-таки осознанно. Дистрибутив всё-таки -- в том числе и набор удобных шаблонов на базе опыта создававших его людей, но есть же разница между предложением резонного и навязыванием неожиданного. On Wed, Jun 23, 2010 at 03:50:09AM +0400, Evgeny Sinelnikov wrote: > Хотелось бы быть защищённым не только от "удалённого подбора > паролей пользователей, которые, будучи взломанными, открывали > бы возможность прямого локального подбора пароля рута", но и > вообще от подбора паролей не доверенных пользователей. > > Кроме того, по группе, удобнее отслеживать и администрировать, > тех кто может "ходить" удалённо. Полностью согласен. Но описать то, как тебе или мне на машинку с пользовательскими аккаунтами, _позже_ выставленную :22 в инет, повесили бота, _и_ какие действия мы по обнаружении сего факта предприняли -- это одно, а попытаться переставить мебель в чужой комнате -- это другое. On Wed, Jun 23, 2010 at 04:47:03AM +0400, Dmitry V. Levin wrote: > > > AllowGroups remote > > Отлично, а можно эту строку добавить в конфиг, по умолчанию? ;) > > Полагаю, что ответ нет, поскольку это точно подстава при обновлении. > Миша утверждает, что даже "PasswordAuthentication no" для группы wheel -- > это DoS (хотя я примерил это изменение на себя, и мне так не кажется). У тебя выполняются недистрибутивные условия -- сгенерированы _и_ разложены ключи. Если бы была возможна сколь-нибудь надёжная проверка, что хотя бы один пользователь в группе wheel имеет публичный ключ хотя бы в дефолтном месте... первым приближением может послужить приложенный скрипт, но он тоже 80%, а не 100%. Собсно напоминаю типичный use case с Server 4.0+ -- первый созданный пользователь попадает в группу wheel без своего участия помимо использования инсталятора и введения логина-пароля, при этом ни создать ключик (объяснив, зачем и как пользоваться), ни предупредить -- ничего этого не было и сейчас тоже нет. Если ты будешь навязывать ключи людям, то мой прогноз -- будут они повально беспарольными. Потому как неосознанно у тех, кого угораздит: - выбрать альт - взгромоздить на своё железо - поднять свои задачи - добраться до причины, по которой ssh+su "не работает" > А подобное изменение ввиду низкой вероятности существования > группы remote было бы эквивалентно выключению sshd. Именно. "Тогда уж и на другой порт сразу пересаживайте" почти (c) -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/