This is my ssh implementation, moussh. This file is a compilation document; for a usage document, see README. This directory does not contain everything necessary to build moussh. There are a number of libraries you will have to get from elsewhere: -larc4 -lblowfish -lcamellia -ldes -lidea -lmd5 -lrijndael -lsha My crypto libraries. If you have existing code that implements the relevant crypto algorithms, it will probably be fairly simple to write a glue layer to use it; you probably will need a glue layer, though, since my code was not written with API-compatibility with any other code as a goal. If you remove the relevant lines from alg-lists and the relevant files from the build, you can skip any of these. (Well, mostly. A few may be needed for other purposes. And, of course, if you remove an MUST-implement algorithm, the result will no longer conform to the spec, even to the extent out-of-the-box moussh does - see README's discussion of UTF-8 and conformance.) -laio A pseudo-asynchronous I/O library (wrappers around poll() and a bunch of support functions). Loosely put, it is to true asynchronous I/O what cooperative multitasking is to preemptive multitasking. -lXau X authentication libraries. These will normally come with your X installation. See below for what to do if you don't have (or just don't want to use) X. -lgmp The GNU multiprecision arithmetic library. I use version 2.0.2; I don't know how suitable other versions may be. See below for more on this. -ldsa Another crypto library (for DSA signatures). I list this separately, rather than with the crypto stuff above, because this dependency can be eliminated relatively easily; see the discussion below about -lgmp and the bignum branch in the git repo. -lcrypt The library containing crypt(3), used for password authentication in the server. See below for more on this. -lz Used for zlib compression. See below for what to do if you don't have (or don't want to use) this. Except for -lXau, -lcrypt, and -lz, all these are available as anonymously-clonable git repos on git.rodents-montreal.org; they are also available via anonymous ftp from ftp.rodents-montreal.org, in /mouse/local/src/libarc4/, .../libblowfish/, .../libdes/, etc, but those versions are updated sporadically at best. If you picked up moussh from my git repo on git.rodents-montreal.org, you can find the crypto libraries in sibling repos named libarc4, libblowfish, etc. (You might not need -ldsa. See below about -lgmp; if you use the bignum branch, you don't need -ldsa either.) -lXau needs to come from your X installation; if you don't have X installed, you can build moussh with all the X support disabled by rebuilding with -DNO_X11 added to the compilation of x.c and -lXau removed from the link. (If you're using the Makefile, the easiest way to add -DNO_X11 is to add it to the CC_ADD line.) -lcrypt needs to come from your OS. Some OSes may have this included in libc; if libcrypt appears to be nonexistent, try just removing -lcrypt from the link and see if that works. If you can't figure out where crypt(3) lives on your system - or if you want to totally disable server-side password authentication for any other reason - you can rebuild alg-ua-password.c with -DNO_SERVER_PW_AUTH, in which case there is no need for -lcrypt, and password authentication won't be available. -lz comes with most OSes these days; if you would prefer to remove the dependency on it for any reason, simply comment out or remove the zlib line in the compression section of alg-lists and remove -lz from the link (which means from LIBS_moussh if you're using the Makefile as-is). This will of course make zlib compression unavailable. -lgmp is for big-number arithemtic, as is used by public-key crypto. I have written my own big-number arithmetic code, which can be obtained by checking out the `bignum' branch in the git tree, but I still use libgmp where it works because it's significantly faster than my code. (Fortunately, the machines where I care most about speed are also the ones where libgmp works for me.) If you use the bignum branch, you won't need libgmp (nor libdsa; see above); if you use the master branch, you will. If you have this version of this file, you've got the libgmp-using version. It might be possible to build something like ssh without needing any large-number arithmetic, but it would mean replacing all the public-key cryptography, and I don't even know of, never mind have an implementation of, any public-key crypto that doesn't require large-number arithmetic. The result would not conform to the standard, of course, since there are MUSTs requiring support for some of the existing public-key crypto, but it might be useful in some special-case environments. It might be possible to use newer libgmp than 2.0.2; I haven't tried, because (a) avoiding libgmp was the incentive to write my own large-number arithmetic code, (b) libgmp has drunk the ./configure koolaid, which makes the brain cycles required for switching versions ludicrously high (see my blah post about this, ftp.rodents-montreal.org:/mouse/blah/2009-11-20-1.html at this writing, for more), and (c) recent versions show signs of switching to GPLv3, which is completely unusable for open-source work (at this writing, the latest version is at least partially dual-licensed, LGPLv3 or GPLv2, and I don't have the motivation to check it out in full detail). The X11 support handles X over both TCP and AF_LOCAL sockets. However, as far as I know there is no de-jure standard way to transport X over AF_LOCAL sockets; what moussh implements is what the X I have does, which is to use /tmp/.X11-unix/X0, /tmp/.X11-unix/X1, etc, as the paths of sockets for displays :0, :1, etc. If you want to disable AF_LOCAL use, build x.c with -DX11_NO_LOCAL; if you want to disable TCP for some reason, use -DX11_NO_TCP. (I suspect it will not work to enable X support, ie, build without -DNO_X11, but to disable all connection methods, ie, use all the -DX11_NO_* flags. This is not a use case I care much about; if you have reason to think someone does care about it, please let me know.) The language moussh is written in is a slight superset of gcc. I've added labeled control structure to my gcc. On the assumption that you don't have labeled control structure in your gcc, I've provided a conversion program, designed to be run over gcc's preprocessor output, to replace these constructs with semantically equivalent (but signficantly less human-comprehensible) constructs that are valid in stock gcc. The Makefile is designed to do this conversion automatically unless the system looks enough like one of my own (at this writing, this means that uname -r reports "1.4T" and /local/bin/mcsh exists - check the Makefile for the exact details). The conversion program is not suitable for converting all uses of labeled control structure, but it is suitable for use with moussh. moussh also uses nested functions, which are a stock gcc extension to C. They are the major reason you will probably need gcc; I know of no other C(ish) compiler that supports nested functions. (clang/llvm, in their "gcc versus clang/llvm" document, say that nested functions are a little-used feature. I don't know how true that is in general, but it is not true of my code, and it is why clang/llvm is a total nonstarter for my purposes.) Declaration of nested functions is a minor sticky issue. You may want to read the comment in nested.h if you see errors relating to the various nested functions in the code (and possibly add a suitable -D option to your Makefile or other compilation commands). moussh wants to use AF_TIMER sockets. However, it uses them only for relatively minor things. (AF_TIMER sockets are basically a socket interface to timer facilities a la setitimer(). setitimer() supports only a very small number of timers per process - only one, if you want real-time timeouts - and delivers timeouts as signals. AF_TIMER sockets support as many timeouts as you care to create, one per socket, and deliver timeouts as data on the sockets. For related facilities elsewhere, see Linux's timerfd_create() and NetBSD's kqueue's EVFILT_TIMER.) Specifically, here is what it uses them for and how it degrades if they are not available: - The authentication agent uses them for timing out keys which have timeouts. If unavailable: keys never time out. - The user authentication module uses them to provide an overall timeout on the authentication process. If unavailable: there is no overall timeout. - Auto-share mode uses them to implement auto-share-timeout. If unavailable: this timeout never happens. - The interactive agent uses them to avoid printing reprompts which are immediately followed by more agent output. If unavailable: the extra reprompts happen. - The agent code uses them to avoid reusing confirmation tag numbers and client ID numbers too soon after they've been freed up. If unavailable: this holddown doesn't happen, and these numbers may be reused immediately. - The protocol-level keepalive code is driven off them. If unavailable: protocol-level keepalives are unavailable. I consider these all relatively minor things. Furthermore, patches to add AF_TIMER sockets to NetBSD are available for 1.4T, 4.0.1, and 5.2 (via my git daemon), so I do not consider these serious obstacles. moussh autodetects whether AF_TIMER sockets are supported by #including and checking whether AF_TIMER is defined. moussh assumes a Torek stdio, or at least one which has funopen(). For use on Linux (which has the high-level functionality, via fopencookie, but, as usual for Linux, does it in an incompatible way), check out the linux branch in the git repo (and add -llinuxcompat to the dependencies list, above, sibling to -larc4 and -lmd5 and such); for other systems, looking at the Linux changes may give you some clues - if your stdio has no support at all for streams connected to callbacks rather than to file descriptors, you will probably have nontrivial work to do to get moussh working. The Makefile is designed for a Berkeley make. If you don't have one, you may be able to rewrite it to work with your make, or you may have to build things by hand. The Makefile does include a generic Makefile template (local-prog); I've dropped a copy of it in this directory as well, so you quite possibly can use it by running "make -I." to tell make to find it here. The Linux branch includes some attempts at build infrastructure usable with GNU make, which may help. If you want to go the by-hand route, you will need to * Build the various libraries mentioned above. You will either need to put their include files where your compiler expects to find them or will need to add suitable options to the compile steps to make it find them where they are. * Build algs-list.c: ./list-algs.sh -c < alg-lists > algs-list.c * Build algs-list.h: egrep '^(#include|extern)' < algs-list.c > algs-list.h * Build verbose-bits.h, using gen-verbose-bits: cc -o gen-verbose-bits gen-verbose-bits.c ./gen-verbose-bits > verbose-bits.h * At this point you should be able to just compile all the .c files, except gen-verbose-bits.c and lcs-cvt.c, and link the resulting object files together with the libraries. If you're not using the Makefile at all, its code to automatically run lcs-cvt will not take effect, and you'll have to do that by hand. For example, rather than gcc -c bpp.c you will need to do something like gcc -E bpp.c -o _.i ./lcs-cvt _.i gcc -c -o bpp.o _.i This is needed only for source files using labeled control structure; a conservative but easy approximation to `source files using labeled control structure' is `source files containing the string <"'. It's quite possible there are other compilation issues I've not noticed. If you find any such, I'd appreciate hearing about it, so that at the very least I can add a warning to this file (and quite possibly fix them, if they're things I can fix). Here are some such notes: * On some systems, is not a supserset of (as it is on mine). On such systems, you may need to add an #include of to (some of?) the files that #include . This note is an interim measure; I'm thinking about how I want to handle this in the long term. * On NetBSD 3.0 (and possibly other systems), I've been told that there are errors when compiling client.c, stuff like /usr/include/sys/ucred.h:49: error: `NGROUPS' undeclared here (not in a function) /usr/include/sys/proc.h:66: error: `MAXLOGNAME' undeclared here (not in a function) These arise because some include files ( and in the above examples) depend on things from another file (definitions from in the above examples) but take no steps to make sure those things are available. I consider these bugs in the include files, pure and simple. If you run into such problems, my preferred fix is, of course, to go fix those bugs in your include files. If you don't want to do that, you can just add the necessary includes to the moussh source files. At this writing, I know of these cases: in client.c (needed by ) in config.c (needed by ) in writev.c (needed by ) * There is a problem getting uid_t in userauth.h. For me, it comes from , which gets pulled in, indirectly, by bpp.h. This is not sufficient on at least one Debian version. My correspondent writes "I settled for including from userauth.h and defining -D_XOPEN_SOURCE in CC_ADD"; until I figure out something more satisfactory, if you have trouble with uid_t you might start with that. * On Debian (and quite possibly other Linuces), my correspondent writes "I added -D_BSD_SOURCE on principle, since it makes GNU libc act a lot more like BSD than SYSV". If you're using a Linux distro that leans more towards the SV direction than the BSD direction, you might want to try that too. * I have gotten moussh to build on some variant of Linux - something Ubuntu-based, I think (I'm not a Linux geek; the details of distros and how they relate are unclear to me). Have a look at the linux branch in the git repo; while it may not work painlessly for you, it likely will have some of the necessary work already done. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B