keepassxc-cli Как передать ввод пароля?

Спасибо но не работает ваш вариант.

spawn: command not found
expect: command not found
send: command not found
interact: command not found

spawn: command not found
expect: command not found
send: command not found
interact: command not found

Тебе это ни о чём не говорит?

установил expect

t: 4: spawn: not found
couldn't read file "Enter password to unlock": no such file or directory
t: 6: send: not found
t: 7: interact: not found
t: 8: send: not found
couldn't read file "eof": no such file or directory

Ты первую строчку скрипта не забыл написать?

#!/usr/bin/expect -f

Такое впечатление, что скрипт не экспект выполняет, а кто-то другой. В первом случае — баш (или другой шелл), во втором — хз. Как ты его запускаешь?

В предыдущем сообщении запускал sh t

сейчас так

user@host:~$ ./t
spawn keepassxc-cli show -a username test.kdbx test
Enter password to unlock test.kdbx: qwerty

TESTCONTENT
send: spawn id exp4 not open
    while executing
"send "\r""
    (file "./t" line 8)
user@host:~$ 

Вроде бы всё получилось, но тут какие-то ошибки посыпались, а вывод хотелось бы получить чистым, то есть

user@host:~$ ./t
TESTCONTENT
user@host:~$ 

Обрезать могу, но хотелось бы понимать что происходит и можно ли пароль подставлять из переменной?

В документации подобной функции не нашёл.

Гм, а вот это что:

 -k, --key-file <path>
       Specifies a path to a key file **for unlocking the database**.

Сделай вход по ключу.

Ключ неудобен. На сам ключ можно установить пароль? Суть базы теряется, ведь нужно помимо самой базы ещё хранить где-то ключ. База призвана хранить другие ключи. В любом случае всё должно сводится к одному паролю который не хранится на постоянном накопителе.

В предыдущем сообщении запускал sh t

Но почему?? Там же ясно написано, что скрипт для экспекта (#!/usr/bin/expect), зачем запускать его шеллом, а потом удивляться ошибкам??

На сам ключ можно установить пароль?

Можно.

Суть базы теряется…

Не теряется. Суть базы — заменить знание множества ключей или паролей одним паролем или ключом. Храни базу на винте, ключ от неё — на флешке (лучше на двух флешках ).

В любом случае всё должно…

Извини, но если ты такой умный и знающий что и как всё должно, почему задаёшь на форуме такие глупые вопросы?

Мне кажется, что ты к корове не с той стороны подходишь.

Я не понял как шифровать ключ паролем. Он любой файл готов съедать в качестве ключа и это как-то не логично потому что файл является тем же паролем только на постоянном накопителе. бред же

#!/usr/bin/expect -f

set timeout -1
spawn keepassxc-cli open /tmp/rest.db
expect "Enter password to unlock"
send "qwerty\r"
interact ++ return

Так работает без ошибок, но я не пойму как засунуть переменную вместо пароля? Мне нужно что бы пароль брался из переменной

#!/usr/bin/expect -f
read -p "pass: " pass
set timeout -1
spawn keepassxc-cli open /tmp/rest.db
expect "Enter password to unlock"
send "$pass\r"
interact ++ return

Проблема не решена. Застой в этим expect

Я так делаю.

$ kwallet-query -f 'Passwords' -r 'KPDB' kdewallet | keepassxc --pw-stdin ~/.passwd.kdbx

kwallet-query? нашёл пакет kwalletcli, так же в вашем примере keepassxc, а не keepassxc-cli. мне не нужно запускать гуи. только в режиме cli. Можно пояснения?

Может создать тему в джоб? Сориентируйте сколько это будет стоить.

Ну а зачем ты вставляешь встроенные команды shell в tcl-скрипт?
Expect - модуль-расширение tcl, expect - tcl-интерпретатор, собранный с этим расширением.
Если тебе нужны вызовы типа prog -pass "pass", то и смотри, как в tcl обращаются к параметрам скрипта, если тебя устроит MYPASS="pass" prog, то опять-таки смотри, как в tcl обеспечивается доступ к к переменным среды.
Хотя с точки зрения безопасности плохо и то и то.

Не знаю что такое tcl. Вообще сложно понять что вы написали. Мне бы простым языком объяснить. Что с точки зрения безопасности не так?

Эту запчасть #!/usr/bin/expect -f нельзя опустить и выполнить команды без неё? В одноу строку например, что бы этот болт был прикручен внутри цикла.

Не знаю что такое tcl.

Когда ты пишешь в первой строке скрипта #!/usr/bin/expect -f, это заставляет систему запустить соответствующюю программу, подав ей на вход сам скрипт. Т.е. если ты хочешь выполнить sh-скрипт #!/bin/sh, то далее и должны следовать команды shell. Если у тебя bash-специфический скрипт, надо так и писать #!bin/bash (или где он утебя).
tcl - это такой язык программирования, расширением которого является expect.

Когда ты пишешь в первой строке скрипта #!/usr/bin/expect -f, это заставляет систему запустить соответствующюю программу, подав ей на вход сам скрипт.

Ну это очевидно, я лишь для наглядности засунул нужную строку туда. Я всегда пишу без #!bin/sh и у меня всё работает. Почему? Так же я стараюсь не плодить лишние файлы и записывать программу в один файл. В моём случае это удобнее и я не пойму как этот скрипт записать таким образом что бы в него можно было разместить другие команды, в том числе переменные. Суть задачи такова что пароль нужно подставлять из переменной.

и у меня всё работает. Почему?

Нет, когда ты не указываешь явно через #! интерпретатор, то система, не определив этот файл как способный к исполнению бинарник (elf, coff, и т.д.), считает его текстовым файлом, скриптом, предназначенным для интерпретации /bin/sh, который в большинстве систем просто символическая ссылка на какой-либо более-менее posix-совместимый shell - bash, dash, и т.п.

Я понял. Так как решить мою проблему? Кроме expect, который мне непонятен - нет других путей?

1) Кроме expect, который мне непонятен - нет других путей?
«К геометрии нет царских путей» (приписывается Эвклиду).
2) Так как решить мою проблему?
Не знаю. Многие программы, например su, специально отказываются работать, если не запущены на терминале. В принципе, можно запустить любую программу на псевдотерминале, особенно если ядро поддерживает BSD-псевдотерминалы. Но expect проще.
3) «Свою проблему» ты так толком и не сформулировал.
Если проблема в том, чтобы запустить «prog -p пароль», то, кроме expect, можно попробовать метод aquadon, записав предварительно пароль во временный файл.
4) Что с точки зрения безопасности не так?
То, что пока работает этот скрипт/программа/... её параметры и переменные окружения видны через ps или /proc кому угодно, так что само использование менеджера паролей является самоуспокоением.
5) Может создать тему в джоб?
Мне, например, было бы стыдно брать деньги за нанесение вреда заказчику.

3. «Свою проблему» ты так толком и не сформулировал.

уже много раз писал. нужно передать ввод пароля через переменную. переменная будет добывать пароль из read

записав предварительно пароль во временный файл.

пароль на диск? тогда проще вообще не шифровать

То, что пока работает этот скрипт/программа/… её параметры и переменные окружения видны через ps или /proc кому угодно, так что само использование менеджера паролей является самоуспокоением.

когда расшифрован допустим luks-контейнер, его содержимое не доступно кому-угодно? Если допускать что система скомпрометирована, тогда нет смысла постоянно держать базу паролей закрытой, один ввод пароля отдаст доступ злоумышленнику. А учитывая предыдущее предложение записать пароль в файл, это вовсе лишено здравой логики.

Прочти ниже, а позже не забудь забаниться.

$ more 1.sh
#!/usr/bin/expect -f

set arg1 [lindex $argv 0]
set timeout -1
spawn keepassxc-cli open /tmp/rest.db
expect "Enter password to unlock"
send "$arg1\r"
interact ++ return
send "\r"
expect eof

$ ./1.sh $PASS
spawn keepassxc-cli open /tmp/rest.db
Enter password to unlock /tmp/rest.db: 
/tmp/rest.db>

Этот код работает только если оставить пароль в истории ввода, а он не нужен в истории/файле! Он нужен в переменной которая добаывает пароль из read. Но в этот скрипт read не пропихнёшь. К тому же мне не нужно открывать базу. Нужно доставать из неё данные.

keepassxc-cli show -a username rest.db entryname

Но если эту команду подставить в spawn

$ ./1.sh $PASS
spawn keepassxc-cli show -a username rest.db entryname
Enter password to unlock rest.db:
here_is_username
send: spawn id exp4 not open
    while executing
"send "\r""
    (file "./1.sh" line 9)
$

То выйдет такая черепаха которую нужно ещё чистить от мусора.