Next Previous Contents

30. SSH Terminal, FTP, X-windows, and tunnel encryption

30.1 What is SSH and the differences between SSH protocol v1 and v2

SSH is both a protocol and a program suite that allows for TELNET-like CLI communications, FTP, and the ability to create VPN connections while having all of it ENCRYPTED. For me, I always use SSH because if I was to login with non-encrypted programs like TELNET, FTP, POP-3, etc., all of my username/passwords (and all following traffic) would go over the Internet in CLEAR-TEXT. * THIS IS BAD! * What's even cooler is you can actually use SSH to encrypt NON-secure systtems like TELNET and POP3 if need be.

So why is non-encryted communications bad? For example, say some evil person was between your local machine and your POP-3 server. If they were to sniffing the traffic, not only would they be able to get your username / password but also get all of your transmitted email too! Now you might be thinking this is paranoid thinking but securing your connections isn't hard and you should be better safe than sorry.

Using SSH, ALL traffic is encrypted. Plus.. it can actually ease the setup of remote Xwindows connection and even speed things up with the use of built-in SSH compression!

NOTE: SSH comes in two flavors and two versions. SSH protocol Version 1 and Version 2 from both OpenSSH and SSH.com

I used to recommend the use of the SSHv2 service along with SSHv1 compatibity mode but I can't recommend this any longer. With SSHv1 being no longer supported, the recent CRC32 Compensation Attack vunerability, and the fact that there are enough good comercial/free SSHv2 clients out there, we can finally get rid of SSHv1 servers and clients. But, if this doesn't work for you, just be sure to keep up Bugtraq for any known SSHv1 exploits, etc.

NOTE: I have personally noticed that when connecting to SSHv2 servers running in SSHv1 Compatibility mode, the initial connection time until you receive a prompt is SIGNIFICANTLY slower than SSH v1 servers. Oh well.

NOTE #2: The following example does showshow to install both SSHv1 and SSHv2 to support both types of connections. If you don't want to run SSHv1 (because it's old) or SSHv2 (because of licensing issues), simply skip that section.

30.2 Running OpenSSH vs. SSH.com code

So you might be asking yourself, why is there both a commercial and free version of SSH? Well, the people at SSH.com orginally created SSHv1 and later, SSHv2. Understandably, they needed to make money from their work it so they charged ALL users for the use of it. This annoyed many people from the OpenBSD camp and thus they started to write their own version of SSH that would always be free. Over the years, SSH.com changed their licensing where it was now free to use for NON-commercial use for the Linux and *BSD operating systems. If used in a commercial setting or you wanted to run it on Solaris, HPUX, AIX, etc., it was still quite pricey.

Another reason why OpenSSH came to be was that SSH.com wanted to open up the the SSH protocol to become a standard. For this to happen, the various standards bodies required that the protocol be implimented by at least one 3rd party. Fortunately for SSH.com, the OpenSSH and OpenSSL people were already working on it.

So which do I recommend to you? Well, first, I recommend you review what SSH.com considers "NON-Commercial" use. JUst bring up a web browser and look at their LICENSING terms (they are surprisingly readible). After reading that, if you have no money and work in a a commercial environment, you probably need to run OpenSSH. Even if you work in a non-commercial environment, they have the right to change their minds again. As linux becomes more and more popular, you can plan on it to some extent. Ultimately, that would be a support nightmare going from SSH.com to OpenSSH. If your're starting fresh, why not just start with OpenSSH?

The main reasons why you might want to go with SSH.com's code are things like:

30.3 OpenSSH: Thoughts, Issues, and Features

OpenSSH uses OpenSSL for it's encryption libraries. Because of this, you need to install OpenSSL before you install OpenSSH. Currently, this is not covered in this section but should be easily added via a RPM, PKG, DEB, or the "use the source Luke!". If enough people ask for it, I can add OpenSSL instructions to TrinityOS. Anyway, you should verify that the version of OpenSSL on your machine is v0.9.5a or newer due to security issues. To do this, run the command: 

  openssl version

For users that still use SSHv1, OpenSSL 0.9.5a+will not properly support Blowfish over SSHv1 connections. This shouldn't be an issue as the use of SSHv1 is NOT recommended. You should strive to ONLY use SSHv2 in your environment.

Features:

Before you install OpenSSH, you should know something about OpenSSH 3.x. OpenSSH has a powerful chroot mechanism called "Privilege Separation". With this system in place, even an exploit against OpenSSH should only get user-level access and NOT root access. This system now mostly works on all systems now but there are a few corner cases. Specifically, some Linux kernels make this feature incompatible with SSH compression. If you use compression (I do), I recommend to avoid the use of this feature for now.

If you do want to use Privilege Separation, you need to setup the CHROOT environment *FIRST*: 

        mkdir /var/empty
        chown root:sys /var/empty
        chmod 755 /var/empty
        groupadd sshd
        useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false

30.4 Compiling OpenSSH:

30.5 Compiling up SSH.com's SSH

30.6 Configuring OpenSSH or SSH.com to load the server daemon upon reboot with startup scripts

Next, you need to have the SSH daemon load upon every reboot

Basically, there are two ways to do it. One is the Sys-V way (Redhat, Solaris, etc) or the BSD way (Slackware, SuSe, etc). Please see the middle portition of Section 8 to see if you had disabled SSHd from starting upon reboot.

NOTE: When loading the SSH daemon, lower the "xx" numbers Sxx.sshd or eariler in the rc.local, the faster the box will come back up with SSH support after a reboot.

For me with a CD-ROM changer, if the SSHd daemon was after the rc.cdrom startup script file, I would have to wait until all 7 CD-ROMs were mounted before SSHd begins to load! A slow process indeed!

For SysV machines (Redhat, etc):

/etc/rc.d/init.d/sshd 

--
#!/bin/bash
#
#       /etc/rc.d/init.d/sshd
#   v1.2
#
# sshd          Start the Secure Shell daemon
#
# chkconfig: 345 12 12
# description: The Secure Shell daemon, versions 1 and 2, allows for strong \
#              authentication, encrypted communications and tunnels with \
#              remote clients also using SSH.
# processname: sshd
# pidfile: /var/run/sshd.pid
# config: /etc/sshd_config

# v1.2 - Support for OpenSSH (default setting) added
# v1.1 - Fixed an error where it was starting SSHD and not SSHD2
# v1.0 - initial release
#
# Source function library.
. /etc/rc.d/init.d/functions

# OpenSSH settings - Add #s in front of the following lines if you want to
#    use SSH.com code
#
# (enabled by default)
#
SSHD=/usr/local/sbin/sshd
SSHD_CONFIG=/etc/ssh/sshd_config


# Disabled ssh.com settings - remove the #s if you want to use SSH.com
#
# (disabled by default)
#
# SSHD=/usr/local/sbin/sshd2
# SSHD_CONFIG=/etc/ssh2/sshd2_config

# If you are running SSHv1 in addition to SSHv2, uncommend out the
# following lines
#
#SSHD1=/usr/local/sbin/sshd
#SSHD1_CONFIG=/etc/sshd_config

case "$1" in
    start)
        echo -n "Starting SSH services: "
  
        if [ -x $SSHD -a -f $SSHD_CONFIG ]
    
    # If also running SSHv1, # out the line above and un-# the line below
    #if [ -x $SSHD1 -a -f $SSHD1_CONFIG -a -x $SSHD -a -f $SSHD_CONFIG ]

        then
                daemon $SSHD
        else
                echo_failure    
        fi
        echo
        touch /var/lock/subsys/sshd
        ;;
    stop)
        echo -n "Shutting down the SSHd daemon: "
        killproc sshd
        echo
        rm -f /var/lock/subsys/sshd
        ;;
    status)
        status sshd
        ;;
    restart)
        $0 stop; $0 start
        ;;
    reload)
        killall -HUP sshd
        ;;
    *)
        echo "Usage: sshd {start|stop|status|reload|restart}"
        exit 1
        ;;
esac

To activate this new script, run the following command: 

        chkconfig --level 345 sshd on

For BSD-style machines (Slackware, etc): ----------------------------------------

Edit the following file and put the text toward the TOP of the file:

/etc/rc.d/rc.local 

--
echo "Starting sshd v2 with Compatibility mode..."
/usr/local/sbin/sshd    
--

30.7 Configuring the Unix services

Most machines should have this first step already done but just make sure it's there:

Edit "/etc/services", find where port "22" should go and add this line (if it isn't there already): 

                ssh             22/tcp

Configuring OpenSSH:

Ok, time to configure SSH:

30.8 Configuring SSH.com SSH:

***** If you installed SSH.com SSH v2 but STILL want to support SSH v1 clients (not recommended), etc., do the following:

30.9 Configuring BASH aliases for proper SSH operation through firewalls

- Next, I would recommend to add the following line towards the bottom of /etc/bashrc: 

                        alias ssh='/usr/local/bin/ssh -C -P -c blowfish'
                        alias scp='/usr/local/bin/scp -C -c blowfish -L'

What this does is when you SSH out of the Linux box itself, SSH will:

Please note that for this alias to take effect, you will have to log out and then re-login.

- Now you need to either load or RE-load the SSH server.

30.10 Starting the SSH server:

If you don't currently have a SSHd server running, simply type in the following to test it out: 

                        /usr/local/sbin/sshd

Hopefully, you will just get the command prompt back and the SSH server will be running in the background.

If you already have a SSH v1 server running, things get a little more complicated:

That's it! The SSH server should be running now! If there seems be be problems or the server doesn't load, see below for some troubleshooting ideas. If things DO seem to be running, load up your SSH client and try it out. To SSH from your Linux box, just run "ssh username@xyz" where the "username@" can be left blank if you want to use the current username you're already logged in as or a different username and udquot;xyz" is the remote SSH-enabled server's fully qualified domain name or IP address.

30.11 SSH Problems? Here are a few possible solutions

  1. Are you getting the error "WARNING: Privilege separation user "sshd" does not existd" from OpenSSH? If so, you either forgot to create the SSHd user as shown above or you didn't disable priviledge separation in the /etc/sshd_confif file (disabled by default in TrinityOS)
  2. Can't connect to your SSH server from a host out on the Internet? Make sure that if you are using a IPTABLES / IPCHAINS / IPFWADM firewall, that port 22 is allowed IN and OUT.

  3. Does SSH initially make a connection and then disconnect? Make sure that if you are using TCP Wrappers, /etc/hosts.allow, that SSH access is allowed in from the requesting remote machine's FQDN or IP address.

  4. If you can SSH out from a MASQed PC but NOT from the Linux server itself AND you are getting firewall hits in /var/log/messages that look something like: 

      Jul  6 10:28:49 roadrunner kernel: Packet log: output REJECT eth0 PROTO=6 
100.200.300.19:716 212.222.333.222:22 L=60 S=0x00 I=5107 F=0x0000 T=64 SYN (#38)

    What is happening is that you didn't follow the above requirement to add an SSH alias to your /etc/profile and have SSH run with the "-P" option. Specifically, the SSH packet leaving the server is using LOW ports (in this example, port 716).

30.12 SSH Port Forwarding

FULL SSH port forwarding!

UNIX access:

SSH PORTFWDing is a method to tunnel or "VPN" traffic through an SSH server. So not only can you transparently gain access to remote systems, you can tunnel non-encrpted applications like TELNET, FTP, etc. through an encrypted SSH connection. Here is how you can configure a SSH client for secure IMAP, SNMP, and LDAP access through a SSH tunnel. Also know that other people can setup these tunnels to YOUR SSH server if they have the proper access.

NOTE: One VERY cool thing about this setup is that the server that has the SSH server does NOT have to be the server you need to access. What this means is that the SSH server can actually terminate the tunnel on the edge of the remote network but then FORWARD the PORTFW traffic to a specific intended INTERNAL server. Very cool.

To setup this tunnel, I recommend to create a script called "start-tunnel". This script assumes that "some.remote-ssh-server.com" is the SSH server and that "some.internal-mail-server.com" is the internal server that you ultimately want to connect to (for this example, that internal machine is a mail server).

start-tunnel 

echo Forward IMAP, LDAP, SMTP to allegro
/usr/local/bin/ssh.old -C -P johnjoe@some.remote-ssh-server.com \
        -L 143:some.internal-mail-server.com:143 \
        -L 25:some.internal-mail-server.com:25 \
        -L 389:some.internal-mail-server.com:389 sleep 7200

Lets break this script out to better understand it: 

        1) this example uses the older SSHv1 client.  If you get an 
           error like:

             "Executing /usr/local/bin/ssh1 for ssh1 compatibility.
                Bad forwarding specification '143'."

                   This means that the remote SSH server is NOT supporting
                   SSHv2.  So, this is why I hard coded it to use SSHv1.

                        2) -C means use compression
                        3) -P means to NOT use ports less that 1024 (privileged ports)
                        4) "johndoe" is the login on the remote SSH server
                        5) "some-remote-ssh-server.com" is the remote SSH server

                        6) "-L 143 some.internal-mail-server.com:143" means:
                                A) I want to forward all LOCALHOST traffic to port 143
                                B) Send this traffic to "some.internal-mail-server.com" 
                   on port 143

                           NOTE:  If you didn't catch that, it will be forwarding 
                          ******  your LOCALHOST traffic on port 143 to that remote server.
                                    SO, if you were originally configuring your IMAP client
                                    to directly connect to "some.internal-mail-server.com", 
                                    you will now have to re-configure it to connect to "localhost".
                                    Weird huh?  Once the SSH tunnel comes up, it will work 
                                    completely transparently.

                    One trick several people like is to create an /etc/hosts.ssh 
                    file.  In this file, add the line:

                         some.internal-mail-server.com     127.0.0.1

                    With this in place, add some lines to your SSH PORTFW
                    script that will rename your original /etc/hosts file and
                    use this /etc/hosts.ssh file in it's place.  When this
                    happens and your email client comes up, it will check the 
                    /etc/hosts file FIRST before going to DNS.  So, when SSH 
                    PORTFWDing is running, your email client will automatically 
                    use the PORTFW connection.  If SSH is down, it will use DNS.
                    Plain and sweet huh?

                        7) Repeate the forwards for SMTP and LDAP as well

                        8) Like RSH, SSH will execute the command "sleep 7200" 
               on the remote server.  So, after 7200 seconds or 2 hours, the tunnel 
               will shut down.

* For other UNIX examples, please see the SSH section in Section 5:

Windows access:

- If you are looking for a great SSH client for Windows, check out SecureCRT at http://www.vandyke.com. Here is an example how to setup SecureCRT perfectly for Linux.

----------- NOTE: This SCRT configuration example shows how to configure SecureCRT to both enable SSH encrypted communications to the remote host but also enable transparent SSH port forwarding for ALL POP-3 and communications to that same given server. If you also want to encrypt additional protocols like IMAP4, etc., just use this configuration as this as a template.

Please note that to enable SSH port forwarding, a normal SecureCRT SSH connection needs to be established FIRST to your remote server. Once the SSH connection is running, all POP-3, etc communications will be transparently encrypted! You won't even notice its doing it.

Once the SSH connection is down, all POP-3, etc communications will break because the given POP-3, etc clients must be reconfigured to connect to IP address 127.0.0.1. More on this in a moment.

-----------

I would also recommend to do the following:

Session-->Advanced-->

General tab:

Port Forwarding: - Click on the NEW button

Emulation

Options

- You have to do one last thing for SSH forwarded connections. You need to reconfigure your POP-3 client, say Netscape or Eudora, to connect to 127.0.0.1 and -NOT- your normal POP-3 server. What this does is the POP-3 client will conenct to 127.0.0.1 (localhost on your local machine) and then SecureCRT will SSH it and forward it over the first configured instance of SCRT with port 110 forwarded. As mentioned above, you can create a batch file that swaps around the C:\WINDOWS\HOSTS file and let you not have to reconfigure your applications. See above in the Unix PORTFWD section for more details.

NOTE: If you have multiple POP-3 clients running, this will be a problem since you can't port forward port 110 twice. To fix this, you will have change the POP-3 client to use a different port other than port 110 (say port 123) and then configure that SCRT sesstion profile to SSH forward port 123 to remote port 110. Get it?

NOTE2: SSH port forwarding does NOT work well with ACTIVE-style ftp connections. Re-configure your FTP clients to use PASV connections on port 21 and then SSH'ed FTPs will work ok.

------------

- That's it. From S-CRT, go ahead and try connecting to your remote SSH server and you should be prompted with a dialog box asking to "Accept and save" the keypair. Click on "OK". Now you should be prompted to enter in your password and you should now login over an SSH encrypted connection! With the SSH connection running, now all your POP-3 traffic will also be transparently encrypted to make your username/password and files safe from prying eyes.

Next Previous Contents