SECURE SHELL (SSH)

Seminar ID:2863
A Technical Seminar Report
submitted in partial fulfillment of
the requirement for the B.Tech.
under Biju Patnaik University of Technology, Rourkela.

Submitted By
AMIT KUMAR Roll No. # CSE201440735

March- 2017

Under the guidance of

Mr. Arkaprava Bhaduri Mandal

NATIONAL INSTITUTE OF SCIENCE & TECHNOLOGY

Palur Hills, Berhampur, Odisha 761008, India
ABSTRACT

In this modern time, Individuals and organizations worry about security on a regular
basis, be it online or offline, over a network computer or just with a personal computer.
Security of a computer connected to the internet and within a network is very essential as
people need to protect their information and data from unwanted or unauthorized access.
This Report is all about the Application Layer Network Protocol Secure Shell. It is one
of the advance protocols which replaced the trivial Telnet protocol because of having
much security than the latter.

Using Secure Shell, we can control the desktop in our offices sitting at the home. And that
too can be done without worrying about the hackers while transferring file over the
Protocol. SSH is connection oriented which use TCP only, and it is primarily used for
shell based solutions. SSH has been used to replace telnet, rsh, rlogin and many more
protocols for insecurity purpose. Prior to any transfer taking place, the SSH client and
server must first establish a secure connection. This will then allow them to share private
information between each other.

There are two types of versions for the SSH, the first is SSH1 and the second is SSH2.
The SSH1 is the original protocol and it has its own shortfalls, so it is not normally
recommended or in use today. But SSH2 is the common of the two SSH protocols and is
commonly used today as it is more secure and efficient than SSH1. The SSH1 uses server
and host keys to verify the networks while SSH2 uses just the host keys to verify the
networks and even more, they are not compatible with each other.

i
ACKNOWLEDGEMENT

I would like to acknowledge all the people who have been of the help and assisted me

throughout my project work. First of all, I would like to thank my respected guide Mr.

Arkaprava B. Mandal, Professor in Department of Computer Science for introducing me

throughout features needed. The time-to-time guidance, encouragement, and valuable

suggestions received from him are unforgettable in my life. This work would not have

been possible without the enthusiastic response, insight, and new ideas from him.

I am also grateful to all the faculty members of National Institute of Science &

Technology for their support and cooperation.

I would like to thank my lovely parents for time-to-time support and

encouragement and valuable suggestions, and thank my friends for their valuable support

and encouragement.

The acknowledgement would be incomplete without mention of the blessing of

the Almighty, who helped me in keeping high moral during most difficult period.

Amit Kumar

ii
TABLE OF CONTENTS

ABSTRACT.....................................................................................................................i
ACKNOWLEDGEMENT..............................................................................................ii
TABLE OF CONTENTS...............................................................................................iii
LIST OF FIGURES.......................................................................................................iv
LIST OF TABLES...........................................................................................................v

1. INTRODUCTION......................................................................................................1
1.1 What is SSH?......................................................................................................2
2. HISTORY OF SSH.....................................................................................................3
2.1 SSH-1..................................................................................................................3
2.2SSH-2...................................................................................................................3
3. FUNCTIONALITY OF SSH......................................................................................4
3.1 Features of SSH..................................................................................................4
3.2 SSH Security Mechanism...................................................................................4
3.3Client Authentication...........................................................................................6
3.4Additional Features of SSH-2..............................................................................7
3.5Functions..............................................................................................................7
3.6Protocols Basics of Secure Shell..........................................................................9
3.7 Threats Addressed by Secure Shell...................................................................13
4. ALGORITHMS IN THE SSH PROTOCOLS..........................................................17
4.1 Public-Key Algorithms.....................................................................................17
4.2Private-Key Algorithms.....................................................................................18
4.3 Hash-Functions.................................................................................................21
5. SSH- ADVANTAGES AND DISADVANTAGES...................................................23
6. CONCLUSION.........................................................................................................24
REFERENCES..............................................................................................................25

iii
LIST OF FIGURES

Figure 1.1 Confidentiality, Integrity and Authentication.....................................................1

Figure 1.2 SSH Interconnection...........................................................................................2

Figure 3.1 Process of Establishing Secure Connections......................................................6

Figure 3.2 Secure File Transfer............................................................................................8

Figure 3.3 Port Forwarding..................................................................................................9

Figure 3.4Typical Remote Access Security Risks..............................................................11

Figure 3.5Tunneling Over the Internet..............................................................................13

Figure 3.6Tunneling through the Firewall.........................................................................17

iv
LIST OF TABLES

Table3.1 SSH-1 vs. SSH-2.................................................................................................17

v
 Secure Shell

1.Introduction

As Internet access becomes increasingly inexpensive and available, it has become

a viable replacement for traditional couriers, telephone, and fax, as well as remote dial-up
access to a companys internal computer resources. One of the biggest challenges in using
the Internet is to replace the more traditional communications is security.[1] In the past,
companies have maintained their own modem bank dial-up access to company resources
so that critical data was not being transmitted over the public network. Modem banks are
expensive to maintain and do not scale well. In a large company, long distance charges for
road warriors alone can make this an expensive solution. Security Requirements: There
are three core security requirements for a remote administrative access technology.
Confidentiality: The transmitted data must not be readable by unauthorized parties on the
network. Confidentiality is achieved through encryption.
Integrity: Unauthorized parties must not be able to modify the data without detection.
Integrity is achieved by using checksum values, which allow detection of tampering
attempts at the receiving end.
Authentication: Both parties of the communication must be able to identify each other
reliably, so that no one can masquerade as the other party. Authentication can be
implemented by using challenge passwords, for example. However, the strongest
authentication is achieved through public-key cryptography and digital signatures.[1]

Figure 1.1: Confidentiality, Integrity and Authentication[1]

1
 Secure Shell

1.1What is SSH?

Although SSH stands for Secure Shell, it is not a true shell in the sense of the Unix
Bourne shell and C shell. It is not a command interpreter, nor does it provide wildcard
expansion, command history, and so forth.[1] Rather, Secure Shell is a protocol that
provides authentication, encryption and data integrity to secure network communications.
Implementations of Secure Shell offer the following capabilities: a secure command-
shell, secure file transfer, and remote access to a variety of TCP/IP applications via a
secure tunnel. Secure Shell client and server applications are widely available for most
popular operating systems.
In short, SSH makes network connections between computers, with strong guarantees that
the parties on both ends of the connection are genuine. It also ensures that any data
passing over these connections arrives unmodified and unread by eavesdroppers.

Figure 1.2: SSH Interconnection (Source: zend.com)

2
 Secure Shell

2. History of SSH

Secure Shell was created in 1995 by Finland native TatuYlnen, a researcher at the
Helsinki University of Technology, in response to a password-sniffing attack at his
university. Seeing the flaws in plain text communication for secure information, Tatu
created Secure Shell/SSH with a strong emphasis on encryption and security.

2.1 SSH-1

The first version of SSH protocol (now called as SSH-1 protocol) were developed in 1995
by TatuYlnen, in Finland. After his university network was the victim of a password-
sniffing attack earlier that year, Ylnen whipped up SSH-1 for himself. When beta
versions started gaining attention, however, he realized that his security product could be
put to wider use.[2]
In July 1995, SSH-1 was released to the public as free software with source code,
permitting people to copy and use the program without cost. By the end of the year, an
estimated 20,000 users in 50 countries had adopted SSH-1, and Ylnen was fending off
150 email messages per day requesting support. In response, Ylnen founded SSH
Communications Security, Ltd., (SCS, http://www.ssh.com/) in December of 1995 to
maintain, commercialize, and continue development of SSH. Today he is chairman and
chief technology officer of the company.

2.2 SSH-2

"Secsh" was the official Internet Engineering Task Force's (IETF) name for the IETF
working group responsible for version 2 of the SSH protocol. In 2006, a revised version
of the protocol, SSH-2, was adopted as a standard. This version is incompatible with
SSH-1. SSH-2 features both security and feature improvements over SSH-1. Better
security, for example, comes through DiffieHellman key exchange and strong integrity
checking via message authentication codes. New features of SSH-2 include the ability to
run any number of shell sessions over a single SSH connection. Due to SSH-2's
superiority and popularity over SSH-1, some implementations such as Lsh and Dropbear
support only the SSH-2 protocol.

3
 Secure Shell

3. Functionality of Secure Shell

This section gives an overall picture of how the features are implemented in Secure Shell
to guarantee security of a network connection.

3.1 Features of SSH

The major features of the Secure Shell protocol are Privacy, Integrity, Authentication,
Authorization, and Forwarding.
Privacy: of data is obtained via strong end-to-end encryption that is based on
random keys which are securely negotiated for that session, and then destroyed
when the session is over. SSH supports encryption algorithms such as DES,
IDEA, Blowfish, ARC-FOUR, and triple-DES. The next section goes into the
details of the security mechanism.
Integrity: .SSH1 uses a weak method which is a 32 bit Cyclic Redundancy
Check (CRC-32) on the unencrypted data in each packet.SSH2 uses keyed hash
algorithms based on MD5 and SHA1.
Authentication: involves server authentication which is done using the servers
host key, and client authentication is usually done by password authentication or
public key authentication.
Authorization: occurs after authentication, and is controlled at a server wide
level or per account basis.
SSH supports Forwarding, means encapsulating another TCP based service such
as Telnet within an SSH session. For example, by forwarding telnet through SSH,
all data are automatically encrypted, integrity checked, and authenticated using
SSH credentials.

3.2 SSH Security Mechanism

Four keys are used in SSH to establish a secure connection. They are the user key, session
key, host key and server key. Of these, the session key is private and all the other three
keys are public keys.

4
 Secure Shell

Establishing the Secure Connection

Typically, the client initiates the connection by sending a request to the TCP port of the
SSH server. At this point all communication is un-encrypted. Server reveals it's SSH
protocol version to the client. If the client and server decide their versions are compatible,
the connection process continues; other wise either party may decide to terminate the
connection. After protocol version is accepted, client and server switch to a packet-based
protocol.
SSH server then sends the following to the client - its host key which is used to identify
itself, the server key which helps to establish the secure connection, a list of supported
encryption, compression and authentication methods, and a sequence of eight random
bytes. Client checks identity of server by using the host key, and checking it in the
known-hosts database. If Client rejects host key, connection ends. Client then, has to
prove its identity by including the eight random bytes called check bytes in its next
response. This is a built-in mechanism to prevent IP spoofing.[6]

In the next step, the client generates a session key, which is a private key used to encrypt
and decrypt the real data. The SSH client generates the session key and encrypts it with
the public host key it received from the server. Generated output is again encrypted with
the server key (the client received from the server). This double encrypted session key is
then sent to the server along with the check bytes and acceptable algorithm. Server then
decrypts the session key it received. It then sends to the client a confirmation
(acknowledgement) which is encrypted with this session key. Once the client gets the
confirmation from the proper server (which accepted and deciphered the session key
encrypted with the host key verified earlier), the server authentication is also
confirmed, and the real encrypted SSH communication starts. Session key is encrypted
twice for added security. Server key changes periodically, so even if unauthorized client
has the old key, for a new session such unauthorized client cannot create a valid session
key. Entire process of establishing a secure connection is shown in Figure:

5
 Secure Shell

Figure 3.1: Process of Establishing Secure Connections

3.3 Client Authentication

After the secure connection is established, the client attempts to authenticate itself. There
are many methods of authentication. Here, we discuss two widely used ones which are
password authentication and public-key authentication.
User on the client machine types in the password, which is sent through the encrypted
channel. Server uses the password authentication mechanism of server operating system
to check the validity. User is granted login connection on successful validation against the
password database. This authentication mechanism does not need any additional
configuration on the server side.
In public key authentication, client sends the server a part of authorization private key.
Server receives it and checks for the corresponding public key in ~/.ssh/authorized_keys
(where ~ stands for user's home directory). If the server finds the corresponding public
part, connection proceeds otherwise connection is ended. If it proceeds, server checks for
authorization restrictions and proceed accordingly. After successful authorization, server
generates random 256-bit challenge string, encrypts it with clients public key and send to
client. Client decrypts it with private key, then generates a hash value with a session
identifier and sends hash value to server. Server generates hash value of the challenge, if
those match; session is authenticated, otherwise not. The public key method is the most
secure authentication method for SSH.

6
 Secure Shell

3.4 Additional features of SSH2

SSH-2 is a new protocol, an improvement over SSH-1. Recently, SSH communications

security Ltd., introduced SSH-3. SSH-2, unlike SSH-1 is a combination of three separate
protocols. These three modular protocols are SSH-Transport layer protocol, SSH-
Authentication protocol and SSH-Connection protocol. SSH-1 has a single host table for
server and client authentication. SSH-2 keeps 2 different tables, one each for server
authentication and client authentication. Servers running SSH-2 can also run SSH-1 to
take care of clients running SSH-1. Unlike SSH-1, host based authentication is
independent of client machines network used. Thus, a client machine can be behind a
proxy server or even can use NAT (Network address translation). SSH-2 allows more than
one form of user authentication per session. The need for server key (which is an integral
part of SSH-1) is removed in SSH2. SSH2 allows any number of sessions per
connection. (SSH-1 only allows one session per connection). Unlike SSH-1, SSH-2 uses
Message Authentication Code (MAC) algorithm for integrity checking.

3.5 Functions

Secure Shell provides three main capabilities, which open the door for many creative
secure solutions. -Secure command shell -Secure file transfer -Port forwarding

3.5.1 Secure Command Shell

Command shells such as those available in Linux, Unix, Windows, or the familiar DOS
prompt provide the ability to execute programs and other commands, usually with
character output. A secure command-shell or remote log on allows you to edit files, view
the contents of directories and access custom database applications. Systems and network
administrators can remotely start batch jobs, start, view or stop services and processes,
create user accounts, change permissions to files and directories and more. Anything that
can be accomplished at a machines command prompt can now be done securely from the
road or home.

3.5.2 Secure File Transfer

7
 Secure Shell

Secure File Transfer Protocol (SFTP) is a subsystem of the Secure Shell protocol. In
essence, it is a separate protocol layered over the Secure Shell protocol to handle file
transfers. SFTP has several advantages over non-secure FTP. First, SFTP encrypts both
the username/password and the data being transferred. Second, it uses the same port as
the Secure Shell server, eliminating the need to open another port on the firewall or
router. Using SFTP also avoids the network address translation (NAT) issues that can
often be a problem with regular FTP. One valuable use of SFTP is to create a secure
extranet or fortify a server or servers outside the firewall accessible by remote personnel
and/or partners. Typical uses of a secure extranet include uploading of files & reports and
providing a secure mechanism for remote administration file oriented tasks. A secure
extranet is one of the safest ways to make specific data available to customers, partners
and remote employees. Using SFTP on your extranet machines effectively restricts access
to authorized users and encrypts usernames, passwords and files sent to or from

Figure 3.2: Secure File Transfer (Source: 4changboard.wikia.com)

3.5.3 Port Forwarding

Port forwarding is a powerful tool that can provide security to TCP/IP applications
including e-mail, sales and customer contact databases, and in-house applications. Port
forwarding, sometimes referred to as tunneling, allows data from normally unsecured
TCP/IP applications to be secured. After port forwarding to be set up, Secure Shell
reroutes traffic from a program (usually a client) and sends it across the encrypted tunnel,
then delivers it to a program on the other side (usually a server). Multiple applications can

8
 Secure Shell

transmit data over a single multiplexed channel, eliminating the need to open additional
vulnerable ports on a firewall or router. For some applications, a secure remote command
shell is not sufficient and graphical remote control is necessary. Secure Shells port
forwarding capabilities can be used to create an encrypted tunnel over which an
application can be run. Virtual Network Client, a cross platform GUI remote control
application is a good example. Now we are going to tell about tunneling or port
forwarding in detail. The following sections include tunneling over the Internet, Intranet
and to the shared resources and we explain how Secure Shell tunneling works:

Figure 3.3: Port Forwarding (Source: 14core.com)

Tunneling with Secure Shell can help by eliminating open ports, blocking unauthorized
users, and ensuring the privacy and integrity of all SMTP, POP, and IMAP traffic
exchanged between mail clients and servers.

3.6 Protocol Bacics of Secure Shell

The Secure Shell protocol provides four basic security benefits:

I. User Authentication
II. Host Authentication
III. Data Encryption
IV. Data Integrity

3.6.1 User Authentication

9
 Secure Shell

Authentication, also referred to as user identity, is the means by which a system verifies
that access is only given to intended users and denied to anyone else. Many authentication
methods are currently used, ranging from familiar typed passwords to more robust
security mechanisms. Most Secure Shell implementations include password and public
key authentication methods but others (e.g. kerberos, NTLM, and keyboard interactive)
are also available. The Secure Shell protocols flexibility allows new authentication
methods to be incorporated into the system, as they become available.[6]

3.6.1.1 Password authentication

Passwords, in combination with a username, are a popular way to tell another computer
that you are who you claim to be. If the username and password given at authentication
match the username and password stored on a remote system, you are authenticated and
allowed access. Some protocols like FTP and Telnet send usernames and passwords as
easily visible ASCII text in the clear, allowing anyone with a sniffer program to easily
capture them and then gain access to the system. Secure Shell safeguards against this
attack by encrypting all data, including usernames and passwords, before transmission.
Although passwords are convenient, requiring no additional configuration or setup for
your users, they are inherently vulnerable in that they can be guessed, and anyone who
can guess your password can get into your system.[6] Due to these vulnerabilities, it is
recommended that you combine or replace password authentication with another method
like public key.

3.6.1.2 Public Key Authentication

Public key authentication is one of the most secure methods to authenticate using Secure
Shell. Public key authentication uses a pair of computer generated keys- one public and
one private. Each key is usually between 1024 and 2048 bits in length. Even though you
can see it, it is useless unless you have the corresponding private key. Public-private keys
are typically generated using a key generation utility. Both keys in the pair are generated
at the same time and, while the two are related, a private key cannot be computed from a
corresponding public key. In addition to authentication, keys can also be used to sign
data.

10
 Secure Shell

To access an account on a Secure Shell server, a copy of the clients public key must be
uploaded to the server. When the client connects to the server, it proves that it has the
secret or private counterpart to the public key on that server, and access is granted. The
private key never leaves the client machine, and therefore cannot be stolen or guessed like
a password can. Usually the private key has a passphrase associated with it, so even if
the private key is stolen, the attacker must still guess the passphrase in order to gain
access. Public key authentication does not trust any information from a client or allow
any access until the client can prove it has the secret private key.
Agent Forwarding Secure Shell Agent is a way to authenticate to multiple Secure Shell
servers that recognize your public key without having to re-type your passphrase each
time. Additionally, by turning on agent forwarding, you can connect to a network of
Secure Shell servers, eliminating the need to compromise the integrity of your private
key. Notice that the private key only has to exist on the original SSHclient machine and
the passphrase only needs to be typed when SSHClient connects to SSHServerA. Without
agent forwarding enabled, each Secure Shell machine in the chain (except the last) would
have to store a copy of the private key. SSHServerA, when authenticating SSHClient to
SSHServerB becomes, in essence, a client and would require a private key to complete
the authentication process. Agent support eliminates the need for the pass phrase to be
typed for each connection in the sequence.

11
 Secure Shell

Figure 3.4: Typical Remote Access Security Risks (Source: iconlabs.com)

3.6.2 Host Authentication

A host key is used by a server to prove its identity to a client and by a client to verify a
known host. Host keys are described as persistent (they are changed infrequently) and
are asymmetric much like the public/private key pairs discussed above in the Public key
section. If a machine is running only one SSH server, a single host key serves to identify
both the machine and the server. If a machine is running multiple SSH servers, it may
either have multiple host keys or use a single key for multiple servers. Host authentication
guards against the Man-in-the-Middle attack. Host keys are often confused with session
keys, which are used in the data encryption process discussed below.

3.6.3 Data Encryption

Encryption, sometimes referred to as privacy, means that your data is protected from
disclosure to a would-be attacker sniffing or eavesdropping on the wire. Ciphers are the
mechanism by which Secure Shell encrypts and decrypts data being sent over the wire. A
block cipher is the most common form of symmetric key algorithms (e.g. DES, 3DES,

12
 Secure Shell

Blowfish, AES, and Twofish). These operate on a fixed size block of data, use a single,
secret, shared key, and generally involve multiple rounds of simple, non-linear functions.
The data at this point is encrypted and cannot be reversed without the shared key. When
a client establishes a connection with a Secure Shell server, they must agree which cipher
they will use to encrypt and decrypt data. The server generally presents a list of the
ciphers it supports, and the client then selects the first cipher in its list that matches one in
the servers list. Session keys are the shared keys, described above and are randomly
generated by both the client and the server during establishment of a connection. Both the
client and host use the same session key to encrypt and decrypt data although a different
key is used for the send and receive channels. Session keys are generated after host
authentication is successfully performed but before user authentication so that usernames
and passwords can be sent encrypted. These keys may be replaced at regular intervals
(e.g., every one to two hours) during the session and are destroyed at its conclusion.

3.6.4 Data Integrity

Data integrity guarantees that data sent from one end of a transaction arrives unaltered at
the other end. Even with Secure Shell encryption, the data being sent over the network
could still be vulnerable to someone inserting unwanted data into the data stream Secure
Shell version 2 (SSH2) uses Message Authentication Code (MAC) algorithms to greatly
improve upon the original Secure Shells (SSH1) simple 32-bit CRC data integrity
checking method. Other Benefits: Compression, another feature of the Secure Shell
protocol, is performed prior to encryption and can significantly reduce the computational
cost of encrypting data. Compression can also noticeably improve the efficiency of a
connection and is especially beneficial in file transfers, X11 forwarding and running
curses-style programs. Secure Shell provides helpful output or log messages. These
messages can be turned on or off or configured to give varying levels of detail. Log
messages can prove very helpful when trouble shooting a problem. For example, if a
client were unable to connect to a given server, this log output would be the first place to
look to determine the source of the problem.

13
 Secure Shell

Figure 3.5: Tunneling over the Internet (Source: maketecheasier.com)

3.7 Threats Addressed by Secure Shell

Below is a discussion of the threats that Secure Shell is well suited to protect your system
against. Eavesdropping or Password Sniffing An eavesdropper is a network device, also
known as a sniffer, which will intercept information being transmitted over the wire.
This sniffing takes place without the knowledge of either the client or server and is called
passive monitoring. User data including passwords can be stolen this way if you use
insecure protocols like telnet and FTP. Because the data in a Secure Shell session is
encrypted, it is not vulnerable to this kind of attack and cannot be decrypted by the
eavesdropper.

3.7.1 Man-In-The-Middle Attack (MITM)

If the first connection and host key exchange between a client and a particular host is
compromised, the MITM attack fools both the client and server into thinking that they are
communicating directly with one another when, in fact, an attacker is actually
intercepting all traffic between the two as illustrated below: The client (Bob) initiates a
connection withthe server (Alice). Unknown to both Bob and Alice, an attacker (Eve) is
waiting to intercept their connection negotiation. Eve receives Bobs request for a
connection and authenticates herself as Alice. Eve then initiates a connection with Alice
posing as Bob and authenticates herself. Two secure SSH sessions are now in place with
Eve reading all of the data beingpassed between Bob and Alice in clear text. Secure Shell

14
 Secure Shell

protects against MITM attacks through server host authentication. Unless the host itself
has been compromised, Eve does not have access to the servers private key and cannot
impersonate Alice.

Insertion and Replay Attacks: Secure Shells implementation of Message Authentication

Code algorithms prevents the threat of a replay or insertion attack. In this type of
attack, the attacker is not only monitoring your Secure Shell session but is also observing
your keystrokes (either physically, as in looking over your shoulder or by monitoring your
terminals keyboard with software). By comparing what you type with the traffic in the
SSH stream, an attacker can deduce the packet containing a particular command (delete
all files, for example) and replay that command at a particularly inappropriate time
during your session. Need for Policy with Secure Shell: No single piece of software can
be a complete security solution. There are factors beyond securing communications
through strong authentication and encryption that must be considered. The physical
environment and the human factor are often overlooked as significant contributing
factors to security breaches. The following list provides a suggested starting point for
issues and areas of concern that a thorough security policy should address:
Password and/or passphrase policies are needed so that users dont select short, weak or
guessable passwords. In addition, you should have a policy that states how often a
password should be changed, and whether or not passwords can be reused. Site security is
a critical area that many organizations fail to address adequately. Portable computer users
should be provided with security devices such as locking cables and encouraged not to
leave these devices unattended, even for a minute or two?. Physical access to servers,
routers, network connections and backup media should be secured and limited only to
those personnel who require it. Security audits of service providers are an excellent next
step after your physical plant is secure and policies and procedure for your organization
have been established and implemented. Internet Service Providers (ISP), Application
Service Providers (ASP) and data storage vendors generally have robust physical and
logical security in place. An audit may reveal deficiencies in their policies and physical
plant but will more likely provide your organization with additional ideas to improve your
own security plan. Backup procedures are generally adopted for servers but often
overlooked or ignored for client workstations. Implementing network backup procedures
can protect and insure retrieval of valuable data if a client machine is lost, stolen or

15
 Secure Shell

damaged. Using Secure Shell with the above policies in place will enable you to
economically, privately, effectively and safely use public networks like the Internet to do
your day-today business communications with remote users or business partners.

SSH1 vs. SSH2

SSH protocol, version 2 SSH protocol, version 1

Separate transport, authentication, and
One monolithic protocol
connection protocols
Weak CRC-32 integrity check; admits an
Strong cryptographic integrity check insertion attack in conjunction with some
bulk ciphers.
Supports password changing N/A
Exactly one session channel per connection
Any number of session channels per
(requires issuing a remote command even
connection (including none)
when you don't want one)
Full negotiation of modular cryptographic and
Negotiates only the bulk cipher; all others
compression algorithms, including bulk
are fixed
encryption, MAC, and public-key
The same algorithms and keys are used in
Encryption, MAC, and compression are
both directions (although RC4 uses
negotiated separately for each direction, with
separate keys, since the algorithm's design
independent keys
demands that keys not be reused)
Extensible algorithm/protocol naming scheme
Fixed encoding precludes interoperable
allows local extensions while preserving
additions
interoperability
Supports a wider variety:
User authentication methods: public-key (RSA only)
Public-key (DSA, RSA*, OpenPGP) R-hosts RSA
Host-based password
password R hosts (rsh-style)
TIS
(R-hosts dropped due to insecurity)
Kerberos
Use of Diffie-Hellman key agreement removes Server key used for forward secrecy on the
the need for a server key session key
Supports public-key certificates N/A
User authentication exchange is more flexible,
Allows for exactly one form of
and allows requiring multiple forms of
authentication per session.
authentication for access.
hostbased authentication is in principle RhostsRSA authentication is effectively
independent of client network address, and so tied to the client host address, limiting its
can work with proxying, mobile clients, etc. usefulness.

16
 Secure Shell

(though this is not currently implemented).

periodic replacement of session keys N/A

Table 3.1 SSH-1 vs. SSH-2

Figure 3.6: Tunneling through the firewall (Source: mikefrank.wordpress.com)

4. Algorithms In The SSH Protocols

Secure Shell Protocol (SSH) uses the standard algorithms namely DES, AES and the
RSA. Any user normally can use these algorithms which is being specified by the SSH
protocol. As it is an OpenSSH, it is possible for the hackers to break the security during
transmission of data. The idea behind the paper was when we allow the users to specify
their own encryption techniques, which is not known to others can improve their security
and also from hackers breaking the code. This will help the user to create their encryption
standards in the SSH protocol which provides more security to the users network and
known only to the users.

4.1 Public Key Algorithms

There are three types of Public Key Encryption schemes. It has been discussed in this
sections

4.1.1 Rivest-Shamir-Adleman (RSA)

17
 Secure Shell

The Rivest-Shamir-Adleman public-key algorithm (RSA) is the most widely used

asymmetric cipher. It derives its security from the difficulty of factoring large integers
that are the product of two large primes of roughly equal size. Factoring is widely
believed to be intractable(i.e., infeasible, admitting no efficient, polynomial-time
solution), although this isnt proven. RSA can be used for both encryption and signatures.
Until the mid-1990s, RSA Security provided a freely available reference implementation,
RSAref, with a license allowing educational and broad commercial use (as long as the
software itself was not sold for profit). Since RSA is now in the public domain, theres no
longer any reason to use RSAref. It is no longer supported, some versions contain security
flaws, and there are better implementations out there; we discourage its use.

4.1.2 Digital Signature Algorithm (DSA)

The Digital Signature Algorithm (DSA) was developed by the U.S. National Security
Agency (NSA), and promulgated by the U.S. National Institute of Standards and
Technology (NIST) as part of the Digital Signature Standard (DSS). The DSS was issued
as a Federal Information Processing Standard, FIPS-186, in May 1994. It is a public-key
algorithm, based on the Schnorr and ElGamal methods, and relies on the difficulty of
computing discrete logarithms in a finite field. It is designed as a signature-only scheme
that cant be used for encryption, although a fully general implementation may easily
perform both RSA and ElGamal encryption.

4.1.3 Diffie-Hellman key Agreement

The Diffie-Hellman key agreement algorithm was the original public-key system,
invented by Whitfield Diffie, Martin Hellman, and Ralph Merkle in 1976. It was patented
by them in 1977 (issued in 1980, patent 4,200,770); that patent has now expired, and the
algorithm is in the public domain. Like DSA, it is based on the discrete logarithm
problem, and it allows two parties to derive a shared secret key securely over an open
channel. That is the parties engage in an exchange of messages, at the end of which they
share a secret key. It isnt feasible for an eavesdropper to determine the shared secret
merely from observing the exchanged messages. SSH-2 uses the Diffie-Hellman
algorithm as its required (and currently, its only defined) key-exchange method

4.2 Private-key Algorithms

18
 Secure Shell

Symmetric encryption (also called private-key encryption or secret-key encryption)

involves using the same key for encryption and decryption.

4.2.1 International Data Encryption Algorithm (IDEA)

The International Data Encryption Algorithm (IDEA) was designed in 1990 by Xuejia Lai
and James Massey, and went through several revisions, improvements,andrenamings
before reaching its current form. Although relatively new, it is considered secure; the
wellknown cryptographer Bruce Schneier in 1996 pronounced it the best and most
secure block algorithm available to the public at this time.X. Lai and J. Massey, A
Proposal for a New Block Encryption Standard,Advances in Cryptology EUROCRYPT
92 Proceedings, Springer-Verlag,1992, pp 389-404.IDEA is patented in Europe and the
United States by the Swiss company Ascom-Tech AG.The name IDEA is a trademark
of Ascom-Tech. The attitude of Ascom-Tech towards this patent and the use of IDEA in
the United States has changed over time, especially with regard to its inclusion in PGP. It
is free for noncommercial use. Government or commercial use may require a royalty,
where commercial use includes use of the algorithm internal to a commercial
organization, not just directly selling an implementation or offering its use for profit

4.2.2 Dtata Encryption Standard (DES)

The Data Encryption Standard (DES) is the aging workhorse of symmetric encryption
algorithms. Designed by researchers at IBM in the early 1970s under the name Lucifer,
the U.S. government adopted DES as a standard on November 23, 1976 (FIPS-46). It was
patented by IBM, but IBM granted free worldwide rights to its use. It has been used
extensively in the public and private sectors ever since. DES has stood up well to
cryptanalysis over the years and is becoming viewed as outdated only because its 56-bit
key size is too small relative to modern computing power. A number of well-publicized
designs for special-purpose DES-cracking machines have been put forward, and their
putative prices are falling more and more into the realm of plausibility for governments
and large companies. It seems sure that at least the NSA has such devices. Because of
these weaknesses, NIST is currently in the process of selecting a successor to DES, called
the Advanced Encryption Standard (AES).

4.2.3 Triple-DES

19
 Secure Shell

Triple-DES, or 3DES, is a variant of DES intended to increase its security by increasing

the key length. It has been proven that the DES function doesnt form a group over its
keys, which means that encrypting multiple times with independent keys can increase
security. 3DES encrypts the plaintext with three iterations of the DES algorithm, using
three separate keys. The effective key length of 3DES is 112 bits, a vast improvement
over the 56-bit key of plain DES

4.2.4 ARCFOUR (RC4)

Ron Rivest designed the RC4 cipher in 1987 for RSA Data Security, Inc.(RSADSI); the
name is variously claimed to stand for Rivest Cipher or Rons Code. It was an
unpatented trade secret of RSADSI, used in quite a number of commercial products by
RSADSI licensees. In 1994, though, source code claiming to implement RC4 appeared
anonymously on the Internet. Experimentation quickly confirmed that the posted code
was indeed compatible with RC4, and the cat was out of the bag. Since it had never been
patented, RC4 effectively entered the public domain. This doesnt mean that RSADSI
wont sue someone who tries to use it in a commercial product, so it is less expensive to
settle and license than to fight. We arent aware of any test cases of this issue. Since the
name RC4 is trademarked by RSADSI, the name ARCFOUR has been coined to
refer to the publicly revealed version of the algorithm. ARCFOUR is very fast but less
studied than many other algorithms. It uses a variable-sized key; SSH-1 employs
independent 128-bits keys for each direction of the SSH session. The use of independent
keys for each direction is an exception in SSH-1, and crucial: ARCFOUR is essentially a
pad using the output of a pseudo-random number generator. As such, it is important never
to reuse a key because to do so makes cryptanalysis trivially easy. If this caveat is
observed, ARCFOUR is considered secure by many, despite the dearth of public
cryptanalytic results.

4.2.5 Blowfish

Blowfish was designed by Bruce Schneier in 1993, as a step toward replacing the aging
DES. It is much faster than DES and IDEA, though not as fast as ARCFOUR, and is
unpatented and free for all uses. It is intended specifically for implementation on large,
modern, general-purpose microprocessors and for situations with relatively few key
changes. It isnt particularly suited to low-end environments such as smart cards. It
employs a variable-sized key of 32 to 448 bits; SSH-2 uses 128-bit keys. Blowfish has

20
 Secure Shell

received a fair amount of cryptanalytic scrutiny and has proved impervious to attack so
far. Information is available from Counterpane, Schneiers security consulting company.

4.2.6 Twofish

Twofish is another design by Bruce Schneier, together with J. Kelsey, D. Whiting, D.

Wagner, C. Hall, and N. Ferguson. It was submitted in 1998 to the NIST as a candidate
for the Advanced Encryption Standard, to replace DES as the U.S. governments
symmetric data encryption standard. Two years later, it is one of the five finalists in the
AES selection process, out of 15 initial submissions. Like Blowfish, it is unpatented and
free for all uses, and Counterpane has provided uncopyrighted reference implementations,
also freely usable. Twofish admits keys of lengths 128, 192, or 256 bits; SSH-2 specifies
256-bit keys. Twofish is designed to be more flexible than Blowfish, allowing good
implementation in a larger variety of computing environments (e.g., slower processors,
small memory, in-hardware). It is very fast, its design is conservative, and it is likely to be
quite strong

4.2.7 CAST

CAST was designed in the early 1990s by Carlisle Adams and Stafford Tavares. Tavares
is on the faculty of Queens University at Kingston in Canada, while Adams is an
employee of Entrust Technologies of Texas. CAST is patented, and the rights are held by
Entrust, which has made two versions of the algorithm available on a worldwide royalty-
free basis for all uses. These versions are CAST-128 and CAST-256, described in RFC-
2144 and RFC-2612, respectively. SSH-2 uses CAST-128, which is named for its 128-bit
key length.

4.3 Hash Functions

A hash function is a mathematical function that converts a numerical input value into
another compressed numerical value. The input to the hash function is of arbitrary length
but output is always of fixed length. Values returned by a hash function are called
message digest or simply hash values.

21
 Secure Shell

4.3.1 CRC-32

The 32-bit Cyclic Redundancy Check (CRC-32), defined in ISO 3309, is a non
cryptographic hash function for detecting accidental changes to data. The SSH-1 protocol
uses CRC-32 (with the polynomial 0xEDB88320) for integrity checking, and this
weakness admits the insertion attack discussed later. SSH-2 protocol employs
cryptographically strong hash functions for integrity checking, obviating this attack.

4.3.2 MD5

MD5 (Message Digest algorithm number 5) is a cryptographically strong, 128-bit hash

algorithm designed by Ron Rivest in 1991, one of a series he designed for RSADSI (MD2
through MD5). MD5 is unpatented, placed in the public domain by RSADSI, and
documented in RFC-1321. It has been a standard hash algorithm for several years, used in
many cryptographic products and standards. A successful collision attack against the
MD5 compression function by den Boer and Bosselaers in 1993 caused some concern,
and though the attack hasnt resulted in any practical weaknesses, there is an expectation
that it will, and people are beginning to avoid MD5 in favor of newer algorithms.
RSADSI themselves recommend moving away from MD5 in favor of SHA-1 or
RIPEMD-160 for future applications demanding collision-resistance.

4.3.3 SHA-1

SHA-1 (Secure Hash Algorithm) was designed by the NSA and NIST for use with the
U.S. government Digital Signature Standard. Like MD5, it was designed as an
improvement on MD4, but takes a different approach. It produces 160-bit hashes. There
are no known attacks against SHA-1, and, if secure, it is stronger than MD5 simply for its
longer hash value. It is starting to replace MD5 in some applications; for example, SSH-2
uses SHA-1 as its required MAC hash function, as opposed to MD5 in SSH-1.

4.3.4 RIPEMD-160

Yet another 160-bit MD4 variant, RIPEMD-160, was developed by Hans Dobbertin,
AntoonBosselaers, and Bart Preneel as part of the European Community RIPE project.
RIPE stands for RACE Integrity Primitives Evaluation RACE, in turn, was the program
for Research and Development in Advanced Communications Technologies in Europe, an

22
 Secure Shell

ECsponsored program which ran from June 1987 to December 1995, RIPE was part of
the RACE effort, devoted to studying and developing data integrity techniques. Hence,
RIPEMD-160 should be read as the RIPE Message Digest (160 bits).

4.3.5 Compression Algorithms:zlib

zlib is currently the only compression algorithm defined for SSH. In the SSH protocol
documents, the term zlib refers to the deflate lossless compression algorithm as first
implemented in the popular gzip compression utility, and later documented in RFC-1951.
It is available as a software library called ZLIB.

5. SSH- Advantages and Disadvantages

In this section, the pros and cons has been discussed.

5.1 Advantages
It is reliable, it is available free and also in commercial versions
It never trusts the network.

If the network is experiencing a hostile takeover, it will only disconnect the SSH,
but any decryption or connection take over is impossible.

It is possible to tunnel TCP based applications through SSH, e.g., email protocols.

For system administrators, SSH is a popular remote administration platform.

Although, the server runs on UNIX, Linux and VMS, SSH clients can run on most
platforms.

23
 Secure Shell

Many authentication methods including Kerberos, TIS, SecurID and RSA can be
SOCKS5 proxy aware.

5.2 Disadvantages
SSH is not designed to be added into network gateways such as routers or
firewalls.
Performance for SSH can be a problem on old machines.

Its port range and dynamic ports cannot be forwarded.

A client on the Internet that uses SSH to access the Intranet can expose the
Intranet by port forwarding.

When a user authenticates themself on a server, it is always sent in clear text.

6. CONCLUSION

SSH is a powerful, convenient approach to protecting communications on a computer

network. Through secure authentication and encryption technologies, SSH supports
secure remote logins, secure remote command execution, secure file transfers, access
control, TCP/IP port forwarding, and other important features.
The Secure Shell technology provides you with network security tools that help
compliment your system and data security. With Secure Shell, remote connections are
encrypted and the administrators can decide which means of authentication they require.
Additionally, Secure Shell enables you to create secure remote backups and tunnel other
TCP-based traffic. Using Secure Shell ensures that your mission-critical data is safe from
eavesdropping while traversing the Internet and the users of the data are strongly
authenticated. The SSH2 protocol provides robust security services over TCP transport
layer. These include strong, secure authentication methods, data confidentiality, and

24
 Secure Shell

integrity. Secure Shell products utilize this security layer to provide tools like interactive
and scripted command-line access and file transfer capabilities. There is a family of end-
user binary products, which are widely used by system and network administrators today.
Secure Shell Protocol (SSH) uses the standard algorithms namely DES, AES and the
RSA. Any user normally can use these algorithms which is being specified by the SSH
protocol.

25
 Secure Shell

REFERENCES

[1] Daniel J. Berrett, Richard E. Silverman, Robert G. Byrness book SSH: The Secure
Shell. The definitive guide
[2] www.wikipedia.com (last modified on 10 February 2017, at 05:37)
[3] http://www.snailbook.com/faq/ssh-1-vs-2.auto.html "ssh- frequently asked questions"
by snailbook
[4] James Bamfords book, The Puzzle Palace (Penguin), for an investigative history of
theNSA.
[5] http://www.iconlabs.com/prod/products/secure-remote-access/iconfidant - Iconfidant
SSH
[6] http://ieeexplore.ieee.org/document/5395032/?reload=true - IEEE

26