Newsgroups: comp.security.unix,comp.security.misc
Subject: SSH (Secure Shell) FAQ - Frequently Asked Questions
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


Archive-name: computer-security/ssh-faq
Url: http://www.uni-karlsruhe.de/~ig25/ssh-faq/
Posting-frequency: every 14 days

-----BEGIN PGP SIGNED MESSAGE-----

  Ssh (Secure Shell) FAQ - Frequently asked questions
  by Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de
  $Date: 1996/03/27 14:17:53 $

  This document is a list of Frequently Asked Questions (plus hopefully
  correct answers) about the Secure Shell, ssh.	 IMPORTANT: There is a
  security bug in all versions of ssh before 1.2.12.92.	 Upgrade to a
  newer version is recommended.


  1. Meta-questions
  1.1. Where do I get this document?
  1.2. Where do I send questions, corrections etc. about this document?


  2. Ssh basics
  2.1. What is ssh?
  2.2. Why should I use it?
  2.3. What kinds of attacks does ssh protect against?
  2.4. What kind of attacks does ssh not protect against?
  2.5. How does it work?


  3. Obtaining and installing ssh
  3.1. What is the latest version of ssh?
  3.2. May I legally run ssh?
  3.3. What about commercial use of ssh?
  3.4. Where can I obtain ssh?
  3.5. How do I install it?
  3.6. Where do I get help?
  3.7. Are there any versions for other operating systems than UNIX?
  3.8. What about administration of ssh?


  4. Ssh Applications
  4.1. Can I run backups over ssh?
  4.2. Should I turn encryption off, for performance reasons?
  4.3. Can I use ssh to communicate across a firewall?
  4.4. Can I distribute files with ssh, as with rdist?
  4.5. Can I use ssh to securely connect two subnets across the
  Internet?
  4.6. Can I use ssh to securely forward UDP-based services, such as NFS
  or NIS?
  4.7. Can I forward SGI GL connections over ssh?
  4.8. Can I use ssh to protect services like ftp or POP?


  5. Problems
  5.1. ssh otherhost xclient & does not work!
  5.2. Ssh fails with "Resource temporarily unavailable" for Solaris 2.4
  5.3. X11 forwarding does not work for an SCO binary with the iBCS2
  emulator under Linux.
  5.4. Ssh is doing wrong things for multi-homed hosts!
  5.5. Userid swapping is broken under AIX!
  5.6. ssh-keygen dumps core on Alpha OSF!
  5.7. ssh-keygen dumps core on Solaris or SunOS
  5.8. On Linux, compilation aborts with some error message about
  libc.so.4
  5.9. X authorization sometimes fails.
  5.10. Ssh on Irix 5 tells me "You don't exist, go away!"
  5.11. Ssh asks me for passwords despite .rhosts!
  5.12. Why does ssh loop with "Secure connection refused'?
  5.13. ssh-agent does not work with rxvt! rxvt closes all file
  descriptors when starting up, including the one used by

  6. Miscellaneous
  6.1. How widespread is use of ssh?
  6.2. Credits

  1.  Meta-questions

  1.1.	Where do I get this document?

  The latest version of this document is available from http://www.uni-
  karlsruhe.de/~ig25/ssh-faq/. It will also be posted, on a regular
  basis, to the Usenet newsgroups comp.security.misc,
  comp.security.unix, comp.answers and news.answers. This version is
  PGP-signed, and will be available from
  ftp://rtfm.mit.edu/pub/usenet/news.answers/computer-security/ssh-faq
  and from http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq.faq.

  The original SGML file is at http://www.uni-karlsruhe.de/~ig25/ssh-
  faq/ssh-faq.sgml.

  Also of interest is the ssh home page, at http://www.cs.hut.fi/ssh/.

  1.2.	Where do I send questions, corrections etc. about this document?

  Please send them to the maintainer, Thomas.Koenig@ciw.uni-karlsruhe.de

  2.  Ssh basics


  2.1.	What is ssh?

  To quote the README file:

  Ssh (Secure Shell) is a program to log into another computer over a
  network, to execute commands in a remote machine, and to move files
  from one machine to another. It provides strong authentication and
  secure communications over insecure channels. It is intended as a
  replacement for rlogin, rsh, and rcp.

  Additionally, ssh provides secure X connections and secure forwarding
  of arbitrary TCP connections.

  2.2.	Why should I use it?

  The traditional BSD 'r' - commmands (rsh, rlogin, rcp) are vulnerable
  to different kinds of attacks. Somebody who has root access to
  machines on the network, or physical access to the wire, can gain
  unauthorized access to systems in a variety of ways. It is also
  possible for such a person to log all the traffic to and from your
  system, including passwords (which ssh never sends in the clear).

  The X Window System also has a number of severe vulnerabilities. With
  ssh, you can create secure remote X sessions which are transparent to
  the user. As a side effect, using remote X clients with ssh is more
  convenient for users.

  Users can continue to use old .rhosts and /etc/hosts.equiv files;
  changing over to ssh is mostly transparent for them. If a remote site
  does not support ssh, a fallback mechanism to rsh is included.

  2.3.	What kinds of attacks does ssh protect against?

  Ssh protects against:

  o  IP spoofing, where a remote host sends out packets which pretend to
     come from another, trusted host. Ssh even protects against a
     spoofer on the local network, who can pretend he is your router to
     the outside.

  o  IP source routing, where a host can pretend that an IP packet comes
     from another, trusted host.

  o  DNS spoofing, where an attacker forges name server records

  o  Interception of cleartext passwords and other data by intermediate
     hosts.

  o  Manipulation of data by people in control of intermediate hosts

  o  Attacks based on listening to X authentication data and spoofed
     connection to the X11 server.

  In other words, ssh never trusts the net; somebody hostile who has
  taken over the network can only force ssh to disconnect, but cannot
  decrypted or play back the traffic, or hijack the connection.

  The above only holds if you actually use encryption. Ssh does have an
  option to use encryption of type "none" this is only for debugging
  purposes, and should not be used.

  2.4.	What kind of attacks does ssh not protect against?

  Ssh will not help you with anything that compromises your host's
  security in some other way. Once an attacker has gained root access to
  a machine, he can then subvert ssh, too.

  If somebody malevolent has access to your home directory, then
  security is nonexistent. This is very much the case if your home
  directory is exported via NFS.

  2.5.	How does it work?

  For more extensive information, please refer to the README and RFC
  files in the ssh directory. The proposed RFC is also available as an
  Internet Draft, as draft-ylonen-ssh-protocol-00.txt.

  All communications are encrypted using IDEA or one of several other
  ciphers (three-key triple-DES, DES, RC4-128, TSS). Encryption keys are
  exchanged using RSA, and data used in the key exchange is destroyed
  every hour (keys are not saved anywhere). Every host has an RSA key
  which is used to authenticate the host. Encryption is used to protect
  against IP-spoofing; public key authentication is used to protect
  against DNS and routing spoofing.

  RSA keys are also used to authenticate hosts.

  3.  Obtaining and installing ssh


  3.1.	What is the latest version of ssh?

  The latest officially released version is 1.2.0. The latest
  development version is 1.2.13.

  ssh-1.2.12.92 and later versions contain an important security fix.
  Using it instead of earlier versions is recommended.	The fix here is
  intended to be temporary, and upgrading to the next release after that
  is highly recommended when it becomes available.  The temporary fix
  has some drawbacks.  For more information, read the ssh mailing list
  archive at
   http://www.cs.hut.fi/ssh/ssh-archive/.


  Ssh currently runs on UNIX or related systems, plus under OS/2.  Ports
  have been successful to all "mainstream" UNIX systems.  The current
  Windows version is believed to be unstable.

  At present, there are no known working versions for other operating
  systems (but see below).

  3.2.	May I legally run ssh?

  Ssh is free software, and can be freely used by anyone for any
  purpose.

  However, in some countries, particularly France, Russia, Iraq, and
  Pakistan, it may be illegal to use any encryption at all without a
  special permit.

  If you are in the United States, you should be aware that, while ssh
  was written outside the United States using information publicly
  available everywhere, the US Government may consider it a criminal
  offence to export this software from the US once it has been imported,
  including putting it on a ftp site.  Contact the Office of Defence
  Trade Controls if you need more information.

  The algorithms RSA and IDEA, which are used by ssh, are claimed as
  patented in different countries, including the US. Linking against the
  RSAREF2 library, which is possible, may or may not make it legal to
  use ssh for non-commercial purposes in the US. You may need to obtain
  licenses for commercial use of IDEA; ssh can be configured to work
  without it.  Ssh works perfectly fine without IDEA, however.

  For more detail, refer to the file COPYING in the ssh source
  distribution.

  For information on software patents in general, see the Leauge for
  Programming Freedom's homepage at http://lpf.org/.


  3.3.	What about commercial use of ssh?

  Ssh has been freely available in the Unix environment, and almost
  certainly will remain to be so in future.

  Tatu Ylönen, the original author of ssh, has started a company, SSH
  Communications Security Oy, that will provide commercial support and
  licenses for ssh.  He is working on licensing the patents to be able
  to provide fully licensed commercial versions.  The negotiations are
  still underway, and it will take a couple more weeks before it is
  known what the situation will really be.

  About commercial issues, it is best to contact him directly for now.
  I can best be reached by e-mail as
   ylo@cs.hut.fi, or by fax at +358-0-4354 3206.

  3.4.	Where can I obtain ssh?

  The central site for distributing ssh is ftp://ftp.cs.hut.fi/pub/ssh/.

  Official releases are PGP-signed, with the key ID

  DCB9AE01 1995/04/24 Ssh distribution key <ylo@cs.hut.fi>
  Key fingerprint =  C8 90 C8 5A 08 F0 F5 FD  61 AF E6 FF CF D4 29 D9


  The latest development version is available from
  ftp://ftp.cs.hut.fi/pub/ssh/snapshots/.

  Ssh is also available via anonymous ftp from the following sites:

     Australia:
	ftp://coombs.anu.edu.au/pub/security/tools

     Chile:
	ftp://ftp.inf.utfsm.cl/pub/security/ssh

     Finland:
	ftp://ftp.funet.fi/pub/unix/security/login/ssh

     Germany:
	ftp://ftp.cert.dfn.de/pub/tools/net/ssh

     Hungary:
	ftp://ftp.kfki.hu/pub/packages/security/ssh

     Ireland:
	ftp://odyssey.ucc.ie/pub/ssh

     Poland:
	ftp://ftp.agh.edu.pl/pub/security/ssh

     Portugal:
	ftp://ftp.ci.uminho.pt/pub/security/ssh

     Russia:
	ftp://ftp.kiae.su/unix/crypto

     Slovenia:
	ftp://ftp.arnes.si/security/ssh

     United Kingdom:
	ftp://ftp.exweb.com/pub/security/ssh

     United States:
	ftp://ftp.net.ohio-state.edu/pub/security/ssh

     United States:
	ftp://ftp.gw.com/pub/unix/ssh

  Some mirrors may not have the most recent snapshots available.

  3.5.	How do I install it?

  Get the file from a site near you, then unpack it with

  gzip -c -d ssh-1.2.13.tar.gz | tar xvf -


  then change into the directory ssh-1.2.13, read the file INSTALL, and
  follow the directions in it.

  3.6.	Where do I get help?

  First of all, read the documentation, this document :-) and the ssh
  home page, at http://www.cs.hut.fi/ssh/.

  If this doesn't help, you can send mail to the mailing list for ssh
  users at ssh@clinet.fi.  To subscribe, send mail to
  majordomo@clinet.fi with

  subscribe ssh


  in the body of the message.

  Before subscribing, you might like to take a look at the archives of
  the mailing list, at http://www.cs.hut.fi/ssh/ssh-archive.

  3.7.	Are there any versions for other operating systems than UNIX?

  Heikki Suonsivu (hsu@clinet.fi) and Michael Henits (moi@dio.com) each
  offered a US$ 100 reward for the first stable, freely redistributable
  version for either Windows or MacOS.

  There is a preliminary version for Windows by Cedomir.Igaly@srce.hr,
  available from http://public.srce.hr/~cigaly/ssh/; you might want to
  test this.  A mirror is avialable from
  ftp://ftp.cs.hut.fi/pub/ssh/windows/cigaly/; the filename is
  ssh-1-2-.zip.

  Tatu Ylönen, the original author of ssh, is currently working on a
  Windows version.

  Bernt.Budde@udac.uu.se is working on a Mac port.

  A port to VMS, by Mark Martinec (Mark.Martinec@nsc.ijs.si), is being
  worked on.

  A port to OS/2 can be obtained from ftp://ftp.cs.hut.fi/pub/ssh/os2/.
  The current maintainer, Robert Muchsel (rmuchsel@iiic.ethz.ch) does
  not have much time to continue supporting it; if you're interested in
  doing so, please drop him a line.

  There is a special mailing list for the OS/2 version of ssh.	To
  subscribe, send mail to majordomo@clinet.fi with

  subscribe ssh-os2


  in the body of the message.

  3.8.	What about administration of ssh?

  The central problem of administering ssh is the management of host
  keys.	 You can collect them automatically each night using either
  make-ssh-known-hosts.pl (distributed with the ssh source distribution)
  or with the much faster ssh-keyscan, from
  ftp://cag.lcs.mit.edu/pub/dm/ (also available from
  ftp://ftp.cs.hut.fi/ssh/contrib/).

  Thomas König has written a script to process output from one of these
  utilities, check for new keys, warn about hosts which have changed
  their keys (which could be an indication of a man in the middle
  attack) and generate a complete new file.  This script is available
  from http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list.

  With these utilities, you can write scripts to verify public keys on a
  regular basis.  When new machines are running ssh or people have
  changed public keys, you may want to contact the people in question
  directly, to make sure there were no man in the middle attacks (to
  which these utilities are vulnerable).

  A fingerprint scheme (equivalent to PGP fingerprints) has been
  proposed to make this easier; it will probably be implemented in the
  next release.


  4.  Ssh Applications


  4.1.	Can I run backups over ssh?

  Yes. Since ssh is a drop-in replacement for rsh, backup scripts should
  continue to work. If you use rdist, see below.

  4.2.	Should I turn encryption off, for performance reasons?

  No; you should keep it turned on, for security reasons.

  Today's CPUs are fast enough that performance losses (if any) only are
  noticable for local Ethernet speeds, or faster.

  You might want to specify RC4 encryption instead of the default, IDEA,
  with -c rc4, for faster operation.

  Following are some measurements where the different encryption methods
  were applied between a P5/90 and a 486/100, both running Linux, for
  copying files with scp across a lightly loaded Ethernet.

  The model chosen was t=a+x/b; a is the startup time in seconds, and b
  the sustainable transfer rate in kB/s. Also given are the 68.3%
  confidence intervals for the data, as determined by the Levenberg-
  Marquardt algorithm as implemented a pre-3.6 version of gnuplot.


  Encryption	  a[s]	    da[s]    b[kB/s]	  db[kB/s]
  none		  2.37	     0.37     386.1	    5.8
  rc4		  1.96	     0.27     318.2	    2.9
  tss		  2.33	     0.37     298.5	    3.5
  des		  2.07	     0.19     218.8	    1.0
  idea		  2.25	     0.45     169.6	    1.3
  3des		  1.92	     0.11     118.2	    0.2


  Across a heavily loaded Ethernet, rc4 encryption together with
  compression may actually be faster than using rcp.

  If you don't encrypt your sessions, you are vulnerable to all the
  attacks which are open on the "r" suite of utilities, and you might as
  well not use ssh.

  4.3.	Can I use ssh to communicate across a firewall?

  Yes; you can use TCP forwarding for that, by using its secure TCP
  forwarding features.

  4.4.	Can I distribute files with ssh, as with rdist?

  Stock rdist 6.1.0 does not work together with ssh, due to bugs in it.
  The 6.1.1 versions of rdist and later versions are believed to work.

  If you use rdist, don't forget to compile the path to ssh into it.
  Alternatively, you may specify the -P option so rdist uses ssh, and
  not rsh.

  4.5.	Can I use ssh to securely connect two subnets across the Inter­
  net?

  This has been discussed on the ssh mailing list. A proposed solution
  was to run ppp with TCP forwarding; however, this has not been
  implemented yet.

  Another solution, proposed and executed by anthony.baxter@aaii.oz.au,
  is to use tunnel devices.

  If you have details of anything that works, please forward them to the
  ssh mailing list.

  4.6.	Can I use ssh to securely forward UDP-based services, such as
  NFS or NIS?

  There is a general working solution for RPC-based services, such as
  NIS.	You can download it from ftp://ftp.tu-
  chemnitz.de/pub/Local/informatik/sec_rpc/. NIS, in particular, is
  working.

  In principle, this could also be adapted for NFS; this has not been
  done yet.

  Services which are based purely on UDP, such as DNS, have not been
  secured with ssh yet, although it is possible in principle.

  4.7.	Can I forward SGI GL connections over ssh?

  It is not likely that this will be implemented. GL uses a totally
  different protocol from X, and at least gld would have to be replaced.

  OpenGL, when run as an X server extension, should pose no problem.

  4.8.	Can I use ssh to protect services like ftp or POP?

  If you want to avoid sending ftp passwords in cleartext over the net,
  you can use ssh to encrypt your command channel.  Suppose you are on a
  host called myhost and want to initiate a ftp connection to ftphost.
  On mymachine, you do

  mymachine$ ssh -L 1234:ftphost.do.main:21 ftphost


  This logs you on to ftphost and also forwards connections to 1234 on
  mymachine to ftphost.

  Then, in another window, you to

  mymachine$ ftp mymachine 1234
  220 ftphost FTP server (Foonix 08/15) ready.
  Name: (mymachine:yourname):
  331 Password required for yourname
  Password:
  230 User yourname logged in.


  For POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) has written a
  script which protects the mail transfer and passwords ussing ssh.  It
  requires no modification to existing POP servers or clients, and is
  available from ftp://ftp.pasteur.fr/pub/Network/gwpop/.

  Other services could be secured by similar means.

  5.  Problems

  If you don't find your problem listed below, please submit a bug
  report to ssh-bugs@clinet.fi giving full details of

  o  Version number of ssh and (if different) sshd


  o  What you expected ssh to do

  o  What ssh did instead (including all error messages)

  o  The system you use (for example, the output of uname -a), and the
     output of config.guess.

  o  The compiler you used, plus any compilation flags

  o  The output of ssh -v

  o  The output of the sshd daemon when run in debug mode, as sshd -d

     Please try the latest snapshot from
     ftp://ftp.cs.hut.fi/pub/ssh/snapshots/ before reporting any bug.

  5.1.	ssh otherhost xclient & does not work!

  No, it doesn't. Use "ssh -f otherhost xclient" instead, or "ssh -n
  otherhost xclient &" if you want a script to be compatible with rsh.

  5.2.	Ssh fails with "Resource temporarily unavailable" for Solaris
  2.4

  This is a kernel bug in Solaris. Get the patch 101945-34 to fix it.

  5.3.	X11 forwarding does not work for an SCO binary with the iBCS2
  emulator under Linux.

  You need to set the hostname to the fully qualified domain name for
  this to work. Some Linux distributions set the hostname to the first
  part of the FQDN only.

  5.4.	Ssh is doing wrong things for multi-homed hosts!

  Check whether gethostbyname() really returns the complete lists of
  possible IP addresses (you might, for example, have your system
  configured to search /etc/hosts first, which might contain only one of
  the IP addresses).

  5.5.	Userid swapping is broken under AIX!

  This is a bug in AIX 3.2.5, reported as APAR IX38941, and fixed by
  patches U435001, U427862, U426915, and a few others. Contact your IBM
  representative for details.

  5.6.	ssh-keygen dumps core on Alpha OSF!

  For Alpha OSF/1 1.3.2, this is due to a bug in the vendor-supplied
  compiler with maximum optimization.

  Turn off all optimization for ssh-keygen, or use gcc.

  5.7.	ssh-keygen dumps core on Solaris or SunOS

  This is a bug in gcc 2.7.0, which causes it to generated incorrect
  code without optimization. Supply the "-O" or "-O -g" options to gcc
  when compiling. Alternatively, upgrade to gcc 2.7.2.

  5.8.	On Linux, compilation aborts with some error message about
  libc.so.4

  This is an incorrectly configured Linux system; do a "cd /usr/lib; ln
  -s libc.sa libg.sa" as root to remedy this.


  5.9.	X authorization sometimes fails.

  This is believed to be a bug in HP-UX 9 xauth, SR 5003209619. Patch
  PHSS_5568 is believed to fix this problem.

  If this occurs for any other platform, please mail details to
   ssh-bugs@clinet.fi.

  5.10.	 Ssh on Irix 5 tells me "You don't exist, go away!"

  As of 1.2.12, you need to remove -lnsl in the Makefile.  A later
  version of ssh might fix this.

  5.11.	 Ssh asks me for passwords despite .rhosts!

  There are several possibilities why this could be the case; common
  ones include

  o  The client host key is not stored in the known_hosts file.	 Note
     that this has to be the canonical (usually, the fully qualified)
     domain name.

  o  The host does not have a reverse mapping in the name servers.  Note
     that ssh requires that it has both a reverse mapping, and a forward
     mapping that contains the original IP address.

  o  A multi-homed host does not have all of its IP addresses listed in
     the DNS entry.  Note that versions prior to 1.2.12 have bugs in
     handling multi-homed hosts.

  o  User's home directory or ~/.rhosts is world or group-writable (see
     StrictModes server configuration option).

  o  On some machines, if the home directory is on an NFS volume,
     ~/.rhosts and your home directory may need to be world-readable.

  o  The root account has to use ~/.rhosts or ~/.shosts;
     /etc/shosts.equiv and /etc/hosts.equiv are disregarded for root.

  o  Confusion between RhostsRSAAuthentication and RSAAuthentication.

     RhostsRSAAuthentication is a functional replacement for the 'r'
     utilities; this requires the ssh program to be setuid root, a
     secret key in /etc/host_key file on the client, a corresponding
     public key entry in /etc/ssh_known_hosts, plus entries in
     ~/.[sr]hosts or /etc/[s]hosts.equiv.

     RSAAuthentication is done on a per-user basis and requires a
     ~/.ssh/identity file on the client side (to be generated with ssh-
     keygen), plus a matching ~/.ssh/authorized_keys on the server side.

  5.12.	 Why does ssh loop with "Secure connection refused'?

  This is a configuration problem.

  Ssh attempts to fall back to the "r" commands when it cannot connect
  to an ssh daemon on the remote host.	It does this by execing your old
  rsh to use the old protocol.

  There are two possibilities why this could be:

  o  You probably have installed ssh as rsh, and forgotten to give the
     --with-rsh=PATH option to configure the second time.  When ssh is
     looking for rsh, it keeps executing itself (or an older version of
     itself).  To solve this, recompile ssh with the correct place for
     rsh.
  o  You  moved the old rsh and rlogin into a different directory and
     correctly are calling the old rsh.	 The old rsh has a hard-coded
     path to the old rlogin program, so you wind up execing the old rsh
     which in turn execs the new replacement (ssh)rlogin.

     In that case, you might want to move the old rsh and rlogin
     binaries into /usr/old, patch the old rsh binary by running the
     Perl script

     perl -pi.orig -e 's+/usr/(bin|ucb)/rlogin+/usr/old/rlogin+g ;' /usr/old/rsh


  which will generate a patched version of rsh and save the old one in
  /usr/old/rsh.orig.

  Reconfigure ssh with --with-rsh=/usr/old/rsh.

  5.13.	 rxvt closes all file descriptors when starting up, including
  the one used by ssh-agent.  Use xterm, or look at the mailing list
  archives at http://www.cs.hut.fi/ssh/ssh-archive/ for Timo Rinne's
  rxvt patch.  ssh-agent does not work with rxvt!

  6.  Miscellaneous


  6.1.	How widespread is use of ssh?

  As with every piece of freely available software, this is difficult to
  find out.  The best current estimates are that at least 1000
  insitutions in 40 countries use it.  This estimate is based on

  o  The number of people on the ssh mailing list, around 600, from 40
     different countries and several hundred domains

  o  Each week, the ssh home pages are accessed from roughly 5000
     different machines, many of them web caches; also, these machines
     often are different from week to week.


  6.2.	Credits

  Most of the credit, of course, goes to Tatu Ylönen for writing ssh and
  making it available to the public. I have also used parts of his text
  from the documentation accompanying the ssh source distribution.
  Thanks also for his corrections for this FAQ.

  Also of invaluable help were corrections and additions from members of
  the ssh mailing list and the Usenet newsgroups, by Mark Martinec,
  Pedro Melo, Michael Soukas, Adrian Colley, Kenneth J. Hendrickson,
  Adam Hammer, Olaf Titz, David Mazieres and Wayne Schroeder.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBMVlOVPBu+cbJcKCVAQFZMwP+J5la5m9ja+N1tEb3afhax//jFvFrqY93
5VS25XIRjp16KV9bl0Q+4LG+sLE91rD49JAIIDgxkeurnorgNjCXIqxM5eVnkCTQ
7Oj1WVn0q96h7llDDuoRorh+jrq3FcQn5PHJPyko/r72FeIPRrGxwqOIFBaAwjRn
R/lD+ulfFeU=
=tmRx
-----END PGP SIGNATURE-----
