Secure Shell
Secure Shell (SSH), sometimes known as Secure Socket Shell, is a protocol originally designed for securely accessing a remote Unix computer. Today, SSH is widely used by network administrators to control many different kinds of servers remotely. SSH enables you to securely execute commands on a remote machine and to move files securely from one machine to another. SSH can provide stronger authentication and secure communications over insecure channels. It provides secures replacement for rlogin (slogin), rsh (ssh), and rcp (SCP). Additionally, SSH provides secure X connections and secure forwarding of arbitrary ports (UDP streams and TCP connections).
SSH can be configured to encrypt all traffic, including the initial authentication password. Stronger authentication can be achieved by using RSA keys (SSH1) or DSA keys (SSH2). For this, each user must have a key file that is verified by the server before the user can access any resources. He also must have a key file for the server or must trust the server by accepting any key it might present.
SSH is very flexible. Besides providing a secure terminal session, some implementations support secure FTP for file copying. You also can tunnel TCP/IP services through SSH to provide secure X11 sessions, email, and Web access.
OpenSSH, available at http://www.openssh.org/, is the free open-source version. F-Secure and SSH Communications provide a commercial server and client for Windows and Unix platforms. Figure 3 shows F-Secure onscreen.
Figure 3 F-Secure provides a Windows client to connect to SSH servers.
To use SSH, you need two components, the SSH server and an SSH client. With OpenSSH, you cannot beat the cost (free). You also have some freely available SSH clients, such as Putty, for use on a Windows system. The network architecture for a company using SSH for remote access to an internal server is shown in Figure 4.
Figure 4 SSH is a simple, cost-effective remote access method.
To access multiple servers with one SSH connection, many organizations designate one server as the SSH server. Users connect with SSH and then Telnet to other internal servers. This also is illustrated in Figure 4. I do not recommend this because internal users can sniff your network and easily find user IDs and passwords. Because administrators often use root or highly privileged accounts, you are putting the integrity of your server security on the line.
I also do not recommend using SSH as your sole means of remote access if you have a large pool of remote access users who use a wide variety of applications. SSH is great for administrators to use for remote management or for environments that are strictly Linux-based, but it does not provide all the capabilities and functionality required by most end users.
If you're looking for high-speed tunneling, SSH isn't for you: Go with a VPN solution optimized for that purpose. Because SSH requires login accounts on the server, it is best used in a trusted environment. SSH can forward individual ports but cannot forward port ranges. Applications such as FTP that bundle several connections into a logical session require vendor extension and thus compatible client/server implementations.
For More Information...
You'll find SSH FAQs at http://www.tigerlair.com/ssh/faq/ssh-faq.html, and an SSH HowTo at http://p25ext.lanl.gov/ssh/ssh-howto.html.
Check out Putty, a free Windows SSH client, at http://www.chiark.greenend.org.uk/~sgtatham/putty/.
There are some good notes on SSH programs and uses at http://www.boran.com/security/ssh_stuff.html.
Another great "how to" on SSH can be found at http://www.isp-planet.com/equipment/ssh_intro.html.