I'm on macOS Catalina 10.15.6
I'm using gpg to sign a file
gpg --sign file.txt
But has error:
gpg: Sorry, we are in batchmode - can't get input
Check the ~/.gnupg/gpg.conf file (I use vim), delete the word batch
vi ~/.gnupg/gpg.conf
Press dd to delete a line, and u to undo. Press :wq to save changes.
Related
I'm trying to run gpg from a Bash script designed to backup a website. The command that fails is
gpg --homedir /home/backupuser/.gnupg --verbose --no-tty --recipient {group-name} --trust-model always --output /home/backupuser/backup/{tar-file}.gpg --encrypt /mnt/ramdir/site-backup-backupuser/{tar-file}
It fails with return code 127. The gpg home directory exists, as does the {tar-file}. The output directory exists but the output file does not.
If I repeat the gpg command in the script it fails in exactly the same way. But if I execute it in shell immediately after it has failed in the script it works as expected. The output is:
gpg: using subkey {hhhhhhhhhhhhhhhh} instead of primary key {hhhhhhhhhhhhhhhh}
gpg: automatically retrieved '{email address1}' via Local
gpg: No trust check due to '--trust-model always' option
gpg: using subkey {hhhhhhhhhhhhhhhh} instead of primary key {hhhhhhhhhhhhhhhh}
gpg: automatically retrieved '{email address2}' via Local
gpg: No trust check due to '--trust-model always' option
gpg: reading from '/mnt/ramdir/site-backup-backupuser/{tar-file}'
gpg: writing to '/home/backupuser/backup/{tar-file}.gpg'
gpg: '/mnt/ramdir/site-backup-backupuser/{tar-file}' already compressed
gpg: RSA/AES256 encrypted for: "{hhhhhhhhhhhhhhhh} {Comment} <{email address1}>"
gpg: RSA/AES256 encrypted for: "{hhhhhhhhhhhhhhhh} {Comment} <{email address2}>"
This is Debian "bullseye" 11.6, gpg 2.2.27 and libgcrypt 1.8.8.
I have tried numerous combinations of parameters, always with the above result. With or without --homedir, with or without sudo (I was getting desperate), from a file on disk rather than in RAM, with or without --verbose and several others.
Brief
I attempted to generate a SSH key for my Github on a Macbook Pro. Yet I encountered the 'Enter PIN for authenticator' issue when I progressed to the step of adding it to the ssh-agent. The bizarre asking is from the following command:
$ ssh-add -K ~/.ssh/id_rsa
Enter PIN for authenticator:
which I totally have no idea what I should type into for this asking. Yet as I typed with the following command, everything just worked as this page revealed.
$ /usr/bin/ssh-add -K ~/.ssh/id_rsa
Identity added: /Users/${user_name}/.ssh/id_rsa (your_email#example.com)
Why there exists this kind of difference ? What exactly you need to type for the asking of 'Enter PIN for authenticator:' ?
Some Info
version information
$ ssh -V
OpenSSH_8.3p1, OpenSSL 1.1.1g 21 Apr 2020
$ sw_vers -productVersion
10.15.6
I generated the key with the ed25519 algorithm.
If you use this command
$ ssh-add -K ~/.ssh/id_rsa
you will be asked to enter the PIN for authentication
so instead of that use
$ ssh-add ~/.ssh/id_rsa
You have a second (Brew-installed?) ssh-add in your shell's $PATH which is not the same as the Apple version. In the Apple version -K stores the password in your keychain, so you don't have to type it every time. In the non-Apple version -K "Loads resident keys from a FIDO authenticator."
The ssh-add at:
/usr/bin/ssh-add
is the Apple provided one, and will work with -K.
Update for macOS Monterey (v12)
The -K and -A flags are deprecated and have been replaced by the --apple-use-keychain and --apple-load-keychain flags, respectively.
I have seen on - https://www.ssh.com/academy/ssh/add and found that if we use -'k' (small k) then it is asking about passpharase what I added during ssh key generaion.
for instance my passphrase while creating ssh key was - Pass#123#
after that when i exeute command -
$ssh-add -k ~/.ssh/id_rsa
Enter passphrase for ~/.ssh/id_rsa: (typed here - Pass#123# and press enter)
Identity added: ~/.ssh/id_rsa (xxxxxxx#xxxx.com)
as specified by the man ssh-add page, the -K option is:
-K Load resident keys from a FIDO authenticator.
so you basically tell it to use an authenticator.
When I try to list my gpg keys I'm getting an error:
gpg --list-keys
gpg: NOTE: trustdb not writable
gpg: checking the trustdb
gpg: trustdb rec 56: write failed (n=-1): Bad file descriptor
gpg: trustdb: sync failed: Bad file descriptor
I tried doing a recursive chown on my user directory. But that didn't seem to solve the problem.
The volume is not read only:
[web1:~] bluethundr% touch test
[web1:~] bluethundr% echo hi > test
[web1:~] bluethundr% cat test
hi
So I'm wondering why the trustdb is not writable.
How can I solve this?
That seems to have been reported in bug 771976
I found this when running the command apt-key list on a machine where
the root filesystem is normally mounted read-only.
This results in running gpg with "--trustdb-name", "/etc/apt//trustdb.gpg", "--list-keys".
gpg in turn attempts to create "/etc/apt//trustdb.gpg.lock" in order to lock the trustdb, which fails.
Seeing how --list-keys is an operation which shouldn't require writing
to anything, having it fail in this situation is bad.
Even though the volume is not read-only, check (with an strace) where gpg --list-key is attempting to create its trustdb.gpg.lock file.
strace gpg --list-key | grep trustdb.gpg.lock
The OP bluethundr adds in the comments:
I changed to the .gnupg directory and did a list.
I saw that the files in there were owned by root! So I did a sudo chown -R myuser:myuser *.
Then I ran gpg --list-keys again and it worked!
The problem was that the files in .gnupg were owned by root for some reason.
I granted the permissions on the trustdb.gpg file present in the installation directory in C Drive, to the user I had logged on with. It worked thereafter.
I'm trying to decrypt a file using gpg and getting this error:
$ gpg --no-tty --batch --verbose --decrypt --passphrase foo file.enc
Version: GnuPG v1.4.11 (GNU/Linux)
gpg: armor header:
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
I tried to reload the gpg agent, no luck:
$ gpgconf --reload gpg-agent
How to solve that?
For the record, if somebody will encounter this problem, too:
The problem was, that the encryption was done using gpg version 1.4.11 and the decryption was using gpg version 2.0.22.
After upgrading the encryption to gpg2 (2.0.17), everything worked fine.
I found this, which seems to be the magic that I could not find anywhere else:
Try adding --pinentry-mode loopback to your command. Maybe there is a
problem with your installation / pinentry program so that it does not start or
you are accidentally using a dummy / test pinentry which provides the wrong
passphrase.
I encrypted my file with a passphrase file in batch mode. When I tried to decrypt my file I got the dreaded "bad session key" message.
I created a passphrase file with Vim for Windows, and Vim left \r\n at the end of the text line even though I did not hit carriage return. gpg ignored the \n but retained the \r as part of the passphrase!
Vim for Windows can be induced to not leave \r\n, but it is easier to just use Notepad without a carriage return at the end of line. Best to check your passphrase file with a hexdump to be sure. There are other ways to get hurt by \r\n issues when supplying the passphrase using the command line, so be alert to it.
I am attempting to connect to an Amazon EC2 Server via Mac Terminal. I have a PPK file that does not have a password attached to it, but when I try to connect I get a popup box that says "Enter the password for the SSH Private Key."
So we tried creating a PPK that has a password - but it does not accept the password, it still rejects the connection.
I have a Windows user who is able to connect using the same PPK on Putty.
Has anyone experienced this issue?
The mac is looking for a .pem key. The ppk is generated specifically for putty. If you don't have the original ppk key.
Download puttygen.exe from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Then go to conversions -> export OpenSSH key. Save the output as a .pem file and try using that with the mac.
If this doesn't work can you post the command you're running from mac. Its possible you've got some extra parameter or something.
Maybe your problem is with permissions for your key. I know in linux its required to change the permissions.
Taken from the website http://om4.com.au/ssh-rsa-key-pairs-passphrases-leopard/
Clear the contents of your ~/.ssh directory and set the directory permissions to 700 (directories need to be "executable")
$ rm ~/.ssh/*
$ chmod 700 ~/.ssh
Generate your rsa key pair (there are variations for this, but this is the version I used):
$ ssh-keygen -t rsa
Set the permissions for all files in ~/.ssh to 600
$ chmod 600 ~/.ssh
Copy your id_rsa.pub key to your server’s .ssh/authorized_keys file
Add your passphrase to your keychain using this command:
$ ssh-add -K
(you will see Enter passphrase for [your system]/.ssh/id_rsa: )
The error Enter your password for the SSH key x can result from using a key of the wrong format (such as a ppk key) in ssh or sftp. This is because it is interpreted as an encrypted ssh key and so prompts for the passphrase, when actually there is no passphrase.
In OS X I was able to simulate this error by simply typing the following into the command line:
sftp -o IdentityFile=randomtextfile mysftpserver.com
The solution is to convert the file using puttygen as suggested by bwight.
In addition to the other answers, the issue might come from the fact you haven't specified which user you want to connect as.
For example ssh -i francky.pem 208.52.170.43 will ask you for your password on Mac, whereas ssh -i francky.pem root#208.52.170.43 shouldn't. Note that on Linux you don't specify the user.
I was running into the exact same problem in MAC, I found a quite simple way of getting rid of it.
Instead of using ssh -i IP address, use the following>
ssh user#IP
Hope you already found the answer after this long time :)
In my case, the problem was the file's break type. Try this:
1.- Open the .pem file with TextWrangler
2.- At Bottom of app, verify if the Break Type is "Windows(CRLF)".
This issue had me pulling my hair out for 20 min or so. Realized that I was able to connect successfully from another terminal window. In my case I just had to close out the current terminal window and use another or new window. Very strange, but may help you out.