Ubuntu – The safest way to backup GPG and SSH keys

I've found the answer on Server Fault: Create a public SSH key from the private key?

The option -y outputs the public key:

ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

As a side note, the comment of the public key is lost. I've had a site which required the comment (Launchpad?), so you need to edit ~/.ssh/id_rsa.pub and append a comment to the first line with a space between the comment and key data. An example public key is shown truncated below.

ssh-rsa AAAA..../VqDjtS5 ubuntu@ubuntu

For keys that were added to the SSH Agent (a program that runs in the background and avoids the need for re-entering the keyfile passphrase over and over again), you can use the ssh-add -L command to list the public keys for keys that were added to the agent (via ssh-add -l). This is useful when the SSH key is stored on a smart card (and access to the private key file is not possible).

I managed to reproduce the problem which you are experiencing. I did so doing the following:

$ gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --gen-key

<specified parameters and let it do its thing>

gpg: key 58018BFE marked as ultimately trusted
public and secret key created and signed.

<snip>

$

Notice that the process marked the key as "ultimately trusted".

Now I export the keys:

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export-secret-keys -a >private.key

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export -a > public.key

Now I import to a new gpg database:

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import public.key

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import private.key

Now if I attempt to encrypt using the new keyrings I get:

$ gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file -r Fake -e
gpg: AE3034E1: There is no assurance this key belongs to the named user

pub  1024R/AE3034E1 2013-06-13 Fake User <fake@example.com>
 Primary key fingerprint: AD4D BAFB 3960 6F9D 47C1  23BE B2E1 67A6 5801 8BFE
      Subkey fingerprint: 58F2 3669 B8BD 1DFC 8B12  096F 5D19 AB91 AE30 34E1

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

The reason for this is the "web of trust" model. By default, in order for a public key to be trusted, it requires either 1 "ultimate" trust certificate (typically where you personally have verified the identities of the people involved), or 3 "marginal" trust certificates (where somebody you know, who knows somebody you know ... has signed the certificate).

Because gpg is a security application, it warns you if you are attempting to encrypt to a key which is not listed as trusted. The reason your own key isn't trusted in this case is simple. It is because you did not export the trust relationships from the previous gpg instance. To do this, use the --export-ownertrust and --import-ownertrust commands.

As always, refer to the man page.