Multi Service Usage via Single Port
If you have a single available IP address and want to use more than one application using the same port on this IP address, using software that can distinguish packets based on protocol header information on a single port will solve the problem. SSHL is a software developed for this purpose. SSHL listens to a port you specify and examines the connection requests coming to this port, determines which protocol the request belongs to, and then directs the connection to the relevant service.
In this way, you can provide HTTPS, OpenVPN and SSH services simultaneously over TCP 443, for example. This article contains detailed information about SSLH, which is a very useful tool for some situations, including installation, configuration and tests.
What is SSHL?
SSLH, which can detect HTTP, SSL, SSH, OpenVPN, TINC, It has shape. In this way, for example, SSLH can be used to access a server with only TCP 80 and 443 through the firewall via SSH. In other words, you can use SSLH to access a system that is behind the firewall and does not have access to the SSH port, through a port that is (probably) not blocked by the firewall, such as 443.
Working Principle
Adhering to the example we gave, let's assume that we will run SSLH over 443 and provide SSH service with HTTPS. In this scenario, we configure SSLH to listen to port 443 of the network interface we want to use - as I will explain the details in the configuration section. Afterwards, we set the HTTPS service to listen to localhost:443 and the SSH service to listen to localhost:22, and run the application by telling SSLH that HTTPS is at 127.0.0.1 443 and SSH is at 127.0.0.1 22.
In this way, SSH connections coming to the relevant host are directed to port 22, while HTTPS connections are directed to localhost port 443. So SSLH acts as a proxy. How the application distinguishes the services is as follows:
Protocol Detection
sslh basically tries to detect the connection protocol by reading the first few bytes of incoming connection requests. For example, in SSH connections, the first thing that happens between the server and the client is that the two ends inform each other of their SSH versions in plain-text as 'SSH-x.0'. In order to determine whether the connection is SSH or not, SSLH looks for the "SSH-" string in the first packets and if it finds it, it directs the connection to the port of the relevant service. For HTTPS traffic, it similarly checks whether ClientHello (0×16) and TLS version information (0×0301) are present at the beginning of the traffic.
For other protocols, for example, "jabber" in the XMPP test, "HTTP" for HTTP traffic, or OPTIONS, GET etc. if the version is not specified. It redirects by checking whether there are methods like this.
SSLH uses a default timeout period of 2 seconds for traffic detection. If the protocol cannot be detected during this period, the traffic is directed to the first protocol specified in the configuration file (SSH in the default installation). For example, this timeout mechanism is important because SSH connection coming from a client that does not report version information to the server cannot be detected by SSLH.
Installation and Configuration
sslh has precompiled packages for RHEL, Debian and FreeBSD-based systems and can be installed via the package managers of the relevant systems. However, since it is very easy to install it by compiling it from the source code, I will talk about how to install it this way.
Requirements
It needs sslh, libconfig and libwrap packages; Therefore, you need to install these packages on your system first. For this process, follow the steps below:
Debian/Ubuntu based systems:
# apt-get install libwrap0-dev libconfig8-dev
RHEL/CentOS based systems:
# yum install libconfig libconfig-devel
Thus, the system becomes ready for SSLH installation.
Installation from Source Code
Now, we will download sslh from http://www.rutschle.net/tech/sslh.shtml. Current latest version is 1.16:
# wget http://www.rutschle.net/tech/sslh-v1.16.tar.gz
Then, we open the package and perform the installation:
# tar xvfz sslh-v1.16.tar.gz
# cd sslh-v1.16
#makeinstall
When you click make install, two different sslh versions named sslh-fork and sslh-select are created in the relevant directory.
The first version, sslh-fork, creates a new sslh process with each new connection request. Since this version is well tested and stable, it is copied to the system under the name /usr/local/sbin/sslh during installation and used by default. However, this version causes a large number of processes to be created for servers that receive a lot of requests and uses system resources at this rate. It may not be ideal in this sense to accommodate too many connections.
The second version, sslh-select, is a less tested and new version of sslh, but it handles all connections through a single process and each connection costs only 16 bytes of system resources. However, if sslh somehow goes down and you are using it for ssh, your remote access to the server may be cut off. If you still want to use this version, you can copy it to the /usr/local/sbin/ directory with the name sslh.
Configuration
Now, first of all, we will copy the init script in the scripts directory under init.d with the name sslh and add the sslh service to the startup:
Debian/Ubuntu Systems:
# cp scripts/etc.init.d.sslh /etc/init.d/sslh
# update-rc.d sslh defaults
RHEL/CentOS Systems:
# cp scripts/etc.init.d.sslh /etc/init.d/sslh
# chkconfig sslh on
On RHEL systems, we also update the “PREFIX=” line in the /etc/init.d/sslh file as follows:
PREFIX=/usr/local
Main Configuration
Now we will move on to the main configuration settings. The main configuration file for sslh is /etc/default/sslh. This file differs in Debian and RHEL systems, although the logic is the same. That's why I'll talk about both separately.
Debian/Ubuntu Systems:
The content of the relevant file is as follows and the fields that need to be edited are marked in bold and red:
# Default options for sslh initscript
# sourced by /etc/init.d/sslh
# Disabled by default, to force yourself
# to read the configuration:
# - /usr/share/doc/sslh/README.Debian (quick start)
# - /usr/share/doc/sslh/README, at "Configuration" section
# - sslh(8) via "man sslh" for more configuration details.
# Once configuration ready, you *must* set RUN to yes here
# and try to start sslh (standalone mode only)
RUN=no
# binary to use: forked (sslh) or single-thread (sslh-select) version
DAEMON=/usr/sbin/sslh
DAEMON_OPTS="--user sslh --listen 0.0.0.0:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:443 --pidfile /var/run/sslh/sslh.pid"
First, we set the RUN section to “yes”.
RUN=yes
–listen 0.0.0.0:443 section is where it is determined which port SSLH will listen on which IP. Here we will bind sslh to the real ip of our system, for example, if your ip address is 1.1.1.1, we set this field as 1.1.1.1:443:
Note: At this point, you should remember to configure your web server to serve only over 127.0.0.1 for port 443. Otherwise, your web server will give an error because port 443 is in use by SSLH.
–ssh 127.0.0.1:22 means that ssh requests coming via 443 should be redirected to 127.0.0.1:22.
–ssl 127.0.0.1:443, on the other hand, means that SSL/TLS connections are assigned to 127.0.0.1:443, with the same logic.
After completing the changes, we start sslh:
# /etc/init.d/sslh start
RHEL/CentOS Systems
In RHEL-based systems, the logic is the same, but the configuration file is as follows:
LISTEN=ifname:443
SSH=localhost:22
SSL=localhost:443
USER=nobody
PID=/var/run/sslh.pid
At the top of this file, we specify which IP and port SSLH will serve on, and as I mentioned above, we set this field as the external IP of our system. For example, if your IP address is 1.1.1.1, we set this field as 1.1.1.1:443:
LISTEN=1.1.1.1:443
Note: At this point, you should remember to configure your web server to serve only over 127.0.0.1 for port 443. Otherwise, your web server will give an error because port 443 is in use by SSLH.
Afterwards, we leave the relevant parts as they are to provide ssh and ssl services over localhost 22 and 443, as detailed in the Debian systems section.
Finally, let's start the service:
# /etc/init.d/sslh start
Yes, this is how the installation and configuration part is completed. Now let's test the system:
Test
The service is currently running and when we look at it with netstat, we get an output like the following:
# netstat -antp |grep LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1522/sshd
tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN 1794/httpd
tcp 0 0 1.1.1.1:443 0.0.0.0:* LISTEN 1780/sslh
As you can see, while sslh is listening to 1.1.1.1:443, httpd is listening to 127.0.0.1:443 as it should be, and ssh is serving via 0.0.0.0:22.
Now, if you establish an SSH connection to 1.1.1.1 from outside, SSLH will receive the request and forward it to the SSH service.
For all the details, you can check out https://github.com/yrutschle/sslh.
