Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 problem for me:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
I'll push an update shortly.
Installing pam_keyring isn't enough though, it still requires manual edition of /etc/pam.d/gdm to make it work. I was hoping to start some discussions on what needs to happen to make its behavior enabled automatically upon installation, especially since this is on the F-8 wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). Or add a patch to the gdm package and make it require pam_keyring ? Or do we want to make this feature optional from authconfig ?
Another issue is how do we update the keyring password when the user changes his/her password ?
denis
Denis Leroy <denis <at> poolshark.org> writes:
Installing pam_keyring isn't enough though, it still requires manual edition of /etc/pam.d/gdm to make it work. I was hoping to start some discussions on what needs to happen to make its behavior enabled automatically upon installation, especially since this is on the F-8 wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). Or add a patch to the gdm package and make it require pam_keyring ? Or do we want to make this feature optional from authconfig ?
What about /etc/pam.d/kdm and /etc/pam.d/kdm-np? Not every gnome-keyring-using application necessarily always runs inside a GDM session. ;-)
Kevin Kofler
On Fri, 2007-06-15 at 21:31 +0000, Kevin Kofler wrote:
Denis Leroy <denis <at> poolshark.org> writes:
Installing pam_keyring isn't enough though, it still requires manual edition of /etc/pam.d/gdm to make it work. I was hoping to start some discussions on what needs to happen to make its behavior enabled automatically upon installation, especially since this is on the F-8 wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). Or add a patch to the gdm package and make it require pam_keyring ? Or do we want to make this feature optional from authconfig ?
What about /etc/pam.d/kdm and /etc/pam.d/kdm-np? Not every gnome-keyring-using application necessarily always runs inside a GDM session. ;-)
wow proposed mixed desktop relations. How risque.
Probably if we write this into authconfig we should think how this should work. Maybe an advanced option. I have definitely had e-mails from very upset kde people that were very upset that pam_keyring was starting up gnome_keyring_daemon in their session. Just something to keep in mind.
Jon
Jon Nettleton <jon.nettleton <at> gmail.com> writes:
wow proposed mixed desktop relations. How risque.
Probably if we write this into authconfig we should think how this should work. Maybe an advanced option. I have definitely had e-mails from very upset kde people that were very upset that pam_keyring was starting up gnome_keyring_daemon in their session. Just something to keep in mind.
This is indeed a problem, if people don't have anything using gnome_keyring_daemon, they'll hate having it autostarted, if they do have something using it, they'll complain if it doesn't get autostarted. You can't win. :-(
Well, maybe pam_keyring could be taught to just do nothing (not error or anything) if gnome_keyring is not installed and the package not made to require it. It might still get dragged in due to some wacky indirect dependencies and end up autostarted even where not needed that way though.
Or maybe the hack of having the pam_keyring scriptlet change the pam configuration is really the way to go, then users could just install it when needed and leave it off where not needed or wanted, it does sound like a pretty hackish solution to me though.
Kevin Kofler
On Fri, 2007-06-15 at 23:22 +0200, Denis Leroy wrote:
Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 problem for me:
okay this isn't a release, release. It is a pre-release that fixes the F-7 problems.
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
I'll push an update shortly.
Installing pam_keyring isn't enough though, it still requires manual edition of /etc/pam.d/gdm to make it work. I was hoping to start some discussions on what needs to happen to make its behavior enabled automatically upon installation, especially since this is on the F-8 wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). Or add a patch to the gdm package and make it require pam_keyring ? Or do we want to make this feature optional from authconfig ?
I have a mostly functional addition to authconfig for enabling and disabling it. I am wondering if the architecture for this app needs to be extended to make it easy for each pam_package to add an xml file somewhere to add support for it in authconfig.
Another issue is how do we update the keyring password when the user changes his/her password ?
The release above has 95% of the code for support of pam_sm_chauthtok. It has a couple of small bugs that I plan on fixing for full functionality in supporting changing the keyring password in the pam_stack.
This will change partially again in 2.20 when we add support for a on_login keyring in gnome-keyring. I just got wiki write access and will create a page about it this weekend.
Jon
On 6/15/07, Denis Leroy denis@poolshark.org wrote:
Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
It should just work for default desktop installs moving forward. I frankly don't care how.
Or add a patch to the gdm package and make it require pam_keyring ?
uhm should avoid making this a hard requirement for gdm. Can pam deal with a scenario where pam_keyring is referenced as an optional rule in the auth stack but the pam_keyring module is not actually installed? And don't we at least have to also consider this being used in the pam stack for kdm, since kdm can start a gnome desktop session?
Or do we want to make this feature optional from authconfig ?
I'm not sure if this makes much sense. Since the keyring isn't referencing any systemwide or networkwide resources when doing the authing and is inherently a per user thing I'm not sure I see a clear use case where this needs to be configurable (other than spite.)
Another issue is how do we update the keyring password when the user changes his/her password ?
Do you really want to automate this for all users? Some users might want a deliberately separate password.
-jef
On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote:
On 6/15/07, Denis Leroy denis@poolshark.org wrote:
Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
It should just work for default desktop installs moving forward. I frankly don't care how.
Or add a patch to the gdm package and make it require pam_keyring ?
uhm should avoid making this a hard requirement for gdm. Can pam deal with a scenario where pam_keyring is referenced as an optional rule in the auth stack but the pam_keyring module is not actually installed? And don't we at least have to also consider this being used in the pam stack for kdm, since kdm can start a gnome desktop session?
Pam deals with it fine (allows login for nonexistent 'optional' modules), but it will issue a nasty warning in syslog. I think that editing gdm config within a %post script is fine.
On Mon, 2007-06-18 at 18:10 +0200, Tomas Mraz wrote:
On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote:
On 6/15/07, Denis Leroy denis@poolshark.org wrote:
Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
It should just work for default desktop installs moving forward. I frankly don't care how.
Or add a patch to the gdm package and make it require pam_keyring ?
uhm should avoid making this a hard requirement for gdm. Can pam deal with a scenario where pam_keyring is referenced as an optional rule in the auth stack but the pam_keyring module is not actually installed? And don't we at least have to also consider this being used in the pam stack for kdm, since kdm can start a gnome desktop session?
Pam deals with it fine (allows login for nonexistent 'optional' modules), but it will issue a nasty warning in syslog. I think that editing gdm config within a %post script is fine.
Editing pam configs in package scriptlets strikes me as a really bad idea... it's not something that's ever been done and so a lot of people are going to get very surprised by it. Especially if they've customized their configs at all. And doing it once is going to set the precedent for it to be done more...
Jeremy
On Mon, 18 Jun 2007, Jeremy Katz wrote:
Editing pam configs in package scriptlets strikes me as a really bad idea... it's not something that's ever been done and so a lot of people are going to get very surprised by it. Especially if they've customized their configs at all. And doing it once is going to set the precedent for it to be done more...
+1. I always add pam_access to pam configs in my %post of kickstarts and I'd not want that mucked with.
-sv
Jeremy Katz wrote:
On Mon, 2007-06-18 at 18:10 +0200, Tomas Mraz wrote:
On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote:
On 6/15/07, Denis Leroy denis@poolshark.org wrote:
Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ).
It should just work for default desktop installs moving forward. I frankly don't care how.
Or add a patch to the gdm package and make it require pam_keyring ?
uhm should avoid making this a hard requirement for gdm. Can pam deal with a scenario where pam_keyring is referenced as an optional rule in the auth stack but the pam_keyring module is not actually installed? And don't we at least have to also consider this being used in the pam stack for kdm, since kdm can start a gnome desktop session?
Pam deals with it fine (allows login for nonexistent 'optional' modules), but it will issue a nasty warning in syslog. I think that editing gdm config within a %post script is fine.
Editing pam configs in package scriptlets strikes me as a really bad idea... it's not something that's ever been done and so a lot of people are going to get very surprised by it. Especially if they've customized their configs at all. And doing it once is going to set the precedent for it to be done more...
I tend to agree, but what's the alternative ?
Denis Leroy (denis@poolshark.org) said:
Editing pam configs in package scriptlets strikes me as a really bad idea... it's not something that's ever been done and so a lot of people are going to get very surprised by it. Especially if they've customized their configs at all. And doing it once is going to set the precedent for it to be done more...
I tend to agree, but what's the alternative ?
Add support in authconfig, set it up by default but require existing users to run authconfig once?
Bill
On Fri, 15 Jun 2007 23:22:42 +0200 Denis Leroy denis@poolshark.org wrote:
Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 problem for me:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
I'll push an update shortly.
A friend scanning this mailing list asked me to pose a question; is there any thought to being able to manage ssh-agent passphrases within gnome-keyring as well? This would cut down on the number of times a password has to be entered. Are there known challenges to using gnome-keyring for ssh-agent as well?
Hi.
On Tue, 17 Jul 2007 10:23:40 -0400, Jesse Keating wrote:
A friend scanning this mailing list asked me to pose a question; is there any thought to being able to manage ssh-agent passphrases within gnome-keyring as well? This would cut down on the number of times a password has to be entered. Are there known challenges to using gnome-keyring for ssh-agent as well?
That ought to work. SSH just calls a helper process, which has to print the keyphrase to stdout. Where it gets the keyphrase is irrelevant.
The current helpers come from openssh-askpass (which is built from the main ssh package), so we'd have to add gnome-keyring-ssh-askpass there.
To be honest, such a helper has been somewhere on my to-do-list for two years at least :)
Jesse Keating wrote:
On Fri, 15 Jun 2007 23:22:42 +0200 Denis Leroy denis@poolshark.org wrote:
Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 problem for me:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741
I'll push an update shortly.
A friend scanning this mailing list asked me to pose a question; is there any thought to being able to manage ssh-agent passphrases within gnome-keyring as well? This would cut down on the number of times a password has to be entered. Are there known challenges to using gnome-keyring for ssh-agent as well?
Speaking of gpg/ssh integration... I've been asked to enable ssh support in gpg-agent, http://bugzilla.redhat.com/247616 any comment/feedback on how to best make this work?
Haven't done much testing myself yet, but would it be worth exploring the idea of augmenting or possibly replacing ssh-agent?
-- Rex
On 17/07/07, Rex Dieter rdieter@math.unl.edu wrote:
Speaking of gpg/ssh integration... I've been asked to enable ssh support in gpg-agent, http://bugzilla.redhat.com/247616 any comment/feedback on how to best make this work?
Haven't done much testing myself yet, but would it be worth exploring the idea of augmenting or possibly replacing ssh-agent?
I felt someone should also mention Seahorse at this point, which handles both GPG and ssh keys and is well integrated into gnome:
http://www.gnome.org/projects/seahorse/
... so I just did.
J.
Jesse Keating wrote:
A friend scanning this mailing list asked me to pose a question; is there any thought to being able to manage ssh-agent passphrases within gnome-keyring as well? This would cut down on the number of times a password has to be entered. Are there known challenges to using gnome-keyring for ssh-agent as well?
While this isn't quite an answer to the question, it may be useful to the friend that asked...
With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar to what you do to use pam_keyring), you can enter your password once and be done. That is, at the gdm login screen you enter your username and password and your ssh keys get loaded. This requires your login password and the password on your ssh key(s) to match.
On 17/07/07, Todd Zullinger tmz@pobox.com wrote:
With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar to what you do to use pam_keyring), you can enter your password once and be done. That is, at the gdm login screen you enter your username and password and your ssh keys get loaded. This requires your login password and the password on your ssh key(s) to match.
That requirement isn't something that should be encouraged, though, IMO. There's a reason that ssh uses passphrases.
J.
Jonathan Underwood wrote:
On 17/07/07, Todd Zullinger tmz@pobox.com wrote:
With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar to what you do to use pam_keyring), you can enter your password once and be done. That is, at the gdm login screen you enter your username and password and your ssh keys get loaded. This requires your login password and the password on your ssh key(s) to match.
That requirement isn't something that should be encouraged, though, IMO.
Yes, there's a benefit to keeping the passphrases separate. This also affect pam_keyring. Anything that intends to unlock a keyring with one passphrase pretty much requires that the passphrases match.
There is always a tradeoff between security and convenience. Are you suggesting that there not be a way for users to enable their login to unlock their various keyrings? Or are there better tools to make this both convenient and more secure?
There's a reason that ssh uses passphrases.
You say that like we don't all use passphrases for login. ;)
My fault for saying password when I should have said passphrase.
On 17/07/07, Todd Zullinger tmz@pobox.com wrote:
Yes, there's a benefit to keeping the passphrases separate. This also affect pam_keyring. Anything that intends to unlock a keyring with one passphrase pretty much requires that the passphrases match.
You were arguing for the login password/phrase matching the ssh password/phrase - that seems like a bad idea and really unecessary.
Surely, what you mean is that it's required for the login password/phrase to be the same password/phrase as for whatever application stores the various passphrases for ssh/gpg etc.
There is always a tradeoff between security and convenience. Are you suggesting that there not be a way for users to enable their login to unlock their various keyrings?
Nope. But that in no way requires login password/phrase == ssh key password/phrase.
J.
Jonathan Underwood wrote:
You were arguing for the login password/phrase matching the ssh password/phrase - that seems like a bad idea and really unecessary.
It's necessary for using pam_ssh at the moment. It is also needed for pam_keyring. I'm not arguing that this is the best way. I was only passing on this info that may help the Jesse's friend find a workable solution with the current tools.
There is always a tradeoff between security and convenience. Are you suggesting that there not be a way for users to enable their login to unlock their various keyrings?
Nope. But that in no way requires login password/phrase == ssh key password/phrase.
At present for pam_ssh it does. I'm not sure how much of a risk this really is. Say that gnome-keyring gets support for unlocking ssh keys. Then I could have my ssh passphrase stored in gnome-keyring, which would be using the same passphrase as my login. My ssh passphrase is now only as secure as gnome-keying is. How secure is gnome-keying?
I'm not suggesting that gnome-keying is inherently insecure, as I've not looked at it (nor am I really qualified to assess it properly). But I'm not sure that having gnome-keyring -- using the same passphrase as my login -- protecting my ssh passphrase is that much different than using the same passphrase as login for the ssh key. Am I missing something really obvious?
For those that want much stronger security, not using any sort of automated passphrase store and using different passphrases for login, ssh keys, etc. is the only way to go. That's not the target audience for the features an automated pam_keyring would provide, as far as I can tell.
Jesse Keating schrieb:
A friend scanning this mailing list asked me to pose a question; is there any thought to being able to manage ssh-agent passphrases within gnome-keyring as well? This would cut down on the number of times a password has to be entered. Are there known challenges to using gnome-keyring for ssh-agent as well?
Hi Jesse,
we have keychain in Fedora, which exactly does this.
Alexander
On Tue, 17 Jul 2007 21:18:11 +0200 Alexander Dalloz ad+lists@uni-x.org wrote:
Hi Jesse,
we have keychain in Fedora, which exactly does this.
Is that a second UI prompt though for a passphrase? My friend's main concern is that multiple password/phrase prompts from multiple UIs is pretty gross and they should all be the same UI, potentially a single prompt.
Jesse Keating schrieb:
On Tue, 17 Jul 2007 21:18:11 +0200 Alexander Dalloz ad+lists@uni-x.org wrote:
Hi Jesse,
we have keychain in Fedora, which exactly does this.
Is that a second UI prompt though for a passphrase? My friend's main concern is that multiple password/phrase prompts from multiple UIs is pretty gross and they should all be the same UI, potentially a single prompt.
Yes, just the same kind of UI prompts for SSH and GPG keys.
I have several SSH keys I load into ssh-agent at first login and thus get several UI input popups initiated by keychain. As well the keyring request for my wireless WPA key. Can't think of a way a single application would reduce the onetime amount of passphrase requests.
Alexander
On Tue, 17 Jul 2007 21:54:22 +0200 Alexander Dalloz ad+lists@uni-x.org wrote:
Yes, just the same kind of UI prompts for SSH and GPG keys.
I have several SSH keys I load into ssh-agent at first login and thus get several UI input popups initiated by keychain. As well the keyring request for my wireless WPA key. Can't think of a way a single application would reduce the onetime amount of passphrase requests.
Well, theoretically you'd allow gnome-keyring to save all those passphrases and then you'd have a master passphrase (different from the rest) that would allow gnome-keyring to dole them out as needed. But yes, that puts all your eggs in the gnome-keyring basket and relying on the strength of your master keyring. I always make sure my login password/phrase is different than that of my master keyring phrase, and that is different from any of the passphrases in my ring.
On Tue, 2007-07-17 at 16:21 -0400, Jesse Keating wrote:
On Tue, 17 Jul 2007 21:54:22 +0200 Alexander Dalloz ad+lists@uni-x.org wrote:
Yes, just the same kind of UI prompts for SSH and GPG keys.
I have several SSH keys I load into ssh-agent at first login and thus get several UI input popups initiated by keychain. As well the keyring request for my wireless WPA key. Can't think of a way a single application would reduce the onetime amount of passphrase requests.
Well, theoretically you'd allow gnome-keyring to save all those passphrases and then you'd have a master passphrase (different from the rest) that would allow gnome-keyring to dole them out as needed. But yes, that puts all your eggs in the gnome-keyring basket and relying on the strength of your master keyring. I always make sure my login password/phrase is different than that of my master keyring phrase, and that is different from any of the passphrases in my ring.
It is not particularly elegant as such but I made a package based on code from this page that Works for Me... http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases
On 17/07/07, Gawain Lynch lists-gawain@felicity-group.com wrote:
It is not particularly elegant as such but I made a package based on code from this page that Works for Me... http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases
To my very pleasant surprise, the updated seahorse packages that Seth just pushed to updates-testing actually takes care of the integration of gnome-keyring and ssh-agent seemlessly. I encourage all interested parties to try this (it's just a yum install seahorse away).
J.
On Fri, 2007-07-20 at 14:38 +0100, Jonathan Underwood wrote:
On 17/07/07, Gawain Lynch lists-gawain@felicity-group.com wrote:
It is not particularly elegant as such but I made a package based on code from this page that Works for Me... http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases
To my very pleasant surprise, the updated seahorse packages that Seth just pushed to updates-testing actually takes care of the integration of gnome-keyring and ssh-agent seemlessly. I encourage all interested parties to try this (it's just a yum install seahorse away).
Good! I'm glad they're working for you. Are they ready to go to final update?
-sv
On 20/07/07, seth vidal skvidal@linux.duke.edu wrote:
Good! I'm glad they're working for you. Are they ready to go to final update?
Well, I've been using it for a day or so without problems. The only thing I did notice is when clicking on the applet, I see this message at the bottom of the popup box:
Warning: Your system is not configured to cache passphrases in secure memory.
I suspect this is about keys being stored in memory that can be swapped out - I am not sure we have the infrastructure in place to do anything about that yet, though?
J.
Jonathan Underwood (jonathan.underwood@gmail.com) said:
Warning: Your system is not configured to cache passphrases in secure memory.
I suspect this is about keys being stored in memory that can be swapped out - I am not sure we have the infrastructure in place to do anything about that yet, though?
Well, it's just using mlock(). Why is it getting that error, though - is it trying to allocate more than the current default?
Bill
On 20/07/07, Bill Nottingham notting@redhat.com wrote:
Jonathan Underwood (jonathan.underwood@gmail.com) said:
Warning: Your system is not configured to cache passphrases in secure memory.
I suspect this is about keys being stored in memory that can be swapped out - I am not sure we have the infrastructure in place to do anything about that yet, though?
Well, it's just using mlock(). Why is it getting that error, though - is it trying to allocate more than the current default?
Am not sure how I would tell? I am seeing that message even though no PGP keys are cached, only an ssh one is. I am not sure if ssh-agent keeps keys in mlock'ed memory or not.
On 20/07/07, Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 20/07/07, Bill Nottingham notting@redhat.com wrote:
Jonathan Underwood (jonathan.underwood@gmail.com) said:
Warning: Your system is not configured to cache passphrases in secure memory.
I suspect this is about keys being stored in memory that can be swapped out - I am not sure we have the infrastructure in place to do anything about that yet, though?
Well, it's just using mlock(). Why is it getting that error, though - is it trying to allocate more than the current default?
Am not sure how I would tell? I am seeing that message even though no PGP keys are cached, only an ssh one is. I am not sure if ssh-agent keeps keys in mlock'ed memory or not.
Yes, as I suspected looking at /proc/pid/status of the ssh-agent, I see:
VmLck: 0 kB
and so ssh-agent isn't using mlock'd memory, which is probably what seahorse is grumbling about.
[As an aside, I wonder if that constitutes a security hole in ssh-agent].
J.
On Fri, 2007-07-20 at 17:32 +0100, Jonathan Underwood wrote:
On 20/07/07, seth vidal skvidal@linux.duke.edu wrote:
Good! I'm glad they're working for you. Are they ready to go to final update?
Well, I've been using it for a day or so without problems. The only thing I did notice is when clicking on the applet, I see this message at the bottom of the popup box:
Warning: Your system is not configured to cache passphrases in secure memory.
I suspect this is about keys being stored in memory that can be swapped out - I am not sure we have the infrastructure in place to do anything about that yet, though?
yah - that's the same message gpg occasionally barks about.
-sv