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

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

Одним прекрасным весенним вечером, когда идти домой не хотелось, а неуемное желание жить и познавать свербило и жгло аки каленым железом, возникла идея поковырять заманчивую приблуду фичу на файрволе под названием "IP DOS policy".
После предварительных ласок и ознакомления с мануалом настроил в режиме Pass-and-Log, чтобы посмотреть вообще на выхлоп и сомнительную полезность данной настройки.
Спустя пару дней (чтобы статистика набралась, конечно, а не потому что забыл) взглянул в логи и, пританцовывая на месте, захлопал в ладоши — записей набралось по самое не балуйся. Казалось бы, чего проще — включай политику в режим блокировки всех флудящих, сканящих, устанавливающих half-open сессии с баном на час и спи себе спокойно с осознанием того факта, что граница на замке. Но 34-ый год жизни преодолел юношеский максимализм и где-то на затылочном участке мозга прозвучал тоненький голосок:«А давай-ка поднимем веки и посмотрим, а чьи же адреса наш любимый файрвол распознал как злостных флудильщиков? Ну так, в порядке бреда.»

Исторически сложилось, что sudo права регулировались содержимым файлов из /etc/sudoers.d и visudo, а авторизация по ключам велась с использованием ~/.ssh/authorized_keys. Однако с ростом инфраструктуры возникает желание управлять этими правами централизованно. На сегодняшний день вариантов решения может быть несколько:

• Система управления конфигурацией — Chef, Puppet, Ansible, Salt
• Active Directory + sssd
• Разнообразные извращения в виде скриптов и ручного редактирования файлов

На мой субъективный взгляд, оптимальным вариантом централизованного управления является все-таки связка Active Directory + sssd. Преимущества данного подхода вот в чем:

• Действительно Единый централизованный каталог пользователей.
• Раздача прав sudo сводится к добавлению пользователя в определенную группу безопасности.
• В случае различных Linux-систем возникает необходимость вводить дополнительные проверки на определение ОС при использовании систем конфигурации.

Сегодняшняя сюита будет посвящена именно связке Active Directory + sssd для управления правами sudo и хранением ssh ключей в едином репозитории.
Итак, зал застыл в напряженном молчании, дирижер поднял палочку, оркестр приготовился.
Поехали.

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

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

Как любой системный администратор, уверившийся в совершенстве собственной памяти и способности посреди ночи вспомнить 25-значный код установки Windows XP, поймал недавно такой вот exception.

В один прекрасный день, решив зайти проверить что там с моим контроллером UniFi, получил удивительное сообщение: Login error.

Идея использовать 802.1x как средство борьбы с неавторизованным доступом к сети, не нова. Каждый из нас наверняка сталкивался с курьером из службы доставки, у которого из рукава фирменной куртки виднеется патчкорд, и ты уже видишь, как он, заметив свободную RJ-45 розетку, стремительным движением бросается к ней и…

Однако, если в общем концепте использование и настройка 802.1x с авторизацией через RADIUS избита и проста, в данном случае произошел казус, решение которого я и предлагаю ниже.