Konubinix' opinionated web of thoughts

Gpg Concepts

fleeting

GPG key is actually a collection of keys. There is one primary key, which is typically used only for signing and certification.

https://opensource.com/article/19/4/gpg-subkeys-ssh

suggested usage of GPG is to create a subkey for encryption

https://opensource.com/article/19/4/gpg-subkeys-ssh

use a subkey that has been created for authentication to complete SSH connections

https://opensource.com/article/19/4/gpg-subkeys-ssh

authentication subkey will completely replace the keypair you may have generated in the past with ssh key-gen. You can create as many of these as you want if you need multiple SSH keys.

https://opensource.com/article/19/4/gpg-subkeys-ssh

get gpg-agent to handle requests from SSH, you need to enable support by adding the line enable-ssh-support to the ~/.gnupg/gpg-agent.conf

https://opensource.com/article/19/4/gpg-subkeys-ssh

specify the keys in the ~/.gnupg/sshcontrol

https://opensource.com/article/19/4/gpg-subkeys-ssh

keygrips—internal identifiers gpg-agent uses to refer to keys.

https://opensource.com/article/19/4/gpg-subkeys-ssh

Unlike a key hash, a keygrip refers to both the public and private key

https://opensource.com/article/19/4/gpg-subkeys-ssh

find the keygrip, use gpg2 -K –with-keygrip

https://opensource.com/article/19/4/gpg-subkeys-ssh

SSH_AUTH_SOCK=$(gpgconf –list-dirs agent-ssh-socket)

https://opensource.com/article/19/4/gpg-subkeys-ssh

sec# instead of just sec for your gpg private key means the secret key is not really there.

Verify that gpg -K shows a sec# instead of just sec for your private key. That means the secret key is not really there.

https://wiki.debian.org/Subkeys