Итак, наверно уже завершающая часть всего этого мерлезонского балета.
Предыдущие части, с которых “всё начиналось”:
- 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:
Готово.
