І збоку батник. Задаємо KeePass'у параметри запуску

1. Фіксуємо робочий каталог
2. вказуємо базу
3. задаємо конфігурацію
4. Відступ про конфігураціях
5. Використовуємо кілька конфігурацій
6. Використовуємо змінні середовища
7. Оптимізуємо роботу з еквівалентними доменами
8. Видаляємо змінні середовища
9. Відкриваємо базу без введення пароля
10. Використовуємо стандартний потік введення
11. Управління працюючим KeePass'ом

Наша взаимовыгодная связь https://banwar.org/

Запускаючи KeePass сорочки з короткими рукавами, ми можемо по-своєму ставити робочий каталог, аргументи командного рядка, значення змінних середовища, а також звертатися до стандартного потоку введення. Що це дає?

Фіксуємо робочий каталог

Багато програм - і KeePass 2.x тут не виняток - вважають робочим каталогом місце, обумовлене способом запуску, а не своїм розташуванням. Через це при зверненні до баз і компонентів програми доводиться вказувати шляхи повністю.

Щоб уникнути непередбачуваності в положенні робочого каталогу, можна домовитися завжди запускати KeePass якимось стартером, який встановлює робочим каталогом розташування програми. Найпростішим варіантом буде батник Run.bat, що лежить в каталозі програми і складається з рядка

start "" / d "% ~ dp0" KeePass.exe

Цей батник можна буде запускати вже довільним способом, наприклад, ярликом на робочому столі (для краси - зі зміненим значком і опцією згорнутого вікна).

Тепер, коли робочий каталог зафіксовано, у багатьох рядках бази і конфігурації можна буде використовувати замість абсолютних шляхів відносні. Однак не будемо зловживати цією можливістю, а все-таки віддамо перевагу вказувати абсолютні шляхи (за допомогою наповнювачів {APPDIR}, {DB_DIR}, {ENV_PROGRAMFILES_X86}) і укладати їх в лапки. Місце, де дійсно знадобляться відносні шляхи, - конфігурація плагінів, які не підтримують наповнювачі.

вказуємо базу

Залежно від настройки, KeePass може відразу при запуску пропонувати відкриття бази, яка закривалася останньої. Це зручно, коли база одна. Але якщо баз кілька, то найчастіше KeePass буде відкривати не те, що потрібно.

Вирішити проблему можна по-різному, наприклад, тригером , Який відкриває потрібну базу за подією «Додаток Ініціалізувати». Інший варіант - створити в каталозі програми файл KeePass.config.enforced.xml і зафіксувати в ньому «останню» базу.

Але мабуть, найпростіший і гнучкий спосіб - додати шлях до бази в командний рядок. Оскільки наш батник Run.bat робить каталог програми робочим, буде досить вказати шлях щодо цього каталогу, і код прийме такий вигляд:

start "" / d "% ~ dp0" KeePass.exe "DBases \ Database.kdbx"

На місце виділеного фрагмента потрібно підставити ваш відносний шлях до бази. Взагалі, у всіх прикладах цієї статті передбачається заміна виділеного коду вашими даними.

Кілька таких батники можуть використовуватися для різних баз.

Крім шляху до бази, можна заздалегідь підставити і шлях до ключового файлу (якщо, звичайно його розташування не таємно), тоді в діалозі відкриття бази залишиться лише ввести пароль. Це робиться аргументом командного рядка -preselect, батник набуде вигляду

start "" / d "% ~ dp0" KeePass.exe "DBases \ Database.kdbx" -preselect: "K: \ Database.key"

Розташування відкривається бази може бути і віддаленим, причому, якщо міркування безпеки дозволяють, можна додати в командний рядок облікові дані підключення:

start "" / d "% ~ dp0" KeePass.exe https://webdav.mydrive.ch/Database.kdbx -iousername: "myConnectionLogin" -iopassword: "myConnectionPassword" -ioiscomplete

задаємо конфігурацію

Запобігаємо небажане збереження конфігурації

Припустимо, в якійсь ситуації портативний KeePass не зможе зберегти конфігурацію. Наприклад, чи не виявиться доступу на запис в каталог програми. Або ви навмисно привласните файлу KeePass.config.xml атрибут «Тільки читання», щоб не зіпсувати настройку програми.

Деяким сюрпризом може виявитися, що в цих випадках конфігурація все-таки зберігається - в профіль користувача. Мабуть, це не зовсім те, чого очікуєш від портативного додатки ...

Проте, така поведінка відповідає заявленому в офіційному керівництві. А щоб запобігти запис в профіль користувача, потрібно вказати в командному рядку інше розташування користувальницької конфігурації - туди зміни і збережуться.

Будемо вважати, що портативному KeePass'у не положено зберігати конфігурацію нікуди, крім файлу KeePass.config.xml в своєму каталозі, тому його ж і призначимо користувальницької конфігурацією. Наш батник прийме такий вигляд:

start "" / d "% ~ dp0" KeePass.exe "DBases \ Database.kdbx" -cfg-local: KeePass.config.xml

Портативний KeePass, запущений таким сорочки з короткими рукавами, буде працювати як зазвичай, коли файл KeePass.config.xml в каталозі програми доступний для запису. А коли недоступний - не відбудеться «дивного» збереження конфігурації в профіль користувача.

Якщо вам трапляється відкривати один KeePass з іншого внутрішньої посиланням виду kdbx: // шлях до бази, то потрібно, щоб і при такому відкритті вказувалася конфігурація в командному рядку. Для цього можна додати в перевизначення схеми kdbx аргумент -cfg-local: "{APPDIR} \ KeePass.config.xml". Кілька більш гнучкий варіант цього аргуммента буде запропонований нижче. А в налаштуванні, яка давалася в попередній статті , Цей аргумент вже присутня, причому в ще більш універсальному вигляді.

Відступ про конфігураціях

Як відступ варто відзначити, що в KeePass'е передбачені різні види конфігурації, що дозволяють адміністраторам досить гнучко обмежувати права користувачів в частині настройки програми. Ці права визначаються вмістом конфігураційних файлів, що знаходяться в каталозі програми, тому при адмініструванні запис туди повинна бути заборонена обмеженим користувачам.

• У enforced-конфігурації (фото KeePass.config.enforced.xml) задаються значення якої-небудь частини параметрів, при цьому вони отримують найвищий пріоритет, багато хто з них забороняється змінювати навіть на час роботи програми.
• Якщо enforced-конфігурація не встановлює значення прапора PreferUserConfiguration, то воно визначається global-конфігурацією (файлом KeePass.config.xml).
• Якщо в результаті цей прапор залишається незадані або встановлюється в false, то всі інші параметри беруться з global-конфігурації, їх дозволяється змінювати.
• Якщо ж цей прапор встановлюється в true, то всі параметри, які не задані в enforced-конфігурації, беруться з local-конфігурації - файлу, що лежить в профілі користувача або заданого аргументом командного рядка -cfg-local.

Хоча enforced-конфігурація призначена, в основному, для адміністрування, їй можна знайти корисне застосування і в використанні портативного KeePass'а.

Використовуємо кілька конфігурацій

Буває зручно одночасно використовувати KeePass в різних варіантах настройки. Наприклад, один екземпляр KeePass'а може працювати з обліковими записами, а інший, налаштований більш м'яко, з закладками. В попередній статті пропонувалося для цього помістити копію програми і деяких плагінів в окремий каталог. Таке рішення здається надмірною - чому б просто не додати додаткову конфігурацію до тій же програмі?

З цим пов'язана одна тонкість: якщо ви хочете запускати один і той же портативний KeePass з різними конфігураціями, то кожен запуск потрібно виконувати з аргументами командного рядка. Тобто при такому використанні неможлива «портативна» конфігурація за замовчуванням, яка застосовувалася б за відсутності цих аргументів.

Таким чином, для бази закладок був віддамо перевагу варіант з окремим екземпляром KeePass'а, щоб не ускладнювати життя користувача додатковими стартерами. Однак тепер, коли ми до них трохи звикли, спробуємо все-таки домогтися від одного портативного KeePass'а роботи з різними конфігураціями.

Щоб активувати довільних конфігурацій, створимо в каталозі програми спеціальний файл KeePass.config.enforced.xml.

Тепер при кожному запуску KeePass'а будемо задавати бажану конфігурацію аргументом командного рядка -cfg-local. Щоб використовувати звичайну конфігурацію KeePass.config.xml, будемо запускати KeePass сорочки з короткими рукавами, що складається з рядка

start "" / d "% ~ dp0" KeePass.exe "DBases \ Database.kdbx" -cfg-local: KeePass.config.xml

Можна додати інші конфігурації під довільними іменами і відповідні батники. Наприклад, конфігурацію KeePass.config.B.xml буде застосовувати батник виду

start "" / d "% ~ dp0" KeePass.exe "DBases \ Bookmarks.kdbx" -cfg-local: "KeePass.config.B.xml"

Налаштований таким чином KeePass ніколи не повинен запускатися без аргументу -cfg-local - інакше він збереже конфігурацію в профіль користувача.

Подбаймо, щоб цей аргумент підставлявся, коли ми відкриваємо будь-яку базу в новому вікні KeePass'а посиланням виду kdbx: // шлях до бази. Будемо вважати, що розташування конфігурації задається полем Cfg поточного запису. Якщо це поле завжди задано, досить просто додати в перевизначення схеми kdbx (Параметри → Інтеграція → Перевизначення URL) аргумент -cfg-local: "{S: Cfg}". Але якщо в якихось kdbx-записах цього поля може не бути, знадобиться більш складна конструкція.

Якщо ви користуєтеся налаштуванням з попередньої статті , То міняти схему kdbx не потрібно - в ній вже передбачено наявність або відсутність поля Cfg і багато іншого.

Якщо ви вирішите використовувати таким способом готову конфігурацію для закладок, запропоновану в попередній статті, замініть в ній все входження {T-REPLACE-RX :: {APPDIR}:. {10} $ ::} на {APPDIR} і збережіть її під ім'ям KeePass.config.B.xml, а в запису, що відкриває базу закладок, додайте поле Cfg зі значенням {APPDIR} {ENV_DIRSEP} KeePass.config.B.xml і видаліть поле AppPath.

Використовуємо змінні середовища

Посилаємося на локальні ресурси

У базі можуть бути присутніми різні посилання на локальні ресурси, наприклад, шляхи запускаються. При цьому одна база часто використовується на декількох ПК і синхронізується між ними. Тому виникає завдання, як зробити базу не залежить від оточення.

Рішення, запропоноване в попередній статті - посилатися в базі не на самі програми, а на їх ярлики, розташовані поруч з KeePass'ом. Однак це рішення має деякі обмеження.

Інший підхід - використання змінних середовища. Ці змінні можна призначати в сорочки з короткими рукавами, запускає KeePass. Наприклад, додамо в початок цього батника рядок

set "KeePass_VeraCrypt = c: \ Program Files \ VeraCrypt \ VeraCrypt.exe"

Тепер в базі або в конфігурації KeePass'а можна буде замість шляху до програми VeraCrypt вживати код% KeePass_VeraCrypt%. Таким чином, на різних ПК буде досить завести різні сорочки з короткими рукавами. А там, де використовується портативна VeraCrypt, каталог якої розташований поруч з каталогом KeePass'а, підійде батник, що визначає шлях до VeraCrypt, виходячи з власного розташування:

Подібним чином можна визначити в сорочки з короткими рукавами кілька змінних середовища і використовувати їх в KeePass'е. Наприклад, задамо розташування відкриваються баз (абсолютний шлях), місце збереження їх резервних копій і кількість збережених версій однієї бази:

Тепер створені змінні можна буде використовувати в тригері резервного копіювання. А змінюючи значення цих змінних, можна буде переносити конфігурацію з цим тригером на різні ПК, в т.ч. з непортативність KeePass'ом, що вимагає зберігати бази окремо від програми.

• Подія: Збережений файл бази даних
• Умова: змінна оточення KeePass_DBDir дорівнює {DB_DIR}
• дії:
  • Активувати базу, фільтр: Виконує тригер
  • виконати команду
    • файл:% comspec%
    • аргументи:
      / C "copy" {DB_PATH} ""% KeePass_BackupDir% \ {DT_UTC_SIMPLE} UTC- {DB_NAME} "/ y & for / f" skip =% KeePass_BackupNumber% tokens = * "% X in ( 'dir"% KeePass_BackupDir% \ * UTC- {DB_NAME} "/ b / o: -n ') do del"% KeePass_BackupDir% \% X "/ q"
    • опції: чекати виходу, приховане вікно.

Якщо ви використовуєте налаштування, запропоновану в попередніх статтях і бажаєте варіювати розташування каталогу з базою, замініть в файлах конфігурації все входження {APPDIR} {ENV_DIRSEP} DBases на% KeePass_DBDir%.

Зауважимо, що для налаштування тригерів необов'язково вдаватися до змінних середовища, так як на різних ПК конфігурацію можна зробити різної, на відміну від синхронізованої бази. Але змінні середовища спрощують зміну настройки.

Змінні середовища успадковуються дочірніми процесами, тому нове вікно KeePass'а, відкрите kdbx-посиланням, буде працювати з цими ж значеннями змінних.

Оптимізуємо роботу з еквівалентними доменами

Спосіб використання KeePass'а, запропонований в попередніх статтях, дозволяє враховувати еквівалентні домени при глобальному автонабір . Наприклад, щоб на сторінці https://passport.yandex.ru вводилися облікові дані з запису з посиланням https://mail.yandex.by

Кожен набір еквівалентних доменів задається окремим записом в групі domains: заголовок запису складається з доменів, розділених знаками |, а також починається і закінчується цим знаком; логін опціонально містить регулярний вираз.

Нагадаю, як реалізована підтримка еквівалентних доменів. У кожного запису в якості асоційованого вікна і адреси прописаний код, який інтерпретується KeePass'ом як регулярний вираз, яке визначається URL'ом записи. При цьому безпосередньо в записах зазначений не сам код, а посилання на нього. Завдяки цьому не потрібно оновлювати всі записи, щоб міняти цей код - досить редагувати лише службову запис <Associations>. Код зберігається в ній в перетвореному вигляді, з екранованими знаками «{»; при зверненні до нього виконується зворотне перетворення.

Однак багаторазові звернення до службової записи і перетворення коду уповільнюють роботу KeePass'а при глобальному автонабір. Крім того, можна помітити, що вибір коду залежить від зовнішнього середовища: від настройки браузерів, від потужності ПК. Тому зберігання коду в базі виглядає не найкращою ідеєю.

Замінимо посилання на службову запис змінними середовища - тоді цей код винесе за межі бази і його можна буде зробити різним для різних ПК. Разом з тим підвищиться швидкодія, так як з мінливих середовища буде надходити готовий код, який не потребує зворотного перетворення.

Отже, URL-посилання записи <Associations> збережемо у файлі TargetUrl.txt в підкаталозі Scripts. Подвійним кліком скопіюємо пароль цього запису і збережемо там же в файлі TargetTitle.txt. Потім в обох файлах замінимо всі входження {{} на {.

Код, що поміщається в файли, необов'язково отримувати через запис <Associations>, можна сформувати його безпосередньо.

У цьому прикладі дозволяється відповідність адреси будь-яким піддоменів, але з метою швидкодії не перевіряється відповідність регулярному виразу. Для браузерів K-Meleon, Pale Moon, а також для будь-яких браузерів, запущених в пісочниці Sandboxie, враховується Ви додали будь-яким розширенням в кінець віконного заголовка. В інших браузерах адреса визначається лише плагіном WebAutoType.

Файл TargetUrl.txt:

//^(?i)(?:\w+\:\/\/)?(?:[\w\-\.]+\.)?(?=\w)(?:{T-REPLACE- RX: / {REF: T @ T: | {T-REPLACE-RX:! {URL: HOST}! ^ www \. !!} |} / ([^ \ w \ s \ |]) / \ $ 1 / }) (?: [\: \ / #] \ S *)? $ //

Файл TargetTitle.txt:

// (? I) \ W * (?: \ W + \: \ / \ /)? (?: [\ W \ - \.] + \.)? (? = \ W) (?: {T- REPLACE-RX: / {REF: T @ T: | {T-REPLACE-RX:! {URL: HOST}! ^ www \. !!} |} / ([^ \ w \ s \ |]) / \ $ 1 /}) (?: [\: \ / #] \ S *)? \ W * (?: [^ \.] * \ [# \] | Pale Moon (?: \ (Private Browsing \))? | K \ -Meleon) $ //

В сорочки з короткими рукавами, запускає KeePass, инициализируем змінні середовища вмістом цих файлів:

Тепер асоціюємо кожну запис з адресою% KeePass_TargetUrl% і заголовком% KeePass_TargetTitle%. Це можна зробити ручним редагуванням або різними варіантами XML-заміни (Сервіс → База даних → XML-заміна). Щоб в подальшому нові записи мали готові асоціації з адресою і заголовком, будемо створювати їх за шаблонами.

На вкладці Автонабір потрібно додати дві асоціації або змінити наявні: в одній записати код% KeePass_TargetTitle% в поле Цільове вікно, в іншій - код% KeePass_TargetUrl% в поле Target URL.

Якщо ви користуєтеся налаштуванням з попередніх статей, знадобиться виконати XML-заміну, що перетворює посилання на службову запис в змінні середовища:

• вузли: // Entry / AutoType / Association / Window
• дію: Замінити дані
• дані: Внутрішній XML
• знайти: \ {T \ -REPLACE \ -RX \: \ / \ {REF \: P @ T \: & lt; Associations. *
• замінити на: & # 37; KeePass_TargetTitle & # 37;
• включити опцію Регулярні вирази.

Потім аналогічно:

• знайти: \ {T \ -REPLACE \ -RX \: \ / \ {REF \: A @ T \: & lt; Associations. *
• замінити на: & # 37; KeePass_TargetUrl & # 37;

Можна однією XML-заміною обробити всі записи з параметрами автонабори за замовчуванням: тобто у яких автонабір дозволений, послідовність перестав перевизначена, ускладнення відключено, асоціацій з вікнами немає.

• Вузли дерева: // Entry / AutoType
• Дія: Замінити дані
• Дані: Зовнішній XML
• шукати:
  <AutoType> \ s * <Enabled> True <\ / Enabled> \ s * <DataTransferObfuscation> 0 <\ / DataTransferObfuscation> \ s * <\ / AutoType>
• Замінити на:
  <AutoType> <Enabled> True </ Enabled> <DataTransferObfuscation> 1 </ DataTransferObfuscation> <Association> <Window> & # 37; KeePass_TargetTitle & # 37; </ Window> <KeystrokeSequence /> </ Association> <Association> <Window> ??: URL: & # 37; KeePass_TargetUrl & # 37; </ Window> <KeystrokeSequence /> </ Association> </ AutoType>
• опція Регулярний вираз включена.

В результаті в таких записах включиться ускладнення і додасться підтримка еквівалентних доменів, а решта записи залишаться недоторканими.

Щоб додати підтримку еквівалентних доменів в усі записи з певного набору і ні в які інші, створимо в базі групу toImprove і перемістимо в неї записи, що підлягають редагуванню. Виконаємо XML-заміну з такими параметрами:

• Вузли дерева: // Group [Name = "toImprove"] // Entry / AutoType
• Дія: Замініті дані
• Дані: Зовнішній XML
• Шукати: </ AutoType> \ Z
• Замініті на:
  <Association> <Window> & # 37; KeePass_TargetTitle & # 37; </ Window> <KeystrokeSequence /> </ Association> <Association> <Window> ??: URL: & # 37; KeePass_TargetUrl & # 37; </ Window> <KeystrokeSequence /> </ Association> </ AutoType>
• опція регулярно вирази включена.

Потім расформіруем групу toImprove і видалимо її.

Видаляємо змінні середовища

Змінні середовища, призначені KeePass'у, можуть успадкувати браузерами та іншими додатками, які він запустить. Можна не брати до уваги це проблемою і нічого не робити, якщо імена і значення змінних не є секретом.

Втім, у разі настройки, запропонованої в попередній статті, і не спостерігається успадкування змінних середовища. Справа в тому, що при цьому налаштуванні браузери и інші додатки запускаються KeePass'ом, в основному, через провідник. Навіть коли запуск додатків виконується за схемою cmdDirect, без участі провідника, він присходит через скрипт RunActivate.js, який видаляє всі змінні, чиї імена починаються на KeePass_.

Відкриваємо базу без введення пароля

Використовуємо командний рядок

У командному рядку можна передати компоненти ключа: аргументом -pw - майстер-пароль, аргументом -keyfile - ключовий файл (шлях або вміст в base64), аргументом -useraccount повідомити про шифрування обліковими даними Windows. Повинні бути вказані всі компоненти, якими зашифрована відкривається база.

start "" / d "% ~ dp0" KeePass.exe "DBases \ Database.kdbx" -pw: "myMasterPassword" -keyfile: "K: \ Database.key" -cfg-local: KeePass.config.xml

Однак передавати майстер-пароль в явному вигляді вельми небезпечно, так як аргументи командного рядка легко побачити, наприклад, в диспетчері завдань, і головне, вони нерідко логіруются. (І само собою, неприпустимо відкрито зберігати цей пароль в сорочки з короткими рукавами.)

Щодо захищений варіант - передавати в командному рядку майстер-пароль, зашифрований даними облікового запису Windows:

start "" / d "% ~ dp0" KeePass.exe "DBases \ Database.kdbx" -pw-enc: "зашифрований пароль" -keyfile: "K: \ Database.key" -cfg-local: KeePass.config.xml

Щоб отримати «зашифрований пароль», який потрібно підставити в цю команду, потрібно буде зробити запис з майстер-паролем бази в якості пароля і логіном {PASSWORD_ENC}, скопіювати логін подвійним кліком і вставити в батник, а потім видалити запис або просто закрити базу без збереження .

Але тепер відкриття бази зводиться до доступу до облікового запису користувача: зловмиснику досить заволодіти зашифрованим майстер-паролем (наприклад, отримавши логи запуску програм або той же батник) і увійти в обліковий запис, причому зробити це можна в різний час і в різному порядку. Зокрема, втрачає будь-який сенс блокування бази. До речі, про це потрібно пам'ятати, відкриваючи будь-яку базу в новому вікні kdbx-посиланням: таке відкриття ставить її майстер-пароль під удар. Безпечніше відкривати базу в новій вкладці того ж вікна за допомогою тригерів.

Використовуємо стандартний потік введення

Крім командного рядка, KeePass надає ще один спосіб передачі майстер-пароля - через стандартний потік введення. Цей варіант виглядає безпечніше попередніх. Для його застосування KeePass повинен запускатися з аргументом -pw-stdin. Таку передачу майстер-пароля здатний виконати батник

Незрозуміло проте, звідки майстер-пароль візьметься в самому сорочки з короткими рукавами - не зберігати ж його там в явному вигляді ... Кілька спірне рішення - прочитаємо пароль з файлу на зашифрованому диску.

Припустимо, перед запуском KeePass'а монтується VeraCrypt-контейнер, наприклад, зашифрована сама ОС. Дозволимо в VeraCrypt кешування пароля (в разі шифрованого ОС - Налаштування → Шифрування системи → Кешувати пароль дозагрузочной аутентифікації). Створимо контейнер VeraCrypt мінімального розміру, захищений тим же паролем, і помістимо в нього файл, який містить майстер-пароль бази. Тепер будемо запускати KeePass сорочки з короткими рукавами, який монтує цей контейнер, зчитує майстер-пароль, демонтує, очищає кеш VeraCrypt і запускає KeePass, передаючи йому майстер-пароль через стандартний потік введення.

Вважаємо, що база Database.kdbx і криптоконтейнера Database.pw з її паролем лежать в одному підкаталозі DBases, пароль записаний у файлі Password.txt в корені віртуального диска, для тимчасового монтування використовується буква «P». Батник Run.bat влаштований так, щоб KeePass і VeraCrypt НЕ успадкували змінну з майстер-паролем.

Таким чином, замість двох паролів, від шифрованого диска і від бази, будемо вводити один. Якщо заблокувати базу, то повторно вона вже не відкриється сорочки з короткими рукавами, оскільки буде очищено кеш VeraCrypt. У разі шифрування ОС має сенс додати батник в автозавантаження, щоб очищення кешу сталася якомога швидше.

Втім, батник тут незручний, так як при такому запуску KeePass'а інтерпретатор не закінчується сам і доводиться закривати консольне вікно вручну. Скористаємося замість нього WSH-скриптом. Цей вид скрипта годиться і для попередніх прийомів з використанням робочого каталогу, аргументів командного рядка і змінні середовища - всі вони присутні в коді.

Попереджу, що яким би способом замість звичайного набору майстер-пароль ні передавався KeePass'у, зняття дампа пам'яті загрожує витоком цього пароля, причому навіть після блокування бази.

Управління працюючим KeePass'ом

Хоча стаття присвячена параметрам запуску, на додаток перерахуємо аргументи командного рядка, якими можна управляти вже запущеної програмою:

• автонабір для обраної записи: -auto-type-selected
  (Але якщо працює кілька KeePass'ов, набираються дані можуть непередбачувано перемішатися);
• глобальний автонабір для всіх працюючих KeePass'ов: -auto-type
  (уникнути змішання даних допоможе опція Завжди показувати вікно вибору запису для глобального автонабори);
• глобальний автонабір пароля для всіх працюючих KeePass'ов: -auto-type-password
• Відкриття посилання для запису із заданим ідентифікатором: -entry-url-open -uuid: ідентифікатор
  (Наприклад, в разі kdbx-посилання ця команда відкриє якусь базу в новому вікні KeePass'а);
• закриття всіх KeePass'ов (не примусовою): -exit-all
• блокування всіх KeePass'ов: -lock-all
• розблокування всіх KeePass'ов: -unlock-all
• скасування відкриття / збереження бази в усіх KeePass'ах (наприклад, при зависанні): -cancel
• відправка довільного повідомлення плагинам всіх KeePass'ов: -e: повідомлення
  (Як і на які повідомлення реагувати, визначається плагінами);
• відправка довільного повідомлення плагинам одного KeePass'а: -e1: повідомлення
  (Якщо працює кілька KeePass'ов, то не визначене, який з них отримає повідомлення).