[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] keyring integration from a user POV

From: Justin Patrin
Subject: Re: [Monotone-devel] keyring integration from a user POV
Date: Tue, 10 Apr 2007 09:45:37 -0700

On 4/9/07, Benoît Dejean <address@hidden> wrote:
Le lundi 09 avril 2007 à 14:40 -0700, Justin Patrin a écrit :
> On 4/9/07, Benoît Dejean <address@hidden> wrote:

> >
> > > If you do it using ssh-add (which is
> > > a command-line program) then it's going to ask on the command-line.
> >
> > No. Graphical GTK+.
> > ssh-add -l pops up graphical prompt on first use.
> No, ssh-add is not popping up a graphical prompt. gnome-keyring is.
> There's a chain of processes here at work.
> * ssh-add -l is asking for a list of keys from the agent
> * ssh-agent looks for its list of keys

(Do you think i should fill a bug against ssh-agent because it tries to
unlock my keys just to list them ?)

I'm not sure. I would think you'd normally have your keys unlocked
when logged you lock them after a certain amount of time? Any
program that needs to use your keys would likely cause them to unlock.
Don't you have to enter your password when you ssh as well?

> * seahorse-agent notices that you want to look at the key and asks
> gnome-keyring for the password to decrypt it so that it can be added
> to the agent
> * gnome-password asks for your master passphrase to unlock your key
> passphrase (or just asks for your passphrase for the key depending on
> how you have it set up)
> Then back the other way
> * gnome-password passes the passphrase back to seahorse-agent
> * seahorse-agent uses the passphrase to decrypt your key and pass it
> to ssh-agent
> * ssh-agent adds the key to its in-memory keystore and passes the list
> of keys to ssh-add
> * ssh-add lists your keys
> Or something close to that anyway. mtn uses ssh-agent, not
> gnome-keychain or seahorse-agent so it asks for the passphrase itself.

Hum OK. Somthing is really inconsistent here because "ssh-add -l" uses a
graphical prompt where "ssh-add key" doesn't. Or maybe i don't
understand. I have to reread this thread.

It's not inconsistent. It makes perfect sense, in fact. ssh-add -l is
only listing keys so ssh-agent and hence seahorse and gnome-keychain
are the ones loading the keys and causing the prompts. When you
ssh-add key ssh-add is the one loading the key and hence needs your

*The program that adds the key to the keystore is the one that asks
for the password.* When ssh-add does it, you get a command-line
prompt. When seahorse does it you get an X prompt. Note that these are
not the same password prompts either. ssh-add asks for the key
passphrase. Likely when you list keys gnome-keychain is asking for
your master password to unlock the keychain so that seahorse can get
the key password (I'm assuming you've saved your key password in your
gnome-keychain here.)

> >
> > > Are you using seahorse for ssh-agent integration or something else?
> >
> > yes, seahorse-agent. GNOME 2.16 on Debian SID.
> >
> >
> > One thing i don't understand : if i export my key ssh_agent_export, it
> > tries to change the password. Why ?
> We figure that most people are using the get_passphrase hook right
> now. It would be a good idea to change your key passphrase when you
> export it since your passphrase was previously in plaintext on your
> hard drive.

OK. What about adding messages to explain that ? Because it actually
exports the key to ssh format with a new password. But the keystore
key's password is unchanged if i'm right.

mtn address@hidden ssh_agent_export mtn.key
<It would be a good idea to change your key passphrase when you
export it since your passphrase was previously in plaintext on your
hard drive.>

Except that not all users necessarily used this feature.

<Enter a new passphrase for the exported key>.
enter passphrase for key ID address@hidden:
enter new passphrase for key ID address@hidden:
confirm passphrase for key ID address@hidden:

Oh, and it looks like there is a little ~bug. I couldn't find the
exported key. I figured that mtn was changing dir to .. because there it
could found a _MTN dir. I ran "mtn address@hidden
ssh_agent_export mtn.key" in "/tmp/mtn" and the output key was
"/tmp/mtn.key" where i expected "./mtn.key"

stat64("/tmp/mtn/_MTN", 0x7fea8af8)     = -1 ENOENT (No such file or directory)
stat64("/tmp/_MTN", {st_mode=S_IFDIR|0700, st_size=144, ...}) = 0
stat64("/tmp/_MTN", {st_mode=S_IFDIR|0700, st_size=144, ...}) = 0
stat64("/tmp/_MTN", {st_mode=S_IFDIR|0700, st_size=144, ...}) = 0
stat64("/tmp/_MTN", {st_mode=S_IFDIR|0700, st_size=144, ...}) = 0
stat64("/tmp/_MTN/..", {st_mode=S_IFDIR|S_ISVTX|0777,
st_size=1016, ...}) = 0
open("mtn.key", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4

Hmmm....I don't know why that would be happening, the code is thus:
ofstream fout(idx(args,0)().c_str(), ofstream::out);
unless mtn is elsewhere changing the path in the arg to be ../ but I
kind of doubt it... perhaps mtn always changes its dir to the root of
the workspace when in a workspace. I'm not sure about that. Anyone
else care to comment?

I have tried to import my mtn.key in seahorse but the key fails to load
"file:///home/monotone/mtn_benoit Invalid file format"

Sounds like seahorse doesn't support all of the key formats that
ssh-agent/add does. I had to patch SSHKeychain to make it allow
importing of this format.

Justin Patrin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]