Authenticating SSH and GPG keys from another user on same machine

Question

I'm curious if this is possible or even recommended.

Let's say that I want to prevent people from being able to steal my SSH or GPG keys if they manage to compromise my user account (Let's call the account user). So, I want the private portion of the keys on another account that I don't have any permissions to (let's call the account user-keys). So, if I want to be able to do any sort of SSH or GPG authentication, I need to send that request to the user-keys account, it does the auth work, then sends back the result to my user account.

Is this possible to do? If so, how? Also, is this recommended, or is there another better way to protect the keys asides from the obvious be careful with downloading and running software from the internet?

Answer 1

You would be more or less looking for ssh-agent and similar tools. They hold the signing keys in memory (usually locked so that even debugging tools could not access them) and only dispense signatures on request.

• ssh-agent isn't exactly built to be shared between accounts, but ssh itself does have an "agent forwarding" mode – so you can start the agent as user 1, then run ssh -A user2@localhost, and now processes running as user 2 can connect to the agent and ask it to sign an authentication challenge. (Note they must know the $SSH_AUTH_SOCK value created by 'ssh -A'.)

  This works because there is no command in ssh-agent's protocol to export a private key. You can add a private key to the agent; you can make it sign things; you can list public keys; and that's it.

  Alternatively, you can run the agent under your main account and hold the actual private keys somewhere remote – then you connect using ssh -A, add keys, and disconnect. This of course requires you to trust the OS-provided lockdown features that ssh-agent uses (e.g. being unable to attach gdb).

• gpg-agent is a bit more complex to forward over SSH, but it still has the same general idea. It is already required by GnuPG, but it provides two different sockets for apps to connect to; S.gpg-agent gives full access (including key export), whereas S.gpg-agent.extra only gives access to the basic sign/decrypt functions similar to ssh-agent.

  Note that gpg-agent differs from ssh-agent in that the former has persistent key storage (as files under ~/.gnupg/), so the "alternative" method won't work. It also insists on launching its own password dialog popups (the pinentry), which again might cause difficulties when trying to SSH-forward.

  So if your distro supports it, I would actually look into "mandatory access control" modules such as AppArmor or SELinux, which can be used to deny all access to ~/.gnupg/ even from the same UID except by the agent process.