git ssb

Files: 9bcb2cdd7a920ebc78b59d0b5797d678424aa93a / README

5988 bytesRaw

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

Built with git-ssb-web

cel / sslh

Tree: 9bcb2cdd7a920ebc78b59d0b5797d678424aa93a

Files: 9bcb2cdd7a920ebc78b59d0b5797d678424aa93a / README

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

cel / sslh

Tree: 9bcb2cdd7a920ebc78b59d0b5797d678424aa93a shsmasterv1.9v1.8v1.7v1.6v1.5v1.3v1.2v1.18v1.17v1.16v1.15v1.14v1.13v1.12v1.11v1.10v1.1v1.0 <input type="submit" value="Go"/>

Files: 9bcb2cdd7a920ebc78b59d0b5797d678424aa93a / README

Tree: 9bcb2cdd7a920ebc78b59d0b5797d678424aa93a