Frequently Asked Questions
Introduction
The purpose of this book is to explore the needs and functions of Secure Shell (SSH). We will endeavor to explain the history of the networks we use today and how they developed and expanded to a point where tighter security became increasingly more important.
We will look at how the OSI (Open Systems Interconnect) model and SSH relate to each other and also how to use the OSI model for troubleshooting network connectivity. Then we will look at the role of cryptography and the various methods of encryption from which we can draw. Once we understand the cryptography, we will then look at the actual SSH standards and how this protocol can aid in the secure transmission of controls and commands across the network. Then the various SSH platforms will be discussed and documented. The later chapters will round out the book with topics on port forwarding.
So let us embark on our journey with a brief history and introduction to SSH; all aboard!
Why Is There a Need To Use SSH?
In the beginning there were main frame computers. These large computers allowed programmers to input large mathematical formulas that would take hours or days to solve by hand. These computers could take the same formula and datum and solve it in seconds or minutes. As these computers became more flexible and could handle not only mathematical datum but also text and numerical information, people began to use them to manage more and more business and research data. Computers became more than just a tool for college and government organizations, as they started to be able to manage business data. As they became smaller and more powerful, tools to input and store data came into being and costs became more reasonable.
More customers were in the business world. These computers stored massive amounts of data and people could access these machines in a controlled environment. The topology of the network was called the Centralized Data Model; in this model all the data was stored on one central computer and access was through "dumb" terminals. The terminals themselves had no computer processing power or storage. This protected the data from loss, damage, theft, and spying. In this model encryption was not necessary as the data was never vulnerable to the outside world. People could see only what the administrators allowed through the "green screen," or dumb terminal.
As computers became more powerful and a need to share data across diverse and distant locations became more prevalent, wide area connections were established. At first these connections were done over analog phone lines using modem (Modulator/Demodulator) technology. There were two types of modems, synchronous and asynchronous. Synchronous modems used a special timing bit in the stream to keep the communications channel operating smoothly. In asynchronous modems, instead of a constant timing bit, the technology used a start and stop bit for each part of the transmission, ensuring each piece of data was received consistently. These analog connections were point to point and it was not easy for people to "listen in" on these connections.
As communications technology progressed and a shared, or interconnected, network of networks developed and more and more "private" data was being transmitted over these open links, the need for encrypted transmission become necessary. In addition, with the wide areas of transmission, personal computers also brought about internal or Local Area Networks (LANs). These internal networks allowed computers to transmit and receive data from other computers and servers within the building. The data traffic of these devices became subject to eavesdropping by other individuals inside the network. The eavesdropping, also known as packet capturing, allowed internal people to view data they might not otherwise had the privilege of viewing. These two scenarios increased the need for data encryption.
For each type of remote connection, there are options on how to secure it. In this book we will focus on remote login/control from a client to a server. In the early days, we had two options. The first was remote login, or RLOGIN (TCP port 513); it allowed us to open a session on a UNIX server and issue commands. The second option was telnet (TCP port 23); both of these protocols use a clear text channel to send and receive information. Any user with a packet capture program like Wireshark™ will be able to see the entire session, including usernames and passwords. As networks became more vulnerable to these types of attacks and data leakage, we needed to protect the sessions. For this connectivity issue, SSH is the answer.
SSH employs strong industry recognized encryption methods to protect your data from exposure. It makes no difference if you are using SSH across your local area network or the Internet from a remote location; your data will be secured in these encrypted channels. This software replaces telnet and rlogin as your connectivity method and offers protection to your data. Continued use of rlogin and telnet could be considered a violation of your organization's security police and in some cases a violation of law; Sarbanes Oxley, for example, mandates that all communications containing financial data must be encrypted. If you are using telnet to create a remote session to a UNIX computer that contains your financial application, you are not in compliance with Sarbanes Oxley.
What SSH Does and Does Not Do
Is SSH a complete encryption solution for all your network needs? No! SSH is a method of connecting to a remote system and creating a console session for the issuing and executing of commands in an encrypted channel. It is not a remote access method for connecting to a LAN over a wide area connection; it is not a protocol that will encrypt your e-mail over the Internet. It provides for the ability to do the functions of rlogin and telnet with the added protection of encryption.
If you were to connect to a remote network (LAN) from a remote location, you would need Virtual Private Network (VPN) technology; to protect your e-mail with encryption, you would need PKI (Public Key Infrastructure), also known as digital signatures. Each type of data and connectivity will have its own type of encryption and protection. If you do not employ some method of protection, you will increase the risk to data exposure and loss.
It is important to know the limitations of any type of security solution. SSH's major purpose is to establish encrypted shell sessions between your client machine and a server of some sort (that server could be an actual Linux, UNIX or Windows server, or it could be a router, firewall or switch).
It also gives you the ability to securely copy files from machine to machine. It does not, however, protect data sent outside the encrypted channel. You can use some aspects of SSH to create encrypted tunnels between your e-mail server and a spam filtering system. Once you get past the spam filtering system, you are back to clear text data!
Comparison Between SSH and SSHv2
The major differences between the original SSH and the second version are the added encryption and security features. According to the US Computer Emergency Response Team (US-CERT), there are, at the time of this writing, at least 50 known vulnerabilities with SSH in their database. Over time any protection standard will be weakened by attacks. It was not long ago that the 3DES block encryption standard was unbreakable; now it cannot be used on federal and military networks because it has been breached.
SSH Version 1 was developed by Tatu Ylönen in 1995, which was the year the Internet was first opened to the general public. It was a response to attacks that he detected to his data sessions. Ylönen was a researcher at the Helsinki University of Technology; he gathered a group of researchers to come up with a protocol that would replace the unsecure methods, such as telnet and rlogin, of connecting to shell sessions and stop the exposure of usernames and passwords in clear text. In July of 1995 he released his first version, now known as SSH-1, and by December 1995, the user base of SSH-1 had grown to over 20,000. In 1996 a revised SSH was release by Ylönen; this was called SSH-2 and had increased security by adding stronger hashing algorithms created by Whitfield Diffie and Martin Hellman. These algorithms not only strengthened the protocol, but also, by incorporating industry recognized technologies, made the protocol more compatible across divergent technologies. In 2006 the SSH-2 protocol became a proposed industry standard by having been submitted as an RFC (Request For Comment) with the Internet Engineering Task Force (IETF). See Chapter 4 for references to the RFC's documenting SSH-2 or SSHv2.
The volunteers at the OpenBSD Foundation, a Canadian not-for-profit Corporation who do not fall under US encryption laws, took the open source standards created and created OpenSSH, which was derived from code originally released as OSSH. This has become one of the most popular releases of SSH in use today due to its open source license. Figure 1.1 shows the current website of the OpenSSH foundation.
Encryption Standards
If you are talkingVPN, SSH, digital signatures, and PGP (Pretty Good Privacy), you are talking about encryption and hashing algorithms. In this book we will talk primarily about the algorithms that pertain to SSH. However, most of the technologies and algorithms we discuss will be similar, if not the same as, protocols used in other secure protocols.
Some of the protocols we will discuss in future chapters are as follows:
3DES (Triple Data Encryption Standard)
ARCFOUR (Alleged RC4)
Twofish symmetric
Serpent
Blowfish
AES, the Advanced Encryption Standard
These protocols are industry standard protocols that are currently included in the SSH protocol and in other associated commands such as SCP and SFTP. As other protocols are accepted by the industry at large, they will be added to the SSH standards. See Chapter 4 for more information on these protocols.
What Is SCP and SFTP?
SCP (Secure Copy) is a command defined by the IETF in cooperation with SFTP (Secure File Transport Protocol). SFTP has in the past been confused with Simple File Transport Protocol as both have been referenced by the SFTP acronym. These two utilities allow us to move files and data from one machine to another in an encrypted manner. SCP allows files from one directory on the source machine to be copied to a directory on the remote machine in a scripted, or batch file, structure. See the chapter on command line and advanced SSH for the options and functions of this command. IETF RFC (Request for Comment) describes these protocols.
Both SCP and SFTP operate on TCP Port 22, like SSH itself. However SFTP is not just FTP (File Transport Protocol) over SSH; it is a totally new program developed from the ground up.
Table 1.1 compares FTP, SCP and SFTP.
SSH and the C-I-A Triad
The C-I-A triad (Figure 1.2) is a balance between confidentiality, integrity, and availability. If any of these are compromised, the data we are trying to protect can be affected in a negative and costly way. Let's take a look at each of these three parts, how the effect the data, and how we protect them.
(Continues...)
Excerpted from Next Generation SSH2 Implementation by Dale Liu Max Caceres Tim Robichaux Dario V. Forte Eric S. Seagren Devin L. Ganger Brad Smith Wipul Jayawickrama Christopher Stokes Jan Kanclirz, Jr. Copyright © 2009 by Elsevier, Inc.. Excerpted by permission of Syngress Publishing, Inc.. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
