Tunnel SSH Connections Over SSL Using ‘Stunnel’ On Debian 7 / Ubuntu 13.10

Tunnel SSH Connections Over SSL Using ‘Stunnel’ On Debian 7 / Ubuntu 13.10

6877
 

stunnel is designed to work as an SSL encryption wrapper between remote client and local (inetd-startable) or remote server. It can be used to add SSL functionality to commonly used inetd daemons like POP2, POP3, and IMAP servers without any changes in the programs code. Stunnel uses the OpenSSL library for cryptography, so it supports whatever cryptographic algorithms are compiled into the library. In simple words, stunnel can be used to turn any insecure port to a secure encrypted port.

In this tutorial, i will describe how to tunnel SSH over SSL using stunnel. The setup is pretty simple. You’ll need stunnel installed on both your client PC and a remote PC with sshd already running.

I am using two systems as mentioned below.

Remote System:

Operating System: Debian 7
IP address: 192.168.1.200/24

Client(Local) System:

Operating system: Ubuntu 13.04 desktop
IP address: 192.168.1.100/24

Configure Remote System

 

Let us install stunnel package in our remote Debian 7 server.

# apt-get install stunnel4

Now let us create a SSL certificate as shown below.

# openssl genrsa 1024 > stunnel.key

Sample output:

Generating RSA private key, 1024 bit long modulus
............................................++++++
...................++++++
e is 65537 (0x10001)
# openssl req -new -key stunnel.key -x509 -days 1000 -out stunnel.crt

You will be asked to answer for a couple of questions such as Country, State, company details etc.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:IN
State or Province Name (full name) [Some-State]:Tamilnadu
Locality Name (eg, city) []:Erode
Organization Name (eg, company) [Internet Widgits Pty Ltd]:unixmen
Organizational Unit Name (eg, section) []:Technical
Common Name (e.g. server FQDN or YOUR name) []:server.unixmen.com
Email Address []:sk@unixmen.com
# cat stunnel.crt stunnel.key > stunnel.pem
# mv stunnel.pem /etc/stunnel/

Now we have to configure stunnel to tunnel 443(https) to 22(ssh). This can be done by creating a new file stunnel.conf under /etc/stunnel/ directory:

 # vi /etc/stunnel/stunnel.conf

Add the following lines:

pid = /var/run/stunnel.pid
cert = /etc/stunnel/stunnel.pem
[ssh]
accept = 192.168.1.200:443
connect = 127.0.0.1:22

The above lines says stunnel that where to look for the certificate file and where to accept and forward ssh connections. In our case, stunnel will accept the incoming traffic on port 443 and forward it back to port 22.

Save and close the file.

Now let us enable stunnel service. To do that, edit file /etc/default/stunnel4:

# vi /etc/default/stunnel4

Change the line Enabled = 0 to 1.

# /etc/default/stunnel
# Julien LEMOINE <speedblue@debian.org>
# September 2003

# Change to one to enable stunnel automatic startup
ENABLED=1
FILES="/etc/stunnel/*.conf"
OPTIONS=""

# Change to one to enable ppp restart scripts
PPP_RESTART=0

Then start stunnel service with command:

# service stunnel4 start

Configure Local System

Install stunnel with command:

$ sudo apt-get install stunnel4

We need the same certificate file(stunnel.pem) from the remote system. Copy the remote system stunnel.pem file to our local system and save it in the same location(i.e /etc/stunnel).

creating a new file stunnel.conf under /etc/stunnel/ directory:

$ sudo vi /etc/stunnel/stunnel.conf

Add the following lines:

pid = /var/run/stunnel.pid
cert = /etc/stunnel/stunnel.pem
client=yes
[ssh]
accept=443
connect=192.168.1.200:443

Save and close the file. Here 192.168.1.200 is our remote system IP.

Now let us enable stunnel service. To do that, edit file /etc/default/stunnel4:

$ sudo vi /etc/default/stunnel4

Change the line Enabled = 0 to 1.

# /etc/default/stunnel
# Julien LEMOINE <speedblue@debian.org>
# September 2003

# Change to one to enable stunnel automatic startup
ENABLED=1
FILES="/etc/stunnel/*.conf"
OPTIONS=""

# Change to one to enable ppp restart scripts
PPP_RESTART=0

Then start stunnel service with command:

$ sudo service stunnel4 start

Test SSH connection

Now we’re good to go. You’ll be able to connect to your remote machine using command:

$ ssh sk@localhost -v -p 443

Sample output:

OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 443.
debug1: Connection established.
debug1: identity file /home/sk/.ssh/id_rsa type -1
debug1: identity file /home/sk/.ssh/id_rsa-cert type -1
debug1: identity file /home/sk/.ssh/id_dsa type -1
debug1: identity file /home/sk/.ssh/id_dsa-cert type -1
debug1: identity file /home/sk/.ssh/id_ecdsa type -1
debug1: identity file /home/sk/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 78:05:ba:1b:73:02:75:86:10:33:8c:0f:21:61:d4:de
debug1: Host '[localhost]:443' is known and matches the ECDSA host key.
debug1: Found key in /home/sk/.ssh/known_hosts:12
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/sk/.ssh/id_rsa
debug1: Trying private key: /home/sk/.ssh/id_dsa
debug1: Trying private key: /home/sk/.ssh/id_ecdsa
debug1: Next authentication method: password
sk@localhost's password: #   ## Enter your remote system user password
debug1: Authentication succeeded (password).
Authenticated to localhost ([127.0.0.1]:443).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_PAPER = en_IN.UTF-8
debug1: Sending env LC_ADDRESS = en_IN.UTF-8
debug1: Sending env LC_MONETARY = en_IN.UTF-8
debug1: Sending env LC_NUMERIC = en_IN.UTF-8
debug1: Sending env LC_TELEPHONE = en_IN.UTF-8
debug1: Sending env LC_IDENTIFICATION = en_IN.UTF-8
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_MEASUREMENT = en_IN.UTF-8
debug1: Sending env LC_TIME = en_IN.UTF-8
debug1: Sending env LC_NAME = en_IN.UTF-8
Linux server 3.2.0-4-486 #1 Debian 3.2.51-1 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Mon Dec 30 15:12:22 2013 from localhost
sk@server:~$

Or you can simply use the command:

$ ssh -p 443 sk@localhost

Sample output:

sk@localhost's password: 
Linux server 3.2.0-4-486 #1 Debian 3.2.51-1 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Mon Dec 30 15:22:08 2013 from localhost
sk@server:~$

Now you’ll be able to make ssh connection to your remote system, but all the traffic tunneled through SSL.

You’re done now! You can SSH to your remote system even when the ssh default 22 is blocked by any firewall.

0 (0)
Article Rating (No Votes)
Rate this article
Attachments
There are no attachments for this article.
Comments
There are no comments for this article. Be the first to post a comment.
Full Name
Email Address
Security Code Security Code
Related Articles RSS Feed
RHEL: How to change a USER/GROUP UID/GID and all owned files
Viewed 19950 times since Sat, Jun 2, 2018
LVM: Move allocated PE between Physical Volumes
Viewed 3545 times since Sat, Jun 2, 2018
Enabling automatic updates in Centos 7 and RHEL 7
Viewed 2212 times since Wed, Oct 17, 2018
www.unixarena.com
Viewed 2175 times since Fri, Jul 27, 2018
LVM: Reduce an existing Logical Volume / Filesystem
Viewed 3327 times since Sat, Jun 2, 2018
RHCS6: Basic operations on clustered services
Viewed 2388 times since Sun, Jun 3, 2018
Install Security Patches or Updates Automatically on CentOS and RHEL
Viewed 1507 times since Fri, Oct 26, 2018
6 rsync Examples to Exclude Multiple Files and Directories using exclude-from
Viewed 4374 times since Wed, Oct 31, 2018
Red Hat Cluster Tutorial
Viewed 1820 times since Sun, Jun 3, 2018
How To Run Multiple SSH Command On Remote Machine And Exit Safely
Viewed 3660 times since Tue, Aug 6, 2019