Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 134984 - net-misc/keychain: support to use only gpg-agent for GPG and SSH
Summary: net-misc/keychain: support to use only gpg-agent for GPG and SSH
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: Keychain (show other bugs)
Hardware: All Linux
: Low enhancement (vote)
Assignee: Daniel Robbins
URL: https://github.com/funtoo/keychain/is...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-30 21:18 UTC by Timothy Stotts
Modified: 2020-11-29 21:43 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timothy Stotts 2006-05-30 21:18:59 UTC
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
Comment 1 Aron Griffis (RETIRED) gentoo-dev 2006-09-08 14:42:54 UTC
How about a sample patch?

http://sources.gentoo.org/viewcvs.py/keychain/trunk/
Comment 2 Timothy Stotts 2006-09-08 17:20:43 UTC
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.
Comment 3 Aron Griffis (RETIRED) gentoo-dev 2006-09-10 20:59:23 UTC
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.
Comment 4 Timothy Stotts 2006-09-10 22:21:52 UTC
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.
Comment 5 Aron Griffis (RETIRED) gentoo-dev 2006-09-13 06:16:36 UTC
(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.
Comment 6 Nick Brown 2007-07-12 11:43:29 UTC
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
Comment 7 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-08-07 00:46:59 UTC
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 ;)
Comment 8 Daniel Robbins 2009-08-12 18:13:44 UTC
I can look into this for future versions of keychain. Please keep this bug open.
Comment 9 Jonas Stein gentoo-dev 2020-11-29 21:43:57 UTC
moved this ticket to upstream