4

If I generate a PGP subkey that only has the authentication capablity and use this to generate an SSH keypair to authenticate Git for example, does this pose a security threat?

When I do, should I use my PGP private key, or the public authentification subkey?

Then when I add my passphrase-proteced private SSH key (./ssh/id_rsa) using te ssh-add command, I am prompted for my passphrase. But then when I make subsequent commits using Git, I am not prompted for my passphase by the SSH Agent. Why is this?

What's the best practice regarding this? Should I keep my keys seperate?

Improve this question
2
  • 1
    I was under the impression that ssh agent caches the decrypted private key in memory so you only have to type in the password the first time.
    – Buge
    Commented Jun 7, 2015 at 2:54
  • That is what prompted my question about the ssh agent. I was asked for my password only the first time I set it up, not every subsequent reboot. Therefore I assumed that the decypted key had to be stored somewhere, thus creating a security risk. But that's a matter of configuration I guess.
    – matthiasdv
    Commented Jun 7, 2015 at 11:26

2 Answers 2

Reset to default
3

As far as I do understand, you want to convert an authentication subkey to an SSH key, and authenticate using this.

If I generate a PGP subkey that only has the authentication capablity and use this to generate an SSH keypair to authenticate Git for example, does this pose a security threat?

Whether this is reasonable or not depends on what you're trying to achieve. The important parts of OpenPGP are its key and trust management features. When you want to use those for authenticating using SSH (monkeysphere makes this possible, but requires some configuration), you completely hand off key management from SSH to OpenPGP, making adding, exchanging and revoking keys much easier. If so; go for authentication subkeys, they offer a real advantage!

If you don't want to use those extended capabilities (or just might use them at any time in future without specific plans), don't do so. You're adding up complexity (which is always a bad thing in information security) without actually having an advantage. For example, you won't be able to use the extended capabilities of monkeysphere with GitHub -- so better directly stick with a good old normal SSH key, you'll have to "revoke" it manually anyway (but removing it from the GitHub account panel).

Generally, reusing secrets will result in more systems/services falling for a single breach in one of them, so generally doing so is a bad idea; but the advantages in key management might be worth the slightly larger risk. If you're not using OpenPGP authentication keys otherwise anyway, there is no further risk in an authentication-only subkey being used for SSH, because there's no other service it could be used for.

When I do, should I use my PGP private key, or the public authentification subkey?

You would have to store your public authentication subkey on the system on which you want to be able to authenticate. Your private key stays private and is used to answer a challenge sent by the authenticating server.

Then when I add my passphrase-proteced private SSH key (./ssh/id_rsa) using te ssh-add command, I am prompted for my passphrase. But then when I make subsequent commits using Git, I am not prompted for my passphase by the SSH Agent. Why is this?

Authenticating using SSH and signing using GnuPG don't have anything in common. I don't quite get your question; you might want to be more specific on what's requesting your password (and where you'd expect it) and how you add the OpenPGP key to the ssh-agent.

Improve this answer
5

The problem is probably not so much algorithmic security. The problem is that if there is a security problem with one of the applications that you also have a security problem the other application. Furthermore, it may be that some kind of attacks on the protocol may be made possible because you share keys. In other words, this is not a good idea with regards to system security.

All in all, you should try to keep the keys separate. Usually one key is used for a particular application. Sharing encryption keys and authentication or signing keys may lead to attacks on the algorithm that would otherwise not be possible.

As for your second question, as long as the SSH session is authenticated the keys are not required any more.

Improve this answer

You must log in to answer this question.

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