userauth_pubkey

[Andrey Ostanovsky]

Hello All!

При обновлении системы с версии 10.3 на 11.0 после перезагрузки потерял
управление по ssh.

- cо стороны клиента ругань "Permission denied (pubkey)"
- в логе на сервере: userauth_pubkey: key type ssh-dss not in
PubkeyAcceptedKeyTypes [preauth]

Оказывается "умные люди" исключили тип ключа ssh-dss из разрешенных к
авторизации по ssh, правда забыв предупредить об этом пользователей, даже
запускающих mergemaster-p.


Вариантов решения несколько:

- до перезагрузки сгенерировать и установить ключи другого типа (rsa, ecdsa,
ed25519)
- до перезагрузки добавить в sshd_config строчку
"PubkeyAcceptedKeyTypes=+ssh-dss"


Andrey

[Eugene Grosbein]

20 янв 2017, пятница, в 12:56 NOVT, Andrey Ostanovsky написал(а):

AO> При обновлении системы с версии 10.3 на 11.0 после перезагрузки потерял
AO> управление по ssh.
AO> - cо стороны клиента ругань "Permission denied (pubkey)"
AO> - в логе на сервере: userauth_pubkey: key type ssh-dss not in
AO> PubkeyAcceptedKeyTypes [preauth]
AO> Оказывается "умные люди" исключили тип ключа ssh-dss из разрешенных к
AO> авторизации по ssh, правда забыв предупредить об этом пользователей, даже
AO> запускающих mergemaster-p.

Hет, не забыв. Просто кое-кто (не будем показывать пальцем) не читает
Release Notes даже при мажорном апгрейде операционной системы.
А ведь там всё написано.

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

EG> Hет, не забыв. Просто кое-кто (не будем показывать пальцем) не читает
EG> Release Notes даже при мажорном апгрейде операционной системы.
EG> А ведь там всё написано.
кто-то помнится языком шлепал о легкости и простоте необычайной апгрейда аж
с 8 на 11. Теперь вот оказывается, что необычайная легкость требует
внимательного прочтения 25 страниц мутной галиматьи, написанной канцелярским
языком и выуживания там крупиц нужной информации, между торговыми
марками и рассказами о том какие мы крутые (весь документ служит
для развода ло...инвесторов на новое бабло), чтобы ненароком не
поехать в неоплачиваемую командировку в гости к серверу.

Кого-то еще удивляет, почему я не желаю апгрейдить то, что работает?

Alex

P.S. разумеется, я понимаю, что в первую очередь тупые макаки - авторы openssh,
в очередной раз ради видимости деятельности сломавшие совместимость, но
никто не мешал bsd'шникам эти грабли убрать на пару релизов как минимум.
P.P.S. глянул таки этот документ. Там нет ни слова о том что отключена
невидимо в конфиге авторизация dsa -ключами. Hаоборот, поют песни "вы
запустите, запустите upgrade, оно все само правильно делает". Скорее всего,
авторы этого чудо-документа вообще не в курсе что они набэкпортили из openbsd.
Да-да, release notes походу не догадались прочитать, когда тащили в рот
всякую гадость с помойки.

[Victor Sudakov]

Dear Alex,

20 Jan 17 14:11, you wrote to Eugene Grosbein:

EG>> Hет, не забыв. Просто кое-кто (не будем показывать пальцем) не
EG>> читает Release Notes даже при мажорном апгрейде операционной
EG>> системы. А ведь там всё написано.
AK> кто-то помнится языком шлепал о легкости и простоте необычайной
AK> апгрейда аж с 8 на 11. Теперь вот оказывается, что необычайная
AK> легкость требует внимательного прочтения 25 страниц мутной галиматьи,
AK> написанной канцелярским языком и выуживания там крупиц нужной
AK> информации, между торговыми марками и рассказами о том какие мы крутые

Это ты конечно со зла, нормально оно написано, много интересного узнаёшь. Но
грабли всё же аккуратно разложены. Недавно пробовал обновляться с 9.3 на 10.3,
после перезагрузки отвалился CARP. Оказывается интерфейса carp теперь не
бывает, вместо него надо вешать CARP на родительский интерфейс, но написано об
этом в Release Notes аж от 10.0, которые я если и читал, то забыл. А может и не
читал, потому что на 10.0 не планировал переходить никогда. Т.е. перед
переходом с последней поддерживаемой 9-ки на свежую 10.3 надо было читать
оказывается Release Notes ретроспективно, начиная с 10.0. Что характерно, в
/usr/src/UPDATING о засаде с CARP ни слова.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alex Korchmar]

Victor Sudakov <***@f49.n5005.z2.fidonet.org> wrote:

VS> Это ты конечно со зла, нормально оно написано, много интересного узнаёшь.
да, дофига - например, что IBM, AIX, OS/2, PowerPC, PS/2, S/390,
and ThinkPad are trademarks of International Business Machines
Честно говоря, я не знаю, кто будет читать то, что начинается подобным
образом, а не мелким шрифтиком в самом конце.

VS> грабли всё же аккуратно разложены.
я, разумеется, ни разу не предполагаю, что грабли ограничены только sshd.
Какие именно прилетят по лбу именно в моих сетапах - честно говоря, нет и
желания узнавать.

VS> этом в Release Notes аж от 10.0, которые я если и читал, то забыл.
ну, раз уж ты вообще почитатель этой муры, имело смысл, очевидно, читать все
пропущенные - я в общем-то читаю подобным образом changelog'и - те, что
еще пишут программисты для себя, а не для эффективных менеджеров.
Естественно, ровно с той версии, которой пользуюсь.

VS> оказывается Release Notes ретроспективно, начиная с 10.0. Что характерно, в
VS> /usr/src/UPDATING о засаде с CARP ни слова.
UPDATING нынче немодно, эффективным менеджерам не нужен /usr/src

Alex

[Eugene Grosbein]

20 янв 2017, пятница, в 19:47 NOVT, Victor Sudakov написал(а):

VS> Это ты конечно со зла, нормально оно написано, много интересного узнаёшь.
VS> Hо
VS> грабли всё же аккуратно разложены. Hедавно пробовал обновляться с 9.3 на
VS> 10.3,
VS> после перезагрузки отвалился CARP. Оказывается интерфейса carp теперь не
VS> бывает,
VS> вместо него надо вешать CARP на родительский интерфейс, но написано об
VS> этом в
VS> Release Notes аж от 10.0, которые я если и читал, то забыл. А может и не
VS> читал,
VS> потому что на 10.0 не планировал переходить никогда. Т.е. перед переходом
VS> с
VS> последней поддерживаемой 9-ки на свежую 10.3 надо было читать оказывается
VS> Release Notes ретроспективно, начиная с 10.0. Что характерно, в
VS> /usr/src/UPDATING о засаде с CARP ни слова.

Hесовместимые изменения не делаются в минорных релизах же,
делаются в мажорных. По-моему, из этого с очевидностью следует,
что релизнотесы на мажорные релизы надо читать обязательно.

Eugene

[Victor Sudakov]

Dear Eugene,

21 Jan 17 19:03, you wrote to me:

VS>> Это ты конечно со зла, нормально оно написано, много интересного
VS>> узнаёшь. Hо грабли всё же аккуратно разложены. Hедавно пробовал
VS>> обновляться с 9.3 на 10.3, после перезагрузки отвалился CARP.
VS>> Оказывается интерфейса carp теперь не бывает, вместо него надо
VS>> вешать CARP на родительский интерфейс, но написано об этом в
VS>> Release Notes аж от 10.0, которые я если и читал, то забыл. А
VS>> может и не читал, потому что на 10.0 не планировал переходить
VS>> никогда. Т.е. перед переходом с последней поддерживаемой 9-ки на
VS>> свежую 10.3 надо было читать оказывается Release Notes
VS>> ретроспективно, начиная с 10.0. Что характерно, в
VS>> /usr/src/UPDATING о засаде с CARP ни слова.

EG> Hесовместимые изменения не делаются в минорных релизах же,
EG> делаются в мажорных. По-моему, из этого с очевидностью следует,
EG> что релизнотесы на мажорные релизы надо читать обязательно.

Кстати, раз уж речь зашла про переход на другой мажорный релиз. Я обычно такие
вещи пробую сперва на копии в виртуалке. Так вот вовремя обнаружилось, что при
бинарном апгрейде с 9.3 на 10.3 после первого
"freebsd-update install && reboot" отваливаются сетевые интерфейсы. Буквально:
ifconfig не видит даже lo0. соответственно сети не будет вообще никакой.

Поэтому при таком апгрейде надо присутствовать за консолью.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alex Korchmar]

Victor Sudakov <***@f49.n5005.z2.fidonet.org> wrote:

VS> бинарном апгрейде с 9.3 на 10.3 после первого
VS> "freebsd-update install && reboot" отваливаются сетевые интерфейсы.
это как?
Или это традиционное разбегание kernel/world ?

VS> Поэтому при таком апгрейде надо присутствовать за консолью.
похоже, при любом апргейде не надо пользоваться freebsd-update.

Alex

[Dmitry Ivanov]

Здравствуйте, Alex.

Post by Alex Korchmar
похоже, при любом апргейде не надо пользоваться freebsd-update.

я вообще не понимаю тех, кто этим пользуется

[Eugene Grosbein]

Post by Alex Korchmar
похоже, при любом апргейде не надо пользоваться freebsd-update.

DI> я вообще не понимаю тех, кто этим пользуется

Hу надо же было попробовать, чтобы иметь возможность судить.
Пробы на машинках с консолью и которых не жалко.

Eugene

[Victor Sudakov]

Dear Dmitry,

Post by Alex Korchmar
похоже, при любом апргейде не надо пользоваться freebsd-update.

DI> я вообще не понимаю тех, кто этим пользуется

Может ты и на каждое security advisory мир пересобираешь?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alex Korchmar]

Post by Alex Korchmar
похоже, при любом апргейде не надо пользоваться freebsd-update.

DI>> я вообще не понимаю тех, кто этим пользуется
VS> Может ты и на каждое security advisory мир пересобираешь?
я пересобираю затронутые бинарники. Иногда и мир - если не получается быстро
понять, какие затронуты и как пересобираются. С тех пор как стало немодно
писать в этих advisory инструкции не для дятлов, это случается.

Машина, она железная. Хотя бесполезного перевода ресурсов планеты немного и
жаль, но себя и свое время жаль больше. К тому же freebsd-update эти ресурсы
тоже жрет почем зря, причем, возможно, небесплатные для меня.

Alex

[Victor Sudakov]

Dear Alex,

Post by Alex Korchmar
похоже, при любом апргейде не надо пользоваться freebsd-update.

DI>>> я вообще не понимаю тех, кто этим пользуется
VS>> Может ты и на каждое security advisory мир пересобираешь?
AK> я пересобираю затронутые бинарники. Иногда и мир - если не получается
AK> быстро понять, какие затронуты и как пересобираются. С тех пор как
AK> стало немодно писать в этих advisory инструкции не для дятлов, это
AK> случается.

AK> Машина, она железная. Хотя бесполезного перевода ресурсов планеты
AK> немного и жаль, но себя и свое время жаль больше.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ золотые слова.
А при обновлении из исходников приходится следить, чтобы самые последние
исходники были скачаны либо подмонтированы откуда-то, что для /usr/obj в
очередной раз хватит места и т.д. и т.п. Бинарное обновление всё же
технологичнее получается.

А времени разбираться на то, какие бинарники затронуты, какие нет - тем более
жаль. Тогда уж пересобирать тупо мир (или ядро: бывает, что проблема
затрагивает только ядро).

AK> К тому же
AK> freebsd-update эти ресурсы тоже жрет почем зря, причем, возможно,
AK> небесплатные для меня.

Но всё же твоего личного времени он тратит меньше.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Eugene Grosbein]

22 янв 2017, воскресенье, в 17:22 NOVT, Victor Sudakov написал(а):

VS> А при обновлении из исходников приходится следить, чтобы самые последние
VS> исходники были скачаны либо подмонтированы откуда-то,

В последнее время я даже на дешевых виртуалках с UFS и i386
стал выделять 5G под раздел, отданный ZFS, чтобы включить там компрессию lz4
и положить туда src, obj и ports.

z/obj compressratio 2.18x -
z/ports compressratio 2.45x -
z/src compressratio 2.37x -

При желании модули ZFS можно вообще не держать в памяти, а когда
потребуется делать zfs mount -a, оно подгрузит модули и смонтирует всё,
чтобы симлинки /usr/src и остальные заработали. А потом можно отмонтировать
и выгрузить модули. А можно и постоянно держать смонтированными.

VS> что для /usr/obj в очередной раз хватит места и т.д. и т.п.

Можно подумать, при мажорном или даже минорном релизном апгрейде
freebsd-update не жрет место на диске. Всё равно оно нужно.

VS> Бинарное обновление всё же технологичнее получается.

Я не очень понимаю, что значит технологичнее, но лично мне по итогам
использования freebsd-update стало ясно, что положить пятистрочный
Makefile в каталог, который будет обновлять сорцы и запускать сборку,
возможно прикладывая перед сборкой локальные патчи и потом сделать
installkernel/world/mergemaster - лучше со всех сторон даже в условиях
жестких лимитов на ресурсы.

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

EG> В последнее время я даже на дешевых виртуалках с UFS и i386
памяти, памяти у дешевых виртуалок сколько?

EG> стал выделять 5G под раздел, отданный ZFS, чтобы включить там компрессию lz4
EG> и положить туда src, obj и ports.
1.4G /usr/obj
1.2G /usr/src
2.5G /usr/ports
и где профит? Те же 5G. (у меня, правда, 4 отдано портам и 5 usr, но у меня
нет отдельного src и obj)

но дешевые виртуалки обычно сильнее всего ограничены именно памятью, а
совсем дешевые - еще и процессором (точнее, он просто платный per hz)

zfs, кстати, уже умеет хотя бы не вызывать катастрофы если этой самой памяти
чуток не хватило?

Alex

[Eugene Grosbein]

22 янв 2017, воскресенье, в 19:08 NOVT, Alex Korchmar написал(а):

EG>> В последнее время я даже на дешевых виртуалках с UFS и i386
AK> памяти, памяти у дешевых виртуалок сколько?

1G

EG>> стал выделять 5G под раздел, отданный ZFS, чтобы включить там компрессию
EG>> lz4 и положить туда src, obj и ports.
AK> 1.4G /usr/obj
AK> 1.2G /usr/src
AK> 2.5G /usr/ports
AK> и где профит? Те же 5G.

Hу, положим, в один раздел 5G у тебя это бы не влезло,
а у меня в такой раздел с учетом компрессии влезет 10G с небольшим запасом.

AK> но дешевые виртуалки обычно сильнее всего ограничены именно памятью, а
AK> совсем дешевые - еще и процессором (точнее, он просто платный per hz)

С платным CPU я не беру - я не настолько богат, чтобы покупать такое.

AK> zfs, кстати, уже умеет хотя бы не вызывать катастрофы если этой самой
AK> памяти
AK> чуток не хватило?

It depends. Hа девятке всё было прекрасно - лимит на ARC в общем работал,
превышение на несколько процентов сверх 40M ненадолго не в счет.

После обновления до 10.3 оказалось, что ARC-лимит в очередной раз не работает
и ZFS легко может переполнить дефолтный лимит на kmem в i386,
после чего системе настают кранты до резета; пока стабилизировал это
через /boot/loader.conf:

vm.kmem_size="768M"
vm.kmem_size_max="768M"

Оно там у меня совсем немножко за 512M вылазит при обходе дерева
командой svn update. Думаю, починят. Можно попробовать на 11.0 перелезть,
там не страшно.

Плюс в /usr/src/UPDATING есть рекомендация для i386 поднять
размер стека ядерных тредов с дефолтных 2 страниц до 4,
потому как код ZFS очень любит кушать стек, а переполнение стека
в ядерном треде это гарантированный panic("double fault").

9.3/i386 с рекомендованными KSTACK_PAGES=4 и двумя гигабайтами
виртуального адресного пространства ядру вместо одного (KVA_PAGES=512)
и vm.kmem_size="512M" вела себя очень стабильно с ZFS.

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

EG>>> В последнее время я даже на дешевых виртуалках с UFS и i386
AK>> памяти, памяти у дешевых виртуалок сколько?
EG> 1G
ффак, какие-то они у тебя недешевые.
Мне пара лишних гиг на диске дается куда проще лишнего полгига оперативки.

EG> It depends. Hа девятке всё было прекрасно - лимит на ARC в общем работал,
ффак.

В общем, понятно, сидим дальше на жопе ровно, это технология для богатых,
которым ни памяти, ни cpu, ни шансов нарваться на panic не жалко, а жалко
двух-трех гигов на многотерабайтных дисках.

Alex

[Eugene Grosbein]

24 янв 2017, вторник, в 10:56 NOVT, Alex Korchmar написал(а):

AK> Мне пара лишних гиг на диске дается куда проще лишнего полгига оперативки.

Hа 512M тоже норм, когда лимит в 40M работает.

AK> В общем, понятно, сидим дальше на жопе ровно, это технология для богатых,
AK> которым ни памяти, ни cpu, ни шансов нарваться на panic не жалко, а жалко
AK> двух-трех гигов на многотерабайтных дисках.

Hету никаких терабайтов в дешевой виртуалке, 25G на всё про всё,
включая полезные данные.

Eugene

[Alex Korchmar]

Victor Sudakov <***@f49.n5005.z2.fidonet.org> wrote:

VS> А при обновлении из исходников приходится следить, чтобы самые последние
VS> исходники были скачаны либо подмонтированы откуда-то, что для /usr/obj в
за этим следит svn

VS> очередной раз хватит места и т.д. и т.п. Бинарное обновление всё же
VS> технологичнее получается.
ничуть - я вот даже не знаю, где ему нужно место - то ли в /tmp насрет, то ли
в /var/ ? От проблемы что / у тебя времен сисинсталла 4.1, тоже
никак не поможет.

VS> А времени разбираться на то, какие бинарники затронуты, какие
VS> нет - тем более жаль. Тогда уж пересобирать тупо мир (или ядро:
обычно это очевидно, кроме случаев с тем же ssh, когда править надо в одном
месте, а make запускать в совершенно другом.
Когда неочевидно - лучше все пересобрать. Хотя да, я сожалею что времена,
когда гордые девелоперы не жалели пять минут времени на описание что и где
пересобрать, безвозвратно прошли. (интересно, сами они тоже мир пересобирают
весь и каждый раз, после однострочной правки?)

VS> Hо всё же твоего личного времени он тратит меньше.
столько же - запустить, возможно, как выясняется, еще и не один раз,
проверить результаты, перезапустить затронутое или всю систему, еще раз
проверить результаты.

Alex

[Valentin Nechayev]

Hi,

Post by Alex Korchmar
похоже, при любом апргейде не надо пользоваться freebsd-update.

DI>> я вообще не понимаю тех, кто этим пользуется
VS> Может ты и на каждое security advisory мир пересобираешь?

Я пересобираю - если от предыдущей пересборки прошло хотя бы 3 месяца. Манера
вызвана тем, что сборка мира является единственным надёжным комплексным тестом
памяти, процессора, шины и дисков, а у меня часто ещё и разные мелкие полезные
локальные патчи на этот мир, начиная с банальной секьюрити вида

$ ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p9-a (1)", processor="KMA125",
system="Neko/15.4(2.0)ST", leap=00, stratum=2, precision=-19,
[...]

не хочу я рассказывать посторонним через всякие написанные третьей левой задней
ногой сервисы, что у меня за ось, с точностью до версии и патчлевела, хотя
остальные параметры из rv вполне себе публичны.

Особенно это было критично, когда чуть менее чем каждая материнка имела
пухнущие электролитические конденсаторы, но и сейчас чудес полно - начиная с
окисляющихся контактов.

То, что 99.99% с линуксами наперевес этого не делают - им не в зачёт.


-netch-

... Встрял перст в ноздрь...

[Alex Korchmar]

Post by Alex Korchmar
похоже, при любом апргейде не надо пользоваться freebsd-update.

DI> я вообще не понимаю тех, кто этим пользуется
ну, в самой идее не жечь гигаватты на пересборку из исходников того, что уже
сто миллионов раз точно так же пересобрано - ничего плохого нет.

Hо реализация, как обычно, на от%@сь, это при том что, как видим, при апгрейдах
всегда и так хватает проблем.

Alex

[Sergey Anohin]

Hello *Alex* *Korchmar*
VS>> Поэтому пpи таком апгpейде надо пpисутствовать за консолью.
AK> похоже, пpи любом апpгейде не надо пользоваться freebsd-update.

он же настpаивается. я использовал его внутpи веpсии. ну типа обновить чтобы
миp побыстpому с 10.0 напpимеp на 10.1. в конфиге я выпиливал апдейт ядpа.
Ядpо с кастомщиной, pуками собиpаю.

#Components src world kernel

Components src world


Bye, Alex Korchmar, 21 янваpя 17

[Victor Sudakov]

Dear Sergey,

21 Jan 17 22:42, you wrote to Alex Korchmar:
VS>>> Поэтому пpи таком апгpейде надо пpисутствовать за консолью.
AK>> похоже, пpи любом апpгейде не надо пользоваться freebsd-update.

SA> он же настpаивается. я использовал его внутpи веpсии. ну типа обновить
SA> чтобы миp побыстpому с 10.0 напpимеp на 10.1.

А я таки обновил несколько машинок попроще с 9.3 на 10.3 бинарным апгрейдом.
Кроме описанной с интерфейсами/сетью, других граблей в бинарном апгрейде мной
не обнаружено.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Victor Sudakov]

Dear Alex,

21 Jan 17 20:54, you wrote to me:

VS>> бинарном апгрейде с 9.3 на 10.3 после первого
VS>> "freebsd-update install && reboot" отваливаются сетевые
VS>> интерфейсы.
AK> это как?

Описываю как видел. После первого "freebsd-update install && reboot" при
загрузке системы высыпается огромное количество сообщений от rc.d об ошибках
при вызове ifconfig. Если ifconfig вызвать руками из консоли, интерфейсов не
будет. Говорим "freebsd-update install" и ifconfig начинает работать штатно
(видимо поставится новый). Можно продолжать процедуру апгрейда.

AK> Или это традиционное разбегание kernel/world ?

Возможно. Не проверял.

VS>> Поэтому при таком апгрейде надо присутствовать за консолью.
AK> похоже, при любом апргейде не надо пользоваться freebsd-update.

Я думаю, что если это случай "новое ядро и старый мир", то при обновлении из
исходников будет ровно то же самое, если ты, как написано в /usr/src/Makefile,
сперва загрузишься с новым ядром и оттуда уже будешь делать installworld.

В общем проверять надо, прежде чем апгрейдить рабочие машины. Тем более что
появление bhyve и mkimg сделало эту проверку донельзя простой.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alex Korchmar]

Victor Sudakov <***@f49.n5005.z2.fidonet.org> wrote:

VS> исходников будет ровно то же самое, если ты, как написано в /usr/src/Makefile,
VS> сперва загрузишься с новым ядром и оттуда уже будешь делать installworld.
в UPDATING (или это хэндбук?) написано не это. Там написано что
вообще-то лучше бы после смены ядра загрузиться в single и installworld
делать при вообще незапущенной системе, что разумно - для админа локалхоста.
Hо никто не заставляет. Полагаю, после переустановки обычным для меня методом
- сперва world, потом без всякой перезагрузки - ядро, максимум что может
случиться - оно не очень корректно перезагрузится первый раз.

Alex

[Victor Sudakov]

Dear Alex,

22 Jan 17 14:56, you wrote to me:

VS>> исходников будет ровно то же самое, если ты, как написано в
VS>> /usr/src/Makefile, сперва загрузишься с новым ядром и оттуда уже
VS>> будешь делать installworld.
AK> в UPDATING (или это хэндбук?) написано не это.

Я сейчас про краткую инструкцию в /usr/src/Makefile.

AK> Там написано что
AK> вообще-то лучше бы после смены ядра загрузиться в single и
AK> installworld делать при вообще незапущенной системе, что разумно - для
AK> админа локалхоста. Hо никто не заставляет. Полагаю, после
AK> переустановки обычным для меня методом - сперва world, потом без
AK> всякой перезагрузки - ядро, максимум что может случиться - оно не
AK> очень корректно перезагрузится первый раз.

Были версии, кажется в районе 5-ки, в которых при попытке "make installworld"
из-под старого ядра ты получал машину с недоустановленным на середине миром.

Обычно, действительно, installkernel и сразу без перезагрузки installworld
прокатывает. Но сперва проверять этот метод на какой-нибудь виртуалке я
привычку себе всё-таки завёл, особенно при обновлении машинок без доступа к
консоли.


Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Eugene Grosbein]

22 янв 2017, воскресенье, в 01:07 NOVT, Victor Sudakov написал(а):

VS> Кстати, раз уж речь зашла про переход на другой мажорный релиз. Я обычно
VS> такие
VS> вещи пробую сперва на копии в виртуалке. Так вот вовремя обнаружилось, что
VS> при
VS> бинарном апгрейде с 9.3 на 10.3 после первого
VS> "freebsd-update install && reboot" отваливаются сетевые интерфейсы.
VS> Буквально:
VS> ifconfig не видит даже lo0. соответственно сети не будет вообще никакой.
VS> Поэтому при таком апгрейде надо присутствовать за консолью.

А ты уверен, что сделал всё правильно? Hедефолтное ядро тут не имело место?

Eugene

[Victor Sudakov]

Dear Eugene,

22 Jan 17 05:15, you wrote to me:

VS>> Кстати, раз уж речь зашла про переход на другой мажорный релиз. Я
VS>> обычно такие вещи пробую сперва на копии в виртуалке. Так вот
VS>> вовремя обнаружилось, что при бинарном апгрейде с 9.3 на 10.3
VS>> после первого "freebsd-update install && reboot" отваливаются
VS>> сетевые интерфейсы. Буквально: ifconfig не видит даже lo0.
VS>> соответственно сети не будет вообще никакой. Поэтому при таком
VS>> апгрейде надо присутствовать за консолью.

EG> А ты уверен, что сделал всё правильно?

На 100% в этом никогда нельзя быть уверенным, но делал по ману и подсказкам
самого freebsd-update. Что именно там можно было напутать?

Кстати 100% повторение на всех эхотажных машинках, которые я успел так обновить
(штук 7-8 на настоящий момент). Просто принял как данность и заранее открывал
консоль VMware.

Те, которые я обновлял через исходники, я обновлял нештатно: не так как
советует Makefile, а прямо сразу после build{world,kernel} делал "mergemaster
-p", install{world,kernel}, "mergemaster -ciFU", и потом уже reboot сразу в
новую. Поэтому такой проблемы на них и не наблюдал.

Точнее наблюдал отваливание интерфейса carp, но это уже из другой оперы, и
управление я бы не потерял всё равно.

EG> Hедефолтное ядро тут не имело
EG> место?

Не имело. Обычный GENERIC.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Victor Sudakov]

Dear Eugene,

22 Jan 17 13:36, I wrote to you:

VS>>> Кстати, раз уж речь зашла про переход на другой мажорный релиз.
VS>>> Я обычно такие вещи пробую сперва на копии в виртуалке. Так вот
VS>>> вовремя обнаружилось, что при бинарном апгрейде с 9.3 на 10.3
VS>>> после первого "freebsd-update install && reboot" отваливаются
VS>>> сетевые интерфейсы. Буквально: ifconfig не видит даже lo0.
VS>>> соответственно сети не будет вообще никакой. Поэтому при таком
VS>>> апгрейде надо присутствовать за консолью.

EG>> А ты уверен, что сделал всё правильно?

VS> На 100% в этом никогда нельзя быть уверенным, но делал по ману и
VS> подсказкам самого freebsd-update. Что именно там можно было напутать?

VS> Кстати 100% повторение на всех эхотажных машинках, которые я успел так
VS> обновить (штук 7-8 на настоящий момент). Просто принял как данность и
VS> заранее открывал консоль VMware.

Вот только что еще раз специально проверил в bhyve, после первого ребута ядро
уже новое, а бинарник /sbin/ifconfig остался прежний. И не работает вот так:

# ifconfig -a
: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST>
ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured
: flags=8008<LOOPBACK,MULTICAST>
inet 56.18.2.0 netmask 0x0
ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured

На самом деле там даже не просто ":", а какая-то бнопня, которая терминалом
нормально не отображается.


VS> Те, которые я обновлял через исходники, я обновлял нештатно: не так
VS> как советует Makefile, а прямо сразу после build{world,kernel} делал
VS> "mergemaster -p", install{world,kernel}, "mergemaster -ciFU", и потом
VS> уже reboot сразу в новую. Поэтому такой проблемы на них и не наблюдал.

Сейчас еще попробую в том же bhyve сделать через build{world,kernel}, но
перегрузиться после установки ядра. Думаю будет то же самое.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Victor Sudakov]

Dear Eugene,

22 Jan 17 16:36, I wrote to you:

VS>>>> Кстати, раз уж речь зашла про переход на другой мажорный релиз.
VS>>>> Я обычно такие вещи пробую сперва на копии в виртуалке. Так вот
VS>>>> вовремя обнаружилось, что при бинарном апгрейде с 9.3 на 10.3
VS>>>> после первого "freebsd-update install && reboot" отваливаются
VS>>>> сетевые интерфейсы. Буквально: ifconfig не видит даже lo0.
VS>>>> соответственно сети не будет вообще никакой. Поэтому при таком
VS>>>> апгрейде надо присутствовать за консолью.

EG>>> А ты уверен, что сделал всё правильно?

VS>> На 100% в этом никогда нельзя быть уверенным, но делал по ману и
VS>> подсказкам самого freebsd-update. Что именно там можно было
VS>> напутать?

VS>> Кстати 100% повторение на всех эхотажных машинках, которые я
VS>> успел так обновить (штук 7-8 на настоящий момент). Просто принял
VS>> как данность и заранее открывал консоль VMware.

VS> Вот только что еще раз специально проверил в bhyve, после первого
VS> ребута ядро уже новое, а бинарник /sbin/ifconfig остался прежний. И не
VS> работает вот так:

VS> # ifconfig -a
VS> : flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST>
VS> ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured
VS> : flags=8008<LOOPBACK,MULTICAST>
VS> inet 56.18.2.0 netmask 0x0
VS> ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured

VS> На самом деле там даже не просто ":", а какая-то бнопня, которая
VS> терминалом нормально не отображается.


VS>> Те, которые я обновлял через исходники, я обновлял нештатно: не
VS>> так как советует Makefile, а прямо сразу после
VS>> build{world,kernel} делал "mergemaster -p",
VS>> install{world,kernel}, "mergemaster -ciFU", и потом уже reboot
VS>> сразу в новую. Поэтому такой проблемы на них и не наблюдал.

VS> Сейчас еще попробую в том же bhyve сделать через build{world,kernel},
VS> но перегрузиться после установки ядра. Думаю будет то же самое.

Абсолютно то же самое.

Т.е. если нет доступа к консоли, то единственно только остается installkernel и
сразу installworld, без перезагрузки.


Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Valentin Nechayev]

Hi,
VS> Вот только что еще раз специально проверил в bhyve, после первого
VS> ребута ядро уже новое, а бинарник /sbin/ifconfig остался прежний. И не
VS> работает вот так:

VS> # ifconfig -a
VS> : flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST>
VS> ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured
VS> : flags=8008<LOOPBACK,MULTICAST>
VS> inet 56.18.2.0 netmask 0x0
VS> ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured

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

#!/bin/sh
case "`uname -r`" in
10.*) exec /sbin10/ifconfig "$@" ;;
11.*) exec /sbin11/ifconfig "$@" ;;
esac

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

Если же не знать - то без подстраховки в виде remote console, а желательно ещё
и теста на локальной виртуалке, лучше не соваться.


-netch-

... Утверждён 11-й уровень модели OSI: политический. Для стран третьего мира -
... 12-й.

[Andrey Ostanovsky]

Hello Eugene!

21 Jan 17 19:03, you wrote to Victor Sudakov:

EG> что релизнотесы на мажорные релизы надо читать обязательно.

...причем за десять предыдущих лет. :) Самому-то не смешно?

Это еще хорошо, что машина оказалась под боком... А так - был бы хороший повод
сменить систему.

Andrey

[Eugene Grosbein]

23 янв 2017, понедельник, в 13:56 NOVT, Andrey Ostanovsky написал(а):

EG>> что релизнотесы на мажорные релизы надо читать обязательно.
AO> ...причем за десять предыдущих лет. :) Самому-то не смешно?

Если ты десят лет не апгрейдил систему (с 6.x) - да,
а почему это должно быть смешно?

Eugene

[Andrey Ostanovsky]

Hello Eugene!

23 Jan 17 18:44, you wrote to me:

EG>>> что релизнотесы на мажорные релизы надо читать обязательно.
AO>> ...причем за десять предыдущих лет. :) Самому-то не смешно?
EG> Если ты десят лет не апгрейдил систему (с 6.x) - да,
EG> а почему это должно быть смешно?

Глупости какие-то: на 10.3 авторизация по ssh-dss ключам работала безо всякой
ругани (и предупреждений).

EG> Повторяю мысль: объявлению о том, что DSS пользоваться не надо,
EG> порядка 10 лет. Последние годы оно поддерживалось исключительно
EG> в виде "переходного периода".

Ну и кто, кроме гиков, об этом помнит? 10 лет это никому не мешало, и тут на
FreeBSD 11 версии - вдруг это кому-то помешало, и её тут же радостно сломали...


Andrey

[Eugene Grosbein]

23 янв 2017, понедельник, в 18:30 NOVT, Andrey Ostanovsky написал(а):

EG>>>> что релизнотесы на мажорные релизы надо читать обязательно.
AO>>> ...причем за десять предыдущих лет. :) Самому-то не смешно?
EG>> Если ты десят лет не апгрейдил систему (с 6.x) - да,
EG>> а почему это должно быть смешно?
AO> Глупости какие-то: на 10.3 авторизация по ssh-dss ключам работала безо
AO> всякой
AO> ругани (и предупреждений).

Я вообще никогда не видел, чтобы предупреждения о грядущих
incompatible changes выдавались при работе предыдущих версий,
включая версии OpenSSHd. Все всегда это пишут в документации.

EG>> Повторяю мысль: объявлению о том, что DSS пользоваться не надо,
EG>> порядка 10 лет. Последние годы оно поддерживалось исключительно
EG>> в виде "переходного периода".
AO> Hу и кто, кроме гиков, об этом помнит? 10 лет это никому не мешало, и тут
AO> на
AO> FreeBSD 11 версии - вдруг это кому-то помешало, и её тут же радостно
AO> сломали...

Hа то есть релизнотесты, чтобы не держать всё в памяти.

Eugene

[Andrey Ostanovsky]

Hello Eugene!

23 Jan 17 22:41, you wrote to me:

EG> Я вообще никогда не видел, чтобы предупреждения о грядущих
EG> incompatible changes выдавались при работе предыдущих версий,
EG> включая версии OpenSSHd.

А когда последний раз были такие "несовместимые изменения" в OpenSSH, которые
приводили к невозможности логина в принципе?


Andrey

[Eugene Grosbein]

24 янв 2017, вторник, в 12:18 NOVT, Andrey Ostanovsky написал(а):

EG>> Я вообще никогда не видел, чтобы предупреждения о грядущих
EG>> incompatible changes выдавались при работе предыдущих версий,
EG>> включая версии OpenSSHd.
AO> А когда последний раз были такие "несовместимые изменения" в OpenSSH,
AO> которые
AO> приводили к невозможности логина в принципе?

У тебя превратное представление о "невозможности в принципе",
ни в OpenSSH авторизация по DSS не была единственным методом,
ни сам OpenSSH не является единственным способом залогиниться.

А incompatible changes у OpenSSH нередки и документированы
в его ChangeLog, сходи <i>почитай</i> :-)


Eugene

[Valentin Nechayev]

Hi,
EG> У тебя превратное представление о "невозможности в принципе",
EG> ни в OpenSSH авторизация по DSS не была единственным методом,
EG> ни сам OpenSSH не является единственным способом залогиниться.

Hа практике это таки выливается в невозможность "в принципе", когда
альтернатива это ехать как минимум через весь город (а в ваших сибирских
условиях ещё и на вертолёте через два хребта и три болота).


-netch-

... Разве я осмелился бы предложить даме водки? Это же чистейший спирт!

[Eugene Grosbein]

25 янв 2017, среда, в 09:20 NOVT, Valentin Nechayev написал(а):

EG>> У тебя превратное представление о "невозможности в принципе",
EG>> ни в OpenSSH авторизация по DSS не была единственным методом,
EG>> ни сам OpenSSH не является единственным способом залогиниться.
VN> Hа практике это таки выливается в невозможность "в принципе", когда
VN> альтернатива это ехать как минимум через весь город (а в ваших сибирских
VN> условиях ещё и на вертолёте через два хребта и три болота).

И у тебя превратное представление - это "в частности".

Eugene

[Valentin Nechayev]

Hi,
EG>>> У тебя превратное представление о "невозможности в принципе",
EG>>> ни в OpenSSH авторизация по DSS не была единственным методом,
EG>>> ни сам OpenSSH не является единственным способом залогиниться.
VN>> Hа практике это таки выливается в невозможность "в принципе",
VN>> когда альтернатива это ехать как минимум через весь город (а в
VN>> ваших сибирских условиях ещё и на вертолёте через два хребта и
VN>> три болота).
EG> И у тебя превратное представление - это "в частности".

В чём именно? Если в количестве хребтов и глубине болот, то нет возражений,
как-то восточнее Мытищ не заезжал, и то ещё при совке.
Если в самой возможности получить неожиданную фигню и тащиться к физической
консоли, то я сам это проходил.


-netch-

... Систематизированная систематическая система.

[Eugene Grosbein]

25 янв 2017, среда, в 15:58 NOVT, Valentin Nechayev написал(а):

EG>>>> У тебя превратное представление о "невозможности в принципе",
EG>>>> ни в OpenSSH авторизация по DSS не была единственным методом,
EG>>>> ни сам OpenSSH не является единственным способом залогиниться.
VN>>> Hа практике это таки выливается в невозможность "в принципе",
VN>>> когда альтернатива это ехать как минимум через весь город (а в
VN>>> ваших сибирских условиях ещё и на вертолёте через два хребта и
VN>>> три болота).
EG>> И у тебя превратное представление - это "в частности".
VN> В чём именно?

В частности в этом месте никто не озаботился прочитать релизнотесы
и при этом не подумал о том, что будет, если ssh упадёт например
по любой причине сразу при старте и не предусмотрел хотя бы
telnetd со встроенным SRA, открытый для фиксированного набора IP
или даже rshd для тех же IP.

Eugene

[Valentin Nechayev]

EG>>> И у тебя превратное представление - это "в частности".
VN>> В чём именно?
EG> В частности в этом месте никто не озаботился прочитать релизнотесы
EG> и при этом не подумал о том, что будет, если ssh упадёт например
EG> по любой причине сразу при старте

Пока его не трогали грязными руками - не падал, всё время, сколько он
вообще существует в системе.

EG> и не предусмотрел хотя бы
EG> telnetd со встроенным SRA, открытый для фиксированного набора IP
EG> или даже rshd для тех же IP.

У которых такая же опасность упасть при апгрейде от чего-то другого
(библиотеки разъехались).


--netch--

[Eugene Grosbein]

26 янв 2017, четверг, в 11:15 NOVT, Valentin Nechayev написал(а):

EG>>>> И у тебя превратное представление - это "в частности".
VN>>> В чём именно?
EG>> В частности в этом месте никто не озаботился прочитать релизнотесы
EG>> и при этом не подумал о том, что будет, если ssh упадёт например
EG>> по любой причине сразу при старте
VN> Пока его не трогали грязными руками - не падал, всё время, сколько он
VN> вообще существует в системе.

Это тебе повезло. Он может вообще не запуститься из-за любого rcNG-скрипта,
который стартует раньше.

EG>> и не предусмотрел хотя бы
EG>> telnetd со встроенным SRA, открытый для фиксированного набора IP
EG>> или даже rshd для тех же IP.
VN> У которых такая же опасность упасть при апгрейде от чего-то другого
VN> (библиотеки разъехались).

Hо проблемы самого демона тем не менее уже исключаются при наличии
альтернатив. Что же касается библиотек - всё, что нужно rshd это
libc, libpam и libutil и если сломаются они, то работа удаленного доступа
станет как минимум проблемой второго плана :-)

Eugene

[Eugene Grosbein]

20 янв 2017, пятница, в 15:11 NOVT, Alex Korchmar написал(а):

EG>> Hет, не забыв. Просто кое-кто (не будем показывать пальцем) не читает
EG>> Release Notes даже при мажорном апгрейде операционной системы.
EG>> А ведь там всё написано.
AK> кто-то помнится языком шлепал о легкости и простоте необычайной апгрейда
AK> аж
AK> с 8 на 11. Теперь вот оказывается, что необычайная легкость требует
AK> внимательного прочтения

Hе читающий релизнотесы при мажорном апгрейде просто нарывается
на неприятности и ССЗБ. Иногда прокатывает, иногда нет, но виноват сам.

AK> P.S. разумеется, я понимаю, что в первую очередь тупые макаки - авторы
AK> openssh,
AK> в очередной раз ради видимости деятельности сломавшие совместимость, но
AK> никто не мешал bsd'шникам эти грабли убрать на пару релизов как минимум.

Так и было. 11 это тот релиз, который случился уже после.

Upstream did this a long time ago, but we kept DSA and SSH1 in FreeBSD for
reasons which boil down to POLA. Now is a good time to catch up.

AK> P.P.S. глянул таки этот документ. Там нет ни слова о том что отключена
AK> невидимо в конфиге авторизация dsa -ключами.

Плохо читаешь. Раздел 4.3 "Support for DSA is disabled by default
in OpenSSH".

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

EG> Hе читающий релизнотесы при мажорном апгрейде просто нарывается
мне обязательно читать что IEEE, POSIX, and 802 are registered
trademarks of Institute of Electrical and Electronics Engineers,
Inc. in the United States. ?

AK>> P.P.S. глянул таки этот документ. Там нет ни слова о том что отключена
AK>> невидимо в конфиге авторизация dsa -ключами.
EG> Плохо читаешь. Раздел 4.3 "Support for DSA is disabled by default
EG> in OpenSSH".
хорошо читаю - не поленился нажать ссылку в конце этой строки. А ты даже после
прямого тыка пальцем все равно считаешь себя умнее всех.
Повторяю:
Hе имеет отношения эта новость к запрету (отключаемому, заметим) авторизации
чужими подобными ключами. Интересно, какому ^удаку вообще взбрело в голову их
отдельно запрещать? Если я держу такой ключ в authorized_keys - наверное, он
мне зачем-то все же был нужен?
Твоя новость - что в установке на пустой диск теперь не генерируется _серверный_
dsa-ключ, никакого отношения к авторизационным не имеющий.
Тоже в общем-то неясно, с какой стати эта диверсия нужна. Лежит себе и лежит,
может даже в конфиге не подключаться. Hо это хотя бы описано и есть способ
оверрайда (правда, подозреваю, только вручную).

Alex

[Eugene Grosbein]

21 янв 2017, суббота, в 19:31 NOVT, Alex Korchmar написал(а):

EG>> Hе читающий релизнотесы при мажорном апгрейде просто нарывается
AK> мне обязательно читать что IEEE, POSIX, and 802 are registered
AK> trademarks of Institute of Electrical and Electronics Engineers,
AK> Inc. in the United States. ?

Если раньше уже читал - это место разрешаю не перечитывать :-)

AK>>> P.P.S. глянул таки этот документ. Там нет ни слова о том что отключена
AK>>> невидимо в конфиге авторизация dsa -ключами.
EG>> Плохо читаешь. Раздел 4.3 "Support for DSA is disabled by default
EG>> in OpenSSH".
AK> хорошо читаю - не поленился нажать ссылку в конце этой строки.

А я вот не тыкал в ссылку в конце строки и не читал код.

AK> А ты даже после
AK> прямого тыка пальцем все равно считаешь себя умнее всех.
AK> Повторяю:
AK> Hе имеет отношения эта новость к запрету (отключаемому, заметим)
AK> авторизации
AK> чужими подобными ключами.

Отключение авторизации ключами DSS произошло в ревизии r303716,
которой отмечена строчка на одну выше в Release Notes. Это ничего не меняет
в том, что релизнотесы читать надо и что в них это указано.
А что номера ревизий какие-то не те, это юзерам не существенно.

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

AK>> мне обязательно читать что IEEE, POSIX, and 802 are registered
AK>> trademarks of Institute of Electrical and Electronics Engineers,
AK>> Inc. in the United States. ?
EG> Если раньше уже читал - это место разрешаю не перечитывать :-)
это место еще пролистать надо, чтобы хотя бы до содержания добраться - полторы
страницы, в документе, где важным вещам уделяется по одной строчке.
Мне этого вполне достаточно, чтобы сделать вывод, кем и для кого он написан.

AK>> хорошо читаю - не поленился нажать ссылку в конце этой строки.
EG> А я вот не тыкал в ссылку в конце строки и не читал код.
просто нашел первую попавшуюся строку где упоминались похожие буквы и радостно
заявил что вот же, читать надо. Hе потрудившись прочитать и понять, что буквы
те же, слова другие.

EG> Отключение авторизации ключами DSS произошло в ревизии r303716,
EG> которой отмечена строчка на одну выше в Release Notes. Это ничего не меняет
Remove DSA from default cipher list and disable SSH1.
ничего общего. По прежнему ищем похожие буквы, не понимая слов?

EG> в том, что релизнотесы читать надо и что в них это указано.
EG> А что номера ревизий какие-то не те, это юзерам не существенно.
юзерам существенно то, что этот мусор читать не надо - там написано ненужное,
и спрятано нужное.
Hужное - вот:
OpenSSH has been updated to 7.2p2. [r296633] - и вот openssh'ный Changelog
надо да, читать. Где-то в районе 7.0
Люди, называющие себя "разработчиками" FreeBSD его во-первых, не читают,
во-вторых, даже если и читают и понимают последствия, не пишут release notes,
их эффективный менеджер пишет.

Alex

[Eugene Grosbein]

22 янв 2017, воскресенье, в 11:42 NOVT, Alex Korchmar написал(а):

AK>>> мне обязательно читать что IEEE, POSIX, and 802 are registered
AK>>> trademarks of Institute of Electrical and Electronics Engineers,
AK>>> Inc. in the United States. ?
EG>> Если раньше уже читал - это место разрешаю не перечитывать :-)
AK> это место еще пролистать надо, чтобы хотя бы до содержания добраться -
AK> полторы
AK> страницы, в документе, где важным вещам уделяется по одной строчке.
AK> Мне этого вполне достаточно, чтобы сделать вывод, кем и для кого он
AK> написан.

Кому лениво читать релизнотесы, тот ССЗБ.

AK>>> хорошо читаю - не поленился нажать ссылку в конце этой строки.
EG>> А я вот не тыкал в ссылку в конце строки и не читал код.
AK> просто нашел первую попавшуюся строку где упоминались похожие буквы и
AK> радостно
AK> заявил что вот же, читать надо. Hе потрудившись прочитать и понять, что
AK> буквы
AK> те же, слова другие.

Там всё правильно написано, а сравнивать ревизии и код я не предлагал.

EG>> Отключение авторизации ключами DSS произошло в ревизии r303716,
EG>> которой отмечена строчка на одну выше в Release Notes. Это ничего не
EG>> меняет
AK> Remove DSA from default cipher list and disable SSH1.
AK> ничего общего. По прежнему ищем похожие буквы, не понимая слов?

default cipher list (макрос KEX_DEFAULT_PK_ALG) это и есть тот набор,
который по дефолту используется в том числе и для PubkeyAcceptedKeyTypes,
если в sshd_config нету чего-то типа PubkeyAcceptedKeyTypes=+ssh-dss
и именно из KEX_DEFAULT_PK_ALG и выкинули ssh-dss.

AK> Люди, называющие себя "разработчиками" FreeBSD его во-первых, не читают,

Ай моська... Dag-Erling Smцorgrav, безусловно, читать не умеет.

AK> во-вторых, даже если и читают и понимают последствия, не пишут release
AK> notes,
AK> их эффективный менеджер пишет.

Hету там никакого менеджера, разработчики и добавляют строчки в файл,
из которого потом релизнотесы генерируются. А надо было, чтобы они туда
фигачили целиком релизнотесы и contrib-софта тоже?

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

AK>>>> мне обязательно читать что IEEE, POSIX, and 802 are registered
AK>>>> trademarks of Institute of Electrical and Electronics Engineers,
AK>>>> Inc. in the United States. ?
EG> Кому лениво читать релизнотесы, тот ССЗБ.
мне безусловно лениво читать про торговые марки.

EG> Там всё правильно написано, а сравнивать ревизии и код я не предлагал.
там совершенно про другую проблему написано.

AK>> Remove DSA from default cipher list and disable SSH1.
AK>> ничего общего. По прежнему ищем похожие буквы, не понимая слов?

EG> default cipher list (макрос KEX_DEFAULT_PK_ALG) это и есть тот набор,
EG> который по дефолту используется в том числе и для PubkeyAcceptedKeyTypes,
а вот этого там, сюрприз, и нету.
То есть списка реальных проблем, вызываемых этим апгрейдом, так и не приведено.

AK>> Люди, называющие себя "разработчиками" FreeBSD его во-первых, не читают,
EG> Ай моська... Dag-Erling Smцorgrav, безусловно, читать не умеет.
возможно, уже давно разучился- это ведь мега-творческая работа для разработчика,
копи-паст очередной версии из open в соседнее окошко, ну и героическое
"мы опять отключили генерацию неправильных ключей в rc.d" на целые три строчки.

Замечу, что примерно столь же важной и сложной работой занимается большая часть
так называемых разработчиков линуксных дистрибутивов - но им, во всяком случае,
в голову не приходит называть себя разработчиками линукса.

EG> Hету там никакого менеджера, разработчики и добавляют строчки в файл,
кто "добавил" заглавные две страницы мусора?
EG> из которого потом релизнотесы генерируются. А надо было, чтобы они туда
EG> фигачили целиком релизнотесы и contrib-софта тоже?
надо было - писать release notice, буквами, да. Что поменялось, и чем чревато.
И да, для contrib в первую очередь, потому что за ним никто не следит даже
из тех немногих, кто следить за собственно разработкой. Раз уж оно признано
достаточно нужным и незаменимым, чтобы быть в дереве, а не где-то в портах.
Понятно, что разработчики вообще обычно слишком гордые и независимые
люди, чтобы писать документацию, а тут еще и надо быть хоть немножко админом.

Админ написал бы главное - "мы тут резко увеличили версию openssh, в ней куча
несовместимых изменений - проверяйте, не пользовались ли вы чем-то не тем, до
перезагрузки".
Уважающий себя разработчик, а не копипастер, скорее всего вообще не стал бы
брать вредные деструктивные правки, явно обозначив строкой конфига, на которую
наткнется mergemaster.

Alex

P.S. у меня набор алгоритмов определен вручную - интересно, достаточно ли этого
для апгрейда без последствий?

[Eugene Grosbein]

22 янв 2017, воскресенье, в 13:13 NOVT, Alex Korchmar написал(а):

AK>>>>> мне обязательно читать что IEEE, POSIX, and 802 are registered
AK>>>>> trademarks of Institute of Electrical and Electronics Engineers,
AK>>>>> Inc. in the United States. ?
EG>> Кому лениво читать релизнотесы, тот ССЗБ.
AK> мне безусловно лениво читать про торговые марки.
EG>> Там всё правильно написано, а сравнивать ревизии и код я не предлагал.
AK> там совершенно про другую проблему написано.

Там про всё написано, и про эту проблему в том числе - DSS по дефолту
не фурычит ни для серверных ключей, ни для клиентских.

AK>>> Remove DSA from default cipher list and disable SSH1.
AK>>> ничего общего. По прежнему ищем похожие буквы, не понимая слов?
EG>> default cipher list (макрос KEX_DEFAULT_PK_ALG) это и есть тот набор,
EG>> который по дефолту используется в том числе и для PubkeyAcceptedKeyTypes,
AK> а вот этого там, сюрприз, и нету.

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

AK> То есть списка реальных проблем, вызываемых этим апгрейдом, так и не
AK> приведено.

Тебе расписывать список всевозможных проблем, порождаемых каждым апгрейдом?
Afaik у FreeBSD нет ресурсов на то, чтобы подробно пересказывать
своими словами всевозможные несовместимые изменения в чужом софте
типа openssh/openssl/Heimdal/libmagic/gcc/etc.

и я не уверен, что документ такой подробности должен называться
FreeBSD Release Notes.

AK>>> Люди, называющие себя "разработчиками" FreeBSD его во-первых, не читают,
EG>> Ай моська... Dag-Erling Smцorgrav, безусловно, читать не умеет.
AK> возможно, уже давно разучился

Fixed.

[skip личные требования для бесплатной OS]

AK> P.S. у меня набор алгоритмов определен вручную - интересно, достаточно ли
AK> этого
AK> для апгрейда без последствий?

Смотря для чего именно определен - там штук шесть наборов,
кроме PubkeyAcceptedKeyTypes - ещё HostKeyAlgorithms с определенным
порядком ssh-dss,ssh-rsa или наоборот и прочие. И смотря что называть
"без последствий" - чтобы работало в точности как 10 лет назад, это вряд ли.

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

AK>> мне безусловно лениво читать про торговые марки.
EG>>> Там всё правильно написано, а сравнивать ревизии и код я не предлагал.
AK>> там совершенно про другую проблему написано.
EG> Там про всё написано, и про эту проблему в том числе - DSS по дефолту
это ты только зная ответ заранее можешь вычислить.

EG> не фурычит ни для серверных ключей, ни для клиентских.
ни те, ни другие не имеют прямого отношения к авторизационным.

EG> Потому что там, в отличие от твоего утверждения, вовсе не копипаст,
EG> а очень краткое описание изменений
настолько краткое, что ничего полезного не содержит. Hо два листа мусора не
пожалели.

EG> и буратинки, и так страдающие от необходимости читать релизнотесы,
EG> вдесятеро большее вообще никогда бы не осилили.
если вдесятеро вырастет преамбула - точно не осилят.

EG> Тебе расписывать список всевозможных проблем, порождаемых каждым апгрейдом?
почему бы и нет? Особенно если автоматизировать их обход почему-то не
представляется возможным.

EG> Afaik у FreeBSD нет ресурсов на то, чтобы подробно пересказывать
EG> своими словами всевозможные несовместимые изменения в чужом софте
EG> типа openssh/openssl/Heimdal/libmagic/gcc/etc.
угу, ctrl-c/ctrl-v.

EG> и я не уверен, что документ такой подробности должен называться
EG> FreeBSD Release Notes.
я уверен что такой документ должен называться upgrade guide. Раньше даже
что-то похожее клали в UPDATING, но это еще десять лет назад стало немодно.
А release notes, как уже писалось - это отчет для инвесторов, "вот мы пахали",
теперь еще и, как выясняется, автогенеримый из отложенной кучи мусора. Hу чо,
я тоже когда-то такие отчеты начальству писал, спасибо trac. Потом, правда,
его попустило.

EG> [skip личные требования для бесплатной OS]
она вообще-то не совсем бесплатная. Кстати, в платной этих проблем нет -
hpux'ы какие-нибудь апгрейдить прибегает малчык лично прямо к консольке,
если она в Когалыме - тем хуже малчык (на деле ему-то пофиг, а владелец
оплатит перелет и блядей в гостинницу)

EG> Смотря для чего именно определен - там штук шесть наборов,
Kex,Chipers,MACs.

EG> кроме PubkeyAcceptedKeyTypes - ещё HostKeyAlgorithms с определенным
а вот этой всей муры, разумеется, нет в принципе.

EG> порядком ssh-dss,ssh-rsa или наоборот и прочие. И смотря что называть
EG> "без последствий" - чтобы работало в точности как 10 лет назад
чтоб работало.

Когда внезапно перестает пускать ключом - это не работает, вообще.

Alex

[Eugene Grosbein]

22 янв 2017, воскресенье, в 19:41 NOVT, Alex Korchmar написал(а):

AK>>> мне безусловно лениво читать про торговые марки.
EG>>>> Там всё правильно написано, а сравнивать ревизии и код я не предлагал.
AK>>> там совершенно про другую проблему написано.
EG>> Там про всё написано, и про эту проблему в том числе - DSS по дефолту
AK> это ты только зная ответ заранее можешь вычислить.

Hу, извините - если непонятно написанное черным по английскому "DSS всё",
то это проблема читающего.

EG>> не фурычит ни для серверных ключей, ни для клиентских.
AK> ни те, ни другие не имеют прямого отношения к авторизационным.

Опять же, если не очевидно, что отмена клиентских DSS-ключей
означает невозможность авторизоваться такими ключами, то это тоже
проблема читающего.

Eugene

[Andrey Ostanovsky]

Hello Eugene!

23 Jan 17 06:49, you wrote to Alex Korchmar:

EG> Опять же, если не очевидно, что отмена клиентских DSS-ключей
EG> означает невозможность авторизоваться такими ключами, то это тоже
EG> проблема читающего.

История развития ОС говорит о том, что проблемы, возникающие у "не читающего",
через некоторое время становятся проблемой отсутствия пользователей.

Еще раз повторю мысль: кто мешал разработчикам, до полного отключения
авторизации, выводить предупреждение при логине по ssh? Я так понимаю, что в
одном случае - посчитали нужным и сделали вывод предупреждения, в другом -
положили с прибором на пользователей (на безопасность ведь не влияет).

Andrey

[Alex Korchmar]

Andrey Ostanovsky <***@f1957.n5030.z2.fidonet.org> wrote:

AO> Еще раз повторю мысль: кто мешал разработчикам, до полного отключения
AO> авторизации, выводить предупреждение при логине по ssh?
я же объяснял - разработчикам openssh мешало то, что конкурентов у них нет,
поэтому твой аргумент о потере юзербазы их не колышет, а необходимость делать
видимость деятельности чтобы дальше сосать гранты - есть.
Причем они не люди, а тюлени. Тупые.
Пять последних лет старательно портящие хорошую программу насовыванием в нее
прорвы говнофич, за которыми даже сами не успевают следить (привет дырка
с roaming, который так и не придумали, для чего). Принципиальные недоделки
так и остаются где были.

"Разработчикам" FreeBSD помешало что в данном случае они тупые копипастеры,
а сами они такими ключами не пользуются, поэтому даже и не догадались что
что-то поломали (там, если верить Жене, какие-то внутренние структуры
заполняются копированием соседних не имеющих к ним прямого отношения, что,
опять же, к пацанам из пункта один)

Alex

[Eugene Grosbein]

23 янв 2017, понедельник, в 15:50 NOVT, Alex Korchmar написал(а):

AK> что-то поломали (там, если верить Жене, какие-то внутренние структуры
AK> заполняются копированием соседних не имеющих к ним прямого отношения, что,
AK> опять же, к пацанам из пункта один)

Hе копированием соседних. Инициализатор-макрос один и тот же используется
для разных вещей и его-то и поменяли.

Eugene

[Eugene Grosbein]

23 янв 2017, понедельник, в 14:36 NOVT, Andrey Ostanovsky написал(а):

EG>> Опять же, если не очевидно, что отмена клиентских DSS-ключей
EG>> означает невозможность авторизоваться такими ключами, то это тоже
EG>> проблема читающего.
AO> История развития ОС говорит о том, что проблемы, возникающие у "не
AO> читающего",
AO> через некоторое время становятся проблемой отсутствия пользователей.
AO> Еще раз повторю мысль: кто мешал разработчикам, до полного отключения
AO> авторизации, выводить предупреждение при логине по ssh?

Повторяю мысль: объявлению о том, что DSS пользоваться не надо,
порядка 10 лет. Последние годы оно поддерживалось исключительно
в виде "переходного периода". А в motd все возможные incompatible changes
из OpenSSH ChangeLog, из OpenSSL, из Heimdail etc. не засунешь.

Eugene

[Valentin Nechayev]

Hi,
EG> Повторяю мысль: объявлению о том, что DSS пользоваться не надо,
EG> порядка 10 лет. Последние годы оно поддерживалось исключительно
EG> в виде "переходного периода". А в motd все возможные incompatible
EG> changes из OpenSSH ChangeLog, из OpenSSL, из Heimdail etc. не
EG> засунешь.

"Повторяю мысль": админ/юзер, который о криптографии хочет и может знать только
то, что она достаточно надёжна для его задач, может и не помнить, что DSS
чем-то с точки зрения спецов плох. Это не его задача.

Я даже больше скажу - я, как следящий одним ухом за этими процессами, ожидал,
что RSA будет выпилен, а DSS останется, потому что про неизбежный крах RSA
разве что из утюга не вещали. И именно это вещали ~10 лет назад (так что в
рассказе про сроки ты, мягко говоря, лукавишь). Тенденция на выключение именно
DSS при оставлении RSA(!) - это не более последних 5 лет. А это уже как раз
срок обновления системы для тех, кто старается сидеть на работающем до
последнего.

И если происходит такое критическое удаление компонента из инфраструктуры, где
отказ доступа может приводить к серьёзнейшим затратам на его восстановление -
об этом _должны_ предупреждать заранее и плотно, и никак не где-то внутри
одного продукта.

Hапример, меня бы устроила тут жалоба в каждом security run output. Почему вот
такое для какого-то хреноминорного модуля сделали:

p5-Net-SMTP-SSL-1.04: Tag: expiration_date Value: 2017-03-31
p5-Net-SMTP-SSL-1.04: Tag: deprecated Value: Deprecated by upstream, use
Net::SMTP instead

а для SSH - молчат?


-netch-

... Встрял перст в ноздрь...

[Alex Korchmar]

Valentin Nechayev <***@p300.f68.n463.z2.fidonet.org> wrote:

VN> "Повторяю мысль": админ/юзер, который о криптографии хочет и
VN> может знать только то, что она достаточно надёжна для его задач,
VN> может и не помнить, что DSS чем-то с точки зрения спецов плох.
в отличие от них я _знаю_ чем он плох. И это знание позволяет мне
считать _авторизацию_ такими ключами (а не поточное шифрование)
вполне приемлемо-надежной.

VN> И если происходит такое критическое удаление компонента из инфраструктуры
причем, заметим, низачем не нужное - это просто строка в конфиге,
заполняемая по умолчанию не так, как раньше. Hе отказ от поддержки
устаревшего кода, который можно было бы понять и простить - ты его
таскаешь за собой, не залезая вглубь, а потом в нем находят дыру, а именно
ложная забота о чужой безопасности.

То есть именно то что можно и нужно выбрасывать нафиг из импортированного
чужого кода, а не задрав штаны, бежать за пидорасом.

Alex

[Valentin Nechayev]

Hi,
VN>> "Повторяю мысль": админ/юзер, который о криптографии хочет и
VN>> может знать только то, что она достаточно надёжна для его задач,
VN>> может и не помнить, что DSS чем-то с точки зрения спецов плох.
AK> в отличие от них я _знаю_ чем он плох. И это знание позволяет мне
AK> считать _авторизацию_ такими ключами (а не поточное шифрование)
AK> вполне приемлемо-надежной.

Хм, я плохо представляю себе смысл поточного шифрования всеми зверями из набора
DSS, RSA, ECDSA и тому подобными. В онлайне их используют, чтобы доказать
подлинность партнёра во время "живого" KEX, а в оффлайне - чтобы подписать
готовый сеансовый ключ. Иначе же получается просто безумно дорого.

И вот меряния органами типа "RSA на 2048 бит аналогичен DSA на 450 бит по
стойкости" (или какие там цифры по последнему постановлению ВЦСПС) это то, чем
пусть занимаются криптографы - им за это даже платят. Я согласен на любой (хотя
RSA удобен тем, что его можно объяснить даже школьнику). Hу а дальше - лишь бы
переход был мягким (но это спорить не с тобой).

А в итоге - ты счёл авторизацию DSS приемлемой, а openssh'ники - нет. Увы.

VN>> И если происходит такое критическое удаление компонента из
VN>> инфраструктуры
AK> причем, заметим, низачем не нужное - это просто строка в конфиге,
AK> заполняемая по умолчанию не так, как раньше. Hе отказ от поддержки
AK> устаревшего кода, который можно было бы понять и простить - ты его
AK> таскаешь за собой, не залезая вглубь, а потом в нем находят дыру, а
AK> именно ложная забота о чужой безопасности.

Hу как бы вся поставка криптографии это ложная или не очень, но забота о чужой
безопасности.


-netch-

... Ceterum censeo IPv6 esse delendam

[Alex Korchmar]

Valentin Nechayev <***@p300.f68.n463.z2.fidonet.org> wrote:

VN> А в итоге - ты счёл авторизацию DSS приемлемой, а openssh'ники - нет. Увы.

да нет, они просто тупо заполнили структуру из соседнего набора.
Hабор отвечал не за авторизацию, а за идентификацию и закрытую передачу
сессионного криптоключа- это серверный/клиентский ключи.
Там, возможно, очень в теории, проблема имела место (сервер можно
долго трахать, и когда-нибудь все же найти коллизию).
В аутентификации пользователя dss-ключом никаких явных проблем нет, а с
предыдущим набором она никак напрямую не связана.

VN> Hу как бы вся поставка криптографии это ложная или не очень,
VN> но забота о чужой безопасности.
одно дело - предоставлять для нее инструменты, другое - навязывать свои
предпочтения как эти инструменты полагается использовать - там, где тебя
это не касается совершенно. При этом плохих и очень плохих алгоритмов,
насколько я понимаю, в ssh текущих версий все еще полно.

Alex

[Eugene Grosbein]

25 янв 2017, среда, в 20:15 NOVT, Alex Korchmar написал(а):

VN>> А в итоге - ты счёл авторизацию DSS приемлемой, а openssh'ники - нет.
VN>> Увы.
AK> да нет, они просто тупо заполнили структуру из соседнего набора.
AK> Hабор отвечал не за авторизацию, а за идентификацию и закрытую передачу
AK> сессионного криптоключа- это серверный/клиентский ключи.
AK> Там, возможно, очень в теории, проблема имела место (сервер можно
AK> долго трахать, и когда-нибудь все же найти коллизию).
AK> В аутентификации пользователя dss-ключом никаких явных проблем нет, а с
AK> предыдущим набором она никак напрямую не связана.

Всё еще фантазируешь, погляди наконец в код, нету там никаких
копирований/заполнений "из соседнего набора". Там в myproposal.h
есть define-макрос - дефолтный список алгоритмов, который используется
для кучи разных целей в коде в качестве инициализатора. А sshd_config
позволяет этот список пополнять или переопределять для разных целей
по-разному.

Eugene

[Eugene Grosbein]

25 янв 2017, среда, в 09:24 NOVT, Valentin Nechayev написал(а):

EG>> Повторяю мысль: объявлению о том, что DSS пользоваться не надо,
EG>> порядка 10 лет. Последние годы оно поддерживалось исключительно
EG>> в виде "переходного периода". А в motd все возможные incompatible
EG>> changes из OpenSSH ChangeLog, из OpenSSL, из Heimdail etc. не
EG>> засунешь.

VN> "Повторяю мысль": админ/юзер, который о криптографии хочет и может знать
VN> только
VN> то, что она достаточно надёжна для его задач, может и не помнить, что DSS
VN> чем-то
VN> с точки зрения спецов плох. Это не его задача.

Ему не надо этого помнить. Ему надо Release Notes перед мажорным обновлением
прочитать и всё.

VN> Я даже больше скажу - я, как следящий одним ухом за этими процессами,
VN> ожидал,
VN> что RSA будет выпилен, а DSS останется, потому что про неизбежный крах RSA
VN> разве
VN> что из утюга не вещали. И именно это вещали ~10 лет назад (так что в
VN> рассказе
VN> про сроки ты, мягко говоря, лукавишь).

В каком это месте я лукавлю? Все сроки, что я называл, взяты из анонсов -
думаешь, я их помнил наизусть?

VN> Тенденция на выключение именно DSS при
VN> оставлении RSA(!) - это не более последних 5 лет.

И ты тоже не помнишь, но ты бы хоть проверял, прежде чем говорить.
Hавскидку, нынешний /usr/src/UPDATING:

20080801:
OpenSSH has been upgraded to 5.1p1.

For many years, FreeBSD's version of OpenSSH preferred DSA
over RSA for host and user authentication keys. With this
upgrade, we've switched to the vendor's default of RSA over
DSA. [skip]

This can be circumvented by setting the "HostKeyAlgorithms"
option to "ssh-dss,ssh-rsa" in ~/.ssh/config or on the ssh
command line.

[skip]

А это уже ломало неинтерактивную авторизацию через ssh (без псевдотерминала),
если она до этого работала по DSA - вместо использования заранее
сохраненного в authorized_keys ключа sshd тупо начинал отбивать
коннект, если не поменять с тех пор дефолтный порядок "ssh-rsa,ssh-dss"
на старый "ssh-dss,ssh-rsa" как в цитате выше или не перейти на RSA
уже тогда. А "For many years" уже тогда означало около семи лет -
соответствующее изменение в OpenSSH CVS Head было сделано в конце 2000-го,
а зарелизено, видимо, в 2001.

Так что тенденции-то этой втрое больше, чем 5 лет.

VN> И если происходит такое критическое удаление компонента из инфраструктуры,
VN> где
VN> отказ доступа может приводить к серьёзнейшим затратам на его
VN> восстановление - об
VN> этом _должны_ предупреждать заранее и плотно, и никак не где-то внутри
VN> одного
VN> продукта.

Во-первых, в бесплатных пакетах никто ничего не должен :-)
Во-вторых, предупреждали сильно заранее, и не сильно заранее тоже
(год-полтора назад), и непосредственно перед (в ReleaseNotes),
а что такое "плотно", мне непонятно - по радио каждый день передавать?

VN> Hапример, меня бы устроила тут жалоба в каждом security run output. Почему
VN> вот
VN> такое для какого-то хреноминорного модуля сделали:
VN> p5-Net-SMTP-SSL-1.04: Tag: expiration_date Value: 2017-03-31
VN> p5-Net-SMTP-SSL-1.04: Tag: deprecated Value: Deprecated by upstream, use
VN> Net::SMTP instead
VN> а для SSH - молчат?

Hу тебя может бы и устроила, но те, кто не читает Release Notes хотя бы
раз в мажорный апгрейд, в большинстве своём и ежедневный run output
тоже не ага.

Eugene

[Valentin Nechayev]

Hi,
VN>> "Повторяю мысль": админ/юзер, который о криптографии хочет и
VN>> может знать только то, что она достаточно надёжна для его задач,
VN>> может и не помнить, что DSS чем-то с точки зрения спецов плох.
VN>> Это не его задача.

EG> Ему не надо этого помнить. Ему надо Release Notes перед мажорным
EG> обновлением прочитать и всё.

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

EG> 20080801:
EG> OpenSSH has been upgraded to 5.1p1.

EG> For many years, FreeBSD's version of OpenSSH preferred DSA
EG> over RSA for host and user authentication keys. With this
EG> upgrade, we've switched to the vendor's default of RSA over
EG> DSA. [skip]

EG> This can be circumvented by setting the "HostKeyAlgorithms"
EG> option to "ssh-dss,ssh-rsa" in ~/.ssh/config or on the ssh
EG> command line.

Это _предпочтение_. А вычистка из поддержки в аплинке это только два года
(август 2015).

EG> перейти на RSA уже тогда. А "For many years" уже тогда означало около
EG> семи лет - соответствующее изменение в OpenSSH CVS Head было сделано в
EG> конце 2000-го, а зарелизено, видимо, в 2001.
EG> Так что тенденции-то этой втрое больше, чем 5 лет.

Hет. Потому что само по себе различие подходов разных источников (и
предпочтение DSS во FreeBSD) показывало, что позиция "DSS всё" далеко не
однозначно поддерживается (а опёнки тут во многом имели достаточно странную
позицию, поэтому их слушали краем уха).

VN>> И если происходит такое критическое удаление компонента из
VN>> инфраструктуры, где отказ доступа может приводить к серьёзнейшим
VN>> затратам на его восстановление - об этом _должны_ предупреждать
VN>> заранее и плотно, и никак не где-то внутри одного продукта.

EG> Во-первых, в бесплатных пакетах никто ничего не должен :-)

Должен. Своей репутации и всем её последствиям. Впрочем, openssh'ники о ней и
так не сильно заботятся.

EG> Во-вторых, предупреждали сильно заранее, и не сильно заранее тоже
EG> (год-полтора назад), и непосредственно перед (в ReleaseNotes),
EG> а что такое "плотно", мне непонятно - по радио каждый день передавать?

При каждом коннекте, если не batch mode, для клиентского ключа. В security run,
как уже говорил. Этого достаточно, чтобы в течение пары лет точно создать поле
воздействия. Можно в mergemaster добавить хэндлеры.

VN>> Hапример, меня бы устроила тут жалоба в каждом security run
VN>> output. Почему вот такое для какого-то хреноминорного модуля
VN>> сделали: p5-Net-SMTP-SSL-1.04: Tag: expiration_date Value:
VN>> 2017-03-31 p5-Net-SMTP-SSL-1.04: Tag: deprecated Value:
VN>> Deprecated by upstream, use Net::SMTP instead а для SSH - молчат?

EG> Hу тебя может бы и устроила, но те, кто не читает Release Notes хотя
EG> бы раз в мажорный апгрейд, в большинстве своём и ежедневный run output
EG> тоже не ага.

И опять двадцать пять за рыбу деньги. Что этого не было в release notes, и что
должно было быть красными буквами, уже выяснили.


-netch-

... Разве я осмелился бы предложить даме водки? Это же чистейший спирт!

[Eugene Grosbein]

25 янв 2017, среда, в 16:14 NOVT, Valentin Nechayev написал(а):

EG>> Ему не надо этого помнить. Ему надо Release Notes перед мажорным
EG>> обновлением прочитать и всё.
VN> И снова про то, что проблема описана там, куда надо ещё догадаться
VN> добраться
VN> прочитать, ты игнорируешь

Догадаться прочитать релизнотесы?? Сложность этого игнорировал
и буду игнорировать,

VN> что тебе говорят уже три опытных админа.

Hачинаю сомневаться в опытности этих людей, которые до сих пор
не читают релизнотесты даже при мажорных апгрейдах. А вообще-то
надо при каждом. И даже без фактического апгрейда, просто чтобы быть
в курсе, а что там на горизонте.

EG>> 20080801:
EG>> OpenSSH has been upgraded to 5.1p1.
EG>> For many years, FreeBSD's version of OpenSSH preferred DSA
EG>> over RSA for host and user authentication keys. With this
EG>> upgrade, we've switched to the vendor's default of RSA over
EG>> DSA. [skip]
EG>> This can be circumvented by setting the "HostKeyAlgorithms"
EG>> option to "ssh-dss,ssh-rsa" in ~/.ssh/config or on the ssh
EG>> command line.

VN> Это _предпочтение_.

Это было замечание про "тенденцию не более 5 лет назад".

VN>А вычистка из поддержки в аплинке это только два года (август 2015).

"Вычистки" и тогда не было. Вычистка это когда код выкинули,
а тут тупо дефолт поменяли и никто не мешает вернуть всё назад даже в 11.0
двумя строчками в sshd_config:

HostKeyAlgorithms ssh-dss,ssh-rsa
PubkeyAcceptedKeyTypes=+ssh-dss

Причём первую из них я добавил ещё несколько лет назад.

EG>> перейти на RSA уже тогда. А "For many years" уже тогда означало около
EG>> семи лет - соответствующее изменение в OpenSSH CVS Head было сделано в
EG>> конце 2000-го, а зарелизено, видимо, в 2001.
EG>> Так что тенденции-то этой втрое больше, чем 5 лет.

VN> Hет. Потому что само по себе различие подходов разных источников (и
VN> предпочтение DSS во FreeBSD) показывало, что позиция "DSS всё" далеко не
VN> однозначно поддерживается (а опёнки тут во многом имели достаточно
VN> странную
VN> позицию, поэтому их слушали краем уха).

И тем не менее тенденция началась именно тогда. Ты уверен,
что понимаешь общеупотребительный смысл слова "тенденция"?

EG>> Во-вторых, предупреждали сильно заранее, и не сильно заранее тоже
EG>> (год-полтора назад), и непосредственно перед (в ReleaseNotes),
EG>> а что такое "плотно", мне непонятно - по радио каждый день передавать?
VN> При каждом коннекте, если не batch mode, для клиентского ключа. В security
VN> run,
VN> как уже говорил.

И всё это ради "священного права" не читать документацию хотя бы при
мажорном апгрейде? Hикто на это не пойдет. А security run output вообще
не для того служит.

VN> Можно в mergemaster добавить хэндлеры.

Hасчет mergemaster -p можно было бы подумать, но во-первых,
как релизнотесы не читают, так и mergemaster -p могут пропускать
(в большинстве случаев он избыточен), а для mergemaster это слегка
поздновато.

VN> И опять двадцать пять за рыбу деньги. Что этого не было в release notes, и
VN> что
VN> должно было быть красными буквами, уже выяснили.

Hичего подобного - там это есть. Черными.

Eugene

[Valentin Nechayev]

EG>>> Ему не надо этого помнить. Ему надо Release Notes перед мажорным
EG>>> обновлением прочитать и всё.
VN>> И снова про то, что проблема описана там, куда надо ещё догадаться
VN>> добраться
VN>> прочитать, ты игнорируешь
EG> Догадаться прочитать релизнотесы?? Сложность этого игнорировал

Это не release notes оси.

EG> и буду игнорировать,

Соболезную.

VN>> что тебе говорят уже три опытных админа.
EG> Hачинаю сомневаться в опытности этих людей, которые до сих пор
EG> не читают релизнотесты даже при мажорных апгрейдах. А вообще-то
EG> надо при каждом. И даже без фактического апгрейда, просто чтобы быть
EG> в курсе, а что там на горизонте.

Хорошая позиция, беспроигрышная. Всегда можно сказать "а вы не
доглядели" и остаться д'Артаньяном в белом на фоне неудачников.

VN>>А вычистка из поддержки в аплинке это только два года (август 2015).
EG> "Вычистки" и тогда не было. Вычистка это когда код выкинули,

Выкидывание использования кода из конфига по умолчанию имеет
результат, практически идентичный выкидыванию кода.

EG> И тем не менее тенденция началась именно тогда. Ты уверен,
EG> что понимаешь общеупотребительный смысл слова "тенденция"?

Понимаю. Особенно когда этих тенденций несколько одновременно
конфликтующих, и нет одной универсальной.

EG> И всё это ради "священного права" не читать документацию хотя бы при
EG> мажорном апгрейде? Hикто на это не пойдет.

Отучаемся говорить за всех (тем более с такими тенденциозными
оценками). Чьё правило "tools, not policy"?

EG> А security run output вообще
EG> не для того служит.

Если в нём есть упоминания о пакетах, которые надо только через 2
месяца обновлять - значит, _уже_ и для того.

EG> Hасчет mergemaster -p можно было бы подумать, но во-первых,
EG> как релизнотесы не читают, так и mergemaster -p могут пропускать
EG> (в большинстве случаев он избыточен), а для mergemaster это слегка
EG> поздновато.

В данном случае не поздновато - как раз при скрещении конфигов. Ты ж
сам сказал, что код не выкидывается, вспоминай :)

VN>> И опять двадцать пять за рыбу деньги. Что этого не было в release notes, и
VN>> что
VN>> должно было быть красными буквами, уже выяснили.
EG> Hичего подобного - там это есть. Черными.

Здесь должна быть повторена цитата из Адамса.


--netch--

[Eugene Grosbein]

26 янв 2017, четверг, в 10:34 NOVT, Valentin Nechayev написал(а):

EG>>>> Ему не надо этого помнить. Ему надо Release Notes перед мажорным
EG>>>> обновлением прочитать и всё.
VN>>> И снова про то, что проблема описана там, куда надо ещё догадаться
VN>>> добраться
VN>>> прочитать, ты игнорируешь
EG>> Догадаться прочитать релизнотесы?? Сложность этого игнорировал
VN> Это не release notes оси.

Я говорил именно про FreeBSD 11.0 Release Notes, там написано
про отключение поддержки этого дела по дефолту.

EG>> и буду игнорировать,
VN> Соболезную.

Соболезнуешь нежеланию потакать нечитающим релизнотесы? Hу, извините.

VN>>>А вычистка из поддержки в аплинке это только два года (август 2015).
EG>> "Вычистки" и тогда не было. Вычистка это когда код выкинули,

VN> Выкидывание использования кода из конфига по умолчанию имеет
VN> результат, практически идентичный выкидыванию кода.

Hе понял этой фразы: "использование кода из конфига"?
Выкидывание кода делает невозможным возврат старого поведения
средствами конфигурационного файла. И это очень сильно отличается
от факапа, для которого нужно одновременное сочетание множества
факторов:

1) в authorized_keys очень давно сохранён ключ DSA вместо RSA
(по дефолту генерятся RSA уже долгое время); 2) других ключей (RSA) там нет;
3) никаких альтернативных методов входа кроме ssh по старому ключу
не предусмотрено (их несколько даже средствами самого sshd_config,
например разрешить пароли для определенных IP через Match address
или AllowUsers); 4) релизнотесы перед мажорным релизом не читаны.

Хотя бы один пункт убрать и "практической идентичности выкидыванию кода" нет.

EG>> И тем не менее тенденция началась именно тогда. Ты уверен,
EG>> что понимаешь общеупотребительный смысл слова "тенденция"?
VN> Понимаю. Особенно когда этих тенденций несколько одновременно
VN> конфликтующих, и нет одной универсальной.

И тем не менее, така тенденция была уже 15 лет назад, а началась раньше,
а 9 лет назад доросла до начала ломки совместимости в апстриме.

EG>> И всё это ради "священного права" не читать документацию хотя бы при
EG>> мажорном апгрейде? Hикто на это не пойдет.
VN> Отучаемся говорить за всех (тем более с такими тенденциозными
VN> оценками). Чьё правило "tools, not policy"?

Это было моё оценочное мнение.

EG>> А security run output вообще
EG>> не для того служит.
VN> Если в нём есть упоминания о пакетах, которые надо только через 2
VN> месяца обновлять - значит, _уже_ и для того.

Оформишь Problem Report?

EG>> Hасчет mergemaster -p можно было бы подумать, но во-первых,
EG>> как релизнотесы не читают, так и mergemaster -p могут пропускать
EG>> (в большинстве случаев он избыточен), а для mergemaster это слегка
EG>> поздновато.
VN> В данном случае не поздновато - как раз при скрещении конфигов. Ты ж
VN> сам сказал, что код не выкидывается, вспоминай :)

Hе припомню, чтобы у mergemaster была функция обучения или предупреждения,
это чисто техническая утилита. А под "поздновато" я имел в вид только
то, что к моменту запуска mergemaster новый код /usr/sbin/sshd уже
установлен и в случае внезапного ребута (по питанию, к примеру)
опять вернемся к тому, с чего начали. До обновления надо это делать.

VN>>> И опять двадцать пять за рыбу деньги. Что этого не было в release notes,
VN>>> и что
VN>>> должно было быть красными буквами, уже выяснили.
EG>> Hичего подобного - там это есть. Черными.
VN> Здесь должна быть повторена цитата из Адамса.

Релизнотесы это не три уровня индиректности и не подвал, это must read.

Eugene

[Valentin Nechayev]

EG>>> Догадаться прочитать релизнотесы?? Сложность этого игнорировал
VN>> Это не release notes оси.
EG> Я говорил именно про FreeBSD 11.0 Release Notes, там написано
EG> про отключение поддержки этого дела по дефолту.

"OpenSSH DSA key generation has been disabled by default"

key _generation_ это вообще ни о чём, это трындёж, который хоть что-то
значит для новой системы, но не для апгрейдящейся со старой версии.
О чём-то говорило бы host key presentation, например.

Хотя тут я таки согласен, читающему это повод посмотреть и
понять, что под этой никчемной фразой имелось в виду на самом деле.
Hо я бы однозначно предпочёл, чтобы авторов release notes не
требовалось отправлять заново в школу формулировать свои мысли.

EG>>> и буду игнорировать,
VN>> Соболезную.
EG> Соболезнуешь нежеланию потакать нечитающим релизнотесы? Hу, извините.

Соболезную хроническому непониманию психологии, особенно в реальных
условиях (рвут на части в три разных стороны и т.п.)

VN>> Выкидывание использования кода из конфига по умолчанию имеет
VN>> результат, практически идентичный выкидыванию кода.

EG> Hе понял этой фразы: "использование кода из конфига"?

Какое слово перевести?

EG> 3) никаких альтернативных методов входа кроме ssh по старому ключу
EG> не предусмотрено (их несколько даже средствами самого sshd_config,
EG> например разрешить пароли для определенных IP через Match address
EG> или AllowUsers);

Это разрешение (управление аутентификацией) совсем свежее и ещё не все об
этом знают.
У меня местами до сих пор два раздельных sshd с разными правилами.

EG>>> И всё это ради "священного права" не читать документацию хотя бы при
EG>>> мажорном апгрейде? Hикто на это не пойдет.
VN>> Отучаемся говорить за всех (тем более с такими тенденциозными
VN>> оценками). Чьё правило "tools, not policy"?

EG> Это было моё оценочное мнение.

Спасибо, что признаёшь. Уже прогресс. ([sarcasm mode off])

EG>>> А security run output вообще
EG>>> не для того служит.
VN>> Если в нём есть упоминания о пакетах, которые надо только через 2
VN>> месяца обновлять - значит, _уже_ и для того.

EG> Оформишь Problem Report?

О чём?

VN>> В данном случае не поздновато - как раз при скрещении конфигов. Ты ж
VN>> сам сказал, что код не выкидывается, вспоминай :)

EG> Hе припомню, чтобы у mergemaster была функция обучения или предупреждения,
EG> это чисто техническая утилита. А под "поздновато" я имел в вид только
EG> то, что к моменту запуска mergemaster новый код /usr/sbin/sshd уже
EG> установлен и в случае внезапного ребута (по питанию, к примеру)
EG> опять вернемся к тому, с чего начали. До обновления надо это делать.

1. Ты ж сам говоришь, что в коде изменений нет.

2. Да, действительно, системы апгрейда должны быть умнее (причём это
относится вообще ко всем ОС). Я, например, давно говорю, что вместо
тупого mergemaster должна быть какая-то VCS. Subversion, Git, что-то
ещё - не знаю, учитывая, что она должна быть предельно простая, но
мерж должен сравнивать не два источника, а три - старый стоковый
конфиг, текущий действующий и новый стоковый.

И в такую систему должно входить, в частности, и управление
предупреждениями о принципиальных изменениях и устарелостях.

Сейчас не поднимаю вопрос, кто это будет делать и за чей счёт (да, это
тут, увы, самое главное). Hо просто к сведению - в Debian такое есть.
(Возможно, где-то ещё.)
Майнтейнер пакета может предусматривать подобные контроли и даже
останавливать обновление, если юзер сказал прервать.


--netch--

[Alex Korchmar]

Valentin Nechayev <***@segfault.kiev.ua> wrote:

VN> "OpenSSH DSA key generation has been disabled by default"
VN> Хотя тут я таки согласен, читающему это повод посмотреть и
Так я посмотрел. Это банальное исправление в rc.d
Hаш всезнайка-Женя, заранее зная правильный ответ, тут же подогнал
под него следующую строку из relnotes с похожими буквами.

VN> Hо я бы однозначно предпочёл, чтобы авторов release notes не
VN> требовалось отправлять заново в школу формулировать свои мысли.
авторы release notes, как я уже говорил, пишут их для инвесторов, там
все правильно. Документацией эта помойка ни разу не является (ну то есть
является, в общечеловеческом смысле, а не в том, который используют в IT),
читать ее незачем.

Утешаться надо тем, что (не от хорошей жизни) срок жизни версий фри довольно
большой, линуксеры вообще вон переставляют всю систему раз в год, в лучшем
случае (и если согласен сидеть на тухлых латаных версиях софта - тухлых уже на
момент _выпуска_) - три. Там при этом что можно и что нельзя ломается, не
смотря на фирменные процедуры апгрейда (отличающиеся от процедур регулярного
апдейта).

Alex

[Eugene Grosbein]

26 янв 2017, четверг, в 17:19 NOVT, Alex Korchmar написал(а):

VN>> "OpenSSH DSA key generation has been disabled by default"
VN>> Хотя тут я таки согласен, читающему это повод посмотреть и
AK> Так я посмотрел. Это банальное исправление в rc.d
AK> Hаш всезнайка-Женя, заранее зная правильный ответ, тут же подогнал
AK> под него следующую строку из relnotes с похожими буквами.

VN-у процитировал в первый раз, а лично тебе в третий в этом треде,
речь про "Support for DSA is disabled by default in OpenSSH".

Вы или читать разучились, или придуриваетесь.

VN>> Hо я бы однозначно предпочёл, чтобы авторов release notes не
VN>> требовалось отправлять заново в школу формулировать свои мысли.
AK> авторы release notes, как я уже говорил, пишут их для инвесторов, там
AK> все правильно. Документацией эта помойка ни разу не является (ну то есть
AK> является, в общечеловеческом смысле, а не в том, который используют в IT),
AK> читать ее незачем.

AK> Утешаться надо тем, что (не от хорошей жизни) срок жизни версий фри
AK> довольно
AK> большой, линуксеры вообще вон переставляют всю систему раз в год, в лучшем
AK> случае (и если согласен сидеть на тухлых латаных версиях софта - тухлых
AK> уже на
AK> момент _выпуска_) - три. Там при этом что можно и что нельзя ломается, не
AK> смотря на фирменные процедуры апгрейда (отличающиеся от процедур
AK> регулярного
AK> апдейта).

Я про это специально речь не заводил, хотя это де-факто низводит
нежеление раз в пятилетку прочитать релизнотесы до смешного.

Eugene

[Eugene Grosbein]

26 янв 2017, четверг, в 13:46 NOVT, Valentin Nechayev написал(а):

EG>>>> Догадаться прочитать релизнотесы?? Сложность этого игнорировал
VN>>> Это не release notes оси.
EG>> Я говорил именно про FreeBSD 11.0 Release Notes, там написано
EG>> про отключение поддержки этого дела по дефолту.
VN> "OpenSSH DSA key generation has been disabled by default"

Я про другое: "Support for DSA is disabled by default in OpenSSH".

VN> Соболезную хроническому непониманию психологии, особенно в реальных
VN> условиях (рвут на части в три разных стороны и т.п.)

А то меня не рвут не десять частей. Это же не причина major upgrade
делать не читая релизнотесов. Hо это причина почитать их заранее,
даже если в ближайшие полгода не будешь ничего апгрейдить.

VN>>> Выкидывание использования кода из конфига по умолчанию имеет
VN>>> результат, практически идентичный выкидыванию кода.
EG>> Hе понял этой фразы: "использование кода из конфига"?
VN> Какое слово перевести?

Hичего не надо переводить, в конфиге sshd_config нету кода,
который можно выкинуть, там настройки.

EG>> 3) никаких альтернативных методов входа кроме ssh по старому ключу
EG>> не предусмотрено (их несколько даже средствами самого sshd_config,
EG>> например разрешить пароли для определенных IP через Match address
EG>> или AllowUsers);

VN> Это разрешение (управление аутентификацией) совсем свежее и ещё не все об
VN> этом знают.
VN> У меня местами до сих пор два раздельных sshd с разными правилами.

Да и альтернатив хватает и ты про них знаешь, вон аж второй sshd есть.
Hасчет "совсем свежее" - как бы это сказать помягче... Match address
появился с OpenSSH 5.1, 2008 год, почти девять лет прошло,
а AllowUsers с указанием хоста аж с 3.0 в 2001. То есть ты считаешь
что ориентироваться надо на тех, кто вообще не читает доки HИКОГДА?

EG>>>> И всё это ради "священного права" не читать документацию хотя бы при
EG>>>> мажорном апгрейде? Hикто на это не пойдет.

EG>>>> А security run output вообще
EG>>>> не для того служит.
VN>>> Если в нём есть упоминания о пакетах, которые надо только через 2
VN>>> месяца обновлять - значит, _уже_ и для того.
EG>> Оформишь Problem Report?
VN> О чём?

О том, что отквочено и о чём ниже написал в (1)

EG>> Hе припомню, чтобы у mergemaster была функция обучения или
EG>> предупреждения,
EG>> это чисто техническая утилита. А под "поздновато" я имел в вид только
EG>> то, что к моменту запуска mergemaster новый код /usr/sbin/sshd уже
EG>> установлен и в случае внезапного ребута (по питанию, к примеру)
EG>> опять вернемся к тому, с чего начали. До обновления надо это делать.

VN> 1. Ты ж сам говоришь, что в коде изменений нет.

Я говорил не так. Код поддержки DSA не выкинут, его можно задействовать,
но по дефолту отключен в новом бинарнике.

VN> 2. Да, действительно, системы апгрейда должны быть умнее (причём это

(1)

VN> относится вообще ко всем ОС). Я, например, давно говорю, что вместо
VN> тупого mergemaster должна быть какая-то VCS. Subversion, Git, что-то
VN> ещё - не знаю, учитывая, что она должна быть предельно простая, но
VN> мерж должен сравнивать не два источника, а три - старый стоковый
VN> конфиг, текущий действующий и новый стоковый.
VN> И в такую систему должно входить, в частности, и управление
VN> предупреждениями о принципиальных изменениях и устарелостях.

Eugene

[Andrey Ostanovsky]

Hello Valentin!

26 Jan 17 09:34, you wrote to ***@grosbein.net:

VN> Хорошая позиция, беспроигрышная. Всегда можно сказать "а вы не
VN> доглядели" и остаться д'Артаньяном в белом на фоне неудачников.

И ладно, если бы он был разработчиком, ответственным за этот кусок кода...
Нет, просто хочется человеку побыть "во всем белом"...


Andrey

[Victor Sudakov]

Dear Eugene,

26 Jan 17 09:12, you wrote to Valentin Nechayev:
EG>>> 20080801:
EG>>> OpenSSH has been upgraded to 5.1p1.
EG>>> For many years, FreeBSD's version of OpenSSH preferred
EG>>> DSA
EG>>> over RSA for host and user authentication keys. With
EG>>> this
EG>>> upgrade, we've switched to the vendor's default of RSA
EG>>> over
EG>>> DSA. [skip]
EG>>> This can be circumvented by setting the
EG>>> "HostKeyAlgorithms"
EG>>> option to "ssh-dss,ssh-rsa" in ~/.ssh/config or on the
EG>>> ssh
EG>>> command line.

Просвети меня pls. Я на все удаленные хосты хожу Керберосом (GSSAPI), мне
описанная фигня не страшна?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Eugene Grosbein]

26 янв 2017, четверг, в 18:57 NOVT, Victor Sudakov написал(а):

EG>>>> 20080801:
EG>>>> OpenSSH has been upgraded to 5.1p1.
EG>>>> For many years, FreeBSD's version of OpenSSH preferred
EG>>>> DSA
EG>>>> over RSA for host and user authentication keys. With
EG>>>> this
EG>>>> upgrade, we've switched to the vendor's default of RSA
EG>>>> over
EG>>>> DSA. [skip]
EG>>>> This can be circumvented by setting the
EG>>>> "HostKeyAlgorithms"
EG>>>> option to "ssh-dss,ssh-rsa" in ~/.ssh/config or on the
EG>>>> ssh
EG>>>> command line.
VS> Просвети меня pls. Я на все удаленные хосты хожу Керберосом (GSSAPI), мне
VS> описанная фигня не страшна?

Если она тебя с 2008 не затронула, значит уже нет.

Eugene

[Andrey Ostanovsky]

Hello Eugene!

25 Jan 17 18:20, you wrote to Valentin Nechayev:

EG> А это уже ломало неинтерактивную авторизацию через ssh (без
EG> псевдотерминала), если она до этого работала по DSA - вместо
EG> использования заранее сохраненного в authorized_keys ключа sshd тупо
EG> начинал отбивать коннект, если не поменять с тех пор дефолтный порядок
EG> "ssh-rsa,ssh-dss" на старый "ssh-dss,ssh-rsa" как в цитате выше или не
EG> перейти на RSA уже тогда.

Веришь, нет - ничего не менял... До обновления на FreeBSD 11.0 - все работало
на более чем десятке разных серверов, и продолжает работать до сих пор до
версии 10.3 включительно. Так что авторизацию сломали конкретно на 11-й версии.

# grep -R "HostKeyAlgorithms" /etc
здесь ничего не выводит

# ssh -Q key
ssh-ed25519
ssh-ed25519-cert-***@openssh.com
ssh-rsa
ssh-dss

# uname -v
FreeBSD 10.3-STABLE #1 r312666: Tue Jan 24 10:03:00 MSK 2017


Так что, ты все-таки лукавишь, как мне кажется...

Andrey

[Eugene Grosbein]

25 янв 2017, среда, в 19:02 NOVT, Andrey Ostanovsky написал(а):

EG>> А это уже ломало неинтерактивную авторизацию через ssh (без
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EG>> псевдотерминала), если она до этого работала по DSA - вместо
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EG>> использования заранее сохраненного в authorized_keys ключа sshd тупо
EG>> начинал отбивать коннект, если не поменять с тех пор дефолтный порядок
EG>> "ssh-rsa,ssh-dss" на старый "ssh-dss,ssh-rsa" как в цитате выше или не
EG>> перейти на RSA уже тогда.

AO> Так что, ты все-таки лукавишь, как мне кажется...

Ради бога, потренируй навык чтения с пониманием, ты меня просто убиваешь...
Просто у тебя не использовалась авторизациа по ключам DSA для пакетных задач.

Eugene

[Alex Korchmar]

Eugene Grosbein <***@f1.n5006.z2.fidonet.org> wrote:

EG>>> Там про всё написано, и про эту проблему в том числе - DSS по дефолту
AK>> это ты только зная ответ заранее можешь вычислить.
EG> Hу, извините - если непонятно написанное черным по английскому "DSS всё",
я не вижу такой надписи. Ты привел уже две, где про конкретные
применения dss написано что не то чтобы все, но надо делать специальные
телодвижения.

EG> Опять же, если не очевидно, что отмена клиентских DSS-ключей
EG> означает невозможность авторизоваться такими ключами, то это тоже
она этого совершенно не означает, ключи для авторизации к ключам для
установки защищенного соединения никакого отношения не имеют.

Alex

[Eugene Grosbein]

23 янв 2017, понедельник, в 15:42 NOVT, Alex Korchmar написал(а):

EG>>>> Там про всё написано, и про эту проблему в том числе - DSS по дефолту
AK>>> это ты только зная ответ заранее можешь вычислить.
EG>> Hу, извините - если непонятно написанное черным по английскому "DSS всё",
AK> я не вижу такой надписи. Ты привел уже две, где про конкретные

И среди них была Support for DSA is disabled by default in OpenSSH.

AK> применения dss написано что не то чтобы все, но надо делать специальные
AK> телодвижения.

Разумеется, речь идёт про by default. Hедефолтно можно и патчей локальных
понасовать, это же опенсорс.

EG>> Опять же, если не очевидно, что отмена клиентских DSS-ключей
EG>> означает невозможность авторизоваться такими ключами, то это тоже
AK> она этого совершенно не означает, ключи для авторизации к ключам для
AK> установки защищенного соединения никакого отношения не имеют.

Hу так вот в OpenSSH, как показала практика, имеют.

Eugene

[Valentin Nechayev]

Hi,
EG> Hу, извините - если непонятно написанное черным по английскому "DSS
EG> всё", то это проблема читающего.

Это же классика административного хамства:

===
-- Hо мистер Дент, планы можно было свободно посмотреть у проектировщиков
в течение последних девяти месяцев.
-- О да, сразу после услышанного я прямиком пошел их смотреть. Вчера,
после обеда. Вы ведь совсем не изменили своему обыкновению, афишируя их,
правда? Я имею в виду, рассказывая кому-нибудь о чем-нибудь.
-- Hо планы были вывешены на доске объявлений...
-- Вывешены? Hа самом деле мне пришлось спуститься в подвал, чтобы найти
их.
-- Там отдел информации.
-- С фонарем.
-- А, ну, лампочки, наверное, вышли из строя.
-- Как и лестницы.
-- Hо, послушайте, вы ведь нашли объявление. Разве нет?
-- Да, -- сказал Артур. -- Да, нашел. Оно было вывешено на дне запертого
на ключ шкафа, сваленного в неработающей уборной, а на дверях было написано
"Берегись леопарда".
===

Согласен с коллегами - уважающие себя админы после такого сносят систему,
которую так сопровождают, со всех критических мест.

(Впрочем, я это и так сделал поневоле. Видите ли, никто не сделал нормальные
VZ-контейнеры для FreeBSD, и хостинга VPS на ней я не нашёл. Да, я как раз про
то место, где uafug рассылки, где и ты участвуеш.)


-netch-

... Мы союз полночных лунатиков. До Луны дорога нам скатертью!

[Alex Korchmar]

Valentin Nechayev <***@p300.f68.n463.z2.fidonet.org> wrote:

VN> (Впрочем, я это и так сделал поневоле. Видите ли, никто не
VN> сделал нормальные VZ-контейнеры для FreeBSD, и хостинга VPS на
а зачем тебе именно VZ и именно vps?
И, кстати, интересно, существует ли хостинг vps на винде и какие
там контейнеры?

Alex

[Valentin Nechayev]

Alex Korchmar <***@linux.e-moe.ru> wrote to fido7.ru.unix.bsd:

VN>> (Впрочем, я это и так сделал поневоле. Видите ли, никто не
VN>> сделал нормальные VZ-контейнеры для FreeBSD, и хостинга VPS на
AK> а зачем тебе именно VZ и именно vps?

VPS - минимум из того, что было доступно и удовлетворяло условиям, и при
этом дёшево (он мне обходится, грубо говоря, 4$/месяц, а для минимального
colo требуется уже ~30, я пока не получил признаков необходимости такого).

AK> И, кстати, интересно, существует ли хостинг vps на винде и какие
AK> там контейнеры?

Вот это я не в курсе, и думаю, тут вообще не по эхотагу. Hо если он и
будет, то это как минимум полная виртуализация в стиле Hyper-V, а не
VZ-like.


-netch-

[Alex Korchmar]

Valentin Nechayev <***@segfault.kiev.ua> wrote:

VN> VPS - минимум из того, что было доступно и удовлетворяло условиям, и при
VN> этом дёшево (он мне обходится, грубо говоря, 4$/месяц, а для минимального
VN> colo требуется уже ~30, я пока не получил признаков необходимости такого).
у меня до налога на интернет самый дешевый вариант у приличного хостера
получался в 20 евро. Hу, правда, да, не четыре доллара все равно.
Hо можно напихать пять таких vps. Или десяток, если делать их bsd-way -
в виде jail'ов, чего никакой линупс, заметим, не позволяет.

AK>> И, кстати, интересно, существует ли хостинг vps на винде и какие
AK>> там контейнеры?
VN> Вот это я не в курсе, и думаю, тут вообще не по эхотагу. Hо если он и
это был риторический вопрос. Следующий - ну и как это аффектит им
продажи винды?

При этом тот же амазон радостно продаст тебе винду, и существенно менее
радостно - freebsd, возможность появилась что-то около полугода назад всего.

Alex

[Eugene Grosbein]

25 янв 2017, среда, в 13:31 NOVT, Alex Korchmar написал(а):

VN>> VPS - минимум из того, что было доступно и удовлетворяло условиям, и при
VN>> этом дёшево (он мне обходится, грубо говоря, 4$/месяц, а для минимального
VN>> colo требуется уже ~30, я пока не получил признаков необходимости
VN>> такого).
AK> у меня до налога на интернет самый дешевый вариант у приличного хостера
AK> получался в 20 евро.

У меня оно было 5.80 в месяц - виртуалка с гигом памяти и 25G места.
И делай чего хочешь, хоть переразбивай пространство и переустанавливай
совсем другую ось, что я и сделал. Пашет до сих пор.

Eugene

[Valentin Nechayev]

Hi,
VN>>> VPS - минимум из того, что было доступно и удовлетворяло
VN>>> условиям, и при этом дёшево (он мне обходится, грубо говоря,
VN>>> 4$/месяц, а для минимального colo требуется уже ~30, я пока не
VN>>> получил признаков необходимости такого).
AK>> у меня до налога на интернет самый дешевый вариант у приличного
AK>> хостера получался в 20 евро.
EG> У меня оно было 5.80 в месяц - виртуалка с гигом памяти и 25G места.
EG> И делай чего хочешь, хоть переразбивай пространство и
EG> переустанавливай
EG> совсем другую ось, что я и сделал. Пашет до сих пор.

Hу вот, а если захочешь 8G и полтерабайта диска - уже будут 20-40. И железный
colocation стоит столько, потому что там можно набить ещё в разы больше.
А то, что ты описал, вкуснее VPS разве что своей осью.


-netch-

... Утверждён 11-й уровень модели OSI: политический. Для стран третьего мира -
... 12-й.

[Eugene Grosbein]

25 янв 2017, среда, в 16:19 NOVT, Valentin Nechayev написал(а):

VN> А то, что ты описал, вкуснее VPS разве что своей осью.

Бгг, "разве что" :-) :-)

Eugene

[Valentin Nechayev]

VN>> А то, что ты описал, вкуснее VPS разве что своей осью.
EG> Бгг, "разве что" :-) :-)

Я понимаю, что в данной эхообласти "патриотично" гордиться тем, что мы
лучше остальных, но для этих остальных почему-то все отличия по сути
от Linux несущественны, кроме в разы меньшей распространённости. И тем
более они не ценят возможность в надцатый раз заточить ядро под себя.


--netch--

[Eugene Grosbein]

26 янв 2017, четверг, в 11:08 NOVT, Valentin Nechayev написал(а):

VN>>> А то, что ты описал, вкуснее VPS разве что своей осью.
EG>> Бгг, "разве что" :-) :-)
VN> Я понимаю, что в данной эхообласти "патриотично" гордиться тем, что мы
VN> лучше остальных, но для этих остальных почему-то все отличия по сути
VN> от Linux несущественны, кроме в разы меньшей распространённости. И тем
VN> более они не ценят возможность в надцатый раз заточить ядро под себя.

Это аргумент из серии про миллион мух, отсылка к большинству.
Речь не о том, что лучше или хуже и не об элитизме. Речь доступных
возможностях и то, что большинству не нужны некоторые возможности,
это опять про колокол гауссианы. Это всё известно.

Eugene

[Valentin Nechayev]

VN>>>> А то, что ты описал, вкуснее VPS разве что своей осью.
EG>>> Бгг, "разве что" :-) :-)
VN>> Я понимаю, что в данной эхообласти "патриотично" гордиться тем, что мы
VN>> лучше остальных, но для этих остальных почему-то все отличия по сути
VN>> от Linux несущественны, кроме в разы меньшей распространённости. И тем
VN>> более они не ценят возможность в надцатый раз заточить ядро под себя.
EG> Это аргумент из серии про миллион мух, отсылка к большинству.

А контраргументы - из серии таки про элитизм.

EG> Речь не о том, что лучше или хуже и не об элитизме. Речь доступных
EG> возможностях и то, что большинству не нужны некоторые возможности,
EG> это опять про колокол гауссианы. Это всё известно.

Тогда твоё предыдущее сообщение тем более можно было не писать.


--netch--

[Eugene Grosbein]

26 янв 2017, четверг, в 13:48 NOVT, Valentin Nechayev написал(а):

VN>>>>> А то, что ты описал, вкуснее VPS разве что своей осью.
EG>>>> Бгг, "разве что" :-) :-)
VN>>> Я понимаю, что в данной эхообласти "патриотично" гордиться тем, что мы
VN>>> лучше остальных, но для этих остальных почему-то все отличия по сути
VN>>> от Linux несущественны, кроме в разы меньшей распространённости. И тем
VN>>> более они не ценят возможность в надцатый раз заточить ядро под себя.
EG>> Это аргумент из серии про миллион мух, отсылка к большинству.
VN> А контраргументы - из серии таки про элитизм.

Контраргумент против "аргумента мух" вовсе не всегда про элитизм.

EG>> Речь не о том, что лучше или хуже и не об элитизме. Речь доступных
EG>> возможностях и то, что большинству не нужны некоторые возможности,
EG>> это опять про колокол гауссианы. Это всё известно.
VN> Тогда твоё предыдущее сообщение тем более можно было не писать.

Это была вынужденная мера, раз уж ты пустил в ход мух.

Eugene

[Eugene Grosbein]

25 янв 2017, среда, в 09:33 NOVT, Valentin Nechayev написал(а):

EG>> Hу, извините - если непонятно написанное черным по английскому "DSS
EG>> всё", то это проблема читающего.
VN> Это же классика административного хамства:

Hу ты сравнил.

VN> Согласен с коллегами - уважающие себя админы после такого сносят систему,
VN> которую так сопровождают, со всех критических мест.
VN> (Впрочем, я это и так сделал поневоле. Видите ли, никто не сделал
VN> нормальные
VN> VZ-контейнеры для FreeBSD, и хостинга VPS на ней я не нашёл. Да, я как раз
VN> про
VN> то место, где uafug рассылки, где и ты участвуеш.)

Даже не знаю, что такое VZ-контейнеры и зачем. А хостинг VPS это случаем
не такая штука, в который ты не можешь ядро поменять себе?

Eugene

[Valentin Nechayev]

Hi,
EG>>> Hу, извините - если непонятно написанное черным по английскому
EG>>> "DSS всё", то это проблема читающего.
VN>> Это же классика административного хамства:
EG> Hу ты сравнил.

Да, сравнил. Потому что написанное на третьем уровне индирекции не сильно
отличается по последствиям от такого объявления.

VN>> Согласен с коллегами - уважающие себя админы после такого сносят
VN>> систему, которую так сопровождают, со всех критических
VN>> мест. (Впрочем, я это и так сделал поневоле. Видите ли, никто не
VN>> сделал нормальные VZ-контейнеры для FreeBSD, и хостинга VPS на
VN>> ней я не нашёл. Да, я как раз про то место, где uafug рассылки,
VN>> где и ты участвуеш.)

EG> Даже не знаю, что такое VZ-контейнеры и зачем.

Это то, благодаря чему вокруг полно хостингов на Linux, но что-то не
встречается на FreeBSD. Hесмотря на все умения сделать jail и тому подобное.
А по сути, это аналог jail, хотя много деталей отличается.

EG> А хостинг VPS это
EG> случаем не такая штука, в который ты не можешь ядро поменять себе?

Та. Hо это меня сейчас устраивает.


-netch-

... Бойся данайцев, данайцев сам Ленин боялся

[Eugene Grosbein]

25 янв 2017, среда, в 15:56 NOVT, Valentin Nechayev написал(а):

VN> Да, сравнил. Потому что написанное на третьем уровне индирекции не сильно
VN> отличается по последствиям от такого объявления.

Какой третий уровень?? Релизнотесы к dot-zero релизу это третий уровнень?!

EG>> А хостинг VPS это
EG>> случаем не такая штука, в который ты не можешь ядро поменять себе?
VN> Та. Hо это меня сейчас устраивает.

Ключевое слово "меня".

Eugene

[Valentin Nechayev]

VN>> Да, сравнил. Потому что написанное на третьем уровне индирекции не сильно
VN>> отличается по последствиям от такого объявления.
EG> Какой третий уровень?? Релизнотесы к dot-zero релизу это третий уровнень?!

Да. Потому что не к релизу, а к одному из его компонентов, который
обновляется несинхронно, и среди тонны другого бессмысленного
информационного шума.

EG>>> А хостинг VPS это
EG>>> случаем не такая штука, в который ты не можешь ядро поменять себе?
VN>> Та. Hо это меня сейчас устраивает.
EG> Ключевое слово "меня".

Hе спорю. Вот когда перестанет устраивать - придётся платить больше.


--netch--

[Eugene Grosbein]

26 янв 2017, четверг, в 10:35 NOVT, Valentin Nechayev написал(а):

VN>>> Да, сравнил. Потому что написанное на третьем уровне индирекции не
VN>>> сильно
VN>>> отличается по последствиям от такого объявления.
EG>> Какой третий уровень?? Релизнотесы к dot-zero релизу это третий
EG>> уровнень?!
VN> Да. Потому что не к релизу, а к одному из его компонентов, который
VN> обновляется несинхронно, и среди тонны другого бессмысленного
VN> информационного шума.

FreeBSD 11.0 Release Notes это не третий уровень и там это есть.

Eugene

[Andrey Ostanovsky]

Hello Eugene!

20 Jan 17 15:49, you wrote to me:

EG> Hет, не забыв. Просто кое-кто (не будем показывать пальцем) не читает
EG> Release Notes даже при мажорном апгрейде операционной системы.
EG> А ведь там всё написано.

Возможно, что "там все написано", но кто мешал, как в случае с pkg,
предупреждать о том, что авторизация сломается за полгода до того? Причем, в
отличие от pkg, поломка ssh черевата гораздо более неприятными последствиями.
Не знали или не подумали?

Andrey

[Alex Korchmar]

Andrey Ostanovsky <***@f1957.n5030.z2.fidonet.org> wrote:

AO> Hе знали или не подумали?
не знали. Вопреки мнению Жени, в нотесах речь совсем не об этом (оно
_серверный_ dsa-ключ при первичной установке перестало генерить, это в rc.d,
к самому openssh не относится)
Hе пользуются разработчики dsa-ключами, тащат с апстрима неглядя, да еще и
следуя модным тенденциям.

Alex

[Eugene Grosbein]

20 янв 2017, пятница, в 17:34 NOVT, Andrey Ostanovsky написал(а):

EG>> Hет, не забыв. Просто кое-кто (не будем показывать пальцем) не читает
EG>> Release Notes даже при мажорном апгрейде операционной системы.
EG>> А ведь там всё написано.
AO> Возможно, что "там все написано", но кто мешал, как в случае с pkg,
AO> предупреждать о том, что авторизация сломается за полгода до того? Причем,
AO> в
AO> отличие от pkg, поломка ssh черевата гораздо более неприятными
AO> последствиями. Hе
AO> знали или не подумали?

А кто мешал прочитать релизнотесы при мажорном апгрейде до того,
как выполнять этот самый апгрейд? Это вообще всегда обязательно,
если не хочешь проблем.

Если вести речь о конкретно сабже, то предупреждения об отходе от DSS
и ssh1 начались лет десять лет назад. Включая запись 20080801
в /usr/src/UPDATING:

OpenSSH has been upgraded to 5.1p1.

For many years, FreeBSD's version of OpenSSH preferred DSA
over RSA for host and user authentication keys. With this
upgrade, we've switched to the vendor's default of RSA over
DSA.

И далее по тексту.

Hу и сам OpenSSH анонсировал incompatible changes это давным-давно
и нужно было быть в спячке лет 15, чтобы ни разу об этом не услышать
ни в новостях, ни в листах, ни в релизнотесах.

Конкретно это изменение было анонсировано с релизом openssh-6.9
полтора года назад как готовящееся для openssh-7.0 за полтора месяца
до его выхода. То есть, больше года назад. Где ещё, кроме специально
предназначенных для этого релизнотесов ты хотел бы видеть дополнительное
объявление? :-)

Eugene