Итак, наверно уже завершающая часть всего этого мерлезонского балета.
Предыдущие части, с которых «всё начиналось»:
- Linux: Nextcloud клиент, qtkeychain и ошибка «The name org.freedesktop.secrets was not provided by any .service files»
— увидел, что в keyring сервисе можно хранить пароли от SSH ключей
— узнал, что Chromium хранит пароли «незашифрованными» - Linux: KeePass, SSH и хранение паролей RSA-ключей
— повспоминал работу сssh-agent, потрогал его интеграцию с KeePass для хранения паролей от SSH-ключей - What is: Linux keyring, gnome-keyring, Secret Service, и D-Bus
— повспоминал, что такое keyring и как его употреблять
— как работать с D-Bus
— потрогал интеграцию KeePass в роли Secret Service - Chromium: Linux, keyrings && Secret Service, шифрование и хранение паролей
— и всё-таки удовлетворил своё любопытство — действительно ли Chromium хранит пароли в открытом виде?
Собственно, теперь можно собрать всё в кучу, и настроить нормальное управдение секретами на рабочей машинке под управлением Arch Linux с Openbox DE.
Будем использовать KeePassXC для:
- интеграция с браузером для хранения паролей вместо SQLite базы Chromium
- настроим генерацию TOTP кодов для MFA
- интегрируем с
ssh-agentдля хранения паролей от SSH-ключей - включим поддержку Secret Service и интегрируем KeePass в роли keyring storage для Linux
Содержание
KeePass vs KeePassXC
Используем KeePassXC вместо стандартного KeePass.
На самом деле изначально я переключился на KeePassXC просто потому, что он нормально выглядит в Linux с Openbox.
KeePass:
KeePassXC:
Кроме того, KeePass написан на богомерзском C# от Microsoft и на Linux работает под mono, тогда как KeePassXC написан на C++ (см. репозиторий), и может легко работать на любой платформе — Linux/BSD/macOS/Windows.
Больше деталей можно узнать в обсуждении на Reddit.
В качестве браузера используем Brave на базе того же Chromium, так что разницы в настройке не будет никакой. Да и Firefox/Chrome/etc настраиваются аналогично.
KeePass и пароли браузера — KeePassXC-Browser
На самом деле тут вопрос — стоит ли вообще переключать хранилище паролей?
Т.е. у вас есть Chromium, у него есть SQLite база, пароли в базе шифруются.
При этом Chromium не имеет проблем с определением полей для логина/пароля, что случается при использовании KeePass.
С другой стороны с KeePass — ваши пароли всегда с вами, в единой базе, вместе с вашими SSH-ключами и прочей sensitive информацией. Проще бекапить, проще переносить, легко можно подключить к любому другому браузеру (не все умеют нормально импортировать пароли из другого браузера).
В общем — каждый решает для себя, но настройку интеграции KeePass и Chroimum запишем.
Переходим в Tools > Settings, переключаемся на Browser Integration, включаем её:
Находим плагин KeePassXC-Browser для Chrome, устанавливаем:
Переходим в настройки:
- Default group for saving new passwords — я обычно отключаю дефолтную группу KeePassXC-Browser Passwords, и включаю запрос того — куда сохранить пароль, потому как для себя разделю всё по группам
- Activate username field icons — отображает иконку возле поля логина-пароля для входа по одному клику
- Activate 2FA/OTP field icons — включаем, если активно пользуемся MFA (но стоит ли? см. ниже, в KeePass MFA TOTP generator)
- Automatically reconnect to KeePassXC — удобно, что бы автоматом переподключалось при перезапуске KeePass, лагов-багов пока не заметил
- Activate autocomplete for username fields — а вот тут можно убрать галочку, потому как иногда вываливает длинный список логинов — неудобно
- Automatically fill in HTTP Basic Auth dialogs and submit them — выглядит полезным, но у меня не получилось заставить её работать — окно HTTP-аутентификации всё-равно вылазит
Возвращаемся к плагину, и кликаем Connect:
Задаём имя браузера:
Проверяем браузеры в настройках базы:
Готово — иконка позеленела:
Логинимся — KeePass предложит сохранить запись:
Сохраняем (New), логинимся ещё раз:
KeePass MFA TOTP generator
Ещё одна интересная возможность KeePass — генерация TOTP-кодов.
Тут, однако, есть вопрос целесообрахзности такого внедрения.
Основная идея MFA как раз состоит в том, что для аутентификации используются разные источники, т.е. логин-пароль с одной стороны, и код с мобильного телефона — с другой.
Стоит ли держать их вместе, в одной базе KeePass — решать вам, но учтите, что если поломают ваш KeePass — то получат доступ ко всему сразу, т.к. надежды на MFA уже не будет.
Still — опция есть, настроим и её.
Во время настройки MFA — выбираем «Show secret key«, или «Can’t scan QR» , в зависимости от сервиса, на котором настраивается.
Тут для примера AWS Console:
Записываем код, находим или создаём запись, для которой хотим настроить получение TOTP кода, правой кнопкой — TOTP > Set up TOTP:
И указываем Secret Key из панели AWS:
Сохраняем, кликаем правой кнопкой ещё раз — Show TOTP:
Завершаем настройку MFA в AWS:
И пробуем залогиниться, но… По кнопке и не работает 🙁
Причём по кнопке не сработало ни в Chromium, ни с Gmail. Может, KeePass не может найти подходящую запись, из которой ему надо взять TOTP?
Тем не менее — код генерируется, так что копируем его из самого KeePass (комбинация Ctrl+T) , логинимся — готово.
KeePass и ssh-agent для паролей SSH-ключей
Уже рассматривалось в посте Linux: KeePass, SSH и хранение паролей RSA-ключей, повторим тут.
Проверяем, что ssh-agent запущен:
Если нет — то запускаем:
Проверяем, что переменная $SSH_AUTH_SOCK, указывающая на сокет для коммуникации с агентом, доступна:
Переходим в Tools > Settings, включаем SSH Agent:
Перезапускаем KeePass, и создаём новую запись.
Создаём ключ, задаём ему пароль:
Обратите внимание, что тут через -f задаётся путь к файлу ключа, и он не в .ssh, что бы потом его проще было добавить в KeePass.
Проверяем файлы:
Возвращаемся в KeePass, создаём запись, имя любое, в Password — задаём пароль ключа, заданный во время генерации:
В SSH Agent ключ можно добавить как Attachment, можно через External file.
Удобнее через Attachment, т.к. тогда ваш ключ всегда будет в базе, и не надо будет его копировать между рабочей/домашней машинами.
Переключаемся в этом же окне во вкладку Advanced, добавляем ключ:
Переключаемся в SSH Agent, добавляем ключ из Attachment:
Тут из опций обратите внимание на Add key to agent when database is opened/unlocked — включайте для ключей, которые используются часто, и что бы таких ключей с auto-load было меньше 5 штук, т.к. SSH клиент будет перебирать все ключи в ssh-agent во время попытки подключения, и SSH-сервер на удалённом хосте может разорвать соедениение из-за подозрения на брутфорс.
Пробуем подключиться:
Готово — залогинились.
Помните, что ssh-agent при таком подходе должен запускаться до KeePass, и экспортировать пемренную $SSH_AUTH_SOCK так, что бы KeePass её увидел. См. варианты запуска в Запуск ssh-agent и несколько консолей.
Как один из варинатов — запускать как `systemd` сервис, а сокет передавать через ~/.config/openbox/environment (т.к. у меня Openbox).
Мой unit-файл /home/setevoy/.config/systemd/user/ssh-agent.service:
[Unit] Description=SSH key agent [Service] Type=simple Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK [Install] WantedBy=default.target
И файл переменных — ~/.config/openbox/environment:
export QT_QPA_PLATFORMTHEME="qt5ct"
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"
Последним, для удобства, добавляем объявление подключения в ~/.ssh/config:
Host rtfm Hostname rtfm.co.ua User setevoy
Обратите внимание, что IdentityFile не указан вообще — ssh-client сам обратится к ssh-agent и попробует подключиться с доступными ключами.
Подключаемся, используя короткое имя:
Пароль ни для юзера, ни для ключа не запросило — всё работает.
sign_and_send_pubkey: signing failed: agent refused operation
Если включить опцию «Require user confirmation when this key is used«:
То при попытке логина можно встретить ошибку «sign_and_send_pubkey: signing failed: agent refused operation«:
Возникает она потому, что ssh-agent пытается запросить разрешение для пользователя, а для этого используется ssh-askpass, которого может не быть в системе:
Устанавливаем x11-ssh-askpass:
Повторяем логин — теперь появится окно с запросом на доступ к ключу:
Кликаем ОК — и всё работает.
KeePass и Secret Service
Что бы понимать роль keyrings вообще, и Secret Service в частности — категорически рекомендую к ознакомлению пост What is: Linux keyring, gnome-keyring, Secret Service, и D-Bus.
Для начала — убедимся, что никакой другой Secret Service в системе неактивен — проверяем сервисы D-Bus:
Переходим в KeePass, Tools > Settings, выбираем Secret Service Integration, включаем её:
Далее, переходим в настройки базы данных, и в её настройках Secret Service Integration указываем коллекцию (группу, папку), которую будем использовать для хранения секретов:
Имеет смысл запускать KeePass до старта всех приложений.
У меня это настраивается в ~/.config/openbox/autostart:
xrandr --output HDMI-1 --primary xrandr --output eDP-1 --right-of DP-1 feh --bg-scale /home/setevoy/Pictures/Wallpaper/seryy-kapli-strela-ten-arch.jpg & tint2 -c /home/setevoy/.config/tint2/setevoy-tint2-90-pecent-bottom-wrk.tint2rc & polybar -c /home/setevoy/.config/polybar/setevoy-polybar-wrk-bars.conf bottom & polybar -c /home/setevoy/.config/polybar/setevoy-polybar-wrk-bars.conf top & sleep 5 keepassxc & dropbox & lxqt-notificationd & xscreensaver & qxkb & skypeforlinux & sleep 5 slack & ...
Запускаем браузер:
И в Tools > Settings KeePass проверяем сервисы, которые используют Secret Service:
Уведомление от KeePass, когда Chromium выполняет обращение к своему паролю, что бы расшировать каую-то запись из своей базы:
Но тут тоже возник нюанс: при запуске через gmrun — Chromium запускается с --password-store=basic вместо --password-store=gnome, хотя должен при запуске видеть, что есть Secret Service, и переключаться на него.
Читаем Arch Wiki, создаём файл ~/.config/chromium-flags.conf:
--password-store=gnome
Перезапускаем браузер, и на странице chrome://version/ проверяем опции:
А вот Brave не подхватил так опции.
Для него в Arch Linux можно создать файл ~/.config/brave-flags.conf, см. комментарий тут>>>, копируем:
Перезапускаем Brave, проверяем:
И в Secret Service самого KeePass появился brave:
Готово.
