-website/changelog
\ No newline at end of file
+packaging/debian/changelog
\ No newline at end of file
+monkeysphere (0.22~pre-1) UNRELEASED; urgency=low
+
+ * New upstream release:
+ [ Jameson Rollins ]
+
+ - added info log output when a new key is added to known_hosts file.
+ - added some useful output to the ssh-proxycommand for "marginal"
+ cases where keys are found for host but do not have full validity.
+ - force ssh-keygen to read from stdin to get ssh key fingerprint.
+
+ [ Daniel Kahn Gillmor ]
+
+ - automatically output two copies of the host's public key: one
+ standard ssh public key file, and the other a minimal OpenPGP key with
+ just the latest valid self-sig.
+
+ -- Jameson Graef Rollins <jrollins@finestructure.net> Mon, 17 Nov 2008 18:15:43 -0500
+
monkeysphere (0.21-2) unstable; urgency=low
* actually rmdir /var/lib/monkeysphere-* during prerm if possible.
;;
'uid') # user ids
if [ "$lastKey" != pub ] ; then
- log verbose " - got a user ID after a sub key?! user IDs should only follow primary keys!"
+ log verbose " ! got a user ID after a sub key?! user IDs should only follow primary keys!"
continue
fi
# if an acceptable user ID was already found, skip
if [ "$validity" = 'u' -o "$validity" = 'f' ] ; then
# mark user ID acceptable
uidOK=true
+ else
+ log debug " - unacceptable user ID validity ($validity)."
fi
else
continue
# if sub key validity is not ok, skip
if [ "$validity" != 'u' -a "$validity" != 'f' ] ; then
+ log debug " - unacceptable sub key validity ($validity)."
continue
fi
# if sub key capability is not ok, skip
if ! check_capability "$usage" $requiredCapability ; then
+ log debug " - unacceptable sub key capability ($usage)."
continue
fi
process_host_known_hosts() {
local host
local userID
+ local noKey=
local nKeys
local nKeysOK
local ok
continue
fi
- # remove the old host key line, and note if removed
- remove_line "$KNOWN_HOSTS" "$sshKey"
+ # remove any old host key line, and note if removed nothing is
+ # removed
+ remove_line "$KNOWN_HOSTS" "$sshKey" || noKey=true
# if key OK, add new host line
if [ "$ok" -eq '0' ] ; then
else
ssh2known_hosts "$host" "$sshKey" >> "$KNOWN_HOSTS"
fi
+
+ # log if this is a new key to the known_hosts file
+ if [ "$noKey" ] ; then
+ log info "* new key for $host added to known_hosts file."
+ fi
fi
done
fingerprint=$(fingerprint_server_key)
gpg_authentication "--fingerprint --list-key --list-options show-unusable-uids $fingerprint"
- # dumping to a file named ' ' so that the ssh-keygen output
- # doesn't claim any potentially bogus hostname(s):
- tmpkey=$(mktemp ${TMPDIR:-/tmp}/tmp.XXXXXXXXXX) || failure "Could not create temporary directory!"
- gpg_authentication "--export $fingerprint" | openpgp2ssh "$fingerprint" 2>/dev/null > "$tmpkey"
+ # do some crazy "Here Strings" redirection to get the key to
+ # ssh-keygen, since it doesn't read from stdin cleanly
echo -n "ssh fingerprint: "
- ssh-keygen -l -f $tmpkey | awk '{ print $1, $2, $4 }'
- rm -rf "$tmpkey"
+ ssh-keygen -l -f /dev/stdin \
+ <<<$(gpg_authentication "--export $fingerprint" | \
+ openpgp2ssh "$fingerprint" 2>/dev/null) | \
+ awk '{ print $1, $2, $4 }'
echo -n "OpenPGP fingerprint: "
echo "$fingerprint"
}
(umask 077 && \
gpg_host --export-secret-key "$fingerprint" | \
openpgp2ssh "$fingerprint" > "${SYSDATADIR}/ssh_host_rsa_key")
- log info "private SSH host key output to file: ${SYSDATADIR}/ssh_host_rsa_key"
+ log info "SSH host private key output to file: ${SYSDATADIR}/ssh_host_rsa_key"
+ ssh-keygen -y -f "${SYSDATADIR}/ssh_host_rsa_key" > "${SYSDATADIR}/ssh_host_rsa_key.pub"
+ log info "SSH host public key output to file: ${SYSDATADIR}/ssh_host_rsa_key.pub"
+ gpg_authentication "--export-options export-minimal --armor --export 0x${fingerprint}\!" > "${SYSDATADIR}/ssh_host_rsa_key.pub.gpg"
+ log info "SSH host public key in OpenPGP form: ${SYSDATADIR}/ssh_host_rsa_key.pub.gpg"
}
# extend the lifetime of a host key:
# established. Can be added to ~/.ssh/config as follows:
# ProxyCommand monkeysphere-ssh-proxycommand %h %p
+########################################################################
+PGRM=$(basename $0)
+
+SYSSHAREDIR=${MONKEYSPHERE_SYSSHAREDIR:-"/usr/share/monkeysphere"}
+export SYSSHAREDIR
+. "${SYSSHAREDIR}/common" || exit 1
+
+########################################################################
+# FUNCTIONS
########################################################################
usage() {
-cat <<EOF >&2
+ cat <<EOF >&2
usage: ssh -o ProxyCommand="$(basename $0) %h %p" ...
EOF
}
+log() {
+ echo "$@" >&2
+}
+
+output_no_valid_key() {
+ local sshKeyOffered
+ local userID
+ local type
+ local validity
+ local keyid
+ local uidfpr
+ local usage
+ local sshKeyGPG
+ local tmpkey
+ local sshFingerprint
+ local gpgSigOut
+
+ userID="ssh://${HOSTP}"
+
+ log "-------------------- Monkeysphere warning -------------------"
+ log "Monkeysphere found OpenPGP keys for this hostname, but none had full validity."
+
+ # retrieve the actual ssh key
+ sshKeyOffered=$(ssh-keyscan -t rsa -p "$PORT" "$HOST" 2>/dev/null | awk '{ print $2, $3 }')
+ # FIXME: should we do any checks for failed keyscans, eg. host not
+ # found?
+
+ # get the gpg info for userid
+ gpgOut=$(gpg --list-key --fixed-list-mode --with-colon \
+ --with-fingerprint --with-fingerprint \
+ ="$userID" 2>/dev/null)
+
+ # find all 'pub' and 'sub' lines in the gpg output, which each
+ # represent a retrieved key for the user ID
+ echo "$gpgOut" | cut -d: -f1,2,5,10,12 | \
+ while IFS=: read -r type validity keyid uidfpr usage ; do
+ case $type in
+ 'pub'|'sub')
+ # get the ssh key of the gpg key
+ sshKeyGPG=$(gpg2ssh "$keyid")
+
+ # if one of keys found matches the one offered by the
+ # host, then output info
+ if [ "$sshKeyGPG" = "$sshKeyOffered" ] ; then
+ log "An OpenPGP key matching the ssh key offered by the host was found:"
+ log
+
+ # do some crazy "Here Strings" redirection to get the key to
+ # ssh-keygen, since it doesn't read from stdin cleanly
+ sshFingerprint=$(ssh-keygen -l -f /dev/stdin \
+ <<<$(echo "$sshKeyGPG") | \
+ awk '{ print $2 }')
+
+ # get the sigs for the matching key
+ gpgSigOut=$(gpg --check-sigs \
+ --list-options show-uid-validity \
+ "$keyid")
+
+ # output the sigs, but only those on the user ID
+ # we are looking for
+ echo "$gpgSigOut" | awk '
+{
+if (match($0,"^pub")) { print; }
+if (match($0,"^uid")) { ok=0; }
+if (match($0,"^uid.*'$userID'$")) { ok=1; print; }
+if (ok) { if (match($0,"^sig")) { print; } }
+}
+' >&2
+ log
+
+ # output the other user IDs for reference
+ if (echo "$gpgSigOut" | grep "^uid" | grep -v -q "$userID") ; then
+ log "Other user IDs on this key:"
+ echo "$gpgSigOut" | grep "^uid" | grep -v "$userID" >&2
+ log
+ fi
+
+ # output ssh fingerprint
+ log "RSA key fingerprint is ${sshFingerprint}."
+
+ # this whole process is in a "while read"
+ # subshell. the only way to get information out
+ # of the subshell is to change the return code.
+ # therefore we return 1 here to indicate that a
+ # matching gpg key was found for the ssh key
+ # offered by the host
+ return 1
+ fi
+ ;;
+ esac
+ done
+
+ # if no key match was made (and the "while read" subshell returned
+ # 1) output how many keys were found
+ if (($? != 1)) ; then
+ log "None of the found keys matched the key offered by the host."
+ log "Run the following command for more info about the found keys:"
+ log "gpg --check-sigs --list-options show-uid-validity =${userID}"
+ # FIXME: should we do anything extra here if the retrieved
+ # host key is actually in the known_hosts file and the ssh
+ # connection will succeed? Should the user be warned?
+ # prompted?
+ fi
+
+ log "-------------------- ssh continues below --------------------"
+}
+
########################################################################
# export the monkeysphere log level
PORT="$2"
if [ -z "$HOST" ] ; then
- echo "Host not specified." >&2
+ log "Host not specified."
usage
exit 255
fi
# update the known_hosts file for the host
monkeysphere update-known_hosts "$HOSTP"
+# output on depending on the return of the update-known_hosts
+# subcommand, which is (ultimately) the return code of the
+# update_known_hosts function in common
+case $? in
+ 0)
+ # acceptable host key found so continue to ssh
+ true
+ ;;
+ 1)
+ # no hosts at all found so also continue (drop through to
+ # regular ssh host verification)
+ true
+ ;;
+ 2)
+ # at least one *bad* host key (and no good host keys) was
+ # found, so output some usefull information
+ output_no_valid_key
+ ;;
+ *)
+ # anything else drop through
+ true
+ ;;
+esac
+
+# FIXME: what about the case where monkeysphere successfully finds a
+# valid key for the host and adds it to the known_hosts file, but a
+# different non-monkeysphere key for the host already exists in the
+# known_hosts, and it is this non-ms key that is offered by the host?
+# monkeysphere will succeed, and the ssh connection will succeed, and
+# the user will be left with the impression that they are dealing with
+# a OpenPGP/PKI host key when in fact they are not. should we use
+# ssh-keyscan to compare the keys first?
+
# exec a netcat passthrough to host for the ssh connection
if [ -z "$NO_CONNECT" ] ; then
if (which nc 2>/dev/null >/dev/null); then
{
sed "s/__VERSION__/$VERSION/g" < utils/releasenote.header
- head -n$(( $(grep -n '^ --' debian/changelog | head -n1 | cut -f1 -d:) - 2 )) debian/changelog | tail -n+3
+ head -n$(( $(grep -n '^ --' packaging/debian/changelog | head -n1 | cut -f1 -d:) - 2 )) packaging/debian/changelog | tail -n+3
sed "s/__VERSION__/$VERSION/g" < utils/releasenote.footer
} > "website/news/release-$VERSION.mdwn"
+++ /dev/null
-I would like to know, at INFO (default) log level, when the
-monkeyspehere makes a "real" modification to my known_hosts file; that
-is, when it adds or deletes a key.
-
-Apparently this is hard because monkeysphere is currently configured to
-delete all keys and then add good keys, so a key added for the first
-time seems to the monkeysphere very similar to a key re-added ten
-seconds after last login.
-
-Still, from a UI perspective, I want to know what monkeysphere is doing.
--- /dev/null
+I would like to know, at INFO (default) log level, when the
+monkeyspehere makes a "real" modification to my known\_hosts file; that
+is, when it adds or deletes a key.
+
+Apparently this is hard because monkeysphere is currently configured to
+delete all keys and then add good keys, so a key added for the first
+time seems to the monkeysphere very similar to a key re-added ten
+seconds after last login.
+
+Still, from a UI perspective, I want to know what monkeysphere is doing.
+
+------
+
+It looks like jrollins committed a change for reporting at INFO level
+when a host key gets added by the monkeysphere:
+2459fa3ea277d7b9289945748619eab1e3441e5c
+
+When i connect to a host whose key is not already present in my
+known_hosts file, i get the following to stderr:
+
+ ms: * new key for squeak.fifthhorseman.net added to known_hosts file.
+
+This doesn't fully close this bug, because we aren't notifying on key
+deletion, afaict.
+
+------
+
+So current log level DEBUG will output a message if the known host
+file has been modified. If the issue is that you want to know at the
+default log level everytime the known\_hots file is modified, then we
+should just move this message to INFO instead of debug, and then maybe
+remove the message that I added above. I was under the impression
+that the issue was more about notification that a *new* key was added
+to the known\_hosts file, and therefore the new INFO message above
+fixed that problem. Should we do this instead?
+
+In general, more verbose log levels *do* tell the user what the
+monkeysphere is doing. Moving to DEBUG log level will tell you pretty
+much everything that happens. I do *not* think that this should be
+the default log level, though.
+
+------
+
+I wouldn't want to see an extremely verbose default log level. But i
+do think that saying something like "key blah blah blah was stripped
+from your known\_hosts file because it was expired" (for example)
+would be useful. I think this case would occur infrequently enough
+that it is worth reporting in the UI at the regular log level.
+
+ --dkg
* Getting started as a [user](/getting-started-user)
* Getting started as a [server admin](/getting-started-admin)
+## Going further ##
+
+ * [Signing server keys](/signing-server-keys)
+
## Under the hood ##
* [Developing the monkeysphere](/community)
## References ##
- * [Initial specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH)
+ * [Initial Monkeysphere specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH)
* [OpenPGP (RFC 4880)](http://tools.ietf.org/html/rfc4880)
* [Secure Shell Authentication Protocol (RFC 4252)](http://tools.ietf.org/html/rfc4252)
* [URI scheme for SSH, RFC draft](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/)
up your machine to automatically identify connecting users by their
presence in the OpenPGP web of trust.
+
Server host key publication
---------------------------
To generate and publish a server host key:
existing session to the machine while you test your changes so you
don't get locked out.
+
Monkeysphere authorized_keys maintenance
----------------------------------------
This would refresh your keychain every day at noon.
+
Install the monkeysphere software on your system
------------------------------------------------
GnuTLS 2.6 or later, there are patches for GnuTLS 2.4 available in
[the Monkeysphere git repo](/community).
+
Keeping your `known_hosts` file in sync with your keyring
------------------------------------------------------------
+---------------------------------------------------------
With your keyring updated, you want to make sure that OpenSSH can
still see the most recent trusted information about who the various
command could be added to a crontab as well, if desired.
+
Using `monkeysphere-ssh-proxycommand`(1)
----------------------------------------
you want to add the subkey to on the command line.
+
Using your OpenPGP authentication key for SSH
---------------------------------------------
FIXME: using the key with a single ssh connection?
+
Establish trust
---------------
--- /dev/null
+# Signing a server OpenPGP key #
+
+This page is meant to address the issue of signing server OpenPGP
+keys. Servers are not people, so the circumstances under which one
+should sign a server key are different from those under which one
+should sign another person's key.
+
+# Why are signatures on the server key important? #
+
+In order for users to connect to a server in a monkeysphere-enabled
+network, the server key must have *full* calculated validity from the
+perspective of the connecting user. If the user has not themselves
+signed the server's key, then the server's key can only be valid if
+other people that the user trusts have signed the key.
+
+If only one person has signed the server's key, then the user must
+fully trust the single person who has signed the server key. Full
+trust should be granted sparingly and with consideration, though, so
+unless the user knows the server admin very well, they will in general
+not have full trust of this person.
+
+However, full trust of the server key can also be achieved if the
+server key has been signed by three or more people that the user has
+ *marginal* trust of. In other words, three or more *marginally*
+trusted signatures equals one *fully* trusted signature. It is much
+more common for users to have marginal trust of other users in the Web
+of Trust. For this reason, it is advisable to have as many people
+sign the server key as possible.
+
+## What information should you have before signing a server key? ##
+
+Before signing the key of a person, you want to do two things:
+
+1. verify the identity of the person.
+2. verify that the person is actually in control of the key that you
+are signing.
+
+For a server, you want to do basically the same thing:
+
+1. verify the identity of the server.
+2. verify that the server is actually in control of the key that you
+are signing.
+
+However, with a server, verifying these things is a little trickier.
+
+Verifying that the server is in control of the key is, in principle,
+straightforward. If you are logged on to the machine in question,
+then you can check directly that the key exists on the system.
+
+What is not so straightforward is what exactly it means to "verify the
+identity" of a remote server on the internet? The identity in this
+case is the fully qualified domain name (FQDN) of the host. Verifying
+this identity amounts to being sure that the host in question really
+is located at that FQDN.
+
+
+## Signing the server key ##
+
+If you are the person (or persons) that actually setup the server and
+configured Monkeysphere and ssh on the server, then clearly you should
+definitely sign the server key right away. When the server is first
+setup, the persons who set it up are the only ones who can actually
+vouch for the server key, so their signatures are necessary to get
+things going. Their signatures are also necessary so that they can
+verify the host key themselves and log into the server via
+monkeysphere-enabled ssh in the future.
+
+If you did not set up the server initially, you do not have an
+accumulated full trust of the person(s) who did, and you do not
+necessarily have console access to the server directly, it's hard to
+confidently verify the server identity and key ownership. You would
+like to be able to walk up to the server, log in at the console, and
+get the fingerprint of the ssh host key directly. But this is usually
+untenable.
+
+However, it is still possible to verify the server identity *and*
+server ownership of the key, even in this case.
+
+
+## Remotely verifying server identify and key possession ##
+
+It is in fact possible to verify the identity and key ownership of a
+server in one fell swoop with monkeysphere-enabled ssh. Here is the
+procedure:
+
+> **Attempt to make a monkeysphere-enabled ssh connection to the host in
+question. Monkeysphere will check that the ssh host key offered by the
+host matches the OpenPGP key with the correct host FQDN user ID. If
+the ssh host key and the OpenPGP key with the correct user ID match,
+then you will have effectively:**
+
+>**1. verified the host identity, because you actually connected to the
+host in question, which you know because you:**
+
+>**2. verified the host is in control of the key, because the ssh host
+key offered by the host matches the OpenPGP key with correct host FQDN
+user ID.**
+
+Here is an example:
+
+ servo:~ 0$ ssh zimmermann.mayfirst.org
+ -------------------- Monkeysphere warning -------------------
+ Monkeysphere found OpenPGP keys for this hostname, but none had full validity.
+ An OpenPGP key matching the ssh key offered by the host was found:
+
+ pub 2048R/860E8F9C 2008-10-29 [expires: 2009-02-26]
+ uid [marginal] ssh://zimmermann.mayfirst.org
+ sig! 76CC057D 2008-11-15 Jamie McClelland <jamie@mayfirst.org>
+ sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org
+ sig! D21739E9 2008-10-29 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
+ sig! 1CF2D62A 2008-11-16 Micah Anderson <micah@riseup.net>
+
+ RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e.
+ -------------------- ssh continues below --------------------
+ The authenticity of host 'zimmermann.mayfirst.org (<no hostip for proxy command>)' can't be established.
+ RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e.
+ No matching host key fingerprint found in DNS.
+ Are you sure you want to continue connecting (yes/no)? no
+ Host key verification failed.
+ servo:~ 255$
+
+I have attempted to connect to the host zimmermann.mayfirst.org.
+zimmermann's host key has only *marginal* validity for the FQDN user
+ID in question, so I am not able to connect. However, the
+monkeysphere has checked that the ssh host key actually does match the
+OpenPGP key with the correct user ID `ssh://zimmermann.mayfirst.org`.
+I have therefore verified the identity of zimmermann, and verified
+that zimmermann is in possession of the key in question.
projects / monkeysphere.git / commitdiff