Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
Can you point me towards this program, preferably it's source? –  Jeff Burdges Dec 10 '11 at 3:22
3  
@JeffBurdges: web.monkeysphere.info –  bstpierre Dec 10 '11 at 3:29
    
I sent them an email about this thread, maybe they'll epand upon the error message. –  Jeff Burdges Dec 12 '11 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 '11 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 '12 at 7:36

3 Answers 3

up vote 8 down vote accepted

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.

share|improve this answer
    
Thank you for this information, this helped immensely. –  Chris Down Dec 10 '11 at 4:16

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 monkeysphere@lists.riseup.net. 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.

share|improve this answer
    
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 '11 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 at 22:36

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
share|improve this answer
    
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 '11 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 '11 at 12:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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