SSH, or Secure Shell, began as a replacement for traditionally insecure methods of accessing a host.
In the beginning, there was telnet, the Internet system to Internet system version of a dialup modem terminal program like ProComm. And the geeks connected to other geeks systems over an academic Internet via telnet, providing user name and password to authenticate themselves; and, it was good! Then more geeks out on the West Coast at Berkeley said, If we connect to a certain system all the time, and its administrators trust us, why should we always have to keep typing our passwords in? By the way, its insecure to transmit passwords in clear-text across the Internet the way telnet does, because anyone who can sniff the bits on the network will be able to discover your passwords. The footnote is for Part 1 of a multi-part article on SSH details152.
So lets create another remote terminal access program which optionally uses our user and source host name to automatically authenticate us instead of requiring us to type in our user name and password? and thus came up with another remote host access method, known as rlogin (or the infamous Berkeley r- commands). Alas, both of these mechanisms have flaws both transmit the password, if used, in clear-text, so that its vulnerable to being sniffed. The r- commands have the added flaw of relying on DNS information, which can be spoofed by attackers, for authentication.
SSH was developed as an answer to these issues largely replacing telnet, rlogin (and other r- commands such as rexec and rcp, a remote file copy utility), and adding the capability of forwarding secure X Window System connections (X is the underlying GUI used on most UNIX systems). It is implemented on servers through the use of SSH daemon that listens for incoming client connections on port 22 by default. (The SSH daemon can also be configured to use any other unused TCP port, by updating a configuration file.)
Someone looked at the technology in SSH, and decided it would make a good low-cost, general-purpose VPN protocol. Today SSH can be used over PPP, to create a VPN at a higher OSI layer, redirecting TCP/IP ports to allow encrypted services, and proxy X Window System traffic. The SSH 1.x protocol permits secure authentication by way of RSA key exchange between client host and server or individual user to server. The client host and user keys are normally 1K in length, and the SSH server key 768 bits. The SSH 2.x protocol, used freely by available clients and servers, avoids the use of the then-patented RSA algorithms, opting instead for the DH and DSA algorithms. SSH supports a wide variety of encryption options, including RC4, 3DES, Blowfish and AES-256, to ensure data integrity and privacy. (Note that all SSH implementations dont support all possible encryption options. For example, OpenSSH153 steers clear of patented algorithms.) Automatic port assignment is in draft stage and an RFC should be ready in early 2003. A draft document is available in the footnote154.
The book Linux System Security155 by Mann et.al. provides detailed coverage of setting up and troubleshooting authentication with SSH (as well as explanations of many open source security tools for Linux, including firewalls, scanners, log checkers, the open source Tripwire IDS, etc.)
153. Open SSH, http://www.openssh.org
155. Mann, Scott, Ellen L. Mitchell, Mitchell Krell, Linux System Security, Prentice-Hall, September, 2002, http://www.nerdbooks.com/item.html?id=0130470112
Home - Table Of Contents - Contact Us
CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com
Version 1.0 - Version Date: November 15, 2004
Adapted with permission from a work created by Tcat Houser et al.
CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.