THE SECURE SHELL - AN OVERVIEW

                                                                                                            (c) VISOLVE

Table of Contents

  1. Introduction 
  2. A Bit of History 
  3. SSH Architecture 
  4. SSH 1
  5. SSH 2 
  6. Quick Configuration
  7. Difference between SSH1 and SSH2
  8. Summary 
  9. Appendix 

Table of Figures
  1. A secure shell session
  2. Secure shell Architecture
  3. Layers of secure shell
  4. SSH 1
  5. SSH 2
  6. Ip spoofing
  7. Tcp Port forwarding

Introduction                                                                                                                    

SSH, a protocol that allows a client computer to connect securely with a server to log in or copy files. It provides authentication and a secure transport layer that allow a user to establish a secure connection even over an insecure network. SSH provides an encrypted terminal session strongly secured with symmetric encryption algorithms. The main functions of the Secure Shell program are
 Some useful  SSH features and capabilities include:
These capabilities permit the user to protect against attacks such as:
A normal SecureShell suite includes
  1. ssh(secure shell)
  2. scp(secure copy)
  3. sftp(secure File Transfer protocol)
  4. slogin(secure Login).
                                                                                                                                                                                                                                      
                                                                                                                                                                                                   

A Bit of  History

SSHv1 and the SSH-1 protocol were developed in 1995 by Tatu Ylonen, a researcher at the Helsinki University of Technology, Finland. Later that year, he released the SSH-1 (SSHv1) protocol to the general public as freeware and submitted an IETF Internet Draft.

SSHv1 protocol  had number of problems and limitations,which lead to the introduction of  a new protocol, SSH-2 (SSHv2), in 1996  incorporated new algorithms and  features.SSHv2 is more secure and powerful than it's counterpart.

When SSH Communications (formed by founder)  released later versions of Secure Shell based on the SSH-1 protocol and then the new versions of Secure Shell based on the SSH-2 protocol in 1998, it tightened the license restrictions and required commercial entities to pay a licensing fee. As a result, many companies declined to move to the more secure version  and they remained on SSHv1.In late 2000, SCS broadened free license for SSHv2  for individual contractors working for qualifying noncommercial entities.

Meanwhile OpenSSH gained prominence as an SSH implementation, developed under the auspices of the OpenBSD project and freely available under the OpenBSD license. It supports both SSH-1 and SSH-2 in a single set of programs, whereas SSH1 and SSH2 have separate executables, and the SSH-1 compatibility features in SSH2 require both products to be installed. , it has been ported successfully to Linux, HP-UX, and other operating systems, in tight synchronization with the main releases.

The OpenSSH team included support for both the SSH-1 and SSH-2 protocols (SSHv1.3, SSHv1.5, and SSHv2), added many security enhancements, and increased portability. Because of the licensing freedom, good support, and continuing development, OpenSSH remains the most popular Secure Shell distribution today.
                                                                                                                                                                                                                                 

SSH Architecture

 

Components of Secure Shell

SSHD Server
A program that allows incoming SSH connections to a machine, handling authentication, authorization.
Clients
A program that connects to SSH servers and makes requests for service
Session
An ongoing connection between a client and a server. It begins after the client successfully authenticates to a server and ends when the connection terminates. Sessions may be interactive or batch.
Key
A relatively small amount of data, generally from tens to one or two thousand bits, used as a parameter to cryptographic algorithms such as encryption or message authentication. The use of the key binds the algorithm operation in some way to the key holder: in encryption, it ensures that only someone else holding that key (or a related one) can decrypt the message; in authentication, it allows you to later verify that the key holder actually signed the message.
There are two kinds of keys:
Agent
A program that caches user keys in memory, so users needn't keep retyping their pass phrases.



How Secure Shell Works

When SSHD is started , it starts listening on port22 for a socket. When a socket get connected the secure shell daemon spawns a child process.Which in turn generates an host key eg.RSA.After key is generated the secure shell daemon is ready for the local client to connect to another secure shell daemon or waits for a connection from remote host.
Connection Establishment
When a client or remote machine needs a connection,the socket is bound to particular port, but this is done only  after receiving IP address of client.when connections are made the servers exchange the public host keys.after the keys are validated,the servers exchange the supported cipher information . when cipher is chosen,the local server acknowledges and authorizes the connection child process is forked to manage  the established connection. The client now transfers data in encrypted and well secured form.
Layers of SSH
The SSH protocol allows any client and server programs built to the protocol's specifications to communicate securely and to be used interchangeably.
Transport layer
The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of and after authentication. The transport layer accomplishes this by handling the encryption and decryption of data and providing integrity protection of data packets as they are sent and received. In addition, the transport layer provides compression, speeding the transfer of information.  Once an SSH client contacts a server, key information is exchanged so that the two systems can correctly construct the transport layer.
Authentication
Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client will then try to authenticate itself to the server using any of the supported methods. Servers can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it will support based on its security model, and the client can choose the order of authentication methods to attempt from among the available options.
Connection
After a successful authentication over the SSH transport layer, multiple channels are opened by  the single connection between the two systems. Each of these channels handles communication for different terminal sessions, forwarded X11 sessions, or other services seeking to use the SSH connection. Both clients and servers can create a new channel. Each channel is then assigned a different number for each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions will not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection. The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.
                                                                                                                                                                                                                                 

SSH 1




One of the key concepts for SSH1 is that each host in the network has a unique RSA cryptographic key, for identification purposes. The length of the host key is by default 1024 bits. Additionally, whenever the SSH1 server is activated, the second RSA key is automatically generated. This is called own server RSA key, and by default is 768-bit long. In order to enhance security, this key is regenerated after a specific timeout (1hour by default), if in the meantime the server had used the key. This key is never saved in any server file.
Whenever a client connects to the server, in response, the server sends a set of both public and host keys. The client compares the host public key with a master key. This procedure is to verify if the connected host is the same as the host in the first query. Due to this fact, the host RSA key is considered immutable. It is worth noticing that the server key cannot be used to authenticate the host, as this key is frequently modified. After host authentication is successively performed, a 256-bit session key is randomly generated by the client and encrypted with the server key and the server host key together. This type of prepared information is then sent to the server which has a set of private keys and can decrypt the value sent by the client. This cipher is now used as a key for symmetric, cryptographic algorithms to encrypt the session.
 For this purpose, Blowfish or 3DES(Default) encryption algorithms are used. The client selects the encryption algorithm to use from those offered by the server. After the negotiation phase has been successfully completed between server and client, the rest of the traffic in the SSH1 session is encrypted with the existing algorithm using the session key. Afterwards the user can be securely authenticated on the server.
                                                                                                                                                                                                                                                                                                                                                                                               

SSH 2                                                                                                                                                     


SSH1 and SSH2 are different versions of the same program. Each host has its own unique RSA or DSA authentication key, not just an RSA key as in SSH1. The first difference found is during the SSH server start-up  – there is no server key. The session key produced by Diffie-Hellman is used to encrypt the real session key. Once the session key has been established, the traffic is encrypted using symmetric algorithms.Additionally, session integrity is provided through sha1 or md5 hash algorithms. This list of algorithms obviously has a certain preference and nothing stands in the way of using other symmetric algorithms, provided that both the server and the client support them.Both SSH1 and SSH2 use some authentication methods. By default, the client attempts to authenticate itself using the set of following methods:
Public key authentication is similar to SSH1 authentication except that the RSA or DSA algorithm is used . In contrast to SSH1, when the  client wishes to authenticate using  public/private keypairs, it signs in with the client’s private key where the session identifier derived from a shared Diffie-Hellman value and then the server check, whether the matching public key is listed in the authorized_keys. If public key authentication fails, then another authentication method is attempted to prove the user’s identity. The order of authentication methods is established with PreferredAuthentications in the configuration file. By default, the configured order is as follows:

SSH2 also uses the authentication methods Like
                                                                                                                                                                                                                                     

Quick Configuration

SSH includes many configuration options.
See the INSTALL file for custom configurations.

                                                                                                                                                                                                                                            

Difference between SSH1 and SSH2                                                                               

The difference between SSH1 and SSH2 is they are two entirely different protocols. SSH1 and SSH2 encrypt at different parts of the packets, and SSH1 uses server and host keys to authenticate systems where SSH2 only uses host keys. SSH2 is a complete rewrite of the protocol, and it does not use the same networking implementation that SSH1 does. Also, SSH2 is more secure. Because of the different protocol implementation, they are not compatible.

The SSH v1 implementation is based on the V1.5 protocol and 1.3.7 F-Secure code base, and the SSH2 implementation is based on the V2 protocol and the F-Secure 3.1.0 code base.Both protocols are offered by the SSH for OpenVMS server, and although they are incompatible, they may exist simultaneously on an SSH for OpenVMS system. The server front-end identifies what protocol a client desires to use, and will create an appropriate server for that client.
   
SSH2 is the current version of the Secure Shell protocol, with a draft under consideration by a working group of the Internet Engineering Task Force (IETF) - the first step in the IETF standards process. The SSH2 protocol was a complete reconception of the protocol and is intended to remove limitations in SSH1, such as the absence of message authentication codes (MACs). The SSH1 draft documentation is not part of the IETF process, and does not match the current SSH1 server implementations. SSH1 has a significant installed base, particularly among early adopters of Secure Shell, and has a more open server licensing for some organizations. However, the maturity and improved security of SSH2 makes  preferred protocol. SSH2 version is fully backwards compatible with SSH1.                                                                                                                                                                                                                  

SSH uses the following ciphers for encryption:
Cipher SSH1 SSH2
DES yes no
3DES yes yes
IDEA yes yes
Blowfish yes yes
Twofish no yes
Arcfour no yes
Cast128-cbc no yes

SSH uses the following ciphers for authentication:
Cipher SSH1 SSH2
RSA yes yes
DSA no yes

                                                                                                                                                                                                                                  

Summary                                                                                                                        


With SSH it is possible to create a secure communication channel between the server and the client. This channel can be used for different purposes, not necessarily for launching a remote terminal session but also for sending any data using the forwarding feature. SSH supports a variety of authentication methods, and new options may be added if required.  Data in transit can be protected with multiple symmetric algorithms that use the key negotiated at the beginning of an SSH session. Both the client and the server can authenticate each other to enhance security against different kinds of attacks.
                                                                                                                                                                                                                                         

APPENDIX                                                                                                                                   

IP spoofing
A remote machine acts as a node on your local network, finds vulnerabilities with your servers, and installs a backdoor program or trojan to gain control over your network resources.

DNS Spoofing

DNS spoofing occurs when an intruder cracks a DNS server, pointing client systems to a maliciously duplicated host.DNS spoofing leads a DNS server to accept and use incorrect information from a host that has no authority giving that information. DNS spoofing is in fact malicious cache poisoning where forged data is placed in the cache of the name servers. Spoofing attacks can cause serious security problems for DNS servers vulnerable to  attacks.

Port Forwarding

Port forwarding works by mapping a local port on the client to a remote port on the server. SSH can map any port from the server to any port on the client, and the port numbers do not need to match for this technique to work.

IP Source Routing

An IP packet can include an option that specifies (in the packet headers) the route the packet should take to its destination.  If a
router pays attention to IP source routing at all (firewall routers should probably configured NOT to pay attention to such information),
this information can be used to over-ride what the router would normally do with the packet and thus possibly subvert security.  Many
UNIX kernels will forward a source-routed packet EVEN IF "IP Forwarding" has supposedly been disabled on that kernel.

      *** End of  The Document. ***