git ssb

0+

cel / sslh



Tree:
📄ChangeLog
📄Makefile
📄README
📄README.MacOSX
📄basic.cfg
📄common.c
📄common.h
📄echosrv.c
📄example.cfg
📄probe.c
📄probe.h
📁scripts
📄sslh-fork.c
📄sslh-main.c
📄sslh-select.c
📄sslh.pod
📄t
📄t_load
README
1===== sslh -- A ssl/ssh multiplexer. =====
2
3Sslh accepts connections on specified ports, and forwards
4them further based on tests performed on the first data
5packet sent by the remote client.
6
7Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are
8implemented, and any other protocol that can be tested using
9a regular expression, can be recognised. A typical use case
10is to allow serving several services on port 443 (e.g. to
11connect to ssh from inside a corporate firewall, which
12almost never block port 443) while still serving HTTPS on
13that port.
14
15Hence sslh acts as a protocol demultiplexer, or a
16switchboard. Its name comes from its original function to
17serve SSH and HTTPS on the same port.
18
19==== Compile and install ====
20
21sslh uses libconfig (http://www.hyperrealm.com/libconfig/)
22and libwrap.
23
24For Debian, these are contained in packages libwrap0-dev and
25libconfig8-dev.
26
27For OpenSUSE, these are contained in packages libconfig9 and
28libconfig-dev in repository
29http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_12.1/
30
31For Fedora, this package should work:
32https://admin.fedoraproject.org/pkgdb/acls/name/libconfig
33(feedback from Fedorans appreciated).
34
35If you can't find libconfig, or just don't want a
36configuration file, set 'USELIBCONFIG=' in the Makefile.
37
38After this, the Makefile should work:
39
40make install
41
42There are a couple of configuration options at the beginning
43of the Makefile:
44
45 USELIBWRAP compiles support for host access control (see
46 hosts_access(3)), you will need libwrap headers and
47 library to compile (libwrap0-dev in Debian).
48
49 USELIBCONFIG compiles support for the configuration
50 file. You will need libconfig headers to compile
51 (libconfig8-dev in Debian).
52
53The Makefile produces two different executables: sslh-fork
54and sslh-select.
55
56sslh-fork forks a new process for each incoming connection.
57It is well-tested and very reliable, but incurs the overhead
58of many processes. sslh-select uses only one thread, which
59monitors all connections at once. It is more recent and less
60tested, but only incurs a 16 byte overhead per connection.
61Also, if it stops, you'll lose all connections, which means
62you can't upgrade it remotely.
63
64If you are going to use sslh for a "small" setup (less than
65a dozen ssh connections and a low-traffic https server) then
66sslh-fork is probably more suited for you. If you are going
67to use sslh on a "medium" setup (a few thousand ssh
68connections, and another few thousand ssl connections),
69sslh-select will be better. If you have a very large site
70(tens of thousands of connections), you'll need a vapourware
71version that would use libevent or something like that.
72
73
74To install:
75
76make
77cp sslh-fork /usr/local/sbin/sslh
78cp scripts/etc.default.sslh /etc/default/sslh
79
80For Debian:
81cp scripts/etc.init.d.sslh /etc/init.d/sslh
82For CentOS:
83cp scripts/etc.rc.d.init.d.sslh /etc/rc.d/init.d/sslh
84
85and probably create links in /etc/rc<x>.d so that the server
86start automatically at boot-up, e.g. under Debian:
87update-rc.d sslh defaults
88
89
90
91==== Configuration ====
92
93You can edit settings in /etc/default/sslh:
94
95LISTEN=ifname:443
96SSH=localhost:22
97SSL=localhost:443
98
99A good scheme is to use the external name of the machine in
100$LISTEN, and bind httpd to localhost:443 (instead of all
101binding to all interfaces): that way, https connections
102coming from inside your network don't need to go through
103sslh, and sslh is only there as a frontal for connections
104coming from the internet.
105
106Note that 'external name' in this context refers to the
107actual IP address of the machine as seen from your network,
108i.e. that that is not 127.0.0.1 in the output of
109ifconfig(8).
110
111==== Libwrap support ====
112
113Sslh can optionnaly perform libwrap checks for the sshd
114service: because the connection to sshd will be coming
115locally from sslh, sshd cannot determine the IP of the
116client.
117
118==== OpenVPN support ====
119
120OpenVPN clients connecting to OpenVPN running with
121-port-share reportedly take more than one second between
122the time the TCP connexion is established and the time they
123send the first data packet. This results in sslh with
124default settings timing out and assuming an SSH connexion.
125To support OpenVPN connexions reliably, it is necessary to
126increase sslh's timeout to 5 seconds.
127
128Instead of using OpenVPN's port sharing, it is more reliable
129to use sslh's -o option to get sslh to do the port sharing.
130
131==== Using proxytunnel with sslh ====
132
133If you are connecting through a proxy that checks that the
134outgoing connection really is SSL and rejects SSH, you can
135encapsulate all your traffic in SSL using proxytunnel (this
136should work with corkscrew as well). On the server side you
137receive the traffic with stunnel to decapsulate SSL, then
138pipe through sslh to switch HTTP on one side and SSL on the
139other.
140
141In that case, you end up with something like this:
142
143ssh -> proxytunnel -e --------ssh/ssl------> stunnel ---ssh---> sslh --> sshd
144
145Web browser --------http/ssl------> stunnel ---http---> sslh --> http:80
146
147Configuration goes like this:
148
149On the server side, using stunnel3:
150stunnel -f -p mycert.pem -d thelonious:443 -l /usr/local/sbin/sslh -- sslh -i --http localhost:80 --ssh localhost:22
151
152stunnel options: -f for foreground/debugging, -p specifies
153the key + certificate, -d specifies which interface and port
154we're listening to for incoming connexions, -l summons sslh
155in inetd mode.
156
157sslh options: -i for inetd mode, --http to forward http
158connexions to port 80, and SSH connexions to port 22.
159
160==== capapbilities support ====
161
162On Linux (only?), you can use POSIX capabilities to reduce a
163server's capabilities to the minimum it needs (see
164capabilities(8). For sslh, this is CAP_NET_ADMIN (to
165perform transparent proxy-ing) and CAP_NET_BIND_SERVICE (to
166bind to port 443 without being root).
167
168The simplest way to use capabilities is to give them to the
169executable as root:
170
171# setcap cap_net_bind_service,cap_net_admin+pe sslh-select
172
173Then you can run sslh-select as an unpriviledged user, e.g.:
174
175$ sslh-select -p myname:443 --ssh localhost:22 --ssl localhost:443
176
177This has 2 advantages over starting as root with -u:
178- You no longer start as root (duh)
179- This enables transparent proxying.
180
181Caveat: CAP_NET_ADMIN does give sslh too many rights, e.g.
182configuring the interface. If you're not going to use
183transparent proxying, just don't use it.
184
185==== Transparent proxy support ====
186
187On Linux (only?) you can use the --transparent option to
188request transparent proying. This means services behind sslh
189(Apache, sshd and so on) will see the external IP and ports
190as if the external world connected directly to them. This
191simplifies IP-based access control (or makes it possible at
192all).
193
194sslh needs extended rights to perform this: you'll need to
195give it cap_net_admin capabilities (see appropriate chapter)
196or run it as root (but don't do that).
197
198The firewalling tables also need to be adjusted as follow
199(example to connect to https on 4443 -- adapt to your needs
200(I don't think it is possible to have httpd listen to 443 in
201this scheme -- let me know if you manage that))):
202
203# iptables -t mangle -N SSLH
204# iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 22 --jump SSLH
205# iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 4443 --jump SSLH
206# iptables -t mangle -A SSLH --jump MARK --set-mark 0x1
207# iptables -t mangle -A SSLH --jump ACCEPT
208# ip rule add fwmark 0x1 lookup 100
209# ip route add local 0.0.0.0/0 dev lo table 100
210
211This will only work if sslh does not use any loopback
212addresses (no 127.0.0.1 or localhost), you'll need to use
213explicit IP addresses (or names):
214
215sslh --listen 192.168.0.1:443 --ssh 192.168.0.1:22 --ssl 192.168.0.1:4443
216
217This will not work:
218sslh --listen 192.168.0.1:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:4443
219
220==== Comments? Questions? ====
221
222You can subscribe to the sslh mailing list here:
223http://rutschle.net/cgi-bin/mailman/listinfo/sslh
224
225This mailing list should be used for discussion, feature
226requests, and will be the prefered channel for
227announcements.
228
229

Built with git-ssb-web