CertiGuide to Security+  9  Chapter 2:  Communication Security (Domain 2.0; 20%)       9  2.1  Remote Access

2.1.5  L2TP/PPTP 1 2.1.7  IPSEC

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, it’s 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 details¹⁵².

“So let’s 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 it’s 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 don’t support all possible encryption options. For example, OpenSSH¹⁵³ 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 footnote¹⁵⁴.

The book Linux System Security¹⁵⁵ 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.)

2.1.5  L2TP/PPTP 1 2.1.7  IPSEC