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.
Best Answer
Your GPG secret keyring is already encrypted, though it's only as strong as your passphrase (which is true of any encryption).
I'd make a tar file of all the files you want to backup (a few folders/files listed to tar, or with
-T, --files-from
get names to extract or create from FILE) and pipe tar's output to GPG. Basically:But be careful that you don't encrypt your only copy of your secret key with your secret key... i.e. don't lock the key to your safe inside your safe. Conventional (passphrase-only) encryption works too:
This avoids making any extra unencrypted copies of the data, that you'd have to find & wipe (or wipe all free space) if that's a concern. Any programs that use standard output can be piped into gpg too, in case it's not just plain files you're backing up.