git ssb

1
===== sslh -- A ssl/ssh multiplexer. =====
2
3
sslh accepts HTTP, HTTPS, SSH, OpenVPN, tinc and XMPP
4
connections on the same port. This makes it possible to
5
connect to any of these servers on port 443 (e.g. from
6
inside a corporate firewall, which almost never block port
7
443) while still serving HTTPS on that port. 
8
9
==== Compile and install ====
10
11
If you're lucky, the Makefile will work for you:
12
13
make install
14
15
The Makefile produces two different executables: sslh-fork
16
and sslh-select. 
17
18
sslh-fork forks a new process for each incoming connection.
19
It is well-tested and very reliable, but incurs the overhead
20
of many processes.  sslh-select uses only one thread, which
21
monitors all connections at once. It is more recent and less
22
tested, but only incurs a 16 byte overhead per connection.
23
Also, if it stops, you'll lose all connections, which means
24
you can't upgrade it remotely.
25
26
If you are going to use sslh for a "small" setup (less than
27
a dozen ssh connections and a low-traffic https server) then
28
sslh-fork is probably more suited for you. If you are going
29
to use sslh on a "medium" setup (a few thousand ssh
30
connections, and another few thousand sslh connections),
31
sslh-select will be better. If you have a very large site
32
(tens of thousands of connections), you'll need a vapourware
33
version that would use libevent or something like that.
34
35
36
To install:
37
38
make
39
cp sslh-fork /usr/local/sbin/sslh
40
cp scripts/etc.default.sslh /etc/default/sslh
41
42
For Debian:
43
cp scripts/etc.init.d.sslh /etc/init.d/sslh
44
For CentOS:
45
cp scripts/etc.rc.d.init.d.sslh /etc/rc.d/init.d/sslh
46
47
and probably create links in /etc/rc<x>.d so that the server
48
start automatically at boot-up, e.g. under Debian:
49
update-rc.d sslh defaults
50
51
52
53
==== Configuration ====
54
55
You can edit settings in /etc/default/sslh:
56
57
LISTEN=ifname:443
58
SSH=localhost:22
59
SSL=localhost:443
60
61
A good scheme is to use the external name of the machine in
62
$LISTEN, and bind httpd to localhost:443 (instead of all
63
binding to all interfaces): that way, https connections
64
coming from inside your network don't need to go through
65
sslh, and sslh is only there as a frontal for connections
66
coming from the internet.
67
68
Note that 'external name' in this context refers to the
69
actual IP address of the machine as seen from your network,
70
i.e. that that is not 127.0.0.1 in the output of
71
ifconfig(8).
72
73
==== Libwrap support ====
74
75
Sslh can optionnaly perform libwrap checks for the sshd
76
service: because the connection to sshd will be coming
77
locally from sslh, sshd cannot determine the IP of the
78
client.
79
80
==== OpenVPN support ====
81
82
OpenVPN clients connecting to OpenVPN running with
83
-port-share reportedly take more than one second between
84
the time the TCP connexion is established and the time they
85
send the first data packet. This results in sslh with
86
default settings timing out and assuming an SSH connexion.
87
To support OpenVPN connexions reliably, it is necessary to
88
increase sslh's timeout to 5 seconds.
89
90
Instead of using OpenVPN's port sharing, it is more reliable
91
to use sslh's -o option to get sslh to do the port sharing.
92
93
==== Using proxytunnel with sslh ====
94
95
If you are connecting through a proxy that checks that the
96
outgoing connection really is SSL and rejects SSH, you can
97
encapsulate all your traffic in SSL using proxytunnel (this
98
should work with corkscrew as well). On the server side you
99
receive the traffic with stunnel to decapsulate SSL, then
100
pipe through sslh to switch HTTP on one side and SSL on the
101
other.
102
103
In that case, you end up with something like this:
104
105
ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh --> sshd
106
107
Web browser --------http/ssl------> stunnel ---http---> sslh --> http:80
108
109
Configuration goes like this:
110
111
On the server side, using stunnel3:
112
stunnel -f -p mycert.pem  -d thelonious:443 -l /usr/local/sbin/sslh -- sslh -i  --ssl localhost:80 --ssh localhost:22
113
114
stunnel options: -f for foreground/debugging, -p specifies
115
the key + certificate, -d specifies which interface and port
116
we're listening to for incoming connexions, -l summons sslh
117
in inetd mode.
118
119
sslh options: -i for inetd mode, --ssl to forward SSL
120
connexions (in fact normal HTTP at that stage) to port 80,
121
and SSH connexions to port 22. This works because sslh
122
considers that any protocol it doesn't recognise is SSL.
123
124
==== IP_TPROXY support ====
125
126
There is a netfilter patch that adds an option to the Linux
127
TCP/IP stack to allow a program to set the source address
128
of an IP packet that it sends. This could let sslh set the
129
address of packets to that of the actual client, so that
130
sshd would see and log the IP address of the client, making
131
sslh transparent.
132
133
This is not, and won't be, implemented in sslh for the
134
following reasons (in increasing order of importance):
135
136
  * It's not vital: the real connecting IP address can be
137
    found in logs. Little gain.
138
  * It's Linux only: it means increased complexity for no
139
    gain to some users.
140
  * It's a patch: it means it'd only be useful to Linux
141
    users who compile their own kernel.
142
  * Only root can use the feature: that's a definite no-no.
143
    Sslh should not, must not, will never run as root.
144
145
This isn't to mean that it won't eventually get implemented,
146
when/if the feature finds its way into the main kernel and
147
it becomes usuable by non-root processes.
148
149
150
==== Comments? Questions? ====
151
152
You can subscribe to the sslh mailing list here:
153
http://rutschle.net/cgi-bin/mailman/listinfo/sslh
154
155
This mailing list should be used for discussion, feature
156
requests, and will be the prefered channel for
157
announcements.
158
159