pass uses gnupg2, which does not share it's keyring with gnupg 1.x.
Import your keys again using gnupg2 instead of gnupg.
If you already have your keys in gnupg on the target machine run:
$ gpg --export-secret-keys > keyfile
$ gpg2 --import keyfile
After importing, you may need to update the trust on your key.
You should see a Secret key is available. ...
I had the same issue; @Kusalananda is spot on - pass uses gpg2, which stores the key separately, so you have to change the passphrase for both versions.
gpg --edit-key "Your Key"
gpg2 --edit-key "Your Key"
The name of the key used by pass is stored in ~/.password-store/.gpg-id.
gpg: 2048R/FA829B53: skipped: No public key
shows a wrong pass initialization. You initialized pass with the command pass init 2048R/FA829B53 whereas you should do it with the command pass init FA829B53. To solve the problem you should change the content of the file ~/.password-store/.gpg-id from 2048R/FA829B53 to FA829B53 and commit changes.
If you just want the solution, you can skip this part. But for the curious, I'll explain the problems we face:
KeePassXC creates an UNIX socket in $XDG_RUNTIME_DIR/kpxc_server for applications to listen too. keepassxc-proxy is started – via native messaging – by the browser (triggered by the add-on firstname.lastname@example.org, i.e. KeePassXC-...
Any idea why sftp is unable to read the temporary file descriptor?
the <(pass foo) process substitution will cause bash to create a pipe, run the pass foo command asynchronously with its output connected to the writing end of the pipe and replace the <(...) with a path of the form /dev/fd/63, where 63 is the file descriptor referring to ...
pass uses GnuPG to handle encryption.
Recent releases of GnuPG uses a GPG daemon.
This GPG daemon caches your valid authentication for 600 seconds (default-cache-ttl), which may be refreshed to another 600 seconds if you use GnuPG again within that time, up to a maximum of two hours (max-cache-ttl).
You have two options:
Kill the GPG agent process after ...
Welcome to Unix & Linux StackExchange!
The problem with that idea is that the password hashes are not reversible: instead of "decrypting" the hashed password and comparing that to user input at login time, the password the user is inputting is hashed with the same salt as the stored password hash, and then the result is compared to the stored hash. If ...
No this isn't possible. It's a one way hash that's been salted. All you can do is take a dictionary of words, hash them using the same crypt function and see if their results match what's in /etc/shadow.
Tools such as John the Ripper automated this process, but that's effectively all they're doing to crack a password.
John the Ripper is a fast password ...
pass root_password | sudo --stdin --shell succeeded. pass printed the password and sudo read it and started a shell; the output of pass ended, meaning that the stream used for output by pass and input by the shell was closed; the shell exited successfully on EOF.
Subsequent executions within the sudo timeout window didn't require authentication, and so the ...
User information is stored in /etc/passwd and passwords are stored /etc/shadow
Each entry in /etc/shadow contains the user's login, their encrypted password, and a number of fields relating to password expiration
The simplest way that comes to one's mind (especially of someone who doesn't know what pass is): use SSH - i.e. scp (sftp or ssh would work as well).
Yet looking at the pass webpage:
It is a very short and simple shell script. It's capable of temporarily putting passwords on your clipboard and tracking password changes using git.
offers a more elegant ...
So there is no xdotool log as far as I am aware, but as kasperd pointed out, running xdotool with the password as an argument is clearly insecure. But we may pass in the password through a pipe to avoid it showing up in the output of ps aux.
echo -n "$pass" | xdotool type --clearmodifiers --file -
By default (in bash), the builtin version of echo is used, ...
The difference in experience between using pass in a console (what you call a virtual terminal) and within a (GUI) terminal has nothing to do with pass, but with the secret key management done for gpg (as used in the pass scripts) by the gpg-agent.
This gpg-agent is, in modern distributions automatically started with X. You can see this by doing env | ...
You can't compress the two commands into one. You need to first initialise the pass store with your key and then, separately, initialise the git repository. Because, as the manual states, pass git only takes git-command-args.
So, the correct approach requires two steps:
pass init YOUR_KEY
pass git init
I solved the problem by upgrading gnupg from 1.4 to 2.1 which seemed to simplify a lot the configuration.
However, it generated an error of migration of the secret key between gpg and
gpg2 generated the following error message when I was requiring password from
gpg: decryption failed: No secret key
The solution came from this previous issue:
I found running it with the verbose flag gave me what I was looking for, chromium-browser --verbose
[VERBOSE1:key_storage_util_linux.cc(53)] Password storage detected desktop environment: XFCE
[VERBOSE1:password_store_factory.cc(235)] Trying libsecret for password storage.
[VERBOSE1:key_storage_linux.cc(61)] OSCrypt using Libsecret as backend.
I've followed the step by step instructions of Mathew Robinson here and it works like a charm.
The linked article recommends making a git repository for the password store and using
pass git push origin master
to sync. Then use
gpg2 --export-secret-keys > [name].gpg
to put your gpg key in a file, which you should move to the new machine. Then on the new ...
It's impossible to query with Xdotool the state of the cursor in every application, for as far as I checked.
If your usecase is only Firefox' text boxes, I'd recommend using native-messaging-hosts script. Or even better suited for passwords, I'd recommend switching to gopass which is a Go based implementation of shell based pass with additional features and ...
Sure, you could do that, specially if you are willing to recompile Thunderbird itself. However, I must ask What is your threat model? What are you trying to protect from by using a different password manager?
To recap: Mozilla Thunderbird stores a number of secrets (such as email server passwords) so that it can do things like fetching your mail (something ...
You may issue the commit with
pass git commit
pass does not automatically commit changes that you make using pass git, so you need to commit these separately.
Note that pass also allows you to rename entries using
pass mv oldname newname
This commits the move but first also re-encrypts the moved entry.
From the pass manual:
mv [ --force, -f ] old-...
LUKS header contains no executable code, only one or more encrypted copies of the master key of the LUKS partition. Each configured passphrase/keyfile/other access method will decrypt a copy of the master key, which is needed to access the encrypted disk. The LUKS password is not "sent to LUKS header for decryption": instead, the cryptsetup luksOpen command ...
The pass password manager is, by its own manual's admission, a simple wrapper around GnuPG and Git, and does not support expiration dates on passwords.
I would possibly suggest editing the password and adding that information to the password entry's text. This would obviously break scripts that relied on pass for extracting passwords (and that expects the ...
Total user information means
1. Account Information
2. Authentication Information
Account Information store in /etc/passwd file
Authentication Information store in /etc/shadow file but only Only root user can see the information
So if you want to see the authentication information means password information you may check the /etc/shadow file ...
Would an alias be enough? You can go to your $HOME/.bashrc file and bellow other existing alias you can enter
alias sudo='sudo -A'
I have similar customized alias in my .bashrc file that work fine.
Before to make it permanent, you can try it in your shell to verify that works ok.