From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, FUZZY_XPILL,HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 Date: Wed, 9 Oct 2019 16:45:53 +0300 From: "Alexey V. Vissarionov" To: ALT Linux Team development discussions Message-ID: <20191009134553.GG7970@altlinux.org> References: <10326261570536682@myt4-a1257bff88cb.qloud-c.yandex.net> <20191008142111.GE7970@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [devel] =?koi8-r?b?7s/X2cogY29udHJvbCDEzNEgIHNzaGQ6IHNzaGQtYWxs?= =?koi8-r?b?b3ctZ3NzYXBp?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 13:46:00 -0000 Archived-At: List-Archive: List-Post: On 2019-10-09 16:10:18 +0400, Evgeny Sinelnikov wrote: > по сути речь о том, стоит ли выносить дополнительные control-файлы > в специальный пакет, если они относятся к конкретному пакету? В > данном случае к openssh. Если они ничего не тянут за собой - в общем случае особого смысла нет. >>> Мы в Саратовском офисе сделали новый control для переключения >>> возможности авторизации sshd с использованием GSSAPI >> s/авторизации/аутентификации/ :-) >>> Предлагаем забрать его в пакет openssh, так как функционал >>> относится именно к нему. >> Вопрос номер ноль: кому и зачем может быть нужна эта дырища? > А можно по-подробнее в чём конкретно это дырища, какие конкретно > векторы атак и при каких условиях подразумеваются? Иначе это > звучит слишком голосовно. Любое включенное, но не настроенное средство аутентификации - дыра, пока не доказано обратное. > В нашем случае, смысл в этом следующий. У нас довольно активно > пользователи из домена (то бишь админы), начинающие управлять > рабочими станциями, ходят через пароль/логин. Такой вот > windows-подход в домене на базе samba - ничего особенного. Аааа... оно для локалки. Тогда вероятность атаки падает до очень низкой, и тогда даже при неизменном очень высоком уровне ущерба уровень риска падает до приемлемого среднего. >> Есть же PubkeyAuthentication - его достаточно для всего (в >> том числе для сертификатов ssh-rsa-cert-v01@openssh.com и >> ssh-ed25519-cert-v01@openssh.com). > Причём тут сертификаты? Прежде всего, это штатное средство SSH. Ну и сами сертификаты на определенный ключ можно выписывать хоть одноразовые или со сроком действия в единицы-десятки секунд. > Кроме включения GSSAPI для серверной стороны (sshd-allow-gssapi), > нужен аналогичный - для клиентской (ssh-allow-gssapi). Оно требует каких-то сборочных зависимостей? Если да - есть смысл собирать отдельно openssh и openssh-featured > Ещё одна настройка, которая кажется интересной и которой я > постоянно пользуюсь - это группа remote [...] > Суть наличия дополнительной группы в том, чтобы дать право > на удалённый логин через ssh, не выдавая права на запуск su > (то есть не добавляя в группу wheel). А еще можно просто выкинуть этот параметр и пускать всех, у кого есть ключ. > Эти настройки - суть политики. Какие-то из них предполагается > включать сразу при вводе компьютеров в домен. Но, в целом, они > самоценны и вне контекста какой-либо инфраструктуры. В локалке пофигу, но может выйти боком на оборудовании, торчащем голой жопой в дикий интернет. > Так вот. Как лучше поступить? Держать их в отдельном пакете > или сразу интегрировать, в openssh? Все же в openssh-featured :-) Или, соответственно, в openssh-featured-control-gssapi -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net