Like this CertiGuide? Get it in PDF format!
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Need more practice? 300 additional Security+ questions!
Get It Here!

Custom Search







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

Previous Topic/Section
2.1.5  L2TP/PPTP
Previous Page
Pages in Current Topic/Section
1
Next Page
2.1.7  IPSEC
Next Topic/Section

2.1.6  SSH

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 details152.

“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, 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.)

SSH Protocol

SSH is often used as a replacement for the telnet terminal communication protocol. Unlike telnet, SSH allows for secure authentication (it doesn’t send the user’s password over the wire in clear text) and encrypted communication.

SSH uses port 22
156

It can also be used as a VPN tunneling protocol.


Open SSH

Do you use telnet or rlogin in your organization? If your environment includes one or more UNIX machines, the answer is likely to be yes. If so, consider deploying OpenSSH (or another SSH package) as a replacement.



 __________________

152. http://www.hackinglinuxexposed.com/articles/20030228.html

153. Open SSH, http://www.openssh.org

154. http://www.ietf.org/html.charters/secsh-charter.html

155. Mann, Scott, Ellen L. Mitchell, Mitchell Krell, Linux System Security, Prentice-Hall, September, 2002, http://www.nerdbooks.com/item.html?id=0130470112

156. http://www.iana.org/assignments/port-numbers

Previous Topic/Section
2.1.5  L2TP/PPTP
Previous Page
Pages in Current Topic/Section
1
Next Page
2.1.7  IPSEC
Next Topic/Section

If you find CertiGuide.com useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from StudyExam4Less.com. (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.