monkeysphere issueshttps://0xacab.org/monkeysphere/monkeysphere/-/issues2018-01-09T15:01:05Zhttps://0xacab.org/monkeysphere/monkeysphere/-/issues/1079ssh-keyscan may not be a good idea in all cases.2018-01-09T15:01:05ZGhost Userssh-keyscan may not be a good idea in all cases.Currently we call @ssh-keyscan@ before presenting the "marginal UI". But in certain circumstances, @ssh-keyscan@ may fail (this is bug #676). Worse, perhaps, in other circumstances it may timeout, delaying the ssh connection. It may even...Currently we call @ssh-keyscan@ before presenting the "marginal UI". But in certain circumstances, @ssh-keyscan@ may fail (this is bug #676). Worse, perhaps, in other circumstances it may timeout, delaying the ssh connection. It may even succeed, but on a high-latency link when we would rather having the overhead of two connections.
I currently lack a proposed solution.
*(from redmine: created on 2009-07-11)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1181enable monkeysphere use without allowing host enumeration (hashed User IDs)2018-01-09T15:01:05Zdkgenable monkeysphere use without allowing host enumeration (hashed User IDs)Some administrators might be leery about publishing a map of all their hosts to the public keyservers.
One proposed way to avoid this would be to publish digested hostnames instead. This was fairly formally proposed in November of 20...Some administrators might be leery about publishing a map of all their hosts to the public keyservers.
One proposed way to avoid this would be to publish digested hostnames instead. This was fairly formally proposed in November of 2008 on the monkeysphere list:
https://lists.riseup.net/www/arc/monkeysphere/2008-11/msg00013.html
There was an observation that simply publishing host names in User IDs
stored in public keyservers would basically expose a list of your
hosts to the outside world. Administrators of a realm that does not
want host enumeration to be possible might see this as a reason to
avoid using the Monkeysphere.
To provide a way that these administrators could use the Monkeysphere
without enumerating their hosts, it was proposed that we allow for
hashing of hostnames in the User ID field. Then clients could search
for the hashed hostnames via the public keyservers, but anyone trying
to establish the name of, say, all hosts in a domain based on a WoT
inventory would be stymied.
Specifically, if i cared about being this kind of sneaky, instead of
having published a key with User ID of ssh://squeak.fifthhorseman.net
i would have published something like:
ssh+sha1://99c5789b129598051ca82578c14ba3923c71c73d
Connecting clients would look up the hashed host name first, and if
they failed to find it (and were configured to be allowed to look up
unhashed hosts), they would query a second time for the unhashed
hostname before falling back to non-monkeysphere ssh connections.
A few outstanding questions:
* What should we do with hosts which have both kinds of keys
available? For a client who is allowed to look up unhashed hosts,
should a published hashed record preclude it from considering the
published unhashed record? I think it should not (otherwise you
can create a DoS attack by simply publishing a forged unhashed
record)
* What prefix should we use for the hashed hostnames? One proposal
was to just keep using ssh://. Another proposal was to use
ssh+hash://. Above, i've used ssh+sha1://. One concern with using
ssh:// is that there is a possibility that icann will eventually
open up the root zone to public registration the same way that .com
and the other TLDs are open (i.e. anyone with enough money could
claim a TLD for a certain period of time). In principle, i see no
reason why they shouldn't do this, and it could be extremely
lucrative for them if they could pull it off. However, if this
happened, someone could actually register
99c5789b129598051ca82578c14ba3923c71c73d as a TLD, which would
conflict with squeak. This seems unlikely at present, but the
potential collisions that could be forced if such a change *was*
evenutally made would suck for the monkeysphere if it used the same
prefix for hashed and non-hashed hosts.
* How do we handle alternate ports? If the connection is on a
non-standard port, what should we do? Should a connection to
squeak on port 2222 look first for
ssh+sha1://18ea3840c81c8f6647c8f5af7f5add419650d2d8 or
ssh+sha1://99c5789b129598051ca82578c14ba3923c71c73d:2222 ? Why?
* Could we provide similar options for users (as opposed to hosts)
who prefer to mask their User IDs in a similar way? How would that
work?
*(from redmine: created on 2009-08-02)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1387document/automate use of monkeysphere with mina sshd (from apache)2023-08-12T13:39:43Zdkgdocument/automate use of monkeysphere with mina sshd (from apache)Apache has a "free sshd implementation based on mina.":http://mina.apache.org/sshd/ It would be good if we could sort out what it would take to get monkeysphere to interact with that implementation as well.
*(from redmine: created on ...Apache has a "free sshd implementation based on mina.":http://mina.apache.org/sshd/ It would be good if we could sort out what it would take to get monkeysphere to interact with that implementation as well.
*(from redmine: created on 2009-10-30)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1500monkeysphere ssh-proxycommand --no-connect should not fail if the host is not...2023-08-12T13:39:44Zdkgmonkeysphere ssh-proxycommand --no-connect should not fail if the host is not directly reachableone of the common use cases for the --no-connect option to monkeysphere ssh-proxycommand is to layer the tool into some other ProxyCommand.
often other (non-monkeysphere) ProxyCommands are used for so-called JumpHosts, where the target ...one of the common use cases for the --no-connect option to monkeysphere ssh-proxycommand is to layer the tool into some other ProxyCommand.
often other (non-monkeysphere) ProxyCommands are used for so-called JumpHosts, where the target server is not directly reachable from the client (due to firewalls, etc).
For example, a simple monkeysphere-enabled ProxyCommand to get through a jumphost might look like @-oProxyCommand='msjump jumphost.example %h %p'@:
<pre>
#!/bin/sh
# usage: ssh -oProxyCommand='msjump jumphost.example %h %p'
jumphost="$1"
host="$2"
port="$3"
monkeysphere ssh-proxycommand --no-connect "$host" "$port" && ssh "$jumphost" nc "$host" "$port"
</pre>
However, if a user uses this when the final destination is unavailable, we see this message, and the ssh connection fails:
target.example: forward host lookup failed: Unknown host : Connection timed out
ssh_exchange_identification: Connection closed by remote host
This is likely because of the ssh-keyscan step of monkeysphere ssh-proxycommand.
it seems to me like the presence of --no-connect should either:
# prevent the ssh-keyscan from happening at all, or
# permit the ssh-keyscan process to fail without triggering an overall error
*(from redmine: created on 2009-12-09)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1566provide bash tab-completion for monkeysphere, monkeysphere-host, and monkeysp...2023-08-12T13:39:44Zdkgprovide bash tab-completion for monkeysphere, monkeysphere-host, and monkeysphere-authenticationit'd be good to provide bash tab completion for the main subcommands for the various user-facing monkeysphere tools.
*(from redmine: created on 2010-01-12)*it'd be good to provide bash tab completion for the main subcommands for the various user-facing monkeysphere tools.
*(from redmine: created on 2010-01-12)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1600known_hosts truncation when filesystem full2023-08-12T13:39:54Zdkgknown_hosts truncation when filesystem fulli ran out of space on the filesystem where i was using @monkeysphere ssh-proxycommand@, and @~/.ssh/known_hosts@ ended up getting truncated somehow, along with a lot of spew of grep complaining (sadly, i don't have access to the spew any...i ran out of space on the filesystem where i was using @monkeysphere ssh-proxycommand@, and @~/.ssh/known_hosts@ ended up getting truncated somehow, along with a lot of spew of grep complaining (sadly, i don't have access to the spew any more).
Because the truncation was in the middle of a key, it meant that future runs of @ssh-keygen -F $hostname@ would fail, which in turn would cause @monkeysphere ssh-proxycommand@ to fail, due to it being @set -e@. this meant that every attempt to ssh would end in:
<pre>
ssh_exchange_identification: Connection closed by remote host
</pre>
looking at the truncated file, i see that it was truncated at position 0x28000 -- very likely a filesystem block boundary, since 4KiB blocks are size 0x1000. Then i see another key slapped right in the middle of the line.
advice to try to replicate:
* i have a large known_hosts file -- on the order of 270KiB -- i suspect that contributed to it being likely to screw up somewhere
* i'd start by trying to replicate the truncation with just @monkeysphere update-known_hosts@ on a mostly-full filesystem.
workaround:
i resolved the problem for myself by cleaning up the @known_hosts@ file (i restored from a backup). you could probably also recover by cleaning out the truncated line (though you'd lose not only that key, all of the keys that come after it)
observations:
it seems likely that some thing is appending to @~/.ssh/known_hosts@ -- if there is no trailing newline in the file, appending is not a good idea, since it would just append the data to the tail of such line. for an otherwise well-formed line with a comment that is simply missing a newline, this would look like an extra-long comment (and the new line would be ignored). for a line that is already truncated in the middle of the key, or has no comment at all, it would make the key unintelligible.
I backed up the corrupted file for future examination. here's an example of the failing output.
<pre>
0 dkg@pip:~$ ssh-keygen -f ~/.ssh/known_hosts.busted -F no.such.host
key_read: uudecode AAAAB3NzaC1yc2EAAAABIwAAAQEAtoXLV1PpBM+Ad+WKUri/0kJyQwKUSJkcum3WiRHpV4j69BG5bWC0D+HKuPfYP5BXBOFaFe2lxNVyOP03bOFvoA4UHUL3l/iBXNqnn8AmkLFHUVJv3/CS8K+XirIqoPUddkaOkRYK1WAEVmIg6GH7z1V3xabfTGmik4LE6kPD+YZ4kuYezpYgLhYYX8x0Rimp0ac+yvIwL5LNOl8uo5DK+VNWFIOD2PRgmocJn/YXH|1|oS9U8neREGPKvjnXgFINWjM/uOg=|Q0PPWPo9fg/8FpSVG5YET3QPUk4= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDasn6qazShJv/hnFpwmo+JJZrm8ZJAvOCYQfZ9uL8p1EDTSgWvla0g3ggJJNS1UEAgoLA6Oly/TR5llRxcEavXH1YU4gMLo9X8BDBNiTwZZ5AlBS3PGNk5jfWGsSBiibMTLJ/uhVOdDm/rjI6Vt1ifGEBcVwFhVfIw87zGK0MPjAwKnluaH8NbpxKkS++6DHcT4cr6QKVkGfkmiqMAyASzo7AzMLyDBBtbnPh3/RgBr/yWFufGhI+L4rNHpoDGnfjl0lQWtS2RSqkh9kdXQr/IF+xkxLMxFcBpJArV8zdlgLzlMoN1v1iF/QjWZaIiS0V/xum+4to/UnH+y50JxKvN failed
line 544 invalid key: some.host.example.org...
/home/dkg/.ssh/known_hosts.busted is not a valid known_hosts file.
1 dkg@pip:~$
</pre>
*(from redmine: created on 2010-02-09)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1685Introducing monkeysphere-host email-key2023-08-12T13:39:43ZrhattoIntroducing monkeysphere-host email-keyCommit "dff5d7edf2a3c0101d1ec579bc6d9e2494e0d981":http://git.sarava.org/?p=monkeysphere.git;a=commit;h=dff5d7edf2a3c0101d1ec579bc6d9e2494e0d981 introduces command </pre>monkeysphere-host email-key</pre>.
I wonder if I implemented in the...Commit "dff5d7edf2a3c0101d1ec579bc6d9e2494e0d981":http://git.sarava.org/?p=monkeysphere.git;a=commit;h=dff5d7edf2a3c0101d1ec579bc6d9e2494e0d981 introduces command </pre>monkeysphere-host email-key</pre>.
I wonder if I implemented in the "right" way and would like to know if that could be merged upstream. :)
*(from redmine: created on 2010-02-18)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1982xul extension should check ownership of agent's listening socket, where possible2023-08-12T13:39:42Zdkgxul extension should check ownership of agent's listening socket, where possibleOn systems that support it, the current msva-perl parses the contents of @/proc/net/tcp{,6}@ to know who is connecting to it.
It seems that the xul extension should make the same checks to ensure that it's connecting to the peer it thin...On systems that support it, the current msva-perl parses the contents of @/proc/net/tcp{,6}@ to know who is connecting to it.
It seems that the xul extension should make the same checks to ensure that it's connecting to the peer it thinks it is.
Ideally, the way to do it would be:
# open the TCP connection to the agent
# examine the state of the connection, including the local port, remote port, and remote IP address
# look it up in @/proc/net/tcp@ (or @/proc/net/tcp6@ if it's an IPv6 connection), and verify the ownership of the process
# if it's OK, then continue with the rest of the HTTP request.
it's not clear to me if we'll be able to get quite that much under the hood directly from javascript, so it might be simpler to do a slightly racier check:
# get the name-to-IP address result somehow
# look up the IP address and the target port in @/proc/net/tcp@, looking for a listening connection
# verify the uid from that entry
# then launch the XMLHttpRequest if it's OK.
There are a couple possible races in the second proposal above:
* the hostname lookup might return different results between steps 1 and 4
* the looked up process might die (and be replaced by a different, possibly-malicious process) between steps 3 and 4
but it's still probably better than nothing.
*(from redmine: created on 2010-03-11)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1996monkeysphere-host does not expose any way to select the primary user ID2023-08-12T13:39:42Zdkgmonkeysphere-host does not expose any way to select the primary user IDif you add a user ID via monkeysphere-host, it appears to set the "primary UID":http://tools.ietf.org/html/rfc4880#section-5.2.3.19 indicator based on the most-recently-created servicename.
it would be nice to be able to specify which s...if you add a user ID via monkeysphere-host, it appears to set the "primary UID":http://tools.ietf.org/html/rfc4880#section-5.2.3.19 indicator based on the most-recently-created servicename.
it would be nice to be able to specify which servicename should be primary.
*(from redmine: created on 2010-03-12)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1999Add DSA support for monkeysphere2023-08-12T13:39:28ZdkgAdd DSA support for monkeysphereit would be nice to be able to support DSA keys (for both users and hosts) in the monkeysphere. currently monkeysphere is RSA-only.
*(from redmine: created on 2010-03-12)*it would be nice to be able to support DSA keys (for both users and hosts) in the monkeysphere. currently monkeysphere is RSA-only.
*(from redmine: created on 2010-03-12)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2000add Elliptic Curve support for Monkeysphere2023-08-12T13:39:42Zdkgadd Elliptic Curve support for MonkeysphereThis is pretty untested stuff, but it would be nice to support elliptic curve-based certificates in the monkeysphere.
*(from redmine: created on 2010-03-12)*This is pretty untested stuff, but it would be nice to support elliptic curve-based certificates in the monkeysphere.
*(from redmine: created on 2010-03-12)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2001debian packaging for msva-ruby2023-08-12T13:39:41Zdkgdebian packaging for msva-rubywe should look at getting some debian packaging in shape for msva-ruby. apparently, "all the dependencies are satisfied except for rack-test":https://lists.riseup.net/www/arc/monkeysphere/2010-03/msg00011.html , and even that is only ne...we should look at getting some debian packaging in shape for msva-ruby. apparently, "all the dependencies are satisfied except for rack-test":https://lists.riseup.net/www/arc/monkeysphere/2010-03/msg00011.html , and even that is only needed for the test suite.
If we have a test suite, i'd really like for it to be run during debian package build -- there's the possibility to learn about compatibility concerns that way.
So maybe the correct path is to set up debian packaging for msva-ruby with testing disabled, and get rack-test into debian in parallel.
Then, once rack-test is available, re-enable the test suite in the debian packaging.
*(from redmine: created on 2010-03-12)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2014CHECK_KEYSERVER semantics need re-thinking2023-08-12T13:39:41ZdkgCHECK_KEYSERVER semantics need re-thinkingcurrently, CHECK_KEYSERVER can be set to true, false, or left unset.
If it is unset, it defaults to "true", except for the @ssh-proxycommand@ subcommand, which has a much more nuanced default based on the presence or absence of matching...currently, CHECK_KEYSERVER can be set to true, false, or left unset.
If it is unset, it defaults to "true", except for the @ssh-proxycommand@ subcommand, which has a much more nuanced default based on the presence or absence of matching keys or user IDs in the local keyring and known_hosts file. Setting it explicitly to @true@ or @false@
It turns out that we might want similarly nuanced defaults for @monkeysphere keys-for-userid@ (see #1997).
I worry that seems like it has become difficult to even describe the semantics of CHECK_KEYSERVER as we're exposed it to the user. Can we re-formulate it to be simpler somehow?
*(from redmine: created on 2010-03-14)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2030thunderbird/icedove plugin should support monkeysphere-authenticated TLS for ...2023-08-12T13:39:41Zdkgthunderbird/icedove plugin should support monkeysphere-authenticated TLS for IMAP/POP/SMTP/Submission.I'd like to see an extension for thunderbird/icedove/etc that would support monkeysphere-authenticated TLS for the various network protocols (e.g. IMAP, POP, SMTP, submission) used by the MUA.
maybe cover https for rss/atom? and also tl...I'd like to see an extension for thunderbird/icedove/etc that would support monkeysphere-authenticated TLS for the various network protocols (e.g. IMAP, POP, SMTP, submission) used by the MUA.
maybe cover https for rss/atom? and also tls for nntp?
*(from redmine: created on 2010-03-22)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2035msva-ruby should implement cert validation internally, instead of calling "mo...2023-08-12T13:39:46Zjrollinsmsva-ruby should implement cert validation internally, instead of calling "monkeypshere keys-for-userid"If the msva can implement certificate validation internally, then they can avoid depending on the "monkeysphere" package, and that package can transition back to being ssh specific. This would be a huge boon, so I'm marking this as High...If the msva can implement certificate validation internally, then they can avoid depending on the "monkeysphere" package, and that package can transition back to being ssh specific. This would be a huge boon, so I'm marking this as High priority.
Certificate validation is currently implemented as a single bash function called process_user_id in src/share/common in the monkeysphere package. It is 130 lines of bash not including comments. It makes a single call to gpg to determine the OpenPGP status of a user ID in a given trust db, and returns the "validity" of the available keys matching the user ID. It should be very easy to implement this functionality in ruby.
*(from redmine: created on 2010-03-22)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2036offer to add a revoker after an import-key operation2023-08-12T13:39:40Zmicahoffer to add a revoker after an import-key operationBecause it is highly recommended that a revocation certificate be made for keys, it might be good to offer to
immediately do a 'monkeysphere add-revoker' after doing an 'import-key' operation. It would be good to have
a generic revoc...Because it is highly recommended that a revocation certificate be made for keys, it might be good to offer to
immediately do a 'monkeysphere add-revoker' after doing an 'import-key' operation. It would be good to have
a generic revocation certificate created, and to offer to immediately add a revoker to the newly imported key.
It might seem redundant to offer the person who is doing the import-key to add their keyid as a valid
revoker on the key, but it seems like good practice to do so for the scenario where the admin no longer has
access to the host's secret key in the future.
Understandably this goes against the simple commands to do simple things philosophy, making it difficult for
scripts to automatically work on these commands. However, typically this is solved through a flag that
disables the human element of prompting to make way for the scripted capabilities.
*(from redmine: created on 2010-03-22)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2043implement openpgp2x5092023-08-12T13:39:40Zdkgimplement openpgp2x509We currently allow translating keys from @pem2openpgp@, and from @opengp2ssh@, but we don't yet have @openpgp2x509@.
It would be great to be able to generate a simple, self-signed X.509 certificate from an OpenPGP secret key, making sen...We currently allow translating keys from @pem2openpgp@, and from @opengp2ssh@, but we don't yet have @openpgp2x509@.
It would be great to be able to generate a simple, self-signed X.509 certificate from an OpenPGP secret key, making sensible guesses for the X.509 parameters from the OpenPGP key info.
Examples of sensible guesses for end user keys:
* the DN would be based on the primary user ID, split into @/CN="real name"/eMailAddress="foo@example"/@ for standard rfc 2822-style user ids (what to do with a comment?)
* the X.509 validity and expiration times should be based on the OpenPGP validity and expiration times
* something with subjectAltNames?
It would also be nice to be able to generate an X.509 certificate request instead of a self-signed cert, in case people want to have a path through X.509 as well.
*(from redmine: created on 2010-03-23)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2044Make mozilla authentication plugin that talks to ssh-agent2023-08-12T13:39:40ZdkgMake mozilla authentication plugin that talks to ssh-agentLook at "mozilla-opensc":http://packages.debian.org/mozilla-opensc -- this is a mozilla authentication plugin that talks to a smartcard to permit client-side authentication based on public keys stored on the smartcard.
By analogy, it wo...Look at "mozilla-opensc":http://packages.debian.org/mozilla-opensc -- this is a mozilla authentication plugin that talks to a smartcard to permit client-side authentication based on public keys stored on the smartcard.
By analogy, it would be nice to make a comparable plugin that could offer a monkeysphere-compatible certificate to the remote server, and talk to the @ssh-agent@ for the cryptographic challenge/response.
*(from redmine: created on 2010-03-23)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2045make mozilla security service plugin that queries the msva2023-08-12T13:39:39Zdkgmake mozilla security service plugin that queries the msva#2044 describes a mozilla security service plugin that handles client authentication.
if possible, it would be nice to make a comparable plugin that handles x.509 validation. This could even take the place of the xul-ext (albeit with l...#2044 describes a mozilla security service plugin that handles client authentication.
if possible, it would be nice to make a comparable plugin that handles x.509 validation. This could even take the place of the xul-ext (albeit with less of a UI) if it worked smoothly.
*(from redmine: created on 2010-03-23)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/2047Display fingerprint with spaces for legibility2023-08-12T13:39:28ZmicahDisplay fingerprint with spaces for legibilitywhen doing monkeysphere-host show-key you see something like this:
OpenPGP fingerprint: 86C6F09FD9C725879CFB532D09CF02F07AB29625
when doing gpg --fingerprint 7AB29625 you see this:
Primary key fingerprint: 86C6 F09F D9C7 2587 9CFB 5...when doing monkeysphere-host show-key you see something like this:
OpenPGP fingerprint: 86C6F09FD9C725879CFB532D09CF02F07AB29625
when doing gpg --fingerprint 7AB29625 you see this:
Primary key fingerprint: 86C6 F09F D9C7 2587 9CFB 532D 09CF 02F0 7AB2 9625
Comparing these two visually is difficult, because the first is not easily
parsed out into chunks that can be put into short term memory, and then
compared against the other. If show-key used the same spacing that
gnupg used, it would be much easier.
*(from redmine: created on 2010-03-24)*