SSH is both a protocol and program suite that allows for ENCRYPTED communictions. For me, I always use SSH because if I was to login with normal versions of 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! *
Why is this bad? For example, if some evil person was between your local machine and your POP-3 server was sniffing packets, 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 then encrypted. Plus.. it can acutally speed things up with the use of built-in SSH compression!
NOTE: SSH now comes in two flavors. Version 1 and Version 2
Version 1 is very good and is supported by other clients like Van Dyke's SecureCRT v2.x for Windows. It also supports both the fast Blowfish and IDEA ciphers (encryption engines). The major benefit of SSHv1 is that it is completely free for both end users and commercial companies.
SSH v2 also supports encrypted file transfers unlike v1. A work around for this is to use something like Zmodem over a SSHed TELNET connection via clients like SecureCRT.
So why is there a V2? At one time, there were some flaws in it and thus SSH V1 was discontinued. But, people complained that v1 could be fixed and the licensing of v2 was too restrictive. Because of this, both v1 and v2 versions of SSH are alive and well.
Version 2 is a stronger version of SSH. Unfortunately, SSH v2 does not support the fast Blowfish or IDEA ciphers but the other ciphers aren't much slower. BUT.. the licensing for SSHv2 doesn make it free for commercial or educational use. So, many companies are either still using SSHv1 or moving over to OpenSSH versions that don't have these legal issues.
Unfortunately, most SSH v1 clients (like SecureCRT v2.x for Windows) -CANNOT- connect to a v2 server unless the server is compiled up to support "compatibility" mode. Please note that SecureCRT v3.x now supports both SSHv1 and SSHv2.
Yet, one great new thing about the new v2 SSH is that it comes with a SSHed -FTP- client (sftp) now! With this feature, users won't have to use things like Zmodem over SSHed TELNETs for secured file transfers.
For now, I *recommend* to support the compatibility mode to support both SSH v1 and v2 clients.
NOTE: I have personally noticed that when connecting to SSHv2 servers in Compatibility mode, the initial connection time until you receive a prompt is SIGNIFICANTLY slower than SSH v1 servers. Oh well.
Please NOTE: The following example shows how to install both SSHv1 and SSHv2 to support both types of connections.
If you don't want to run SSHv1 (because its old) or SSHv2 (because of licensing issues), simply skip that section.
- Go to the SSH archive shown in Section 5 and download the newest versions of BOTH the v1 and v2 SSH servers (these archives also include the Unix SSH client too)
- Un-tar both v1 and v2 SSH server/client archives by running
"tar -xzf ssh-1.2.x.tar.gz" "tar -xzf ssh-2.2.x.tar.gz"
- Now do the following.
NOTE: If you want to support both SSH v1 and v2 clients, you MUST install SSH v1 first.
For SSH v1 server support:
"cd ./ssh-1.2.30"
"./configure --with-libwrap --disable-suid-ssh"
This tells SSH to set itself up for this particular hardware setup with:
"./make clean"
"./make"
"./make install"
For SSH v2 server support:
"cd ./ssh-2.2.0"
"./configure --with-libwrap --disable-suid-ssh"
This tells SSH to set itself up for this particular hardware setup with:
"./make clean"
"./make"
"./make install"
NOTE: The "make install" command might take some time (key generation does 7 passes) and time per pass depends on your Linux box's CPU power.
- Next, you need to have the SSH daemon load upon every reboot.
Basically, there are two ways to do it. One is the SysV way (Redhat, Solaris, etc) or the BSD way (Slackware, SuSe, etc) which was the original way that it was documented in TrinityOS. Please see the middle portition of Section 8 for full details.
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 is below the rc.cdrom file, I have to wait until all 7 CD-ROMs are 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
#
# 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
# Source function library.
. /etc/rc.d/init.d/functions
SSHD=/usr/local/sbin/sshd
SSHD_CONFIG=/etc/sshd_config
case "$1" in
start)
echo -n "Starting SSH services: "
if [ -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 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 --
- Now, edit "/etc/services", find where port "22" should go and add this line (if it isn't there already):
--
ssh 22/tcp
--
***** If you installed SSH v2.x but STILL want to support SSH v1 clients (like SecureCRT), etc, do the following:
- edit /etc/ssh2/sshd2_config and either verify or add the following lines to the section that is under "*:".
If any of the following lines do exist but have a "#" in front of it, delete the "#" and edit the line to look as follows:
/etc/ssh2/sshd2_config
--
Ssh1Compatibility yes
Sshd1Path /usr/local/sbin/sshd1
--
It should also noted that if you are concerned with absolute security and don't need the following function, I recommend to do the following:
/etc/ssh2/sshd2_config
--
#If you don't need SSH tunnels, disable it by putting a "#"
#in front of the line:
ForwardAgent yes
#If you don't need X11 SSH forwarding, disable it by putting
# a "#" in front of the line:
ForwardX11 yes
--
- I also recommend to disable the ability to login via SSH1/2 as root. To do this, edit the following files and change them to read:
/etc/ssh2/ssh2d_config
--
PermitRootLogin no
--
- Next, edit
/etc/sshd_config
--
PermitRootLogin no
--
- Next, edit /etc/ssh2/ssh2_config and either verify or add the following lines to the "*:" section. If the line does exist but there is a "#" in front of it, delete the "#"
/etc/ssh2/ssh2_config
--
Ssh1Compatibility yes
Ssh1Path /usr/local/bin/ssh1
--
- 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.
- If you don't currently have a SSHd server running, simply type in:
/usr/local/sbin/sshd
- If you DO already have a SSH v1 server running, things get a little more complicated:
- You need to either login to the console of the Linux server or TELNET (yes.. TELNET and not SSH) into your Linux box. Also, if you are going to TELNET in and running a strong firewall rule set, you'll have to allow TELNET into your firewall.
- Now, login to your box WITHOUT SSH and kill the running SSHd process:
- Finally, restart the SSHd process
/usr/local/sbin/sshd
- That's it! The SSH server should be running now! So load up your SSH client and try it out.
- To SSH from your Linux box, just run "ssh xyz" where "xyz" is the remote SSH-enabled server's fully qualified domain name.
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.
FULL SSH port forwarding!
UNIX access:
* Here is how you can configure a SSH client for secure IMAP, SNMPT, 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. The SSH server can actually terminate the tunnel on the internal network and then forward the traffic to the intended INTERNAL server. Very cool.
To setup this tunnel, I created 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.
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 out:
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.
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.
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.