Recently fixed bugs.
clusterssh is a package that allows you to control multiple ssh xterm sessions at the same time.
When the monkeysphere-ssh-proxycommand is enabled and I launch 5 or more cssh sessions, intermittently one or two out of every five will fail with: Connection timed out during banner exchange.
I tried to debug by running:
MONKEYSPHERE_LOG_LEVEL=debug cssh -D -d <server1> <server2> etc.
However, while it produced some private data, it didn't give me any insight into what was going wrong. Also, it didn't output any Monkeysphere debugging info.
I had no luck with google and the error message being output.
This isn't a huge priority (it's not hard to disable the monkeysphere-ssh-proxycommand before running cssh), however, it would be nice to figure out why it's not working.
What do you mean by "produced some private data" when you set the log level to DEBUG? Monkeysphere does not output any "private" data in the sense of private keys or passwords or anything like that. Maybe you mean the cssh debug mode outputs private data? or do you just mean "info that you don't want to post here"? It might be useful to see some output, so maybe you could just block out the nasty bits? But I'm not sure it will help.
The problem may be due to the locking of the known_hosts file while the proxycommand is running. At the moment, the monkeysphere-ssh-proxycommand can only be run serially, since each invocation will lock the known_hosts file while it updates it. I think this is required, since we obviously can't have two invocations modifying the file at the same time. However, it's probably possible to decrease the amount of time it takes to update the file. It's not done very efficiently at the moment. The file is locked basically at the very begining, and is locked while all gpg interactions are done, which are slow. I think it should be possible to take the gpg interactions out of the loop.
I just tried cssh and it doesn't seem to work very well with my ssh setup at all. For instance, the simultaneous ssh connections cause simultaneous calls to the agent to get my permission to use the key, which don't interact very well with each other. This of course is not a monkeysphere problem but a general problem with trying to make simultaneous ssh connections with an agent that want key use confirmation.
-- jrollins
I can get cssh to work fine with a confirmation-required agent if i turn off the monkeysphere proxycommand:
cssh -l username -o '-oProxyCommand=none' $(cat hostlist.txt)
with the proxycommand, i definitely get the "Connection timed out during banner exchange" message.
However, i'm also able to get the cssh connection to work if i assert that a longer connection timeout is acceptable:
cssh -l username -o '-oConnectTimeout=30' $(cat hostlist.txt)
Perhaps this is an acceptable workaround?
-- dkg
Sorry for not being more clear. Monkeysphere debug does not reveal personal information - but cluster cssh -d -D exposes the hosts in my ssh config file.
dkg's approach seems to work. His suggestion, as written, didn't work for me. But that's because I ran cssh -u > $HOME/.csshrc, which generates a default cssh config file (that specifies ConnectTimeout=10). That file seems to override the command linke (perhaps a cssh bug?). I changed the ConnectTimeout to 30 in my ~/.csshrc file and now everything works.
I think jrollins' assessment is probably right - the extra delay due to locking causes the timeout. I think tweaking ConnectTimeout parameter via the .csshrc file or via the command line is a reasonable fix for this bug, so I'm closing as done.
-- Sir Jam Jam
I just posted the cssh bug in debian.
I know it's a hack - but installing seckey2sshagent in /usr/bin/ would make it much easier for people to use.
I'm not sure I really want to include this hack with the debs. It's really not useful for any kind of regular use. I would rather focus on getting openpgp2ssh to support passprotected keys.
As another possibility, I was planning on modifying the script so that it could export to a passprotected file. I think this would be a lot more useful. Let me get that working, then let's revist the issue of including it in the packaging.
-- Big Jimmy
Ok - sounds good to me. I'm thinking in terms of getting other people to try out the Monkeysphere - maybe the README should just say: we're only half done. You can verify the identity of servers, but we haven't completed the part about verifying you to a server. Then it could say: if you're really interested, you can run this hacky script but we make no guarantees.
-- Sir Jam Jam
I just realized that i think i can test for the presence of GNU-dummy
support in
GnuTLS,
which means that we can cleanly test whether the proposed handling of
passphrase-locked secret
keys is functional. With
that in mind, I'd like to propose that we could resolve this bug
simply by adding a new subcommand: monkeysphere subkey-to-ssh-agent,
which would fail in the absence of a functionally-patched GnuTLS.
Would this proposal be sufficient to resolve this bug?
--dkg
Version 0.11-1 now has the monkeysphere subkey-to-ssh-agent
subcommand, which works cleanly in the presence of a
functionally-patched GnuTLS.
--dkg
I'm marking this bug as done - I no longer think we should install seckey2sshagent in bin now that we have a clean way of accomplishing that task. Nice work dkg!
--sjj
Right now, monkeysphere-server list-identity-certifiers runs as the
superuser, and just lists the keys in the host's keyring. This might
not be the actual list of valid id certifiers, for a number of reasons:
the keys themselves might have been revoked by the owner
the id-certifiers might have been added with a different trust level, or a regexp/domain limitation.
It would make more sense to derive the list of trusted certifiers
directly from the keyrings as seen by the non-privileged
monkeysphere user, since this user's keyrings are what are going to
judge the validity of various user IDs.
done 2008-08-16 in a29b35e69d0fab5f2de42ed5edd9512a6552e75a
Do we want to allow the system administrator to make adjustments to
the gpg.conf config files found in /var/lib/monkeysphere? At the
moment, there are two such files:
/var/lib/monkeysphere/gnupg-authentication/gpg.conf/var/lib/monkeysphere/gnupg-host/gpg.conf
In the debian postinst scripts (debian/monkeysphere.postinst), the
contents of those files are overwritten on every upgrade/reinstall,
effectively clobbering any changes made by the local admin.
Maybe we do want to do this clobbering, though. Stuff in /var is
generally not expected to be modified by hand. I see two possible
resolutions to this:
when we clobber those files, include a comment along the lines of:
do not make changes to this file! It is overwritten on each upgrade!
Avoid clobbering the files, and treat them as config files.
the latter approach suggests that they should be more properly stored
in /etc/, though. This would give us all the conf-file tracking
apparatus, which is nice. If we do want to do that, I guess we'd
symlink to them from the monkeysphere-specific $GNUPGHOMEs in
/var/lib/monkeysphere, since gpg does not seem to allow for
overriding the location of the gpg.conf independent of $GNUPGHOME.
All the gpg.conf files now reside in /etc/monkeysphere, and are linked in into the GNUPGHOMEs in /var/lib/monkeysphere.
done on 2008-10-11
Some monkeysphere-enabled hosts answer to multiple host names, but the
current monkeysphere-server only generates a single User ID
corresponding to a single hostname.
We should make it easier for machines with multiple names to create
multiple User IDs at gen-key time.
We should also make it easy to add new hostnames (and remove outdated ones).
For example: george.riseup.net is now also known as
monkeysphere.info. It'd be nice to have a convenient way to add
that hostname to the key without mucking around with gpg directly.
So how do we imagine the behavior here? I assume that basically it would just add/remove user ID's to/from the host key locally. I guess we will continue to rely on the "publish-key" subcommand to actually publish all changes to the keys.
-- BJ (jgr)
I think when we reorganize the monkeysphere-server
shortcuts it'll make it
clearer what the right interface should be.
As for what should actually happen, i think that the server should actively revoke old User IDs, rather than removing them. It should probably prompt the administrator to re-publish the host key as well, to ensure that the new User IDs are published.
--dkg
done on 2008-08-15 15:00:02-0400 in 84b775ff0b36ec4b86e6708844ad2d678eced403
Consider the following transcript of a user who starts with no OpenPGP key in the first place:
0 wt215@squeak:~$ monkeysphere gen-subkey
You have no secret key available. You should create an OpenPGP
key before joining the monkeysphere. You can do this with:
gpg --gen-key
255 wt215@squeak:~$ gpg --gen-key
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection? 5
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1
Key expires at Sat 09 Aug 2008 09:41:34 AM EDT
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: Foo T. Bar
Email address: monkey@example.org
Comment: DO NOT USE!
You selected this USER-ID:
"Foo T. Bar (DO NOT USE!) <monkey@example.org>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++
gpg: key A09F70B7 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2008-08-09
pub 1024R/A09F70B7 2008-08-08 [expires: 2008-08-09]
Key fingerprint = C3D3 1063 7CA1 5809 9EB9 7A63 F4E4 8D01 A09F 70B7
uid Foo T. Bar (DO NOT USE!) <monkey@example.org>
Note that this key cannot be used for encryption. You may want to use
the command "--edit-key" to generate a subkey for this purpose.
0 wt215@squeak:~$ monkeysphere gen-subkey
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 2
ms: generating subkey...
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 1024R/A09F70B7 created: 2008-08-08 expires: 2008-08-09 usage: SC
trust: ultimate validity: ultimate
[ultimate] (1). Foo T. Bar (DO NOT USE!) <monkey@example.org>
Key is protected.
You need a passphrase to unlock the secret key for
user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>"
1024-bit RSA key, ID A09F70B7, created 2008-08-08
gpg: Invalid passphrase; please try again ...
You need a passphrase to unlock the secret key for
user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>"
1024-bit RSA key, ID A09F70B7, created 2008-08-08
gpg: Invalid passphrase; please try again ...
You need a passphrase to unlock the secret key for
user: "Foo T. Bar (DO NOT USE!) <monkey@example.org>"
1024-bit RSA key, ID A09F70B7, created 2008-08-08
gpg: Key generation failed: bad passphrase
Invalid command (try "help")
ms: done.
0 wt215@squeak:~$
This user does not have use-agent configured in ~/.gnupg/gpg.conf.
This problem can be resolved by the user doing:
echo use-agent >> ~/.gnupg/gpg.conf
gpg-agent --daemon monkeysphere --gen-subkey
Then they will be prompted for their passphrase during key creation.
If we're OK with relying on gpg-agent, we should make make that an
explicit dependency, and ensure that an agent is running (or start one
up specifically for the process).
If we're not OK with relying on the agent, --gen-subkey needs
fixing.
I think requiring the agent and using it for getting the passphrase is fine. That should make this bug fairly easy to fix, so I'll get on it.
-- BJ (jgr)
Alternately, we could use --passwd-fd and ssh-agent, along the
lines i proposed for handling passphrase-locked secret
keys.
done as of 2008-08-15 16:48:26-0400 (to be released in 0.8-1)
I opted to go with the ssh-askpass route, and fall back to echoing
stuff to a fifo directly if ssh-askpass is not available.
Currently, if you try to run monkeysphere-server publish-key, you
can get the following output:
Really publish key to subkeys.pgp.net? (y/N) y
NOT PUBLISHED (to avoid permanent publication errors during monkeysphere development).
The following command should publish the key:
monkeysphere-server gpg-authentication-cmd '--keyserver subkeys.pgp.net --send-keys foo.example.org'
I think we've demonstrated that this system works enough to warrant using the public keyserver infrastructure.
I suggest that we should actually enable this feature explicitly.
(leaving in the prompt is fine, though it would be nice to be able to
--force it or something).
done 2008-08-15 in 6fb350a883fa4d8b1bc9b5e01cc3b01c96354d08
Currently, monkeysphere-server supports three subcommands to adjust
the "identity certifiers":
add-identity-certifier(a)remove-identity-certifier(r)list-identity-certifier(l)
Since we also want to be able to add/remove multiple
hostnames, i think we should change the shortcuts
from a, r, and l to c+, c-, and c.
This would let us create new subcommands like:
add-host-name(n+)revoke-host-name(n-)list-host-names(n)
done 2008-08-14 in 0181b6fc50824941e4f7ac3f535a216b8189568e
I'm in the process of writing a testsuite for the monkeysphere so that we can verify that it actually performs all the basic expected duties properly.
It occurs to me that lines like these:
ETC="/etc/monkeysphere"
VARLIB="/var/lib/monkeysphere"
Actually make it very difficult to generically test the tool without it being installed system-wide.
Is there any reason that we should not allow these directories to be
overridden with environment variables in the same way that
/usr/share/monkeysphere/share is handled?
SHARE=${MONKEYSPHERE_SHARE:-"/usr/share/monkeysphere"}
I guess i'm proposing something like:
SYSCONFIGDIR=${MONKEYSPHERE_SYSCONFIGDIR:-"/etc/monkeysphere"}
SYSDATADIR=${MONKEYSPHERE_SYSDATADIR:-"/var/lib/monkeysphere"}
Thoughts?
--dkg
done on 2008-10-11
It would be really useful for people trying out the monkeysphere to be able to test it with a participating server as soon as they've finished setting things up. Minimally - just testing the acceptance of the server's identity would be great.
I guess we don't really want to use george for this purpose? Does someone have a spare virtual machine that we could use for this purpose? The test machine wouldn't actually have to do any user authentication, I guess.
-- Big Jimmy.
Maybe we should use George? As you point out - it doesn't actually have to do any user authentication. It seems like a waste to have a virtual machine that does nothing but deny people's ssh connections. And - george is already setup and ready to go. -- Sir Jam Jam
I like the idea of using George for this. There's nothing wrong with denying people's ssh connections. Also, we could make public user account with limited shells that we could add User IDs that we want to encourage to try out the monkeysphere from that perspective. For example, if one of the George admins who is listed as an identity-certifier has already certified Foo T. Bar's key, we could write a simple note like:
Dear Foo T. Bar--
The user account "foo@george.riseup.net" has been created for
you. You can ssh into it by adding an authentication subkey
to your OpenPGP key and publishing it to the public keyservers
(or to george.riseup.net). The easiest way to do this is with
the monkeysphere.
You can verify george's ssh host key with the monkeysphere
before you connect to the host. Here's how...
--dkg
So do we agree that george is doing what we want, and we can therefore close this bug?
-- BJ (jgr)
I'm fine with closing this bug, unless we want to set up the limited shell access/welcome letter like i described above. If we want to do that, it'd be worth keeping it open until those scripts are written.
I envision a script you'd invoke like:
root@george# addmsuser foo 'Foo T. Bar <foo@example.org>'
Which would create the foo account, populate
~foo/.monkeysphere/authorized_user_ids, make a note in a log
someplace, and send a welcome letter.
--dkg
That idea really seems like a lot more trouble than it's worth to me, and I'm not really willing to maintain it myself, but if someone else wants to handle that, that would be fine with me.
-- jgr
i'm not really willing to maintain anything extra either, so i'm closing this ticket as done.
--dkg