It would be really nice for keychain to have the option to use only gpg-agent for both GPG and SSH functionality. -------------------------------------------------------------------- From 'info gnupg' of app-crypt/gnupg-1.9.20-r3, "3.2 Option Summary" -------------------------------------------------------------------- `--enable-ssh-support' Enable emulation of the OpenSSH Agent protocol. In this mode of operation, the agent does not only implement the gpg-agent protocol, but also the agent protocol used by OpenSSH (through a seperate socket). Consequently, it should possible to use the gpg-agent as a drop-in replacement for the well known ssh-agent. SSH Keys, which are to be used through the agent, need to be added to the gpg-agent initially through the ssh-add utility. When a key is added, ssh-add will ask for the password of the provided key file and send the unprotected key material to the agent; this causes the gpg-agent to ask for a passphrase, which is to be used for encrypting the newly received key and storing it in a gpg-agent specific directory. Once, a key has been added to the gpg-agent this way, the gpg-agent will be ready to use the key. Note: in case the gpg-agent receives a signature request, the user might need to be prompted for a passphrase, which is necessary for decrypting the stored key. Since the ssh-agent protocol does not contain a mechanism for telling the agent on which display/terminal it is running, gpg-agent's ssh-support will use the TTY or X display where gpg-agent has been started. To switch this display to the current one, the follwing command may be used: echo UPDATESTARTUPTTY | gpg-connect-agent
How about a sample patch? http://sources.gentoo.org/viewcvs.py/keychain/trunk/
Sure, but it will be a few weeks until I get to it. If you like the idea to support this feature, I'll write a working patch within a month.
I think it sounds interesting, but I don't know what the advantage is to using gpg-agent over ssh-agent. I'd be interested in adding the support to keychain if there's a reason.
Personally, I think it is a nice idea in case any system admins want to use keychain on a system with a large number of users, such as a mainframe, or one of those large N-way Solaris boxes. Reducing from 2 processes per user down to 1 per user is appealing, especially when considering systems with number of procs. limited per user. I'll grant that the real-world likelihood of some admin using keychain in this manner is low. But you never know. I also may like to use keychain on a system for which I only have ~50 allowed processes, in which case, every process counts. Also, my understanding is that both gpg-agent and ssh-agent may be run setuid if the sysadmin wants to enable secure in-memory locking of the passphrase/private key data. And why not reduce from 2 setuid binaries to 1 setuid binary? Or if ssh-agent does not support setuid (not sure), then the user may use gpg-agent which does support setuid. A non-essential feature, but seems like a nice idea if implementation is not too complex.
(In reply to comment #4) > Personally, I think it is a nice idea in case any system admins want to use > keychain on a system with a large number of users, such as a mainframe, or one > of those large N-way Solaris boxes. Reducing from 2 processes per user down to > 1 per user is appealing, especially when considering systems with number of > procs. limited per user. > > I'll grant that the real-world likelihood of some admin using keychain in this > manner is low. Very low IMHO. :-) > But you never know. I also may like to use keychain on a > system for which I only have ~50 allowed processes, in which case, every > process counts. > > Also, my understanding is that both gpg-agent and ssh-agent may be run setuid > if the sysadmin wants to enable secure in-memory locking of the > passphrase/private key data. And why not reduce from 2 setuid binaries to 1 > setuid binary? Or if ssh-agent does not support setuid (not sure), then the > user may use gpg-agent which does support setuid. Recent Linux kernels don't require setuid for secure memory, so this reason no longer exists. > A non-essential feature, but seems like a nice idea if implementation is not > too complex. The best reason I've come up with is reducing the amount of running agent code. Since each agent presents a potential attack vector, reducing to a single agent removes one of the attack vectors entirely. That makes this implementation seem like a good idea.
Integration of seahorse (the gnome ssh/gpg keymanagement front end) would also be nice. It provides support for both ssh and gpg. http://live.gnome.org/Seahorse http://live.gnome.org/Seahorse/SessionIntegration I raised a bug with my distro to allow seahorse agent to work, but requires disabling other agents, or making keychain aware of it. http://qa.mandriva.com/show_bug.cgi?id=31482
Length of time has probably expired on this bug. Let's leave it for a feature request, unless the idea is deemed totally crazy by upstream ;)
I can look into this for future versions of keychain. Please keep this bug open.
moved this ticket to upstream
