Secure Shell
Tam Ngo
Steve Licking
Secure Shell (SSH)
Tam Ngo
Steve Licking
San Jose State University
March 25, 2005
CS265 - Cryptography and Computer Security
Section 1
Page 1 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
Table of Contents
Abstract
3
Acronyms
3
1.0 Introduction to Secure Shell (SSH)
4
1.1 The History of Secure Shell
4
1.2 SSH-1 and SSH-2
4
1.3 What does Secure Shell Protect Against?
5
2.0 SSH Encryption Technique
5
2.1 How does Secure Shell Work?
5
3.0 SSH-2 Architecture
7
4.0 Possible Attacks on SSH
8
5.0 Conclusion – Future Development
9
References
Section 1
10
Page 2 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
Abstract
Secure Shell (SSH) is one of the most popular protocols in the market today that
allows users to connect from a local computer to a remote computer securely.
Secure Shell is able to provide users with such security by using the most
modern and secure cryptographic available. In this paper, we will discuss the
history of SSH, how SSH establishes connection between client and server, what
encryption technology it uses, what kind of attacks SSH protect against, and
what attacks SSH cannot prevent.
Acronyms
3DES – Triple Data Encryption Standard
AES – Advanced Encryption Standard
CAST – Carlisle Adams and Stafford Tavares
CRC-32 – Cyclic Redundancy Check
DES – Data Encryption Standard
DSA – Digital Signature Algorithm
IDEA – International Data Encryption Algorithm
MD5 – Message Digest algorithm number 5
RSA – Rivest-Shamir-Adleman
SCS – SSH Communications Security
SHA-1 – Secure Hash Algorithm
SSH-AUTH – SSH Authentication Protocol
SSH-CONN – SSH Connection Protocol
SSH-TRANS – SSH Transport Layer Protocol
SSH – Secure Shell
Section 1
Page 3 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
1.0 Introduction to Secure Shell (SSH)
Currently, millions of people around the world are using computers to interact
with other users. Unfortunately, many of those users are unaware of the security
behind the technology they use. Instead, many simply rely on the software and
hardware within their computer to provide the security without understanding
what level of security is being provided and where they may still be vulnerable.
There are many different free, as well as commercial, software applications on
the market today which provide a secure means to perform many common tasks
on remote machines. A popular protocol, used by many applications to ensure a
secure connection between two machines, is Secure Shell (SSH). After its
introduction, SSH became the preferred method to access other computers over
existing protocols such as telnet, rlogin, rsh, rdist, and rcp. SSH gained
popularity over these other protocols by providing security the security other
protocols lacked via authentication and encryption.
1.1 The History of Secure Shell
The story behind the development of Secure Shell started in 1995 when a school
network at Helsinki University in Finland was attacked with a password-sniffer. In
response to the incident, a researcher by the name of Tatu Ylönen developed the
protocol SSH-1, which is the first version of Secure Shell. During the same year,
SSH-1 gain rapid attention with an estimated 20,000 users in 50 countries
around the world. Due to its popularity, Ylönen created SSH Communications
Security Ltd. (SCS), a company in which he is the chairman and chief officer, to
manage the research and development of SSH (Barrett, 2002).
1.2 SSH-1 and SSH-2
Like many new protocols, after a year of usage, users found some problems and
limitations with SSH-1. SSH-1 was shown to be insecure after several flaws were
discovered with the protocol. These include SSH-1 being vulnerable to a man-inthe-middle-attack and using CRC-32 as an integrity check, which can allow
intruder to change the supposedly secure data and still pass the CRC-32 check.
In addition to security vulnerabilities, SSH-1 does not provide password change
or public-key certificate authentication. Due to SSH-1’s weak points, SCS
developed SSH-2. Unfortunately, in order to fix the problems with SSH-1, SSH-2
was unable to remain backwards compatibility with SSH-1. In 1998, the program
“SSH Secure Shell” based on the SSH-2 protocol was released. Later, other
SSH-2 implementations such as OpenSSH followed. Currently, the development
of SSH-1 is inactive while SSH-2 is actively being developed and researched
(Barrett, 2002). Since most projects regarding SSH-1 have stopped, this paper
will focus on SSH-2.
Section 1
Page 4 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
1.3 What does Secure Shell Protect Against?
While on the topic of security, one may wonder, what kind of attacks can intruder
perform on an insecure network and more importantly, how does SSH protect
users from falling victim to these attacks. An intruder can view any information
sent when transferring over an insecure network. This information includes
usernames, passwords, messages, IP address, files, and many more. By using
SSH, users are authenticated by the server when a connection is set-up and any
information sent over that connection is encrypted, preventing eavesdropping.
SSH prevents many attacks such as DNS spoofing, IP spoofing, IP source
routing, and manipulating and intercepting data over the connection.
SSH is able to provide users with such security by using modern encryption
algorithms. According to the FAQ document online (Acheson, 2001), SSH uses
RSA (SSH-1) or DSA (SSH-2) for authentication and then for data encryption, it
can use a variety of ciphers including 3DES, Blowfish, Twofish, Arcfour, or
Cast128-cbc (SSH-2). By using these cipher schemes, SSH is able to provide
the user with privacy, integrity, and authentication.
2.0 SSH Encryption Technique
As of today, there are two widely used key encryption algorithms. These keys
are secret-key and public-key. Secret-key algorithm use symmetric keys,
meaning that the same key is used to encrypt and decrypt the data. The second
type is public-key (also known as public/private keys), which uses asymmetric
keys. In general, the public/private key scheme uses a user’s public key, in
which everyone has access to, to encrypt the data. The private key is then used
to decrypt the data; assuming only the intended parties know the private key, it is
possible to send them encrypted data that only they can decrypt. Private-key
can also be used to perform an electronic signature. SSH uses both the secretkey and public-key schemes. The public-key scheme can be used to
authenticate users instead of the traditional password approach while the secretkey scheme is used to encrypt the messages sent during the SSH session.
Since secret-key schemes require all involved parties to know the secret key,
SSH uses a version of the Diffie-Hellman key exchange protocol at the beginning
of the session to determine the shared key; this process will be discussed further
(Barrett, 2002).
2.1 How does Secure Shell Work?
From a high level, SSH is simply a program executed on top of the TCP layer.
Once a user has installed a SSH client, the user contacts the server by entering
its host name and port number (defaulted to 22). After getting a response from
the server, the client and the server send each other the version of their SSH
protocol. This is needed to ensure that both SSH versions are compatible. If the
Section 1
Page 5 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
client has SSH-1 protocol and the server does not support SSH-1, the connection
is terminated due to the incompatibility and an error message will appear
informing the client of the reason. Once compatibility is determined, the server
and client use a packet protocol to send their messages. Next, the server sends
the client its host key, server key, check bytes, and a list of compression,
encryption, and authentication methods for the user to choose from. After
sending the client the data, the client and the server use a hash algorithm to
compute those data, which become the 128-bit session identifier. The 128-bit
session identifier contains the host key, server key, and check bytes.
Once the client has the server’s host key, the client uses it to look up the server
in its own database to determine if the client has contact with the server prior to
this connection. If so, the client will concede that the server is trustworthy, and if
not, the client can reject the connection, accept the connect and store the host
key or prompt the user for how to proceed.
Up to this point, no encryption has been used on the data. The next step is for
the client to send the server a secret key used to encrypt and decrypt data
passed between the two computers. This secret key must be encrypted. In order
to send the secret key to the server securely, the client must use the server’s
public key and server key to encrypt the secret key. The reason for encrypting
the secret key again with a server key is to prevent any chance of a key lying
around that can be used to read information from past or future connection
(Barrett, 2002). By default, the server key is changed every hour. In SSH-2
however, the Diffie-Hellman key exchange protocol is used to determine the key
instead. By using Diffie-Hellman algorithm, it omits the need for a server key and
still provides the same security. At this time the client sends the check bytes and
tells the server which algorithm it wants to use for encryption. Now that an
encryption algorithm is agreed by the client and the server, both can send data
using the session, also known as the secret, key to encrypt and decrypt.
Once a secure connection is established, the client needs to authenticate itself to
the server by going through a public-key or password authentication. The
password authentication requires that the user enter the correct username and
password. During a public-key authentication, the client needs to prove to the
server that it has the private key matching the servers public-key for the desired
user name. Usually the server will send the client a random 256-bit string that is
encrypted with the user’s public-key and the client needs to decrypt it with the
correct private key. After decrypting the random generated string, the client adds
the session identifier to the string, hashes it, and then sends it to the server. The
server will compute the hash and if it matches, the authentication process is
complete (Barrett, 2002).
In summary, when running SSH, the user first connects to a server and shared
key is determined. Usually this shared secret key is created using the DiffieHellman key exchange algorithm. After a key is determined, SSH begins to use
Section 1
Page 6 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
its encryption scheme, usually the Blowfish cipher, to encrypt the information
being sent from user to server and from server to user. Once the server verifies
the user based on username and password or public-key, the server can open an
encrypted connection with the user (SSH Protocol Overview, 2005).
3.0 SSH-2 Architecture
Figure 1: SSH-2 Architecture (Barrett, 2002)
Due to security issues and limitations of SSH-1, the SSH Communications
Security developed SSH-2. One of the main differences between SSH-1 and
Section 1
Page 7 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
SSH-2 are their architectures. SSH-1 is composed of only one layer that
contains all the functions within a single protocol whereas SSH-2 is divided into
three protocols: the transport, authentication, and connection protocol. When
trying to establish a connection, the SSH transport protocol does server
authentication, algorithm negotiation, and key exchange. Once the SSH-TRANS
protocol has been completed, a full-duplex session is established and SSH
Authentication (SSH-AUTH) and Connection protocol (SSH-CONN) begin. SSHAUTH protocol allows for client authentication, which includes public-key, hostbased, password, and password change options. SSH-2 uses the DSA algorithm
for public-key authentication by default. The SSH-CONN protocol’s job is to
allow for flow control, terminal handling, forwarding, data compression, and many
others. Figure 1 shows the overview interactions between the three protocols
(Barrett, 2002). There are many advantages for layering the protocols. One of
those advantages is to decrease the processing overhead, since once a
connection has been established, any application on the client computer wishing
to communicate with the server does not need to go through the SSH-TRANS
protocol (Loshin, 2001).
4.0 Possible Attacks on SSH
Like other secure programs, there are still attacks that can be performed against
which Secure Shell has no protection. Let us consider a few attacks. The first is
users’ carelessness. Secure Shell uses password or a passphrase as a method
of authentication. A password itself, although an inexpensive and easy way to
gain access is not secure because passwords can be easily guessed if not
chosen carefully. Furthermore, users may be careless with storing their
passwords such as writing it on a post-it. In order to authenticate using a
public/private key pair, the intruder would need the private key file. This file is
generally stored in the users home directory and while it is possible to encrypt it,
often times it is stored in plain text. This would allow an attacker who
compromised one machine to possibly access many, many others. Another
attack that SSH does not protect against is the denial-of-service-attack. Anytime
that SSH detects a possible intrusion while the program is sending encrypted
data from and to a remote computer, it will terminate the connection. This
causes the client to lose his/her connection and therefore, the client is denied
from using the server. Lastly, SSH does not protect against traffic-analysis
attack. This attack monitors the traffic being sent between client and server. It
can use this analysis to determine the time the heaviest traffic occurs (for a
denial-of-service-attack), the amount of information being sent, etc (Barrett,
2002).
Besides the attacks mentioned above, there is a research topic done on a timing
attacks on SSH by monitoring keystrokes. In the article, “Timing Analysis of
Keystrokes and Timing Attacks on SSH”, the authors claimed that SSH has two
weaknesses. One is if a block cipher is used SSH only uses 8 bytes to pad each
Section 1
Page 8 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
packet. This allows the intruder to estimate the length of the original message.
Second, SSH sends each keystroke in a single packet right after it is entered,
which can cause the intruder to determine the time between each key being
pressed and the password length. For example, typing the keys “er” is less time
consuming than typing “qz”. To support their research, the authors mentioned
research conduced that use the user’s unique keystroke timing to authenticate
the user (Song, 2001).
Although the authors of “Timing Analysis of Keystrokes and Timing Attacks on
SSH” claims seem plausible, the SSH Communications Security counters that
claim in their article, "Timing Analysis is Not a Real-Life Threat to SSH Secure
Shell Users". In summary, the SCS stated that it is not practical because SSH
does not rely solely on password for authentication. To further investigate on this
matter, the authors of “Analysis of the Feasibility of Keystroke Timing Attacks
over SSH Connections” preformed a practical experiment and concluded that
keystroke timing attacks on SSH is very difficult to achieve in the real world
(Hogye, 2001).
5.0 Conclusion – Future Development
From the overall research done on Secure Shell, Secure Shell has shown to be a
much better program and more secure than what was on the market. Secure
Shell has used modern encryption schemes and algorithm as its base for
security. The encryption schemes such as Diffie-Hellman key exchange, 3DES,
and DSA are still shown to be secure as of today. Furthermore, there are
organizations that research the development of Secure Shell and are always
looking for ways to improve SSH. As of today there are not many successful
attacks published regarding to Secure Shell.
Although many people consider that SSH-2 to be a complete protocol, the
program, SSH still has room for improvement and add-ons. As more secure
encryption algorithms are being develop, SSH is there to adopt them. Even
though SSH has gain many attentions, it is mostly used on Linux and UNIX
systems. If Microsoft incorporates SSH within its operating systems, SSH will
receive the exposure it deserves (Loshin, 2001).
Section 1
Page 9 of 10
March 24, 2005
Secure Shell
Tam Ngo
Steve Licking
References:
Acheson, S. The Secure Shell Frequently Asked Questions. March, 2001
<http://www.employees.org/~satch/ssh/faq/ssh-faq.html>
Barrett, J. D. and Silverman, R. SSH: The Secure Shell The Definitive Guide
O'Reilly & Associates, 2002
<http://www.hn.edu.cn/book/NetWork/NetworkingBookshelf_2ndEd/ssh/ch
01_05.htm>
Boran, S. All About SSH - Part I/II. July, 2004
<http://www.boran.com/security/sp/ssh-part1.html>
Hogye, M., Hughes, C., Sarfaty, J., & Wolf, J. Analysis of the Feasibility of
Keystroke Timing Attacks Over SSH Connections. 2001
<http://www.cs.virginia.edu/~evans/cs588fall2001/projects/reports/team4.pdf>
Loshin, P. Protocols. Information Security Magazine. 2001
<http://infosecuritymag.techtarget.com/articles/june01/features_protocols.s
html>
SSH Protocol Overview
<http://www.freesoft.org/CIE/Topics/139.htm> (Retrieved 3/23/2005)
Song, D. X., Tian, X., & Wagner, D. Timing Analysis of Keystrokes and
Timing Attacks on SSH. 2001
<http://www.cs.jhu.edu/~rubin/courses/fall03/papers/timing.ssh.pdf>
Timing analysis is not a real-life threat to SSH Secure Shell users. 2001
< http://www.ssh.com/company/newsroom/article/204/>
What is SSH? <http://www.webopedia.com/TERM/S/SSH.html> (Retrieved
3/23/2005)
Section 1
Page 10 of 10
March 24, 2005