doc/INSTALL.md
Docker images of master and of the tagged versions are
available directly from Github.
Windows binaries for Cygwin are graciously produced by nono303 on his repository.
sslh uses:
libconfig.
For Debian this is contained in package libconfig-dev.
You can compile with or without it using USELIBCONFIG in the Makefile.
libwrap.
For Debian, this is contained in packages libwrap0-dev.
Presence of libwrap is checked by the configure script.
libsystemd, in package libsystemd-dev.
You can compile with or without it using USESYSTEMD in the Makefile.
libcap, in package libcap-dev.
Presence of libcap is checked by the configure script.
libconfig++-dev, in package lìbconfig++-dev
libbsd, to enable to change the process name (as shown in ps,
so each forked process shows what protocol and what connection it is serving),
which requires libbsd at runtime, and libbsd-dev at compile-time.
Presence of libbsd is checked by the configure script.
libpcre2, in package libpcre2-dev.
You can compile with or without it using ENABLE_REGEX in the Makefile.
libev-dev, in package libev-dev.
If you build a binary specifically and do not build sslh-ev, you don't need this.
libproxyprotocol to support HAProxy's ProxyProtocol. As this is not part of the distribution packages, set C_INCLUDE_PATH, LD_LIBRARY_PATH, and LIBRARY_PATH to the appropriate values:
export C_INCLUDE_PATH=/home/user/src/libproxyprotocol/src
export LD_LIBRARY_PATH=/home/user/src/libproxyprotocol/libs
export LIBRARY_PATH=/home/user/src/libproxyprotocol/libs
For OpenSUSE, these are contained in packages libconfig9 and libconfig-dev in repository http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_12.1/
For Fedora, you'll need packages libconfig and libconfig-devel:
yum install libconfig libconfig-devel
If you want to rebuild sslh-conf.c (after a make distclean for example),
you will also need to add conf2struct
(v1.5) to your path.
The test scripts are written in Perl, and will require
IO::Socket::INET6 (libio-socket-inet6-perl in Debian).
First you have to run ./configure in the ./sslh directory. After this,
the Makefile is created, and you can do your configuration changes in the Makefile.
After each run of ./configure, those changes are gone and the Makefile is recreated.
There are a couple of configuration options at the beginning of the Makefile:
# override undefine HAVE_LANDLOCK if you uncomment this line, sslh will be compiled
without landlock. This works with gcc versions < 12. Otherwise, if your system has
linux/landlock.h in the include path, the configure script creates a config.h file,
which defines HAVE_LANDLOCK. It is not enough, to set this to 0, you must delete it,
when you don't wish to have landlock in your binary.
USELIBWRAP compiles support for host access control (see hosts_access(3)),
you will need libwrap headers and library to compile (libwrap0-dev in Debian).
USELIBCONFIG compiles support for the configuration file.
You will need libconfig headers to compile (libconfig8-dev in Debian).
USESYSTEMD compiles support for using systemd socket activation.
You will need systemd headers to compile (systemd-devel in Fedora).
USELIBBSD compiles support for updating the process name (as shown by ps).
USELIBCAP compiles support for libcap, which allows to inherit capabilities to
daughter-processes, which run as restricted users. You need this, when you wish to
make sure, that the --user= parameter can be used, without setting capabilities etc.
to your binaries, to make this work.
Now you can do either a plain make to create the binaries, or you can do an
make install to create the binaries and install them.
The configuration file and command line parser is generated by conf2struct,
from sslhconf.cfg, which generates sslh-conf.c and sslh-conf.h.
The resulting files are included in the source
so sslh can be built without conf2struct installed.
Further, to prevent build issues,
sslh-conf.[ch] has no dependency to sslhconf.cfg in the Makefile.
In the event of adding configuration settings,
they need to be regenerated using make c2s.
The Makefile produces three different executables:
sslh-fork, sslh-select and sslh-ev:
sslh-fork forks a new process for each incoming connection.
It is well-tested and very reliable, but incurs the overhead of many processes.
If you are going to use sslh for a "small" setup
(less than a dozen ssh connections and a low-traffic https server)
then sslh-fork is probably more suited for you.
sslh-select uses only one thread, which monitors all connections at once.
It only incurs a 16 byte overhead per connection.
Also, if it stops, you'll lose all connections,
which means you can't upgrade it remotely.
If you are going to use sslh on a "medium" setup (a few hundreds of connections),
or if you are on a system where forking is expensive (e.g. Windows),
sslh-select will be better.
sslh-ev is similar to sslh-select, but uses libev as a backend.
This allows using specific kernel APIs that
allow to manage thousands of connections concurrently.
./configure
make
cp sslh-fork /usr/local/sbin/sslh
cp basic.cfg /etc/sslh.cfg
vi /etc/sslh.cfg
cp scripts/etc.init.d.sslh /etc/init.d/sslh
cp scripts/etc.rc.d.init.d.sslh.centos /etc/rc.d/init.d/sslh
You might need to create links in /etc/rc<x>.d so that the server
start automatically at boot-up, e.g. under Debian:
update-rc.d sslh defaults