In this brief tutorial, we will see what is SSLH, how to install SSLH and how to configure SSLH to share a same port for https and ssh in Linux and Unix-like operating systems.
Table of Contents
What is SSLH?
Some Internet service providers and corporate companies might have blocked most of the ports, and allowed only a few specific ports such as port 80 and 443 to tighten their security.
In such cases, we have no choice, but use a same port for multiple programs, say the HTTPS Port 443, which is rarely blocked. Here is where SSLH, a SSL/SSH multiplexer, comes in help.
SSLH will listen for incoming connections on a port 443. To put this more simply, SSLH allows us to run several programs or services on port 443 on a Linux system. So, you can use both SSL and SSH using a same port at the same time.
If you ever been in a situation where most ports are blocked by the firewalls, you can use SSLH to access your remote server.
Install SSLH in Linux
SSLH is packaged for most Linux distributions, so you can install it using the default package managers.
On Debian, Ubuntu, Linux Mint and Pop OS, run:
$ sudo apt install sslh
While installing SSLH, you will prompted whether you want to run sslh as a service from inetd, or as a standalone server.
Each choice has its own benefits. With only a few connection per day, it is probably better to run sslh from inetd in order to save resources.
On the other hand, with many connections, sslh should run as a standalone server to avoid spawning a new process for each incoming connection.
On Arch Linux and derivatives like Antergos, Manjaro Linux, install it using Pacman as shown below.
$ sudo pacman -S sslh
On RHEL, CentOS, AlmaLinux and Rocky Linux, you need to add EPEL repository and then install SSLH as shown below.
$ sudo dnf install epel-release
$ sudo dnf install sslh
On Fedora:
$ sudo dnf install sslh
If it is not available on default repositories, you can manually compile and install SSLH as described here.
Configure Apache or Nginx webservers
As you already know, Apache and Nginx webservers will listen on all network interfaces (i.e 0.0.0.0:443
) by default. We need to change this setting to tell the webserver to listen on the localhost interface only (i.e. 127.0.0.1:443
or localhost:443
).
To do so, edit the webserver (nginx or apache) configuration file and find the following line:
listen 443 ssl;
And, change it to:
listen 127.0.0.1:443 ssl;
If you’re using Virutalhosts in Apache, make sure you have changed that it too.
VirtualHost 127.0.0.1:443
Save and close the config files. Do not restart the services. We haven't finished yet.
Configure SSLH
Once you have made the webservers to listen on local interface only, edit SSLH config file:
$ sudo vi /etc/default/sslh
Find the following line:
Run=no
And, change it to:
Run=yes
Then, scroll a little bit down and modify the following line to allow SSLH to listen on port 443 on all available interfaces (Eg. 0.0.0.0:443
).
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"
Where,
--user sslh
: Requires to run under this specified username.--listen 0.0.0.0:443
: SSLH is listening on port443
on all available interfaces.--sshs 127.0.0.1:22
: Route SSH traffic to port22
on the localhost.--ssl 127.0.0.1:443
: Route HTTPS/SSL traffic to port443
on the localhost.
Save and close the file.
Finally, enable and start sslh
service to update the changes.
$ sudo systemctl enable sslh
$ sudo systemctl start sslh
Testing
Check if the SSLH daemon is listening to 443
.
$ ps -ef | grep sslh sslh 2746 1 0 15:51 ? 00:00:00 /usr/sbin/sslh --foreground --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 sslh 2747 2746 0 15:51 ? 00:00:00 /usr/sbin/sslh --foreground --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 sk 2754 1432 0 15:51 pts/0 00:00:00 grep --color=auto sslh
Now, you can access your remote server via SSH using port 443
:
$ ssh -p 443 sk@192.168.225.50
Sample output:
sk@192.168.225.50's password: Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-55-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage System information as of Wed Aug 14 13:11:04 IST 2019 System load: 0.23 Processes: 101 Usage of /: 53.5% of 19.56GB Users logged in: 0 Memory usage: 9% IP address for enp0s3: 192.168.225.50 Swap usage: 0% IP address for enp0s8: 192.168.225.51 * Keen to learn Istio? It's included in the single-package MicroK8s. https://snapcraft.io/microk8s 61 packages can be updated. 22 updates are security updates. Last login: Wed Aug 14 13:10:33 2019 from 127.0.0.1
See? I can now be able to access the remote server via SSH even if the default SSH port 22
is blocked. As you see in the above example, I have used the https port 443
for SSH connection. Also, we can use the same port 443
for openVPN connections too.
Conclusion
I tested SSLH on my Ubuntu 18.04 LTS server and it worked just fine as described above. I tested SSLH in a protected local area network, so I am not yet aware of the security issues. If you're using it in production, let us know the advantages and disadvantages of using SSLH in the comment section below.
For more details, check the official GitHub page given below.
Resource:
Suggested read:
- How To SSH Into A Particular Directory On Linux
- How To Create SSH Alias In Linux
- How To Configure SSH Key-based Authentication In Linux
- How To Stop SSH Session From Disconnecting In Linux
- Allow Or Deny SSH Access To A Particular User Or Group In Linux
- 4 Ways To Keep A Command Running After You Log Out Of The SSH Session
- ScanSSH – Fast SSH Server And Open Proxy Scanner
3 comments
Okay, this is admittedly a clever work around if port availability is limited.. However, this sounds risky in terms of security. What new and interesting security issues may arise from a protocol multiplexer? Who knows? —and that right limits the usefulness of this until someone takes the time to audit the code.
I connect to an openVPN server configured to run on 443 (login in with SSL cert + user auth). From there on I can connect to any of my servers over SSH. I have found this solution to work in many public WiFi hotspots. No experience with Enterprise networks, they may blacklist the IP numbers of public VPN providers.
That did not work for me. The reason is that by telling sslh to listen on 0.0.0.0:443, it listening on ALL interfaces including 127.0.0.1:443 which ssl already uses.
The work around I did is to use the actual IP of my server instead of 0.0.0.0. That option might not be optional on servers with dynamic IP. So another solution is to change the port that ssl is listening on to something else then 443.