KeePass: настройка MFA, хранение паролей браузера, паролей SSH ключей и интеграция Secret Service

Автор: | 11/12/2019
Нет комментариев
 

Итак, наверно уже завершающая часть всего этого мерлезонского балета.

Предыдущие части, с которых “всё начиналось”:

Собственно, теперь можно собрать всё в кучу, и настроить нормальное управдение секретами на рабочей машинке под управлением 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 запущен:

[simterm]

$ ps aux | grep ssh-agent
setevoy     1505  0.0  0.0   5796   456 ?        Ss   Dec10   0:00 ssh-agent

[/simterm]

Если нет – то запускаем:

[simterm]

$ eval $(ssh-agent)
Agent pid 950428

[/simterm]

Проверяем, что переменная $SSH_AUTH_SOCK, указывающая на сокет для коммуникации с агентом, доступна:

[simterm]

$ env | grep SSH
SSH_AUTH_SOCK=SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket
SSH_AGENT_PID=950428

[/simterm]

Переходим в Tools > Settings, включаем SSH Agent:

Перезапускаем KeePass, и создаём новую запись.

Создаём ключ, задаём ему пароль:

[simterm]

$ ssh-keygen -f /home/setevoy/rtfm-do-prod-setevoy
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/setevoy/rtfm-do-prod-setevoy.
Your public key has been saved in /home/setevoy/rtfm-do-prod-setevoy.pub.
...

[/simterm]

Обратите внимание, что тут через -f задаётся путь к файлу ключа, и он не в .ssh, что бы потом его проще было добавить в KeePass.

Проверяем файлы:

[simterm]

$ ll /home/setevoy/rtfm-do-prod-setevoy*
-rw------- 1 setevoy setevoy 2655 Dec 11 10:53 /home/setevoy/rtfm-do-prod-setevoy
-rw-r--r-- 1 setevoy setevoy  579 Dec 11 10:53 /home/setevoy/rtfm-do-prod-setevoy.pub

[/simterm]

Возвращаемся в 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-сервер на удалённом хосте может разорвать соедениение из-за подозрения на брутфорс.

Пробуем подключиться:

[simterm]

$ ssh [email protected]
Linux rtfm-do-production 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64
...
setevoy@rtfm-do-production:~$

[/simterm]

Готово – залогинились.

Помните, что 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 и попробует подключиться с доступными ключами.

Подключаемся, используя короткое имя:

[simterm]

$ ssh rtfm
...
setevoy@rtfm-do-production:~$

[/simterm]

Пароль ни для юзера, ни для ключа не запросило – всё работает.

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“:

[simterm]

$ ssh rtfm
sign_and_send_pubkey: signing failed: agent refused operation
Load key "/home/setevoy/.ssh/id_rsa": Is a directory
[email protected]'s password:

[/simterm]

Возникает она потому, что ssh-agent пытается запросить разрешение для пользователя, а для этого используется ssh-askpass, которого может не быть в системе:

[simterm]

$ file /usr/lib/ssh/ssh-askpass
/usr/lib/ssh/ssh-askpass: cannot open `/usr/lib/ssh/ssh-askpass' (No such file or directory)

[/simterm]

Устанавливаем x11-ssh-askpass:

[simterm]

$ sudo pacman -S x11-ssh-askpass

[/simterm]

Повторяем логин – теперь появится окно с запросом на доступ к ключу:

Кликаем ОК – и всё работает.

KeePass и Secret Service

Что бы понимать роль keyrings вообще, и Secret Service в частности – категорически рекомендую к ознакомлению пост What is: Linux keyring, gnome-keyring, Secret Service, и D-Bus.

Для начала – убедимся, что никакой другой Secret Service в системе неактивен – проверяем сервисы D-Bus:

[simterm]

$ qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets
Error: org.freedesktop.DBus.Error.NameHasNoOwner
Could not get PID of name 'org.freedesktop.secrets': no such name

[/simterm]

Переходим в 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 &
...

Запускаем браузер:

[simterm]

$ chromium --password-store=gnome

[/simterm]

И в 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, см. комментарий тут>>>, копируем:

[simterm]

$ cp .config/chromium-flags.conf .config/brave-flags.conf

[/simterm]

Перезапускаем Brave, проверяем:

И в Secret Service самого KeePass появился brave:

Готово.