1 |
On Monday 12 February 2007 23:26, Justin Patrin wrote: |
2 |
> On 11/21/06, Jorge Almeida <jalmeida@××××××××××××.pt> wrote: |
3 |
> > On Tue, 21 Nov 2006, Mick wrote: |
4 |
> > >>> They are only stored in locked memory; they are never on disk |
5 |
> > >>> unencrypted. Anyone that can read locked memory can access them, but |
6 |
> > >>> this is very few users/processes on Linux -- and besides those same |
7 |
> > >>> users will be able to read the key as you authenticate even if you |
8 |
> > >>> don't use ssh-agent, as long as they time things right. |
9 |
> > >> |
10 |
> > >> OK, this sounds better! I posted to the gnupg-users, asking a similar |
11 |
> > >> question about gpg-agent. I guess gpg-agent works the same way. |
12 |
> > > |
13 |
> > > Please post back your findings! |
14 |
> > |
15 |
> > Well, no responses yet in the gnupg-users list, so there are no findings |
16 |
> > to post! (Let's wait at least a few hours :)) |
17 |
> > |
18 |
> > > What happens to the /tmp/ directory & socket file after the user logs |
19 |
> > > out? Does it get deleted by the ssh-agent shutdown script? |
20 |
> > |
21 |
> > I didn't start using ssh-agent yet, but I tested it from the command |
22 |
> > line and the directory was removed when I killed the ssh-agent process. |
23 |
> > |
24 |
> > > I am asking this because I seem to continuously accumulate a load of |
25 |
> > > gpg-agent directories and socket files into my /tmp. Unless of course |
26 |
> > > gpg-agent works |
27 |
> > |
28 |
> > I suppose that has to do with the agent(s) working as daemons? I don't |
29 |
> > like that kind of setup. This is what I intend to (try to) do: |
30 |
> > |
31 |
> > - One fixed socket, in some dedicated directory (no /tmp, no random name |
32 |
> > for the socket) |
33 |
> > - The socket name as a fixed env variable, set in the shell config files |
34 |
> > - Hence, no need to eval, etc |
35 |
> > - No daemon (i.e. no backgrounding). Just a service supervised by |
36 |
> > daemontools. Logs go to a directory of my choosing and if the agent |
37 |
> > dies, it is ressurrected, and the socket (with the same name) is |
38 |
> > recreated (of course, keys must be added, then) |
39 |
> > - A perl script to interact with the service, just in case. |
40 |
> > |
41 |
> > I think this is not difficult to do, unless I grossly misunderstood |
42 |
> > something essential. (Comments, anyone?) I just don't see the need to |
43 |
> > run the agent as subordinate of an X session or whatever (please someone |
44 |
> > correct me if I'm wrong!) And if I don't want the service running when |
45 |
> > I'm not logged in, I could bring it down with the perl script (in |
46 |
> > ~/.bash_logout, maybe?) |
47 |
> > For gpg-agent, I'm not so sure, but I hope it can be done too. |
48 |
> > |
49 |
> > > on a different principle all together. My start up & shutdown scripts |
50 |
> > > are in /etc/X11/Sessions/fluxbox. Are they correct for this task? |
51 |
> > > ================================================ |
52 |
> > > eval "$(gpg-agent --daemon)" |
53 |
> > > /usr/bin/startfluxbox |
54 |
> > > kill `echo ${GPG_AGENT_INFO} | cut -d ':' -f 2` |
55 |
> > > ================================================ |
56 |
> > > |
57 |
> > > Or should I have another line to 'rm -Rf /tmp/gpg-*' |
58 |
> |
59 |
> ssh-agent /bin/sh |
60 |
> |
61 |
> When you exit the shell, ssh-agent exits too (after cleaning up). |
62 |
> Running the agent as a daemon means you have to tell it when to shut |
63 |
> down as well (how would it know when to stop?). |
64 |
|
65 |
Thanks Justin, the ssh-agent may clean up after its own lock-files, but the |
66 |
gpg-agent doesn't. At least not when using my script above. My /tmp is full |
67 |
of gpg-xxxx lock-files, which in the absence of a better solution I manually |
68 |
delete every now and then. |
69 |
-- |
70 |
Regards, |
71 |
Mick |