On Tue, 2009-04-14 at 14:24 +0400, Dmitry Morozovsky wrote: > On Tue, 14 Apr 2009, Michal Varga wrote: > > MV> On Tue, Apr 14, 2009 at 3:13 AM, Dmitry Morozovsky <ma...@rinet.ru> wrote: > MV> > Dear Joe Marcus, > MV> > > MV> > DM> JMC> What versions of gnome-keyring and seahorse do you have? > MV> > DM> > MV> > DM> ma...@revamp:/usr/ports> pkg_info | egrep 'gnome-keyring|seahorse' > MV> > DM> gnome-keyring-2.26.0 A program that keeps passwords and other > secrets > MV> > DM> seahorse-2.26.0 GNOME application for managing encryption keys > (PGP, SSH) > MV> > > MV> > After > MV> > > MV> > portupgrade -f seahorse gnome-keyring > MV> > > MV> > and reboot > MV> > > MV> > still the same effect... > MV> > > MV> > Of course, I can wipe packages installed and set it up from scratch, > but I > MV> > would prefer a bit safer way if at all possible ;-) > MV> > > MV> Well, I have no idea what a "Terminal remote login" in this particular > MV> context is, so this may not be of any help, but I've seen this issue > MV> before: > MV> > MV> "Before the upgrade, I had once pop-up asking for my key passphrase, then > MV> let me use this private key during my (home) session without further > asking.. > MV> Now, when I try to connect to the host which even possibly want to check > MV> whether I want to present some key there, I got the pop-up. I even > checked that > MV> I can connect to the host in question using plain xterm, and have usual > MV> password qiery." > MV> > MV> I've been in similiar situation some time ago, when new > MV> gnome-keyring/seahorse (it started with one of the recent versions, > MV> don't remember exactly when, but definitely before 2.26 was > MV> introduced) for some surely interesting reason insisted on creating a > MV> very own keyring every other reboot - while originally you were using > MV> one default keyring (let's call it "default") for storing your > MV> passwords, now gnome-keyring kept creating a new one named "login" and > MV> always set it as the default one. > MV> > MV> That "login" keyring was even more special in that that nothing stored > MV> in it ever worked, it still kept asking for passwords and even then > MV> was not able to use them (and lost them on the next reboot anyway.. > MV> Maybe that's a feature, don't know, don't care). I've run into this on > MV> a few different machines, every time I needed to open 'seahorse', get > MV> to Passwords tab, delete the "login" keyring, set the original > MV> "default" as the default keyring (first time I wiped them all and > MV> created a clean one to be sure, but as it turned out later, this > MV> wasn't needed), after that, passwords worked fine again. This > MV> procedure again and again for a few days/reboots, until seahorse > MV> miraculously stopped this madness and let my default keyring be, well, > MV> default (yes, just like that). > MV> > MV> Anyway, if you weren't there yet, check seahorse gui for what keyring > MV> are you really using, maybe you've hit the same issue with the "login" > MV> stupidity.. > > Yes, seahorse shows me two keyrings; however, deleting "login" one does not > fix > the situation: if in the Terminal I try to open tab which ssh's to outer > host, > I immediately got the popup with > > "There was an error creating the child process for this terminal" > > nothing in this tab is started, and tab is just hanging. > > "login" keyring sometimes got recreated, sometimes not, but the effect above > is > totally reproducible.
If I am following this correctly, the functionality you are talking about is actually provided by seahorse-agent, which is installed with the seahorse-plugins port now. Unless something has changed with the default session (and I don't think it has, since my keyrings still work) we wrap the session with ssh-agent and seahorse-agent if they are found. robert. -- Robert Noland <rnol...@freebsd.org> FreeBSD
signature.asc
Description: This is a digitally signed message part
