8

I wish to covert my PGP key (RSA) to be used performing SSH authentication. After some searching, I found openpgp2ssh, which appears to be an appropriate tool. Everything works swimmingly for my pubkey:

$ gpg --export "$key" | openpgp2ssh "$key"
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC51Cw3ZxO5TSncaDLzQ89SSZAF7Z9cFR5mv4uhmGw3tDfiaAjNFVjp90YNYi2teveb5EjncIK5RMYQefKpvvsawQZ4KJKbrDFrrQbMmIG67A1qopKxn5rF8QsjzYvrlGSi9pnjfZVN+VfTaspomVpwCpe9oxd8ZlKdViABgBV8p0hL6I4Gqm+I37az9apO4wCvlN8XJMia3J1JxIShyLYGfa2ued5rRFYiCEV3/smtrjycEZ8OYLTLhC/vydhXCSYrCxWHxhv213Uho641cttaL2SlPGDX9Uuq3JfjCoC0Y6EN7/+GV2u9R48/QJpUaOjEhLRm8F/LFRuHDFYJmyNgv11DsRAMvh7psGY2196bBYSdrzfZxxCQDdJrNxNzQvIG33JavMXOiBAbAYxaq7DWWlVPcE3fy+VxYPH+XicqxD58qdWapspJhRxEKzQa7IfUULGQHVg31NYWGsN4dkva2XjV35SZf6M3nrfjz4XitiwH0SOxbXBRKUdZhwCnr+5GcsWkax7Ph6QGvWVP6mgpUDBuMQ+znkUVr8tDkmrm5M6PC6x8SOA0ecdjNKB2NK23A6w4V7lsfMvDl4uBMzxRzXOXLIUXunsZ7MQTV5ymtZvk3oYccnXNxtVZGF2Cu9Wfy+6c+XL+z4Zfc6XvPSgtBDOApV3owL86OOoLO5X3HQ==

However, when I try to convert my private key for use, it displays the following error:

$ gpg --export-secret-key "$key" | openpgp2ssh "$key"
We cannot handle encrypted secret keys.  Skipping!

My secret key is indeed encrypted. I'd ideally like a method to convert my PGP secret key into data that standard SSH programs can understand, instead of relying on nonstandard plugins. Is this possible?

Improve this question
8
  • Can you point me towards this program, preferably it's source?
    – Jeff Burdges
    Dec 10, 2011 at 3:22
  • 3
    @JeffBurdges: web.monkeysphere.info
    – bstpierre
    Dec 10, 2011 at 3:29
  • I sent them an email about this thread, maybe they'll epand upon the error message.
    – Jeff Burdges
    Dec 12, 2011 at 7:28
  • 1
    @tylerl - How is it like that? Both the PGP secret and the SSH secret are only going to be deployed in trusted environments (usually the same ones). It makes it no easier by itself to decrypt the private key of either. It doesn't become a single point of weakness since they are encrypted with different passphrases and different encryption methods.
    – Chris Down
    Dec 15, 2011 at 7:57
  • 1
    @tylerl The point of this is that monkeysphere uses the PGP Web Of Trust, such that a server admin can theoretically grant you SSH access via your OpenPGP public key without having to exchange a SSH key first (probably in a OpenPGP encrypted message anyway...)
    – Tobias Kienzler
    Nov 9, 2012 at 7:36

3 Answers 3

Reset to default
8

I'm one of the upstream authors of openpgp2ssh. Sorry for the confusion. You'll note that the openpgp2ssh(1) man page has a "BUGS" section that says:

 openpgp2ssh currently cannot handle passphrase-protected secret keys on
 input.

If you can propose a clearer one-line error message, or an improvement to the man page so that you could have found your answer in the documentation easier, we'd be happy to improve the tool. Drop us a line at [email protected]. I don't think any of the current devs follow stackexchange closely at the moment, so the mailing list is a better way to get in touch.

Improve this answer
2
  • My issue wasn't with the bug itself, it was how best to work around it. Isn't it possible to get the user to give the password, decrypt the key, convert it, and then reencrypt with the same details? Maybe I only see that as possible because of my naivety in areas of cryptography?
    – Chris Down
    Dec 15, 2011 at 7:34
  • In GnuPG 2.1 and recent version of openSSH there is support for ED25519. Is possible to do the same for this kind of keys?
    – Rnhmjoj
    Nov 19, 2014 at 22:36
10

There would be no point in converting a public key if nobody can convert the private key too, meaning this program was created with such a conversion process in mind. You'll notice the error message reads "We cannot handle encrypted secret keys."

I therefore recommend you remove the private key's password using the passwd command in gpg --edit-key. You should obviously reencrypt both the old gpg private key and the new ssh private key after conversion.

If you're worried about unencrypted key remaining on the drive, then create either an encrypted partition using encfs, truecrypt, etc., or else create a ramdisk. You should keep the ramdisk small and short lived to prevent the kernel from swapping it, well unless you find some trick for calling mlock. Any cryptographic file systems should already mlock their data pages.

Improve this answer
0
7

Jeff Burdges' great answer showed me the eventual method. Here are the exact steps I took:

key=2A7D4D74

# Back up the original key so you can reimport it afterwards
gpg --export-secret-key "$key" > id_rsa.bak

# Now remove the encryption using the method listed in Jeff Burdges' answer:
# * gpg --edit-key "$key"
# * Issue passwd and remove the password
# * Quit, and save changes

# We convert the keys
gpg --export "$key" | openpgp2ssh "$key" > ~/.ssh/id_rsa.pub
gpg --export-secret-key "$key" | openpgp2ssh "$key" > ~/.ssh/id_rsa

# Then, we change the password for the SSH secret key
ssh-keygen -f ~/.ssh/id_rsa -p

# Now reimport the original key (deletion is required or for some reason it fails to reimport as encrypted)
gpg --delete-secret-key "$key"
gpg --import < id_rsa.bak
rm id_rsa.bak
Improve this answer
2
  • In theory, your private key has been written onto your hard drive gpg --edit-key "$key" and .. | openpgp2ssh "$key" > ~/.ssh/id_rsa, maybe those sectors were overwritten later, but maybe not. You should ideally have created the intermediate unencrypted keys in either a ramdisk or an encrypted partition. I'd expect ordinary activity like locatedb, syslog, browser cache, etc. should whip them out soonish, just say'n.
    – Jeff Burdges
    Dec 10, 2011 at 7:08
  • @JeffBurdges A good point, but this was all done in T(A)ILS, so there is no risk of that.
    – Chris Down
    Dec 10, 2011 at 12:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .