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

[Justin Patrin]

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 in....do 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
password.

*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
> chdir("/tmp")
> ...
> 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
> 0x7f7f7f7flacenet.org.key: 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