5

Trying to create GPG keys which will be used for an apt repository hosted on my Centos7 box. I created a new user "apt", and then tried to create the keys, but at the very end, it states that I need a pass phrase, but then instantly closes stating cancelled by user. No it wasn't!

I have since successfully repeated these same steps root and as my standard username which happens to be in the wheels group.

Two questions:

  1. Is it a good idea to use different gpg keys for different uses such as this apt repository, and should keys ever be created as root?
  2. Why am I not able to create a gpg key for this user? Do I need to first create some other key for this user?

Thanks

[apt@devserver ~]$ gpg --gen-key
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Thu 12 Jul 2018 04:32:05 PM UTC
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: somename
Email address: example@gmail.com
Comment:
You selected this USER-ID:
    "somename <example@gmail.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

gpg: cancelled by user
gpg: Key generation canceled.
[apt@devserver ~]$
5
  • What's the full chain from your keyboard to that prompt? E.g., opened an xterm, ssh root@devserver, su apt. Or whatever path you actually took. I suspect gpg is getting some error prompting for the passphrase and not reporting it correctly. – derobert Jul 12 '17 at 16:53
  • I putty from windows to centos as user "michael" (my normal username), and then su apt. I've tried rebooting the machine just to be extra sure. I can try puttying in directly as apt, but sill would like to know why. – user1032531 Jul 12 '17 at 16:55
  • if ssh'ing (putty) directly to apt works, I have a good guess as to why... – derobert Jul 12 '17 at 16:56
  • @derobert Direct putty for apt works. What's your guess? Also, if the owner of the http site for this apt repository is apt, should I be using apt to create the keys? – user1032531 Jul 12 '17 at 16:59
  • writing an answer – derobert Jul 12 '17 at 16:59
13

As to the "cancelled by user" error: GnuPG tries to make sure it's reading the passphrase directly from the terminal, not (e.g.) piped from stdin. To do so, it tries to open the tty directly. Unfortunately, file permissions get in the way — the tty device is owned by the user you log in as. So only that user and root can open it. GnuPG appears to report the error incorrectly, saying you canceled (when in fact it got a permission denied).

As to if you should have a separate key for the repository: yes. There are a couple of reasons that come to mind:

  • A repository can be maintained by more than one person. All of them will need access to the key. You obviously don't want to give them access to your personal key.
  • The software processing new packages will need access to the key. For many repositories, that means you have to keep the key available on an Internet-connected machine. This necessitates a lower level of security than you'd ideally have on your personal key.
  • If you're processing uploads automatically, you may even need to store the key with no passphrase. Obviously lowers security.
  • In case of compromise of your personal key, it's nice to only have to revoke that. Same with compromise of the repository key. It makes revoking a compromised key cheaper.

It's pretty normal to use your personal key to sign the repository key.

As to running key generation as root: not ideal (don't run things as root without good reason), but likely not really an issue.

4
  • This comment lead me to precede gpg command with sudo and it properly prompted for the passphrase on the TTY. Thanks. – AXE Labs Mar 8 '18 at 22:18
  • What is the solution for the "cancelled by user" error? I don't want to run it as superuser. – Ziffusion Jun 15 '18 at 1:37
  • @Ziffusion I'd guess anything that gives it a new tty would work, e.g., running inside screen. Or you could generate the keys as your login user, then copy them over. – derobert Jun 15 '18 at 1:53
  • The only real explanation out there... thank you. – Droj May 14 '19 at 22:19
2

I also have this error after multiple ssh -Y to a host.

I managed to get a prompt for the passphrase by adding the --pinentry-mode loopback option.

1
  • that worked for me, also on macOS – Josefine Nov 30 '20 at 15:50
2

I was running into this and today found a solution to move forward; install screen (if not already installed)

sudo yum install screen  

Then as the user needing to generate the key (typically the user that runs apache) run screen, then run

gpg --gen-key  

and the passphrase prompt will appear within the screen session! then when done, enter exit to exit the screen session. hooray.

1

Its probably too late to answer this but one of the options is to export GPG_TTY=$(tty) to let GPG know which tty to use for the passphrase prompt.

2
0

I had the same problem when I logged as user1 via SSH , switched to user2 with the command su - user2, and then tried to generate a key. To resolve the problem, opened a new terminal, ssh to the server as user2, and then did the command:

gpg --gen-key
0

Solution 1: Exit the user if you are on su user and with your user change tty permission to read and write: Use command ps to get the tty detail and then change its permission. For example: chmod 666 /dev/pts/1. Once the tty permission is changed, then switch user back to su and start generating a new key-pair(gpg --gen-key) and it will work and prompt for passphrase.

Solution 2: Install screen (sudo yum install screen) if machine does not have it already, and then run screen and follow all the steps of generating a new key-pair (gpg --gen-key).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.