ОколоITшный дыбр #27
... Ох уж эти "стандарты" и "соглашения".
Стабильный нонче Debian 11 перешел по умолчанию на формат хешей по алгоритму "yescrypt" в файле "/etc/shadow" (сигнатура начинается на "$y$", не путать с "ЪуЪ"). А всякие там RedHat 9 (недавно зарелизившиеся, кстати) по-прежнему используют SHA-512 (сигнатура начинается на "$6$").
С одной стороны, вроде бы и похрен. В одном и том же файле не возбраняется смешивать и те, и другие хеши. С другой стороны, в подавляющем большинстве случаев конченному пользователю (который end user) вообще по барабану как там хешируется его пароль. С третьей стороны, если возникает потребность сгенерировать хеш на одной машине, а потом засунуть его на другую каким-нибудь условным ansibl-ем, возникают вопросы. Конечно, можно использовать по умолчанию максимально совместимый формат, то есть SHA-512. Только вот оглянуться не успеешь, как он уже превратится в legacy. И строить что-то принципиально новое на заведомо старых алгоритмах тоже как-то не особо хочется. Вот и думай как поступить.
А самый прикол, что в том же стабильном Debian-е единственный не сильно геморройный способ сгенерировать yescrypt-овский хеш из строки - это воспольлзоваться утилитой "mkpasswd". Которая находится, внезапно, в пакете "whois". Который надо ставить как минимум из тестируемого (нестабильного) выпуска, потому что в стабильной версии она в yescrypt ещё не умеет. Шизофрения на грани с норкоманией, да.
... В связи с некоторой спецификой работы мне приходится строить и поддерживать большое количество IPSec-тоннелей с разными контрагентами. Прямо сейчас у меня их что-то около 70-ти штук, и говно только ширится. Большая их часть с моей стороны терминируется на Juniper SRX, с вражеской - на Cisco ASA.
У некоторых из них есть "фирменная" беда: они периодически "залипают". То есть работал-работал, потом "бац" и перестал. По мнению моего Juniper-а тоннель живой, но трафик через него не ходит. Грохнешь security associations лапами, смотришь: о, поднялось. И так с завидной регулярностью. Долго думал почему так происходит.
Оказывается, в Cisco ASA по умолчанию включён Dead Peer Detection (DPD), а тоннели создаются как "On-Demand". И народ не особо парится на эту тему. А дальше классика. Какое-нибудь краткосрочное пропадание связности. Линк до провайдера моргнул, BGP перестроил маршруты, да мало ли ещё чего. Сколько-то DPD-пакетов потерялось. Циска решила "а нуегонафуй, peer lost, Lost Service". И похерила к чертям сеансовые ключи второй фазы. Но противоположная сторона про это ничего не знает, с её точки зрения всё идёт своим чередом. Cisco заново поднимать тоннель не хочет, потому что за ней чисто серверные приложения, никто ко мне соединения внутри тоннеля не инициирует, трафика нет. Juniper поднимать тоннель тоже не хочет, потому что по его мнению он и не падал. Всё, приехали. Пока время жизни сеансовых ключей не истечет, использующие тоннель сервисы курят бамбук.
М-дя...