Download An Introduction to SSH Secure Shell

Global Information Assurance Certification Paper
Copyright SANS Institute
Author Retains Full Rights
This paper is taken from the GIAC directory of certified professionals. Reposting is not permited without express written permission.
Interested in learning more?
Check out the list of upcoming events offering
"Security Essentials Bootcamp Style (Security 401)"
at http://www.giac.org/registration/gsec
An Introduction to SSH Secure Shell
Damian Zwamborn
GSEC Assignment v1.2d
ull
rig
ht
s.
Purpose
This paper is meant as an introduction to SSH Secure Shell with emphasis on the
latest version SSH2. When I was researching this paper, a lot of questions came to
mind. I h ave tried to answer all those questions:
Au
th
or
re
tai
ns
f
• Background and licensing.
• The SSH1 and SSH2 protocol.
• How does SSH work?
Key •fingerprint
= AF19
2F94
998D
FDB5threats
DE3Dthat
F8B5
A169 4E46
Why SSH?
What FA27
are some
typical
security
SSH06E4
deters?
• Extended descriptions of SSH features.
• SSH Implementations.
• A few links to p opular clients.
• More helpful links.
Overview
00
-2
00
2,
SSH Secure Shell is a replacement for the Berkeley 'r' commands, telnet and ftp
functionalities. Introduced in the BSD (Berkeley) version of UNIX, the 'r' commands
(rsh, rlogin, rcp) allow you to communicate w ith remote systems. Although they're
not as extensive as ftp and telnet, the 'r' commands are useful tools for extending the
reach of your network.
NS
In
sti
tu
te
20
SSH functions as a type of tunnel for encoding login procedures. All connections
between the local and the remote hosts are encrypted, protecting the dat a sent between
these machines. Secure shell provides s everal security improvements over the telnet,
ftp and rlogin protocols. In particular, passwords are never sent over the network in a
clear text format as t hey are when using telnet, ftp or rlogin. This encryption makes it
difficult for someone to breach the confidentiality of your data and/or compromise
passwords. SSH Secure Shell is based on the SSH2 protocol that is standardized by
IEFT in a draft form at ( www.ietf.org/ids.by.wg/secsh.html ).
SA
Secure Shell does not close all network security holes, but it is one step toward a more
secure network.
©
SSH Secure Shell Background
SSH Secure Shell has been around since 1995 and is widely used in many Unix
systems all over the world. SSH was originally an academic project authored and
distributed by Tatu Ylonen of the University of Finland. SSH Secure Shell was
in 1998
by 2F94
SSH Communications
Se curity
), which
Key commercialized
fingerprint = AF19
FA27
998D FDB5 DE3D
F8B5(www.ssh.com/
06E4 A169 4E46
sells implementations for both Windows and UNIX systems.
The SSH1 and SSH2 protocol
© SANS Institute 2000 - 2002
As part of GIAC practical repository.
Author retains full rights.
ull
rig
ht
s.
As of 1 May 2001, SSH Secure Shell 1.x is no longer available from the SSH
Communications Security site. SSH1 has many security flaws and the SSH2 protocol
adds additional security, If fact, SSH2 is a complete rewrite of the SSH protocol. SSH
Communications Security has stated: “SSH1 (Secure Shell 1) was designed in 1995 ...
it [has] became apparent that the re were inherent security flaws in SSH1. These flaws
include a weak hash and sus ceptible encryption algorithms. These flaws fall in the
following categories: access control and authentication, data integrity, confidentiality,
and connection redirection” (R ef 1).
tai
ns
f
A summary of vulnerabilities in the SSH1 protocol can be found at the CERT
Coordination Center: www.kb.cert.org/vuls .
re
For the sake of clarity, this paper refers to the SSH2 protocol unless explicitly st ated
Key otherwise.
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
or
Licensing
00
Open Source implementation of SSH
2,
Au
th
The SSH Communications Security FTP site offers downloadable source code and
binaries (UNIX platforms and Windows) for both SSH1 and SSH2. However, the
licensing terms allow only SSH1 to be used without restriction. Commercial
enterprises must license SSH2 products on a per -seat basis.
te
20
00
-2
There is also an Open Source implementation of SSH, available from OpenSSH
(www.openssh.com/ ). This implementation suppo rts both the ssh1 and ssh2 protocols
and has no restrictions on its use. The Open Source implementation is largely
compatible with the commercial version, differing mainly in not providing support for
IDEA encryption because of patent restrictions.
In
sti
tu
The FreeSSH (www.freessh.org/ ) site maintains up -to-date links on various free and
Open Source SSH implementations as well as commercial enterprise
implementations.
NS
How does SSH work?
SA
The SSH2 login procedure can be ill ustrated in the following client/server model.
©
Note: SSH1 uses server and host keys to authenticate systems where SSH2 only uses
host keys. A server key (768 bit) is generated every hour by default and is not saved
in a file. The server key ensures the en coded data can no longer be decoded once the
server key, after an hour, has been regenerated (in the case that the private host key is
ever compromised).
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
© SANS Institute 2000 - 2002
As part of GIAC practical repository.
Author retains full rights.
ull
rig
ht
s.
tai
ns
f
Au
th
or
re
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
2,
1. The client makes a connection to a server.
20
00
-2
00
2. The server identifies itself with it's public host key . The key length is 1024 bit
RSA or DSA. The client looks in its local database to verify the public host
key is authentic/known. An unknown key is added to the database or the
session can be broken. If the client determines the host key does not belong to
the server the client is alerted (SSH generates a warning).
In
sti
tu
te
3. The client then generates a random 256 -bit number and chooses an encryption
algorithm (eg. 3DES). The random number is then encoded with RSA or DSA.
Pure RSA/DSA authentication never trusts anyt hing but the private key. The
encoded key is then sent to the server. The host key ensures the authentication
of the particular server.
SA
NS
4. The server decodes the RSA/DSA encryption and reconstructs the session key.
Furthermore, the server sends the client, v ia the encoded s ession key, a
confirmation. The rest of the session is encrypted using a symmetric cipher.
©
5. The client then sends a username authentication request. The server replies
with a success or failure.
Security Threats
TCP/IP was not designed wi th security in mind. That is why it is important to
implement security techniques such as SSH Secure Shell.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
A quick review of some valuable terms:
•
Packet sniffing: A packet sniffer is a utility that sniffs raw packet data without
manipulating the data. P acket sniffers observe, display, and log traffic. A powerful
© SANS Institute 2000 - 2002
As part of GIAC practical repository.
Author retains full rights.
ull
rig
ht
s.
aspect of packet sniffers is their ability to place the network adapter machine
hosting the sniffing software into promiscuous mode. Network adapters running in
promiscuous mode receive not only the data directed to the host's machine but also
all of the traffic on the physically connected local network. Malicious hackers use
packet sniffers gathering information.
• Spoofing: Spoofing is the creation of TCP/IP packets using somebody else's IP
address. Routers use the destination IP address in order to forward packets through
the Internet, but ignore the source IP address. The destination machine only uses
that address when it responds back to the source.
In
sti
tu
te
20
00
-2
00
2,
Au
th
or
re
tai
ns
f
SSH connections are encrypted, protecting the data sent between machines. This
encryption makes it difficult for someone to breach the confidentiality of your data
and/or compromise your passwords. Typical attacks that SSH protects against are:
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
• Trojan horses: Trojans are programs that masquerade as normal programs on an
unsuspecting host but instead contain code designed to break into a system. SSH
authentication happens on both ends of a connection and therefore, for practical
purposes, eliminating unauthorized connections.
• DNS spoofing. “DNS spoofi ng is a term used when a DNS server accepts and
uses 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 a ttacks can caus e serious
security problems for DNS servers vulnerable to such attacks, for example causing
users to be directed to wrong Internet sites or e -m ail being routed to non authorized mail servers” (Ref 2). Follow reference link for detailed expla nation.
DNS is vulnerable to spoofing because of the absence of authentication.
• Man-in-the-middle attack. A man -in-the-m iddle attack “is one in which the
attacker intercepts messages in a public key exchange and then retransmits them,
substituting their ow n public key for the requested one, so that the two original
parties still appear to be communicating with each other directly. The attacker uses
a program that appears to be the server to the client and appears to be the client to
the server” ( www.whatis.com/ ). A well-known tool for this is dsniff
(www.monkey.org/~dugsong/dsniff ). Since most authentications only occur at the
start of a TCP session, this allows th e hacker to gain access to a machine.
©
SA
NS
SSH offers the following solution to prevent public key substitution: “SSH2
automatically maintains and checks a database containing public keys of hosts.
When logging on to a host for the first time, the host's publi c key is stored to a file
in the us er's personal directory. If a host's identification changes, SSH2 issues a
warning and disables password”(Ref 3).
A note regarding SSH1 and man -in-the-middle attacks:
The protocol [SSH1] provides the option that the ser ver name - host key
association is not checked when connecting the host for the first time. This
Key fingerprintallows
= AF19
FA27 2F94 998D
FDB5
F8B5 06E4
A169
communication
without
prior DE3D
communication
of host
keys4E46
or
certification. The connection still provides protection against passive
listening; however, it becomes vulnerable to active m an -in-the-m iddle
attacks. Implementations SHOULD NOT normally allow such connections
by default, as they pose a potential security problem. However, as there is
© SANS Institute 2000 - 2002
As part of GIAC practical repository.
Author retains full rights.
ull
rig
ht
s.
no widely deployed key infrastructure available on the Internet yet, this
option makes the protocol much more usable during the trans ition time
until such an infrastructure emerges, while still providing a much higher
level of security than that offered by older solutions (e.g. telnet and rlogin)
(Ref 4).
Features and Specifications
re
tai
ns
f
Authentication methods.
• Host-based authentication: password protection with 1024 bit RSA -key (publickey cryptographic algorithm).
• Ability to add certificate and public key authentication.
• Password authentication.
Key •fingerprint
= AF19
FA27
2F94
FDB5
DE3D
F8B5key
06E4
A169 4E46
Public key
algorithm
supp
ort:998D
DSA and
Diffie
-Hellman
exchange.
• PGP key support.
Au
th
or
Data encryption for confidentiality and integr ity.
• Encryption algorithms: DES, 3DES Blowfish, Twofish, Arcfour, CAST128 -CBC,
128 bit AES, or 256 bit AES.
• Hash Algorithms: MD5 and SHA1.
©
SA
NS
In
sti
tu
te
20
00
-2
00
2,
Additional functionality.
• File transfer. Files can be copied remotely using a utility called scp (secure copy).
• SFTP (secure file transfer protocol) was introduced with SSH2. It is independent
to the rest of the SSH2 protocol suite (see www.ietf.org/ids.by.wg/secsh.html ).
SFTP-server is not called directly but through the SSH2 daemon – the ssh2
protocol therefore secures the connection.
• TCP/IP port forwarding: SSH supports port forwarding over a secure tunnel. You
configure your SSH client to accept connections on the local machine for certain
ports. Any data that is sent to these ports is then forwarded and returned across the
tunnel. On the other side of the tunnel, the SSH server passes the data back and
forth to a server you wish to access. Typical implementations of port forwarding
are services that have no encryption of their own built -in such as FTP, IMAP,
SMTP and POP3. Note: only root can redirect privileged ports.
• X11 connections for secure X Window Sy stem sessions are a popular
implementation. SSH Communications Security offers special support for this
feature because it so popular. SSH creates a fake X server (Fake Xauthority
information) on the same machine that the SSH client is run. SSH then functi ons
as a go-between between the connection and forwards it to a real X server over a
secure connection.
• TCP Wrapper support. The TCP Wrappers is a public -domain tool/package you
can monitor and filter incoming requests for the SYSTAT, FINGER, FTP,
TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other s ervices. It is us ed to
restrict inbound network access to the s ervices defined in the /etc/inetd/inetd.conf
Key fingerprint
file. TCP=Wrappers
AF19 FA27
is controlled
2F94 998D
by two
FDB5
configuration
DE3D F8B5
files:06E4
/etc/hosts.allow
A169 4E46and
/etc/hosts.deny. If they do not exist or are empty, TCP Wrappers will allow all
hosts to access all services.
• Built-in SOCKS 4 and 5 support for traversing firewalls.
© SANS Institute 2000 - 2002
As part of GIAC practical repository.
Author retains full rights.
•
tai
ns
f
ull
rig
ht
s.
Support for SSH1 fallback functionality. The SSH1 and SSH2 protocols are not
compatible. SSH1 clients cannot conn ect to a SSH2 daemon. The SSH2 daemon
can be configured to start up a SSH1 daemon for a SSH1 client. (Must be installed
with compatible option). The SSH1 and SSH2 daemon can be running on two
separate machines or on the same machine.
• Multiple channel suppo rt. “All terminal sessions, forwarded connections, etc. are
channels. Either side may open a channel. Multiple channels are multiplexed into
a single connection” (Ref 5).
• Distributed key management. The advantage of distributed key management is
that there is no hierarchy. This avoids having a single target for attacks as every
machine can hold it’s own keys. It is also possible to configure these machines to
change session keys every hour.
re
Key SSH
fingerprint
= AF19 FA27
Implementations
. 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Au
th
or
The SSH2 protocol can be implem ented in vari ous ways. In addition to encrypted
terminal connections the SSH protocol can be implemented, for example, as a
complete VPN solution. At the risk of going beyond the scope of this paper, I
recommend going to www.ssh.com/products , and www.f-secure.com/products , to get
an idea of popular implementations/solutions.
00
2,
Popular Clients
tu
te
20
00
-2
SSH Communications Security. URL: www.ssh.com .
F-Secure. URL: www.f-secure.com . In the past, SSH Communications Security did
not sell Secure Shell but were licensing it through F -Secure. F-Secure still licenses the
UNIX server but both companies now develop their own clients.
Van Dyke Technologies. URL: www.vandyke.com .
Open SSH. URL: www.openssh.com .
For a complete list of free and licensed clients, visit the www.freessh.org website.
sti
References (Ref):
©
SA
NS
In
1. SSH Communications Security. “ SSH1 vulnerabilities ”.
http://www.ssh.com/products/ssh/cert/vulnerability .html (12 May, 2001).
2. M EN&MICE. “What is DNS Spoofing?” IWS - The Information Warfare Site.
URL: http://www.iwar.org.uk/comsec/resources/dns/DNS_spoofing.htm (12 May
2001).
3. SSH Communications Security. “SSH2 Functionality”. SSH Secure Shell for
Workstations Windows Client: User M anual. URL:
http://www.ssh.com/products/ssh/winhelp21/8_1_SSH 2_Functionality.html (12 May
2001).
4. Network Working Group. “SSH Protocol Architecture”. Internet -Drafts IETF.
URL: http://www.ssh.com/tech/archive/secsh/architecture.t xt (12 May, 2 001).
5. Network Working Group. “SSH Connection Protocol”. Internet-Drafts IETF. URL:
Key http://www.ssh.com/tech/archive/secsh/connect.txt
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D
(12F8B5
M ay, 06E4
2001).A169 4E46
Extra references:
•
RSA Security. URL : www.rsa.com .
© SANS Institute 2000 - 2002
As part of GIAC practical repository.
Author retains full rights.
•
•
ull
rig
ht
s.
The Official Secure Shell FAQ. URL: www.employees.org/~satch/ssh/faq .
Indiana University security resource page.
URL: www.uwsg.iu.edu/security/ssh.html .
• Colorado School of Mines Secure Shell resource page.
URL: www.mines.edu/Academic/computer/security/tools/ssh/#ab out.
• Crawford, Chuck. “ SSH, Secure Shell ”. Nov 3 2000.
URL: www.sans.org/infosecFAQ/authentic/SSH.htm .
Additional Security Alerts of Interest
•
©
SA
NS
In
sti
tu
te
20
00
-2
00
2,
Au
th
or
re
tai
ns
f
Openwall advisories. “Passive Analysis of SSH (Secure Shell) Traffic.
Determining possible password lengths”. Mar 19, 2001.
URL: www.openwall.com/advisor ies/OW -003-ssh-traffic-analysis.t xt.
Key •fingerprint
= AF19 FA27
2F94 998D Testing
FDB5 DE3D
F8B5.06E4
A169
Russel, Christopher
R. “Penetration
with dsniff”
Feb 18,
2001.4E46
URL:
www.sans.org/infosecFAQ/threats/dsniff.htm .
• CORE SDI S.A. Security Advisor y. “SSH protocol 1.5 session key recovery
vulnerability”. Feb 7th, 2001.
URL: www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm .
• Arce, Iván. “ SSH1 CRC-32 compensation attack detector vulnerability”. Feb 08
2001. URL: www.securityfocus.com/archive/1/161448 .
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
© SANS Institute 2000 - 2002
As part of GIAC practical repository.
Author retains full rights.
Last Updated: May 12th, 2017
Upcoming Training
SANS Northern Virginia - Reston 2017
Reston, VA
May 21, 2017 - May 26, 2017
Live Event
SANS London May 2017
May 22, 2017 - May 27, 2017
Live Event
SANS Melbourne 2017
London, United
Kingdom
Melbourne, Australia
May 22, 2017 - May 27, 2017
Live Event
SANS Stockholm 2017
Stockholm, Sweden
May 29, 2017 - Jun 03, 2017
Live Event
SANS San Francisco Summer 2017
San Francisco, CA
Jun 05, 2017 - Jun 10, 2017
Live Event
SANS Houston 2017
Houston, TX
Jun 05, 2017 - Jun 10, 2017
Live Event
Security Operations Center Summit & Training
Washington, DC
Jun 05, 2017 - Jun 12, 2017
Live Event
Community SANS Ottawa SEC401
Ottawa, ON
Jun 05, 2017 - Jun 10, 2017 Community SANS
SANS Rocky Mountain 2017
Denver, CO
Jun 12, 2017 - Jun 17, 2017
Live Event
SANS Charlotte 2017
Charlotte, NC
Jun 12, 2017 - Jun 17, 2017
Live Event
SANS Rocky Mountain 2017 - SEC401: Security Essentials
Bootcamp Style
Community SANS Portland SEC401
Denver, CO
Jun 12, 2017 - Jun 17, 2017
vLive
Portland, OR
Jun 12, 2017 - Jun 17, 2017 Community SANS
SANS Secure Europe 2017
Amsterdam, Netherlands
Jun 12, 2017 - Jun 20, 2017
Live Event
SANS Minneapolis 2017
Minneapolis, MN
Jun 19, 2017 - Jun 24, 2017
Live Event
Community SANS Philadelphia SEC401
Philadelphia, PA
Jun 19, 2017 - Jun 24, 2017 Community SANS
SANS Columbia, MD 2017
Columbia, MD
Jun 26, 2017 - Jul 01, 2017
Live Event
SANS Cyber Defence Canberra 2017
Canberra, Australia
Jun 26, 2017 - Jul 08, 2017
Live Event
SANS Paris 2017
Paris, France
Jun 26, 2017 - Jul 01, 2017
Live Event
SANS London July 2017
Jul 03, 2017 - Jul 08, 2017
Live Event
Cyber Defence Japan 2017
London, United
Kingdom
Tokyo, Japan
Jul 05, 2017 - Jul 15, 2017
Live Event
SANS Cyber Defence Singapore 2017
Singapore, Singapore
Jul 10, 2017 - Jul 15, 2017
Live Event
Community SANS Minneapolis SEC401
Minneapolis, MN
Jul 10, 2017 - Jul 15, 2017
Community SANS
SANS Los Angeles - Long Beach 2017
Long Beach, CA
Jul 10, 2017 - Jul 15, 2017
Live Event
SANS Munich Summer 2017
Munich, Germany
Jul 10, 2017 - Jul 15, 2017
Live Event
Community SANS Phoenix SEC401
Phoenix, AZ
Jul 10, 2017 - Jul 15, 2017
Community SANS
Mentor Session - SEC401
Macon, GA
Jul 12, 2017 - Aug 23, 2017
Mentor
Mentor Session - SEC401
Ventura, CA
Jul 12, 2017 - Sep 13, 2017
Mentor
Community SANS Atlanta SEC401
Atlanta, GA
Jul 17, 2017 - Jul 22, 2017
Community SANS
Community SANS Colorado Springs SEC401
Colorado Springs, CO
Jul 17, 2017 - Jul 22, 2017
Community SANS
SANSFIRE 2017
Washington, DC
Jul 22, 2017 - Jul 29, 2017
Live Event
SANSFIRE 2017 - SEC401: Security Essentials Bootcamp Style
Washington, DC
Jul 24, 2017 - Jul 29, 2017
vLive