Академический Документы
Профессиональный Документы
Культура Документы
Himanshu Dwivedi
Implementing SSH
Implementing SSH
Himanshu Dwivedi
Dedication
This book is dedicated to my wife, Kusum. Without her, this book would not
have been possible. Kusum, you are truly special to me.
I would like to especially thank my parents, Chandradhar and Prabha
Dwivedi. Without their guidance, support, and inspiration, I would not be
where I am today. Lastly, I would like to thank my brother and sister, Sudhanshu and Neeraja Dwivedi, from whom I have learned every important lesson
in life. Without their influence and experiences, I could not have learned so
much.
I thank you and love you all very much.
Contents
Acknowledgments
xv
xvii
Introduction
xix
Part 1
SSH Basics
Chapter 1
Overview of SSH
Differences between SSH1 and SSH2
Various Uses of SSH
3
4
5
Security
Remote Command Line Execution
Remote File Transfer
Remote Network Access
Secure Management
Proxy Services
5
7
8
10
10
11
12
13
14
14
15
OpenSSH
Red Hat Linux 8.0
OpenBSD 3.1
Windows 2000 Server
Commercial SSH
OpenBSD 3.1 and Red Hat Linux 8.0
Windows 2000
VShell SSH Server
16
16
18
19
23
23
24
27
29
30
vii
viii
Contents
Chapter 2
SSH Servers
OpenSSH
SSH Communications SSH server
SSH Communications SSH Server: Unix
General
Network
Crypto
Users
User Public Key Authentication
Tunneling
Authentication
Host Restrictions
Users Restrictions
SSH1 Compatibility
Chrooted Environment
Subsystem Definitions
SSH Communications SSH server: Windows
General Settings
Network Settings
Crypto Settings
Users Settings
Server Public Key Configuration
Server Certificate Configurations
Tunneling Configurations
Authentication Methods
Host Restrictions
User Restrictions
Subsystem Definitions
31
32
39
39
40
40
42
43
44
46
46
47
48
49
50
50
51
52
54
56
57
60
61
62
63
64
65
67
69
69
70
71
72
73
74
75
77
78
79
80
81
83
84
85
Contents
Chapter 3
Chapter 4
87
88
89
89
94
95
95
96
96
97
97
98
98
98
99
100
101
104
PuTTY
WinSCP
MindTerm
MacSSH
Summary
110
112
113
116
116
Authentication
General Options
117
118
Passwords
Host-Based Authentication
Server Authentication
Public Keys
Creating Keys with OpehSSH
How to Use an OpenSSH Key on an OpenSSH Server
How to Use an OpenSSH Key on SSH Communications
SSH Server
How to Use an OpenSSH Key on a VShell SSH Server
Creating Keys with SSH Communications SSH Client
(Unix and Windows Command Line)
How to Use SSH Client Keys with SSH Communications
SSH Server
How to Use SSH Client Keys with an OpenSSH Server
How to Use SSH Client Keys with a VShell SSH Server
118
120
121
122
123
127
129
131
134
135
136
137
138
139
140
140
ix
Contents
Creating Keys with SSH Communications (Windows GUI)
How to Upload an SSH Client Key Pair to SSH
Communications SSH Server
How to Upload an SSH Client Key Pair to an
OpenSSH Server
How to Upload an SSH Client Key Pair to a
VShell SSH Server
Creating Keys with VanDyke SecureCRT
VShell SSH Server
OpenSSH
SSH Communications SSH Server
SSH Agents
Chapter 5
142
144
145
147
148
149
150
151
152
Summary
153
SSH Management
Network Devices
155
156
Cisco Routers
Cisco Switches
Cisco VPN Concentrator
Cisco PIX Firewalls
Network Appliance Filers
Secure Management
Management Servers
Two-Factor Authentication
SOCKS Management
SSH: User Restrictions
Chroot
User Access Controls
SSH User Restrictions
SSH: Network Access Controls
SSH TCP wrappers
SSH Connection Filters
SSH Host Restrictions
Summary
157
160
160
162
163
164
165
167
169
172
172
173
175
177
177
179
181
183
Part 2
185
Chapter 6
187
193
200
201
205
205
207
209
211
213
213
214
Contents
Configuration for SSH Communications
GUI SSH Client (Windows)
Configuration for VanDyke Softwares SecureCRT
Chapter 7
214
215
217
217
217
220
222
225
226
229
230
232
232
234
237
238
241
241
243
243
244
245
Summary
246
248
249
252
252
253
255
257
259
260
261
261
264
Part 3
Protocol Replacement
267
Chapter 8
SSH Versatility
Terminal Access
269
270
271
272
273
274
xi
xii
Contents
File Transfer with Secure File Transfer Protocol (SFTP)
SFTP with the OpenSSH SFTP Server
Using OpenSSH for Management Purposes
Using OpenSSH for File Sharing
Authorizing Users with OpenSSH
OpenSSH on Windows and Cygdrive
SFTP with VanDyke Software VShell
Using VShell for Management Purposes
Using VShell for File Sharing
Authorizing Users with VShell
SFTP with SSH Communications SSH Server
Using SSH Communications SSH Server for
Management Purposes
Using SSH Communications SSH Server for File Sharing
Authorizing Users with SSH Communications SSH Server
Comparison of the Three SFTP Solutions
Chapter 9
276
277
277
278
279
280
281
281
282
287
287
288
289
292
292
Secure Chat
Secure Backups
Summary
293
297
299
301
302
310
314
Summary
Chapter 10 SSH Case Studies
Case Study #1: Secure Remote Access
The Problem Situation
Business Requirements
Configuration
SSH Client Configuration
SSH Server Configuration
Results Checklist
321
323
324
325
326
329
330
330
330
334
334
339
343
344
344
344
347
347
350
351
Contents
Case Study #3: Secure File Servers
353
The Problem
Business Requirements
Configuration
SSH Server Configuration
SSH Client Configuration
Results Checklist
353
353
354
354
356
357
Summary
358
Epilogue
359
Index
361
xiii
Acknowledgments
I would like to acknowledge and thank several people who have helped me
throughout my career. The following people have supported me in numerous
ways that have made me a better professional. To these people, I want to say
thank you: Andy Hubbard, Ronnie Dinfotan, Amy Bergstrom, Tim Gartin,
Troy Cardinal, Anthony Barkley, Jason Chan, Kevin Rich, Paul Nash, Nitra
Lagrander, Sumit Kalra, Glen Joes, Joel Wallenstrom, Ted Barlow, Allen Dawson, Rob Helt, Larry Harvey, and jum4nj1. Also, special thanks to Mike Schiffman, Carol Long, and Scott Amerman, who were integral in getting this book
established.
xv
Author Accomplishments
Patents
U.S. Patent Serial No. 10/198,728: Patent Pending for Design Architecture and Methods for Enterprise Storage Devices
Published Books
Papers
Storage Security
(http://www.atstake.com/research/reports/index.html)
Introduction
Secure Shell (SSH) is a utility that can be described in many different ways. It
can be described as a protocol, an encryption tool, a client/server application,
or a command interface. Along with its various descriptions, SSH provides
various functions with a single package. SSHs diverse set of services and the
ability to provide those services in a secure manner have allowed it to become
a staple in many enterprise networks.
Most security professionals probably discovered SSH very early in their
careers and have fallen in love with it ever since. SSH to the security professional is like a donut to Homer Simpson: a godsend. Professionals continually
ask themselves if there is anything SSH cant do. For the security professional,
SSH provides everything one could ask for, including a free car wash on weekends (well, that is what it seems like sometimes). One of the great things about
SSH is that not only do security professionals use and love the utility, but nonsecurity technical professionals and nontechnical professionals love it as well.
Furthermore, SSH is compared with other security utilities in the industry,
such as RSA SecureID tokens, it is evident that security professionals are the
predominant end-users of these other utilities. SecureID tokens are not widely
used by nontechnical personnel and are not deployed often in environments
that are not closely affiliated with corporate security. On the other hand, SSH
is deployed in many Unix workstations/servers, Windows workstations, and
a variety of network devices such as Cisco routers and switches.
Some books on the market today cover SSH. Unlike most of them, this book
does not cover the ins and outs of SSH as a protocol, the encryption modules
used in SSH1 and SSH2, or the supported algorithms. Instead, it covers the ins
and outs of implementing and optimizing SSH. Think of this book as a tactical
guide to SSH: Now that I understand SSH, how can I use it? This book covers the
xix
xx
Introduction
how can I use it part. Covered in detail is how to install, implement, optimize,
and support SSH in Unix, Windows, and network architecture environments.
Introduction
xxi
xxii
Introduction
most of the configuration required takes place on the client rather than the
server.
Furthermore, many environments that deploy SSH still use Telnet, RSH,
Rlogin, and FTP. While there may be problems with interoperability and SSH
on various platforms and applications, a lot of organizations use SSH but leave
FTP enabled for file transfer (or even worse, use SFTP for file transfer but leave
Telnet enabled for command line execution). SSH not only can do both; it can
do both with one daemon or service, eliminating the need to have two separate
services running on a single machine.
This book provides a detailed guide, with screen shots and steps, for using
SSH in a variety of ways. The goal of this book is to be an accessible reference
used in data centers to deploy a range of services (from secure FTP to secure
e-mail with Microsoft Exchange).
Introduction xxiii
Defenses
The primary purpose for deploying SSH is security. SSH defends against several attacks that plague IP (Internet Protocol) version 4 networks, including
poor protocols with IPv4, such as Address Resolution Protocol (ARP), Initial
Sequence Numbers (ISN), and various clear-text protocols, such as Telnet,
RSH, Rlogin, FTP, POP3, IMAP, LDAP, and HTTP.
Because space is limited, Implementing SSH does not discuss in detail all
types of attacks that SSH defends against. You should be aware of three critical
types of security attacks against which SSH is quite effective. (Be aware that
while SSH cannot prevent all of these attacks, it has safeguards in place that
make it extremely difficult, if not well-nigh impossible, to execute them.) The
three major types of security attacks are:
Man-in-the-Middle (MITM) attacks. Man-in-the-Middle attacks occur
against ARP in IPv4 networks. Such attacks allow an unauthorized
entity to sniff the network even on a switched environment by capturing
the communication between two trusted entities. SSH version 2 prevents
attackers from gaining access to communication by fully encrypting it.
The chances that an attacker can capture the communication between
two entities are minimized, as the communication is in a form that is
unreadable to the attacker.
Session hijacking. Session-hijacking attacks occur against the ISN in the
TCP header of a TCP/IP packet. An attacker can take advantage of the
poor sequence numbers used by the ISN and hijack a session between
two trusted entities. SSH can make it virtually impossible for an attacker
to view, capture, or attempt to hijack the ISN altogether, although it cannot always make the ISN in a TCP header less predictable.
Sniffing. Sniffing is the simple act of viewing the communication (packets) in a network. SSH provides a strong level of encryption that can protect weak protocols such as Telnet, RSH, Rlogin, FTP, POP3, IMAP,
LDAP, and HTTP either by replacing them altogether (for Telnet, RSH,
and Rlogin, for example) or by wrapping them within a tunnel (for
POP3). This encryption prevents most, if not all, unauthorized users
from sniffing the network.
xxiv Introduction
gives a broad overview of SSH, which can be used as a refresher for professionals familiar with this utility. It also explores why SSH should be used and
some of the major features that make it useful in a network environment.
Chapters 2 and 3 present the various SSH servers and clients that exist on
the market today, both commercial and freely downloadable. SSHs features,
functions, and capabilities often differ from each other, sometimes in extreme
ways, depending on which client or server is used; therefore, these two chapters show the similarities and differences, and positives and negatives of some
of the major SSH vendors in the market.
Chapter 4 delves into authentication, a process that covers everything from
username and password to key-based authentication with digital certificates.
To round out Part One, Chapter 5 explores how SSH can be used on network
devices such as routers, switches, firewalls, and other devices that are traditionally managed by Telnet. In addition, Chapter 5 covers management methods to be used with SSH.
Part Two shifts to the different remote access solutions available with SSH.
Chapter 6 examines the basics of port forwarding, from theory and setup to
configuration, and Chapter 7 discusses port forwarding in greater detail,
explaining specifically how it functions as an enterprise-wide remote access
solution.
Part Three provides a detailed discussion of protocol replacement with SSH.
Chapter 8 describes the versatility of SSH. This chapter not only investigates
how SSH can be used to replace insecure protocols such as RSH, Rlogin, and
FTP but also shows how to use SSH as a secure file transfer solution, a secure
chat server, and a server backup solution. Chapter 9 describes methods for
using SSH with SOCKS proxies and dynamic port forwarding, plus ways in
which SSH can be used as a secure Web and a secure wireless solution.
Chapter 10 presents three case studies involving remote access, secure wireless connectivity, and secure file transfer in mixed operating environments.
Each case study describes a problem situation, presents several business
requirements, and provides a solution involving SSH.
Introduction
Platforms
The platforms used in this book are OpenBSD 3.1, Linux RedHat 8.0, and Windows 2000 (Server or Professional), except where noted. Also, it is safe to
assume that most flavors of Windows (NT4.0 to 2003 Server) and Unix (Linux,
Solaris, HP-UX, and so on) will obtain similar results, if not the same results,
as the platforms used in this book.
xxv
xxvi Introduction
Product Notes
SSH is an industry standard defined by the IETFs Secure Shell working group
(www.ietf.org/html.charters/secsh-charter.html). In addition, SSH has many
open source and commercial implementations for both SSH servers and SSH
clients. In this book we will discuss, reference, or describe the following implementations of SSH:
OpenSSH (www.openssh.org)
OpenSSHWin32 (http://lexa.mckenna.edu/sshwindows/)
Putty (www.putty.com)
F-Secure (www.fsecure.com)
WinSCP (http://winscp.vse.cz/eng)
PA R T
One
SSH Basics
CHAPTER
1
Overview of SSH
Chapter 1
Uses of SSH
Overview of SSH
Security
Secure management
Proxy services
Security
The implementation of SSH in a trusted or nontrusted environment can protect against many of the security issues with Internet Protocol version 4 (IPv4).
IPv4 has been plagued with security issues ranging from poor initial sequence
numbers (ISN) in TCP header packets, which leads to session hijacking, to
unauthenticated address resolution packets (ARPs) being distributed to the
network. The use of SSH not only protects against the common LAN attacks
described previously; it guards against the following types of attacks as well:
Spoofing of IP addresses. A remote device, usually an operating system,
can change its IP address and pretend to be a different source, usually a
trusted source.
Data modification. As data is passed through corporate networks and
the Internet, any intermediary can modify the data while it is in transit.
ARP pollution. This occurs when incorrect ARP packets to redirect and
capture sensitive data are distributed.
Session hijacking. This occurs when individuals guess or predict the
ISN in TCP headers, gaining control of Telnet and RSH sessions.
Clear-text data. This occurs when critical or sensitive clear-text data, such
as usernames, passwords, and commands, is intercepted.
Chapter 1
The preceding list is not exhaustive, as SSH can protect against many other
attacks, which may be direct or indirect. Another reason SSH is so popular is
its ability to protect against network sniffing on both Local Area Networks
(LANs) and Wide Area Networks (WANs). That feature allows network
administrators and server administrators to manage and connect to remote
systems without the risk of losing sensitive information to unauthorized users.
Figure 1.1 shows a Telnet packet between two entities in clear-text:
Notice in Figure 1.1 that the username is in the clear-text, kusum, and the
password is also in the clear-text, password. The session can be captured by
any type of network sniffer, as long as the session is in clear-text. Some of the
most common and vulnerable connections that often get targeted for sensitive
information such as passwords are Telnet, FTP, POP3, SMTP, IMAP, SNMP,
and HTTP. Figure 1.2 shows an SSH packet between the same two entities used
in Figure 1.1.
Notice in Figure 1.2 that none of the information is in clear-text or comprehendible, thus being encrypted. This connection mirrors the Telnet connection
(remote command line execution), but with significantly greater security over
the password and the username kusum.
SSH provides the following three key security features:
Encryption. SSH encrypts all communication with a variety of cipher
algorithms to choose from.
Two-factor authentication. SSH can require a username/password or
public key for authentication. In addition, these two options can be used
together for two-factor authentication
Integrity. SSH can create a digital signature of the data transferred from
one entity to another, ensuring that the data has not been modified or
tampered with in any way.
Overview of SSH
root gets a bash shell, sudhanshu gets a C shell, neeraja gets a Korn shell, and
the user jum4nj1 is not allowed to log in, since the shell allocated to jum4nj1s
Chapter 1
account is nologin, despite making a valid SSH connection. The SSH daemon
running on the Unix server would query the information from the passwd file
in order to process usernames for authentication. SSH does not use its own
username and passwords for authentication; it uses the operating systems
username and password information, which makes the process a lot easier to
use. The result would be that valid accounts with an appropriate shell in the
passwd file would be authenticated and given the correct shell, while being
encrypted with SSH.
The process works a bit differently in the Windows world, but the result is
still the same. Since Windows does not have different shell options, all SSH
users would be given a command prompt (cmd.exe) or some form of the command prompt itself. Similar to the Unix world, SSH services in Windows use
the existing password database (the SAM or ntds.dit files) for authentication.
Overview of SSH
Notice in Figure 1.3 that the FTP username (kusum) and password (dwivedi)
is in clear-text, similar to the Telnet session described previously. Furthermore,
since FTP provides remote file service, SCP and SFTP provide the same service
with a significant amount of security. Also, with a single service, remote command line execution and secure file transfer can be provided, instead of
enabling two different services such as Telnet and FTP. Figure 1.4 shows the
same two entities but uses SFTP instead.
Notice in Figure 1.4 that none of the information is in clear-text and readable
to anyone; thus, it is encrypted. In addition, Figure 1.5 shows the SFTP client
interface, which is similar to many FTP interfaces.
10
Chapter 1
While SCP and SFTP are good replacements for FTP, in certain environments they also can replace other risky protocols such as Windows Server
Message Block (SMB) and Unixs Network File Server (NFS). Both SMB and
NFS networking have had problems with security and continue to plague
many networks today. The use of SFTP for a common file server can reduce or
even eliminate reliance on SMB or NFS networking. Also, using a standard
protocol such as SFTP, both Unix and Windows clients can access the same
server, since both can communicate and use SSH but cannot necessarily communicate with SMB or NFS. Note that SSH can make the file-transfer process
longer than FTP, NFS, or SMB; however, in many cases, the delay is minor.
Secure Management
Many networks today adhere to poor management practices, leaving their
critical systems and devices vulnerable to management attacks. Many environments secure network devices and operating systems and create a properly
segmented network perimeter, but then they connect to sensitive systems/
devices with poor management protocols over wide-open or nonexistent management networks. The clear-text protocols mentioned earlier, such as Telnet,
FTP, and SNMP, are not the only poor management protocols in question, but
many management applications have not secured their communication appropriately or have known issues identified with them. Older versions of certain
management applications such as pcAnywhere, Virtual Network Computer
(VNC), and Citrix have either had poor encrypted management protocols,
which were reversed through engineering, or do not require any type of
Overview of SSH
Encrypted management
Added simplicity
Two-factor authentication
Proxy Services
SSH can also be used to secure proxy services. Proxy servers have been identified to contain established benefits to which SSH can add value. Deploying
SSH as a proxy service to access remote systems, devices, and applications in a
safe and easy manner is one of the strongest, but most unused, benefits of SSH.
SSH proxies can work with traditional proxy services such as SOCKS in order
to secure the application from end to end. A SOCKS server can be set up in an
11
12
Chapter 1
environment and tunnel traffic via SSH. This setup allows remote applications
such as SQL, Oracle, FTP, HTTP, and MySQL to be available with client applications such as SQL*PLUS and Query Analyzer over a secure channel.
SOCKS and SSH proxies can eliminate the need for an abundance of port
forwarding, as discussed in Chapter 9, and can provide secure access to applications that may not be available from the network perimeter.
Unlike the use of Secure Sockets Layer (SSL) in encrypted Web traffic
(denoted by the HTTPS (Hyper-text Transfer Protocol over SSL) prefix in URLS),
SSH proxies can be used in a couple of ways to secure Web traffic over hostile
networks, such as the Internet or wireless networks. SSH proxies can be used
to connect to remote Web servers running on internal networks, by using HTTP
tunneling over SSH, over the Internet. This function adds application security
and Web security when internal systems are accessed from remote sites.
SSH Server
Overview of SSH
The SSH client on the left provides authentication to the SSH server on
the right. In the initial connection, the client receives a host key of the
server; therefore, in all subsequent connections, the client will know it is
connecting to the same SSH server. This places less emphasis on the IP
address of the SSH server, which can be easily spoofed, and more
emphasis on the host key of the server, which cannot be spoofed very
easily.
If the SSH server authenticates the client and the client is authorized,
the SSH session begins between the two entities. All communication is
completely encrypted.
The client/server architecture for SSH provides the ability for clients to have
a single source for authentication and/or authorization. The single source for
authentication/authorization allows access only to the SSH service, while
access to various other services such as e-mail, intranets, extranets, and IRC
requires further authentication. Also, with the use of SSH proxies described
previously, a single source of authentication can provide access to applications
without the need for more usernames and passwords.
3DES
Blowfish
13
14
Chapter 1
Arc Four
CAST
DES
RC4
Any of the preceding encryption algorithms can be used for the ciphers for
the SSH connection. Most of the ciphers are well supported, but the use of DES
is strongly discouraged for the more secure 3DES option.
In addition to the preceding cipher algorithms, SSH offers Message Authentication Code (MAC) algorithm hashes. Two of the choices supported in most
SSH implementations are MD5 and SHA1. MAC algorithm hashes are used for
data integrity. Data transferred from one entity to another is hashed with a
unique cryptographic signature, differentiating it from other data. The cryptographic signature, generated with MD5 or SHA1 hashes, does not change
under any circumstances from one entity to the next. This ensures that the
entity receiving the data has obtained it without any modification, tampering,
or general abuse by unauthorized entities.
Overview of SSH
SSH Servers
OpenSSH (www.openssh.com)
SSH2 (www.ssh.com)
Commerical SSH
OpenSSH
PuTTY
Secure-CRT
WinSCP
15
16
Chapter 1
Commercial SSH on Unix (Red Hat Linux 8.0 and OpenBSD 3.1)
OpenSSH
The following paragraphs describe the prevalent servers using OpenSSH.
After the full installation of a Red Hat 8.0 server, use your favorite FTP client,
such as the command line client or built-in Web browser FTP functionality,
to download the latest RPM (Red Hat Package Manager) from ftp://ftp5.usa
.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm/RH80. I will be using
version 3.5 (openssh-3.5p1-1.i386.rpm). Download the RPM to the directory of
your choice; I recommend /usr/local/src. Once the file has been downloaded,
follow these directions:
1. From a shell, change directories to the location where the OpenSSH
RPM was downloaded:
# cd /usr/local/src
To start the daemon, change to the installation directory and start the service:
# cd /usr/sbin
# ./sshd p 22
Note, the p option is not needed if you are using the default port (22).
You should now have the SSH server running on port 22 on your Red Hat
8.0 machine. To confirm this, type netstat an and you should see the screen
shown in Figure 1.7.
Overview of SSH
Notice that all the interfaces, denoted by 0.0.0.0, are listening on port 22,
which is SSH.
Package-Based Implementation
After the full installation of a Red Hat 8.0 server, use your favorite FTP client,
such as the command line clients or built-in Web browser FTP functionality, to
download the latest package from ftp://ftp3.usa.openbsd.org/pub/OpenBSD/
OpenSSH/portable/openssh03.5p1.tar.gz. I will be using version 3.5 (openssh3.5p1.tar.gz). Download the package to the directory of your choice; I recommend /usr/local/src. Once the file has been downloaded, implement the following directions:
1. From a shell, change directories to the location where the OpenSSH
package was downloaded:
# cd /usr/local/src
Youre done!
To start the daemon, change to the installation directory and start the service:
# cd /usr/local/src/ssh
# ./sshd p 22
Note, the p option is not needed if you are using the default port (22).
17
18
Chapter 1
You should now have the SSH server running on port 22 on your Red Hat
8.0 machine. To confirm this, type netstat an and you should see the same
results as in Figure 1.7. Notice that all the interfaces, denoted by 0.0.0.0, are
listening on port 22, which is SSH.
OpenBSD 3.1
After the full installation of an OpenBSD 3.1 server, use your favorite FTP
client, such as the command line clients or the built-in Web browser FTP functionality, to download the latest tarball from ftp://ftp.openbsd.org/pub/
OpenBSD/OpenSSH/. I will be using version 3.5 (openssh-3.5.tgz). Download
the tarball to the directory of your choice; I recommend /usr/local/src. Once
the file has been downloaded, follow the subsequent directions.
1. From a shell, change directories to the location where the OpenSSH
package was downloaded:
# cd /usr/local/src
To start the daemon, change to the installation directory and start the service:
# cd /usr/local/src/ssh
# ./sshd p 22
Note, the p option is not needed if you are using the default port (22).
You should now have the SSH server running on port 22 on your OpenBSD
3.1 machine. To confirm this, type netstat an and you should see the same
results as in Figure 1.7.
Notice that all the interfaces, denoted by 0.0.0.0, are listening on port 22,
which is SSH.
Overview of SSH
19
20
Chapter 1
5. At this point, you have the option to install the client and server portions of SSH, as well as some shared tools and menu shortcuts (see Figure 1.10). Select Next.
6. Choose the installation location; I recommend keeping the default location (see Figure 1.11). Select Next.
Overview of SSH
7. Choose the shortcut location; I recommend keeping the default (see Figure 1.12). Click Install to begin installing the program:
8. You should see the installation in progress (see Figure 1.13).
9. During the installation process, you should see a text box, telling you
that you MUST edit the password file (passwd) in order for SSH to
work properly (see Figure 1.14). This is a very important step to follow
after the installation has been completed. Hit OK.
21
22
Chapter 1
10. Once installation is complete, select Finish and leave the Show Quickstart guide checked.
11. The Quickstart guide should now appear in Notepad.
12. Read the guide specifications under configuration.
13. From the command prompt, change the directory to the OpenSSH bin
directory.
c:\cd Program Files\OpenSSH\bin
Youre done!
Change to the installation directory and start the service: \Program Files\
OpenSSH\bin\net start opensshd.
To confirm the service has started, type netstat an and you should see the
screen shown in Figure 1.15:
Figure 1.14 Dialog box to edit the passwd file for appropriate installation for OpenSSH.
Overview of SSH
Notice that all the interfaces, denoted by 0.0.0.0, are listening on port 22,
which is SSH.
Commercial SSH
The following paragraphs describe the prevalent servers using the commercial
version of SSH.
23
24
Chapter 1
To start the daemon, change to the installation directory and start the service:
# cd /usr/local/src
# ./sshd2 p 22
Note, the p option is not needed if you are using the default port (22).
To confirm the service has started, type netstat an and you should see the
same results as Figure 1.15. Notice that all the interfaces, denoted by 0.0.0.0,
are listening on port 22, which is SSH.
Windows 2000
After the full installation of a Windows 2000 server, use your favorite FTP client,
such as ftp.exe or Internet Explorer, to download the latest version of Commercial SSH for Windows platforms (evaluation version unless you have purchased the license) from www.ssh.com/support/downloads/secureshellserver/
evaluation.mpl. I use version 3.2.3 (SSHSecureShellSever-3.2.3.exe). After you
have filled out the appropriate evaluation form, download the executable to
the directory of your choice; I recommend c:\temp. Once the file has been
downloaded, follow the subsequent directions.
1. Double-click on the exe file.
2. A welcome screen should appear (see Figure 1.16). Select Next to go to
the next screen.
Overview of SSH
3. Fully read the License Agreement (see Figure 1.17). If you agree, select
Yes. If you dont agree, hit Cancel and send this book to deprived engineers in Brookings, South Dakota.
4. Choose the installation location. I recommend keeping the default.
(See Figure 1.18.) Click Next.
5. Choose the program folder, we recommend keeping the default
(see Figure 1.19). Click Next.
Figure 1.18 Destination Location folder for the installation of Commercial SSH.
25
26
Chapter 1
Figure 1.20 Screen indicating that the SSH service has started.
Overview of SSH
27
28
Chapter 1
Overview of SSH
Remote access to internal applications, such as Road Warrior applications (Time and Expense)
29
30
Chapter 1
As you can see in the preceding list, SSH can address a variety of network
issues that concern security and functionality. For example, the process of port
forwarding an application protocol, such as Windows Terminal Server, may
not necessarily be a security requirement, but might be a functional requirement that limits the number of holes punched though a firewall. This allows a
single firewall rule to allow access from outside connections to the internal
SSH server and to port forward other applications, such as Windows Terminal
Servers 3389 port, to internal hosts.
On the other hand, there could be a security requirement that all management traffic should not only be encrypted but should enforce two-factor
authentication. By setting up an SSH proxy that requires two-factor authentication, all clients are required to use a username/password and public key for
authentication, while all information is encrypted. These uses fulfill the security requirements of the network without the extra costs and complexities of a
separate solution.
The benefits of using and optimizing SSH will continue to grow. As this
book unfolds, I will explore the different methods for using SSH on both Unix
and Windows environments for security and functionality. I will also demonstrate many examples of using SSH with the greatest amount of flexibility to
meet the needs of complex and convoluted networks.
Summary
In this chapter, some of the basics of SSH are discussed. Discussions about the
differences between SSH1 and SSH2 and the different uses of SSH itself establish an understanding of the protocol. The chapter also addresses the architecture of SSH, both client/server and encryption architecture, with a brief
description of the types of SSH servers and clients. The chapter concludes with
a detailed, step-by-step guide to installing SSH. This provides a basic understanding of the protocol as well as basic setup of the application. In the next
two chapters, I discuss the basic implementation and setup of several different
SSH servers and clients, allowing you to proceed with optimal usages for SSH
in Chapter 4 and the rest of the book.
From this point forward, you should have two SSH servers deployed in
some type of network environment: one Unix based and one Windows based.
CHAPTER
2
SSH Servers
There are three main SSH servers that provide different types of functionality
and usage: OpenSSH, SSH Communications SSH server, and VanDyke Softwares VShell SSH server. In chapter one, we install all three of these servers;
however, we do not discuss the configuration, the uses, and the different features of these servers. While the three main SSH servers offer similar SSH services, they provide different levels of functionality, several of which may be
better for your environment than others. The type of SSH server you use can
significantly affect the type of SSH experience you have. For example, several
SSH servers offer both command line access and secure file transfer; however,
if SSH is being deployed for port forwarding only (discussed in Chapters 6
and 7) or for file transfer, giving the user command line access may not be
acceptable.
This chapter discusses the three main SSH servers available for Unix and
Windows. Also, the focus of the chapter is on selected configuration items and
the menus of the three SSH servers, in terms of customization and optimal
usage. The following SSH servers are examined in this chapter:
31
32
Chapter 2
OpenSSH server
Unix
*Windows
Windows
OpenSSH
OpenSSH servers are available on both Windows and Unix environments. The
Windows version is actually a port of OpenSSHs Unix version using the popular Cygwin utility (see www.cygwin.com for more details). While the Windows port of OpenSSH uses Cygwin, note that the port is not a full installation
of Cygwin and does not require additional Cygwin utilities, which is ideal
since Cygwin requires a separate installation procedure. Since both the Unix
and Windows versions of OpenSSH use the same configuration file for the
SSH server, the sshd_config file, I discuss the file itself in detail. It can apply to
both Windows and Unix platforms. To view the configuration file, enter the
following commands.
On Unix:
#cd /etc/ssh
#more sshd_config
On Windows:
C:\cd Program Files\OpenSSH\bin
C:\Programe Files\OpenSSH\bin\type sshd_config
SSH Servers
Table 2.1 describes the first four options in the sshd_config file.
Table 2.1
OPTION
DESCRIPTION
Port
Protocol
22
80
443
8080
ListenAddress
The next section discusses the host-key section. The host-key section discusses parameters around the SSH servers host key, which is the fingerprint
used to identify the SSH server.
#
#
#
#
#
33
34
Chapter 2
version 2 format. Also, for SSH version 2, the section states the location of both
the RSA and DSA keys.
The next section addresses the server key:
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768
This section sets the logging option for the SSH service. The differentiation
between QuiteMode and FascistLogging is that QuiteMode logs only fatal
errors, whereas FascistLogging enables verbose logging. SyslogFacility specifies the syslog code to use when logging messages from SSH, such as Daemon
and Auth. Loglevel specifies the level used when logging messages from SSH,
such as only informational messages (INFO).
The next section addresses authentication options with SSH:
#Authentication
#LoginGraceTime 120
#PermitRootLogin yes
#StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile
.ssh/authorized_keys
Table 2.2 describes the authentication options available for the SSH server.
Table 2.2
Authentication Options
OPTION
DESCRIPTION
LoginGraceTime
SSH Servers
Table 2.2
(continued)OPT
OPTION
DESCRIPTION
PermitRootLogin
StrictModes
RSAAuthentication
PubkeyAuthentication
AuthorizedKeysFile
Table 2.3 describes the rhost authentication options available for the SSH
server.
35
36
Chapter 2
Table 2.3
OPTION
DESCRIPTION
RhostAuthenication
Ignore Rhosts
RhostsRSAAuthenication
HostbasedAuthenication
IgnoreUserKnownHosts
The last authentication section for the sshd_config file addresses more password options, including Kerberos usage:
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#AFSTokenPassing no
# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no
Table 2.4 describes the password and Kerberos authentication options available for the SSH server.
Table 2.4
OPTION
DESCRIPTION
PasswordAuthentication
PermitEmptyPasswords
SSH Servers
Table 2.4
(continued)OPT
OPTION
DESCRIPTION
ChallengeResponse
Authentication
Kerberos Authentication
KerberosOrLocalPasswd
KerberosTicketCleanup
AFSTokenPassing
KerberosTgtPassing
The next section of the sshd_config file addresses X11 options that can be
used with forwarding:
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
37
38
Chapter 2
#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no
# override default of no subsystems
Subsystem
sftp
/usr/libexec/sftp-server
Table 2.5 describes the various miscellaneous options that are available for
the SSH server.
Table 2.5
OPTION
DESCRIPTION
PrintMotd
PrintLastLog
UseLogin
UserPrivilegeSeparation
PermitUserEnvironment
Compression
Banner
Subsystem sftp
You may have noticed that many of the options in the sshd_config file are
specific to Unix implementations of OpenSSH. While a full sshd_config file
can be used on Windows platforms, many of the items will not apply, since
they do not exist in the Windows world, such as Syslog and rhost authentication. Once you have opened the sshd_config on the Windows machine, you
should see only an abbreviated portion of the bigger sshd_config file on Unix,
as the following code shows:
SSH Servers
HostKey
HostDSAKey
PidFile
Protocol
Port
/ssh/ssh_host_key
/ssh/ssh_host_dsa_key
/ssh/sshd.pid
2
22
PermitRootLogin
PasswordAuthentication
IgnoreRhosts
IgnoreUserKnownHosts
RhostsAuthentication
RhostsRSAAuthentication
RSAAuthentication
yes
yes
yes
yes
no
no
no
Subsystem
sftp
/ssh/sftp-server
Despite the abbreviated portion of the sshd_config file, all the entries have
the same definition described in the previous file portion.
39
40
Chapter 2
General
The general section of the sshd2_config file should look similar to the following:
## General
#
VerboseMode
#
QuietMode
#
ForcePTTYAllocation
#
SyslogFacility
#
SyslogFacility
no
yes
no
AUTH
LOCAL7
Table 2.6 describes the general options available for the SSH server.
Table 2.6
OPTION
DESCRIPTION
VerberosMode
QuietMode
ForcePTTYAllocation
SyslogFacility
Network
The network section of the sshd2_config file should look like the following:
#
#
#
#
#
#
#
#
Port
ListenAddress
RequireReverseMapping
MaxBroadcastsPerSecond
MaxBroadcastsPerSecond
NoDelay
KeepAlive
MaxConnections
MaxConnections
22
any
no
0
1
yes
yes
50
0
Table 2.7 describes the network options available for the SSH server.
SSH Servers
Table 2.7
OPTION
DESCRIPTION
Port
ListenAddress
22
80
443
8080
RequireReverseMapping
MaxBroadcastPerSecond
NoDelay
KeepAlive
MaxConnections
41
42
Chapter 2
Crypto
The Crypto section of the sshd2_config file should look similar to the following:
#
Ciphers
AnyCipher
# Following includes none cipher:
#
Ciphers
AnyStd
#
#
Ciphers
AnyStdCipher
#
Ciphers
3des
# Following includes none mac:
#
MACs
AnyMAC
#
#
MACs
AnyStd
#
MACs
AnyStdMAC
#
RekeyIntervalSeconds
3600
Table 2.8 describes the Crypto options available for the SSH server.
Table 2.8
OPTION
DESCRIPTION
Ciphers
MACs
RekeyIntervalSeconds
SSH Servers
Users
The Users section of the sshd2_config file should look like the following:
#
#
#
#
#
#
#
#
#
PrintMotd
CheckMail
UserConfigDirectory
UserConfigDirectory
UserKnownHosts
LoginGraceTime
PermitEmptyPasswords
StrictModes
IdleTimeOut
yes
yes
%D/.ssh2
/etc/ssh2/auth/%U
yes
600
no
yes
1h
Table 2.9 describes the various miscellaneous options available for the SSH
server.
Table 2.9
OPTION
DESCRIPTION
PrintMotd
CheckMail
UserConfigDirectory
UserKnownHosts
43
44
Chapter 2
Table 2.9
(continued)
OPTION
DESCRIPTION
LoginGraceTime
PermitEmptyPasswords
StrictModes
IdleTimeOut
HostKeyFile
PublicHostKeyFile
RandomSeedFile
IdentityFile
AuthorizationFile
AllowAgentForwarding
hostkey
hostkey.pub
random_seed
identification
authorization
yes
Table 2.10 describes the User Public Key options available for the SSH server.
SSH Servers
Table 2.10
OPTION
DESCRIPTION
HostKeyFile
PublicHostKeyFile
RandomSeedFile
IdentityFile
id_dsa_2048_a
id_rsa_2048_a
id_dsa_2048_a.pub
id_rsa_2048_a.pub
45
46
Chapter 2
Tunneling
The Tunneling section of the sshd2_config file should look similar to the
following:
#
#
#
#
#
#
AllowX11Forwarding
AllowTcpForwarding
AllowTcpForwardingForUsers
DenyTcpForwardingForUsers
AllowTcpForwardingForGroups
DenyTcpForwardingForGroups
yes
yes
sjl, cowboyneal@slashdot\.org
2[[:isdigit:]]*4,peelo
priviliged_tcp_forwarders
coming_from_outside
Table 2.11 describes the tunneling options available for the SSH server.
Table 2.11
OPTION
DESCRIPTION
AllowX11Forwarding
AllowTcpForwardingForUsers
DenyTcpForwardingForUsers
AllowTcpForwardingForGroups
DenyTcpForwardingForGroups
Authentication
The Authentication section of the sshd2_config file should look like the
following:
#
#
#
#
#
BannerMessageFile
BannerMessageFile
PasswordGuesses
AllowedAuthentications
AllowedAuthentications
/etc/ssh2/ssh_banner_message
/etc/issue.net
3
hostbased,publickey,password
publickey,pam-1@ssh.com
SSH Servers
#
#
#
#
AllowedAuthentications
publickey,password
RequiredAuthentications
publickey,password
HostbasedAuthForceClientHostnameDNSMatch no
SshPAMClientPath
ssh-pam-client
Table 2.12 describes the authentication options available for the SSH server.
Table 2.12
OPTION
DESCRIPTION
BannerMessageFile
PasswordGuesses
AllowedAuthentications
RequiredAuthentications
HostbasedAuthForce
ClientHostnameDNSMatch
SshPAMClientPath
Host Restrictions
The Host Restrictions section of the sshd2_config file should look like the
following:
#AllowHosts
##AllowHosts
##
AllowHosts
##
AllowHosts
##
#
DenyHosts
#
AllowSHosts
#
DenySHosts
#
IgnoreRhosts
#
IgnoreRootRHosts
47
48
Chapter 2
Table 2.13 describes the Host Restrictions options available for the SSH server.
Table 2.13
OPTION
DESCRIPTION
AllowHosts
DenyHosts
AllowSHosts
DenySHosts
IgnoreRhosts
IgnoreRootRHosts
Users Restrictions
The Users Restrictions section of the sshd2_config file should look like the
following:
#
#
#
#
#
#
AllowUsers
DenyUsers
DenyUsers
AllowGroups
DenyGroups
PermitRootLogin
PermitRootLogin
sj.*,s[[:isdigit:]]*,s(jl|amza)
skuuppa,warezdude,31373
don@untrusted\.org
staff,users
guest
nopwd
no
Table 2.14 describes the Users Restrictions options available for the SSH
server.
SSH Servers
Table 2.14
OPTION
DESCRIPTION
AllowUsers
DenyUsers
AllowGroups
DenyGroups
PermitRootLogin
SSH1 Compatibility
The SSH1 Compatibility section of the sshd2_config file should look similar to
the following:
#
#
#
Ssh1Compatibility
Sshd1Path
Sshd1ConfigFile
Table 2.15 describes the SS1 Compatibility options available for the SSH
server.
49
50
Chapter 2
Table 2.15
OPTION
DESCRIPTION
Ssh1Compatibility
Sshd1Path
Sshd1ConfigFile
Chrooted Environment
The Chrooted Environment allows specific users to be limited to their home
directories, either with a shell or with file transfer. In addition to entering the
correct information in the sshd2_config file, the ssh-chroot manager needs to
be initiated. The Chrooted Environment section of the sshd2_config file should
look like the following:
#
#
ChRootUsers
ChRootGroups
ftp,guest
guest
Table 2.16 describes the Chroot options available for the SSH server.
Table 2.16
OPTION
DESCRIPTION
ChRootUsers
ChRootGroups
Subsystem Definitions
The Subsystem Definitions section of the sshd2_config file should look like the
following:
subsystem-sftp
sftp-server
SSH Servers
Table 2.17 describes the SFTP options available for the SSH server.
Table 2.17
OPTION
DESCRIPTION
subsystem-sftp
51
52
Chapter 2
General Settings
The general section of the sshd2_config file should look like the following:
## General settings
MaxConnections
EventLogFilter
IdleTimeout
BannerMessageFile
TerminalProvider
DoubleBackspace
#
ProtocolVersionString
0
error, warning
0
cmd.exe
yes
The general section of the SSH configuration GUI should look like Figure 2.2.
SSH Servers
Figure 2.2 General screen from the SSH server configuration tool.
Table 2.18 describes the General options available for the SSH server.
Table 2.18
.OPTION
DESCRIPTION
MaxConnections
EventLogFilter
IdleTimeout
BannerMessageFile
TerminalProvider
53
54
Chapter 2
Network Settings
The network section of the sshd2_config file should look like the following:
Port
ListenAddress
RequireReverseMapping
ResolveClientHostName
MaxBroadcastsPerSecond
NoDelay
KeepAlive
443
0.0.0.0
no
yes
0
yes
yes
The network section of the SSH configuration GUI should look like Figure 2.3.
Figure 2.3 Network screen from the SSH server configuration tool.
SSH Servers
Table 2.19 describes the Network options available for the SSH server.
Table 2.19
OPTION
DESCRIPTION
Port
ListenAddress
22
80
443
8080
RequireReverseMapping
ResolveClientHostname
(sshd2_config file only)
MaxBroadcastPerSecond
(sshd2_config file only)
55
56
Chapter 2
Table 2.19
(continued)
OPTION
DESCRIPTION
NoDelay
KeepAlive
Crypto Settings
The Crypto section of the sshd2_config file should look like the following:
Ciphers
MACs
RekeyIntervalSeconds
RandomSeedFile
AnyStdCipher
AnyStdMac
0
server_random_seed
The Encryption section of the SSH configuration GUI should look like
Figure 2.4.
Figure 2.4 Encryption screen from the SSH server configuration tool.
SSH Servers
Table 2.20 describes the Encryption options available for the SSH server.
Table 2.20
OPTION
DESCRIPTION
Ciphers
MACs
RekeyIntervalSeconds
Specifies the amount of time before the keyexchange process is executed again. The default is
3600 seconds, which is one hour. The key-exchange
process can be disabled by setting the value to zero.
RandomSeedFile
Users Settings
The Users section of the sshd2_config file should look like the following:
LoginGraceTime
PermitEmptyPasswords
UserConfigDirectory
AuthorizationFile
PrivateWindowStation
600
no
%D/.ssh2
authorization
yes
The User Authentication section of the SSH configuration GUI should look
like Figure 2.5.
57
58
Chapter 2
Figure 2.5 User Authentication screen from the SSH server configuration tool.
Figure 2.6 User AuthenticationPassword screen from the SSH server configuration tool.
SSH Servers
Figure 2.7 User AuthenticationPublic Key screen from the SSH server configuration tool.
Table 2.21 describes the User Authentication options available for the SSH
server.
Table 2.21
OPTION
DESCRIPTION
LoginGraceTime
PermitEmptyPasswords
UserConfigDirectory
(sshd2_config file)
59
60
Chapter 2
Table 2.21
(continued)
OPTION
DESCRIPTION
id_dsa_2048_a.pub
id_rsa_2048_a.pub
HostKeyFile
PublicHostKeyFile
hostkey
hostkey.pub
The Identity section of the SSH configuration GUI should look like Figure 2.8.
Table 2.22 describes the Server Public Key options available for the SSH
server.
Table 2.22
OPTION
DESCRIPTION
HostKeyFile
PublicHostKeyFile
SSH Servers
Figure 2.8 Identity screen from the SSH server configuration tool.
HostKeyFile
HostCertificateFile
Pki
MapFile
LDAPServers
SocksServer
PkiDisableCRLs
no
Table 2.23 describes the Server Certificate options available for the SSH
server.
Table 2.23
OPTION
DESCRIPTION
HostKeyFile
HostCertificateFile
PKI
61
62
Chapter 2
Table 2.23
(continued)
OPTION
DESCRIPTION
MapFile
LDAPServers
SocksServer
PKIDisableCRLs
Tunneling Configurations
The Tunneling section of the sshd2_config file should look similar to the
following:
#
#
AllowTcpForwarding
AllowTcpForwardingForUsers
DenyTcpForwardingForUsers
no
Figure 2.9 Tunneling screen from the SSH server configuration tool.
SSH Servers
Table 2.24 describes the Tunneling options available for the SSH server.
Table 2.24
OPTION
DESCRIPTION
AllowTcpForwarding
AllowTcpForwardingForUsers
DenyTcpForwardingForUsers
Authentication Methods
The Authentication section of the sshd2_config file should look like the
following:
#
#
PasswordGuesses
AllowedAuthentications
RequiredAuthentications
AuthInteractiveFailureTimeout
AuthKbdInt.NumOptional
AuthKbdInt.Optional
AuthKbdInt.Required
AuthKbdInt.Retries
3
publickey,password,
publickey,
2
0
Table 2.25 describes the Authentication options available for the SSH server.
Table 2.25
OPTION
DESCRIPTION
PasswordGuesses
(Shown in Figure 4.5)
AllowedAuthentications
(Shown in Figure 4.6 and
4.7 with the Password
Authenication drop down
box or the Public Key drop
down box)
(continued)
63
64
Chapter 2
Table 2.25
(continued)
OPTION
DESCRIPTION
RequiredAuthentications
(Shown in Figure 4.6 and
4.7 with the Password
Authenication drop down
box or the Public Key
drop down box)
AuthKbdInt.Optional
(sshd2_config file only)
Identifies the optional submethod that KeyboardInteractive will use. The options can be SecureID,
plugin, and password.
AuthKbdInt.Required
(sshd2_config file only)
AuthKbdInt.Retries
(sshd2_config file only)
Host Restrictions
The Host Restrictions section of the sshd2_config file should look like the
following:
#
#
AllowHosts
DenySHosts
The Host Restrictions section of the SSH configuration GUI should look like
Figure 2.10.
SSH Servers
Figure 2.10 Host Restrictions screen from the SSH server configuration tool.
Table 2.26 describes the Host Restrictions options available for the SSH
server.
Table 2.26
OPTION
DESCRIPTION
AllowHosts
DenyHosts
User Restrictions
The User Restrictions section of the sshd2_config file should look like the
following:
#
#
#
AllowUsers
DenyUsers
PermitRootLogin
PermitUserTerminal
The User Restrictions section of the SSH configuration GUI should look like
Figure 2.11.
65
66
Chapter 2
Figure 2.11 User Restrictions screen from the SSH server configuration tool.
Table 2.27 describes the User Restriction options available for the SSH
server.
Table 2.27
OPTION
DESCRIPTION
AllowUsers
DenyUsers
PermitRootLogin
PermitUserTerminal
SSH Servers
Subsystem Definitions
The Subsystem Definitions section of the sshd2_config file should look like the
following:
subsystem-sftp
SftpLogCategory
Sftp-DirList
Sftp-Home
Sftp-AdminDirList
#
Sftp-AdminUsers
sftp-server2.exe
16
HOME=%D
%D
HOME=%D, C:=C:, D:=D:
The SFTP Server section of the SSH configuration GUI should look like Figure 2.12.
The SFTP ServerPower Users section should look like Figure 2.13.
Figure 2.12 SFTP Server screen from the SSH server configuration tool.
67
68
Chapter 2
Figure 2.13 SFTP ServerPower Users screen from the SSH server configuration tool.
Table 2.28 describes the SFTP options available for the SSH server.
Table 2.28
OPTION
DESCRIPTION
subsystem-sftp
(sshd2_config file only)
Sftplogcategory (sshd2_config) Specifics the SFTP operations that are logged in the
Event Log categories (GUI on Windows Event Viewer. The default value is 16,
Figure 4.12)
which only logs user logins and logouts.
Sftp-DirList (sshd2_config)
Accessible Directories
(GUI on Figure 4.12)
Sftp-Home (sshd2_config)
User Home Directory
(GUI on Figure 4.12)
SSH Servers
Table 2.28
(continued)
OPTION
DESCRIPTION
Sftp-AdminDirList
Accessible Directories
(GUI on Figure 4.13)
Sftp-AdminUsers
Power Users
(GUI on Figure 4.13)
General Settings
To view the configuration screen (see Figure 2.14), browse to the VShell shortcut, Start Program VShell VShell.
69
70
Chapter 2
In the configuration screen, highlight the general section first. The general
section describes some of the global options for the SSH server, which are
listed in Table 2.29.
Table 2.29
OPTION
DESCRIPTION
ListeningPort
22
80
443
8080
MOTD file
Command Shell
Command arguments
GeneralHost Key
Highlight the GeneralHost Key section next (see Figure 2.15). The General
Host Key section describes the host-key location as well as the fingerprint.
Various options are given in Table 2.30.
SSH Servers
Table 2.30
OPTION
DESCRIPTION
Filename
Identifies the path to the host key for the VShell SSH
server
Fingerprint
GeneralKey Exchanges
Highlight the GeneralKey Exchanges section next (see Figure 2.16). The
GeneralKey Exchanges section describes the key exchange options. Various
options are given in Table 2.31.
71
72
Chapter 2
Table 2.31
OPTION
DESCRIPTION
Algorithms
Re-exchanges
Enables (check) or disables (no check) the reexchange of keys. If checked, an interval, in minutes,
should be selected
GeneralCipher
Highlight the GeneralCipher section next (see Figure 2.17) The General
Cipher section describes the encryption options, which are listed in Table 2.32.
SSH Servers
Table 2.32
OPTION
DESCRIPTION
Cipher
GeneralMAC
Highlight the GeneralMAC section next (see Figure 2.18). The GeneralMAC
section describes the hash options, which are listed in Table 2.33.
73
74
Chapter 2
Table 2.33
OPTION
DESCRIPTION
MAC
GeneralCompression
Highlight the GeneralCompression section next (see Figure 2.19). The
GeneralCompression section describes the compression options, which are
listed in Table 2.34.
SSH Servers
Table 2.34
OPTION
DESCRIPTION
Enable Compression
Authentication
Highlight the Authentication section next (see Figure 2.20). The Authentication section describes the key exchange options, which are listed in Table 2.35.
75
76
Chapter 2
Table 2.35
OPTION
DESCRIPTION
Required authentication
methods Password
Required authentication
methods Public Key
Required authentication
methods Public Key
Uploads
SSH Servers
Access Control
Highlight the Access Control section next (see Figure 2.21). The Access Control
section describes the rights and privileges for different users, which are listed
in Table 2.36.
Table 2.36
OPTION
DESCRIPTION
Name
Permissions
77
78
Chapter 2
SFTP Section
Highlight the SFTP section next (see Figure 2.22). The SFTP section describes
the secure file transfer options, which are listed in Table 2.37. These options are
also excellent because they allow the control of specific folders to publish to
SFTP users. This can help secure a file server by allowing only authorized
directories on a file server, such as d:\Common files\, while restricting the
users from sensitive operation system files and folders, such as c:\winnt\.
This option allows an SSH server to provide full file-system security over an
SFTP session without any worries that the user may be able to access and
download other files that may be on the SSH server.
Table 2.37
OPTION
DESCRIPTION
SFTP Root
SSH Servers
Triggers
Highlight the Triggers section next (see Figure 2.23). The Triggers section
describes any triggers options that can be executed to SFTP uploads or failed
authentications, which are listed in Table 2.38.
79
80
Chapter 2
Table 2.38
OPTION
DESCRIPTION
Failed Authentications
Connection Filters
Highlight the Connection Filters section next (see Figure 2.24). The Connection
Filters section describes who can and cannot connect to the SSH server.
Options are shown in Table 2.39. When a VShell SSH server is deployed on a
network, access to everyone, which may be all internal machines or all Internet machines, may not be desired. This option allows you to set filters and
restrict access to the VShell SSH server.
Table 2.39
OPTION
DESCRIPTION
Filter Entries
Test Filter
SSH Servers
Port-Forward Filters
Highlight the Port-Forward Filters section next (see Figure 2.25). The PortForward Filters section describes the port-forwarding options, which are listed
in Table 2.40. The Port-Forward Filters section describes which machines can
be accessed on which ports via SSH tunneling. When a VShell SSH session is
established between a source and a destination, port forwarding to remote
servers may not be desired for security purposes. This option allows you to set
filters that specify the servers and ports allowed to be accessed, eliminating
the security risk of authorized SSH users tunneling to machines they should
81
82
Chapter 2
not be accessing. For example, an SSH session may allow remote management
to a Windows Terminal Server on port 3389 (Terminal Services); however,
access to the FTP (port 21) service on the same machine may be not be desired.
If a filter is set to allow only 3389 to be tunneled to the Windows machine,
access to the FTP service via a port-forward tunnel will be denied.
SSH Servers
Table 2.40
OPTION
DESCRIPTION
Filter Entries
Test Filter
Logging
Highlight the Logging section next (see Figure 2.26). The Logging section
describes the logging options, which are listed in Table 2.41.
Table 2.41
OPTION
DESCRIPTION
83
84
Chapter 2
SSH Servers
Summary
This chapter examines three SSH servers that can be used with any SSH client:
OpenSSH, SSH Communications SSH Server, and VanDyke Softares VSHell
SSH server. Many more, equally effective SSH servers exist than the ones discussed here; however, in the interests of time and space, they have not been
covered. Be aware that most of the other servers are very similar to the ones
examined in the previous paragraphs. For example, F-Secures SSH server and
SSH Communications SSH server are practically alike.
When deciding on the choice of an SSH server for your organization, it is
important to know the business and technical requirements in addition to the
different options available with each. While many SSH servers offer similar
functionality, many offer features that might not be present in others. For
example, if your SSH architecture is being used for terminal access, port forwarding, SFTP, or all of the above, different SSH servers have strengths and
weaknesses that should influence your decision.
In this chapter, I have described in detail the various options available in
each SSH server and use this information throughout the rest of this book to
highlight the strengths and weakness of the SSH servers. This approach will
not only help you understand the features of the SSH servers, but will also
allow you to make an informed decision when choosing a server.
Chapter 1 of this book has covered the basics of SSH (namely, the deployment of SSH servers), and Chapter 2 has covered the detailed descriptions of
SSH servers themselves. The next chapter focuses on SSH clients.
85
CHAPTER
3
Secure Shell Clients
Many SSH clients provide different types of functionality and usage. The list
of SSH clients includes freeware, downloadable easily from the information
superhighway; noncommercial freeware, available for all development and
learning environments; and pay commercial clients, used only for commercial
use and commercial development. While there may be several SSH clients that
can be used for various operating systems, all SSH clients are not created
equal. The type of SSH client you use can significantly affect the type of SSH
experience you have. For example, several SSH clients do not have built-in
SFTP or SCP functionality. The absence of such functionality requires you to
download and use two separate tools: one for SSH usage and one for
SFTP/SCP usage. Although using two tools may be simple enough, the cumbersome process might discourage novice users. The SSH clients that provide
built-in SFTP/SCP functionality might offer you a superior SSH experience.
This chapter explores several SSH clients available for Unix and Windows.
Also, the configuration of various SSH clients and customization for optimal
usage is discussed. The following clients are the focus of this chapter:
Command-Line SSH Clients
OpenSSH
88
Chapter 3
SecureCRT
PuTTY
WinSCP
MindTerm
MacSSH
The discussion of SSH clients in this chapter, and throughout this book, is
limited to the major ones. Keep in mind that there are many other types of SSH
clients, very similar to and as good as the ones covered here. For example,
F-Secures SSH client and SSH Communications SSH client are extremely similar.
Although many of the SSH clients discussed in this chapter offer similar
functionality, there are various subtle differences among them. For example,
SSH Communications SSH client offers an integrated SFTP client that can be
used in a seamless fashion. On the other hand, SecureCRT does not provide a
fully integrated tool for SFTP in its SecureCRT SSH client; however, SecureCRT does contain an HTTP proxy tunnel that is very easily configurable but
not so simple on SSH Commutations SSH client. Furthermore, MindTerms
FTP-to-SFTP bridging capability provides an easy method for connecting nonSSH enabled clients to gain access to an SFTP server. Despite the fact that the
connection from the FTP client to the SFTP client is still insecure, the connection from the SFTP server to SFTP client is still secure, which might be the only
connection used over an insecure network such as the Internet.
Your choice of an SSH client is highly dependant on the type of functionality required for SSH. Since SSH can be used in a variety of ways, it is important
to understand the various clients and the specific functionality that each offers.
This chapter will allow your SSH-client decision to be as informed as possible.
For example, if SSH is being deployed primarily for its file-transfer capabilities, WinSCP and SSH Communications SSH clients are probably good
choices. On the other hand, if SSH is being deployed for remote shell access via
an HTTP proxy server, the SecureCRT and PuTTY clients are probably good
choices. Lastly, if SSH is being deployed for remote access from undefined and
uncontrolled terminal locations, MindTerm is probably a good choice, since it
offers SSH access with the need of only a Web browser.
The SSH client you choose does not have to be based exclusively on technical capabilities; personal preference is important as well. While there may be
many differences among SSH clients, their basic principle is the same:
encrypted communication.
and Unix. Since the OpenSSH and Secure Shell Communications clients are so
similar, the following paragraphs cover both of the clients features. Also, since
the command-line clients contain similar features, if not the same features, on
Windows and Unix versions, the following section can be used on Windows
command-line clients or Unix command-line clients.
The SSH clients can be purchased and/or downloaded for commercial or
noncommercial use from the following Web site:
www.ssh.com/support/downloads/secureshellwks/
Since we will be using SSH for a noncommercial use, the noncommercial
version can be downloaded from www.secondstory.org/mirror/ssh/. Also,
the OpenSSH client for Unix can be downloaded from the following site:
ftp://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/portable
/openssh03.5p1.tar
The Windows command-line client can be downloaded from the following
site:
http://lexa.mckenna.edu/sshwindows/
Windows Installation
Installing the SSH client is a relatively easy process on a Windows operating
system. Once you have downloaded the executable files from http://lexa
.mckenna.edu/sshwindows/ (OpenSSH) or www.ssh.com (SSH Communications), a wizard will walk you through the installation process. Keep in mind
that you need to install only the clients for the purposes of this chapter. Installation of the server is discussed in Chapter 1. Many of the client binaries are
installed automatically when an SSH server has been installed on a Windows
machine.
Unix Installation
Once you have downloaded the SSH client from www.ssh.com or www.openssh
.com on a Unix operating system, it must first be extracted. (The letters XYZ that
follow are a variable that signifies the version number of the SSH client you will
be downloading):
#gunzip c ssh-XYZ.tar.gz | tar xvf
After extraction, change directories to the SSH folder. Once inside the SSH
folder, the binary must be compiled and created:
#cd ssh-XYZ
#./configure
89
90
Chapter 3
#make
#make install
Once the binary has been compiled, it will place the binary in /usr/local/bin.
At this point, the help file should be ready for viewing. SSH Communications SSH client binary is called ssh2 on both Windows and Unix. On Windows, the file can be located at \Program Files\SSH Secure Shell\ssh2.exe. On
Unix, the file can be located at /usr/local/bin/ssh2. OpenSSH client binary is
called ssh on both Unix and Windows. On Windows, the file can be located at
\Program Files\OpenSSH\bin\ssh.exe. On Unix, the file can be located at
/usr/local/bin/ssh. Once you have located the SSH client binary, type ssh2
h for the SSH Communications binary or ssh h for OpenSSHs binary. The
following help should appear:
Usage: ssh2 [options] [user@]host[#port] [command]
Options:
-l
-n
+a
-a
+x
As shown previously, the SSH help file is exhaustive and shows the wide
array of options that SSH can provide. In its simplest sense, SSH can connect
an SSH server listening on its default port, which is 22. The p switch is
required in order to specify a port other than 22; however, if p is not used,
port 22 will be used as the default. Similarly, the l switch needs to be used in
order to specify a username. If you do not use the l switch, the current user
that the command is being executed from will be used:
ssh 10.0.0.3 l cdwivedi p 22
cdwivedis password:
Authentication successful.
Last login: Thurs June 12 05:52:06 2003 from 172.16.11.17
l and p are two of the various switches used with the SSH client. The
following section describes some of the more important switches used
throughout the rest of this book.
The first switch is i. The i switch can be used to point to a pubic-key file
used to authenticate to an SSH server. A copy of the public-key file needs to
exist on the SSH server for public-key authentication, discussed further in
Chapter 4. An example of the i switch follows:
ssh 10.0.0.3 l cdwivedi p 60599 i publickey.pub
The L and R switches are used for local port forwarding and remote port
forwarding. Port forwarding is discussed in Chapter 6; however, a general
understanding of its syntax is required now. Local port forwarding allows the
local connection to a port to be forwarded to a remote server on any remote
port through the SSH server. For example, a mail server that has the IP address
10.0.0.100 and is listening on port 143 can be accessed using SSH. The SSH
91
92
Chapter 3
server, which has the IP address 10.0.0.3, needs a valid route to the machine.
The following is an example of using the L switch for local port forwarding:
ssh 10.0.0.3 l cdwivedi L 143:10.0.0.100:143
Options can be also set for the type of encryption desired as well as the type
of MAC algorithm. For example, if the SSH server accepts only connections
using Triple-DES (3DES), the c switch should be used. Triple-DES is an
algorithm that can be used to encrypt data. This allows 3DES to be used to
encrypt data that traverses the network. If more than one type of encryption is
supported, multiple c options can be used. The following are two examples of
the encryption options:
ssh 10.0.0.3 l cdwivedi c 3DES
ssh 10.0.0.3 l cdwivedi c 3DES c Blowfish
The MAC algorithms used can either be MD5 or SHA1. Both MD5 and
SHA1 are algorithms that can be used to verify the integrity of data. MD5 uses
a 128-bit message digest from data input that is unique to the data. SHA1
uses a 160-bit message digest from data input that is also unique to the data.
This allows the MD5 and SHA1 hashes to be used as a fingerprint for a particular piece of data. To use the MAC algorithms, the m flag should be used with
the specific option (hmac-md5 or hmac-sha1) in order to hash the data that will
be transferred between to entities. The following are two examples of the MAC
options:
ssh 10.0.0.3 l cdwivedi m hmac-md5
ssh 10.0.0.3 l cdwivedi m hmac-sha1
The F switch is used to point to a different configuration file for the SSH
session. Every SSH session uses a configuration file as input when attempting
to establish a connection. Configuration files are discussed in the next section,
SSH Client Configuration File. If an end user needs to connect to two or
more SSH servers that have different parameters, such as listening on different
ports, it is easier to point to a different configuration file than to remember the
input parameters required for the SSH servers. Lets say that SSH server A listens on port 101, enables local forwarding to the mail server, and requires
3DES for encryption. Furthermore, server B listens on port 701, enables local
forwarding to the file server, and requires Blowfish for encryption. The two
commands, without using configuration files, would be as follows:
ssh 10.0.0.3 l cdwivedi p 101 -L 143:172.16.1.100:143 c 3DES
ssh 10.0.0.4 l cdwivedi p 701 L 139:172.16.1.200:139 c Blowfish
Although remembering two commands may not be that difficult, connecting to more than two SSH servers with different forwarding rules, different
port specifications, and different encryption algorithms becomes a cumbersome process. Using two configuration files significantly eases the log in
process and user experience, as shown in the following example:
ssh 10.0.0.3 l cdwivedi F mail.config
ssh 10.0.0.4 l cdwivedi F file.config
The next two switches are quite simple when you are using them with IP
version 4 or IP version 6. Using IP version 6 assumes that an IP version 6 network is in use, which is beyond the scope of this book and SSH; however, SSH
provides support for IP version 6 packets. IP version 4 is the default packet
type, but both flags can be used if the networks are available. Following are
two examples of the switches:
ssh 10.0.0.3 l cdwivedi 4
ssh 10.0.0.3 l cdwivedi -6
The next switches do not add functionality to the SSH client, but they do
provide the opportunity to gather additional information regarding the connection. The d switch sets the debug level for a connection. The higher the
debug value, the greater the amount of information that will be printed on the
screen regarding the connection. The following is an example of the d switch.
Notice all the information that comes before the password request:
ssh 10.0.0.3 l cdwivedi d 1
debug: Connecting to 10.0.0.3, port 22... (SOCKS not used)
debug: client supports 3 auth methods:* publickey,keyboardinteractive,password
debug: Ssh2Common/sshcommon.c:537/ssh_common_wrap:
local ip = 10.0.0.3, local port = 1077
debug: Ssh2Common/sshcommon.c:539/ssh_common_wrap:
remote ip = 10.0.0.3, remote port = 22
debug: Remote version: SSH-1.99-OpenSSH_3.4p1
debug: OpenSSH: Major: 3 Minor: 4 Revision: 0
93
94
Chapter 3
debug: Remote host key found from database.
debug: server offers auth methods
publickey,password,keyboard-interactive.
debug: SshConfig/sshconfig.c:2717/ssh2_parse_config_ext:
Unable to open /root/.ssh2/identification
debug: server offers auth methods
publickey,password,keyboard-interactive.
debug: server offers auth methods
publickey,password,keyboard-interactive.
cdwivedis password:
The next informational switch, -V, displays the version of the remote SSH
server. This is helpful when you are trying to understand what version the
remote SSH server is running for patching and security purposes. The following is an example of the V switch:
ssh 10.0.0.3 V
ssh: SSH Secure Shell 3.2.3 (non-commercial version) on i686-pc-linux-gnu
The last informational switch discussed here is q. In essence, it tells the SSH
server to be quiet and not display any warning messages to the end-user. If the
q switch is used, the SSH server will display only the request for the users
password. The following is an example of the q switch:
ssh 10.0.0.3 q
roots password:
General
Network
Crypto
Tunneling
SSH1 Compatibility
Authentication
CLIENT
WINDOWS OS
UNIX OS
OpenSSH
\Program Files\OpenSSH\etc
/etc/ssh_config
SSH Communications
/etc/ssh2/ssh2_config
General
The general section of the of the configuration file lists generic flags and
switches that can limit the number of commands the end-user needs to type
when trying to access the SSH server. Fields such as VerboseMode, QuietMode, Compression, GoBackground, and EscapeChar allow customized
generic settings to be enabled from the profile file itself instead of typed into
the command line. Some of the selected fields in the General section are provided in Table 3.2, as well as a brief description of each.
Network
The Network section of the configuration file lists networking settings
required for the connection. An example of a network setting is the specific
port that the SSH client should use when attempting to connect to the SSH
server. Table 3.3 gives a brief description of some of the selected fields in the
Network section.
Table 3.2
FIELD
DESCRIPTION
VerboseMode
QuietMode
DontReadStdin
BatchMode
Compression
Enables/Disables compression
GoBackground
EscapeChar
PasswordPrompt
AuthenticationSuccessMsg
SetRemoteEnv
95
96
Chapter 3
Table 3.3
FIELD
DESCRIPTION
Port
NoDelay
KeepAlive
SocksServer
UseSocks5
Crypto
The Crypto section of the configuration file lists the types of cryptography that
can be set for the SSH clients. This section is useful when different SSH servers
require different types of encryption algorithms. For example, a different SSH
configuration file can be set for backups, enabling certain types of encryption
that have the least effect on bandwidth and enabled data validation with
MAC. Table 3.4 gives a brief description of some of the selected fields in the
Crypto section.
Table 3.4
FIELD
DESCRIPTION
Ciphers
MACs
StrictHostKeyChecking
RekeyIntervalSeconds
FIELD
DESCRIPTION
IdentityFile
RandomSeedFile
Tunneling
The Tunneling section of the configuration file specifies the local and remote
tunneling options that should be used on the SSH client. This section adds
a great deal of value when the client has enabled multiple local and remote
port forwards. The selected fields in the Tunnel section are described in
Table 3.6.
Table 3.6
FIELD
TUNNELING
DESCRIPTION
GatewayPorts
ForwardAgent
ForwardX11
TrustX11Applications
LocalForward
RemoteForward
SSH1 Compatibility
The SSH1 Compatibility section of the configuration file specifies the options
to use in order to be compatible with SSH1 version 1. In order for SSH2 clients
to be compatible with SSH1 servers, the following fields must be set (shown in
Table 3.7).
Table 3.7
SSH Compatibility
FIELD
DESCRIPTION
Ssh1Compatibility
Ssh1Path
Ssh1MaskPasswordLength
97
98
Chapter 3
Authentication
The Authentication section of the configuration file specifies the options supported for authentication. This section allows the client to know which type of
authentication to use, whether to use a password and public key instead of just
a password, in order to authenticate. Table 3.8 is a brief list of the selected
fields of the authentication section.
Table 3.8
Authentication
FIELD
DESCRIPTION
AllowedAuthentication
CLIENTS
URL
SSH Communications
www.ssh.com
VanDyke Software
www.vandyke.com/
Putty
www.chiark.greenend.org.uk/~sgtatham/putty/
WinSCP
winscp.vse.cz/eng/
Mindterm
www.appgate.com/mindterm/
MacSSH
pro.wanadoo.fr/chombier/
Windows Installation
Installing Windows-based SSH clients is relatively straightforward. I do not
describe the process of installing each of the SSH clients listed in Table 3.9, but
a wizard of each will walk you through the installation process.
SSH Communications
SSH Communications SSH client is the first I will discuss. Open the SSH client
and initiate a simple SSH connection by executing the following steps:
1. Start Programs SSH Secure Shell Secure Shell Client
2. File Open Quick Connect
As shown in Figure 3.1, the Host Name field is either the fully qualified DSN
name for the SSH server, such as sshserver.aum.com, or the dot notation of the
IP address of the SSH server, such as 172.16.11.17. The User Name field is the
username on the remote SSH server. The username can either be the local
account on a Windows machine or a domain account on a Windows domain,
depending on how the SSH server is implemented. In Unix environments, the
username is the same in the /etc/passwd file. The Port Number field is
used to specify the port number. If the SSH server is listening on a nonstandard port (a port other than port 22), the appropriate port number should
be placed in the port box, such as 202. Lastly, the Authentication Method specifies the type of authentication that should be used when attempting to
connect to the remote SSH server. The possible values and their descriptions
are in Table 3.10.
99
100
Chapter 3
Table 3.10
Authentication Types
AUTHENTICATION TYPE
DESCRIPTION
Password
Public Key
SecureID
PAM
Profile Settings
The profile settings are similar to the ssh2_config file discussed previously with
the command-line utilities. All options under the Profile Settings section
directly correlate to settings used by default when attempting to connect to an
SSH server. The description and usage of the settings are provided in Table 3.11.
Table 3.11
SETTING
Connection
(continued)
SETTING
Cipher List
Lists the types of Ciphers that can be used. Options can be 3DES,
Blowfish, Twofish, AES, Arcfour, and CAST128. (The option chosen
must be supported by the SSH server.)
Colors
Keyboard
Tunneling
Global Settings
The global settings are used for any SSH connection attempt, regardless of the
profile that might be used. All options under the Global Settings section
directly correlate to settings used by default when attempting to connect to an
SSH server. The description and usage of the settings are shown in Table 3.12.
Table 3.12
SETTING
Appearance
User Keys
Manages the public and private-key pairs that can be used for
authentication (instead of a password). This section allows you to
create a key pair, delete an old key pair, export a key to a flat
*.pub file, import a key pair to a flat *.pub file, view the flat
connects of a public key, change the passphrase in order to use
the public key, and upload a public key to an SSH server (the SSH
server must be compatible with the type of key created). The User
Keys section is discussed further in Chapter 4.
(continued)
101
102
Chapter 3
Table 3.12
(continued)
SETTING
Host Key
Public Key
Infrastructure
(PKI)
File Transfer
Firewall
Security
Printing
The profile and global settings are the primary areas where the SSH client
can be configured for functionality. Like the command-line clients, the GUI
client can save settings based on different SSH servers. To customize the profile settings based on a particular SSH server, go to the File Menu bar and
select File Profiles Add/Edit Profiles.
A profile can automatically be set up after the initial valid connection to an
SSH server. As shown in Figure 3.2, once the initial connect is made, the option
to save the profile appears in the upper right-hand corner. The Add/Edit profile option is a simple way to customize SSH connections. After opening the
File Profiles Edit/Add profile option, you should notice the same profile
options that are available with the Edit/Setting menu. However, these options
do not globally change all options; they make changes based on the specific
connection.
One of the most useful options with SSH Communications SSH client is the
built-in SFTP client. It allows the SFTP client to be executed without the need
for any secondary client or another SSH connection. The SFTP client can be
executed from the menu bar with Windows New File Transfer.
After this option has been selected, the SFTP client, with the original session
to the SSH server enabled, displays the contents of the local machine on the left
pane, which is the SSH Client machine, and the contents of the remote SSH
server on the right pane. This allows safe and simple SFTP usage for the
SSH session. Figure 3.3 demonstrates the use of the SFTP client option with
an SSH session that has already been established.
The last option I will discuss for the SSH Communications SSH client is the
Log Session. This option logs the entire connection, including commands, outputs, and inputs, to a log file. The log file can be saved locally on the client
machine for viewing at a later time. The log session option is also located at the
file menu bar at File Log Session.
After Log Session is chosen, the client will display a prompt for a location to
save the log file to. Session-logging capabilities will be enabled for the following connection after the option is enabled.
103
104
Chapter 3
The field options shown in Table 3.13 are available in the Quick Connect
display.
Table 3.13
FIELD
DESCRIPTION
Protocol
Hostname
Port
The port number to use for the remote SSH server. Default SSH
port is 22. The use firewall to connect checkbox enables
firewall settings in the Global Options menu, such as SOCKS or
Proxy settings.
Username
Cipher
Authentication
105
106
Chapter 3
The last options on the Quick Connect display are two checkboxes: The
Show Quick Connect on Startup checkbox displays Quick Connect upon
startup, and the Save Session checkbox saves the custom settings to a profile.
SecureCRT offers different settings to be enabled on SSH clients. Using the
Menu bar, open the options menu by selecting Options Global Options.
Under the Global Options menu are seven sections, including Options,
Appearance, Firewall, SSH1, SSH2, Printing, and Web Browser. Under each of
the sections are several more sections that can be used to configure the client. I
will select options individually and describe their purpose and usage.
All Global Options under this section directly correlate to settings that will
be used by default when attempting to connect to an SSH server. The description and usage of each setting is shown in Table 3.14.
Table 3.14
SETTING
Options
Mouse settings:
- Copy
- Paste
- Hide Mouse
DialogsVarious Dialog information settings
Other Various appearance settings.
Appearance
Firewall
(continued)
SETTING
SSH1
SSH2
Printing
Web Browser
Sets the default Web browser to use when opening a URL via
Secure CRT. In order to use this open, right-click on the URL
string in Secure CRT, such as www.theonion.com, and select
Open URL.
107
108
Chapter 3
All Session Options directly correlate to settings that will be used only when
connecting to the appropriate SSH server. The description and usage of the settings are provided in Table 3.15.
Table 3.15
SECTION
Connection
Emulation
Appearance
Options
File Transfer
(continued)
SECTION
Log File
Printing
109
110
Chapter 3
After Log Session or Raw Log Session is chosen, the client will save the session under the location specified in the Session Options section. The only difference between the two settings is that the Raw Log Session records
connections between the SecureCRT client and the SSH service, including
escape commands.
The Trace options menu allows the display of hidden communication between
the SSH server and the SecureCRT SSH client. To enable the Trace options, select
the option File Trace Options.
PuTTY
PuTTY is a free Telnet and SSH client for Win32 platforms, available from
www.chiark.greenend.org.uk/~sgtatham/putty/. PuTTY has similar functionality as described in other SSH clients. After downloading PuTTY, doubleclick the executable and the configuration menu should appear.
As shown in Figure 3.5, four sections can be configured using PuTTY:
Session, Terminal, Window, and Connection. The description and usage of the
settings are provided in Table 3.16.
SETTING
Session
Terminal
Windows
Connection
111
112
Chapter 3
WinSCP
WinSCP is a free secure copy (SCP) client for Win32 platforms. WinSCP
provides a terminal session similar to other clients we have discussed, but its
primary feature is a Win32 secure copy client. After downloading WinSCP,
open the client by selecting Start Programs WinSCP2 WinSCP2.
As shown in Figure 3.6, WinSCP has four main sections for configuration:
Session, Directories, SSH, and Preferences. The description and usage of the
settings are provided in Table 3.17.
Table 3.17
OPTION
Session
(continued)
OPTION
Shell (Advanced
Option)
Directories
Connection
Settings to configure to enable an SSH connection via a proxy
(Advanced Option) server (either a Web proxy (HTTP) or a SOCKS server).
SSH
Preferences
To configure the advanced options for WinSCP, click the checkbox in the
lower right-hand corner of the WinSCP display.
MindTerm
AppGate provides an SSH client called MindTerm. MindTerm is an SSH client
that uses a Java applet. Using MindTerm, it is possible to connect to an SSH
server with any Java-enabled Web browser such as Internet Explorer, Netscape,
Mozilla, and Opera. To install MindTerm, Java Runtime Environment (JRE)
needs to be installed. JRE can be downloaded from the following locations:
Linux:
www.blackdown.org/java-linux.htmlwww.ibm
.com/developer/java
www.javasoft.com/products/
Macintosh:
www.apple.com/java/
Other platforms:
http://java.sun.com/cgi-bin/java-ports.cgi
113
114
Chapter 3
As shown in Figure 3.7, the AppGate MindTerm client can also be used outside of a Web browser. Once the MindTerm client is displayed, the prompt
allows a connection to a remote SSH server to be established. Table 3.18 lists
some of MindTerms prompts.
Table 3.18
PROMPT
DESCRIPTION
SSH Server/Alias
Save as alias
Login
Password
MindTerm allows several settings other than user prompts. Table 3.19 summarizes some of the selected functions of the SSH client.
To fully use a MindTerm client with a Web browser, the AppGate server
needs to be deployed on the server side of the connection. The AppGate server
provides the MindTerm SSH client via a Web browser; however, the session is
still secure with SSH (versus HTTPS).
Table 3.19
SETTINGS
DESCRIPTION
115
116
Chapter 3
MacSSH
MacSSH is an SSH client for Macintosh environments. MacSSH supports SSH2
only, with no support for SSH1. MacSFTP is similar to MacSSH but is used for
the file-transfer portion of the connection. There are some other good clients
for the Macintosh environment, including JellyfiSSH (www.arenasoftware
.com/grepsoft/) and Rbrowser (www.rbrowser.com).
Summary
This chapter explores several SSH clients that can be used in enterprise architectures and different options. Each SSH client has been examined in detail in
this chapter, with coverage of the options, settings, and configuration steps in
a typical environment.
Chapters 1, 2, and 3 of this book have covered the basics: SSH servers and
SSH clients. The focus of this book now turns from descriptions and implementation steps of servers and clients to specific features and options of SSH
servers and clients. Chapter 4 discusses the authentication methods provided
by SSH. Although I have covered the client-configuration options with
authentication in this chapter, I have not discussed how to implement the
various options and the best methods for optimal usage.
The remaining portions of this book assume that you are familiar with most
of the features of the SSH clients discussed in Chapter 3, as well as the major
uses of SSH servers from Chapter 2.
CHAPTER
4
Authentication
The first three chapters of this book focus on the various aspects of SSH servers
and SSH clients. I now shift the focus from the actual packages of SSH to the
detailed options and optimal uses of SSH. The first topic is authentication.
Authentication is the process of determining if an entity is actually who or
what it claims to be. The entity can be a person, a server, an application, a service, or even a process. In most networks, authentication is commonly used
with usernames and passwords. In this type of authentication, the password is
the only object that guarantees that the entity is actually what it claims to be.
While users can choose and change their own passwords for successful
authentication, the fact that passwords are often stolen, shared, sticky-noted (a
manual technique of writing passwords on a Post-It note and sticking it to a
monitor), or simply forgotten makes the use of passwords for authentication a
less-than-ideal solution.
Since passwords may not be the best solution for sensitive information or for
hostile environments, SSH offers the use of a more stringent authentication
process. The use of public keys or digital certifications can be the required
method of authentication across any SSH environment that uses sensitive information or transcends hostile networks, such as the Internet or internal networks.
Furthermore, since authorization is highly dependant on authentication, the
authentication process needs to be as strong as possible, since most authorization processes do not perform a second layer of error checking for validity.
This chapters focus is common authentication methods used in SSH, primarily passwords, host-based authentication, and public keys. The chapter
117
118
Chapter 4
summarizes some of the other authentication options available via SSH, such
as server authentication, where the client authenticates the server, and generaloption authentication settings. The order of the discussions is as follows:
General options
Passwords
Host-based authentication
Server authentication
Public keys
General Options
SSH offers several general authentication options depending on the type of
SSH server deployed. The options range from valid password attempts to the
use of blank passwords. The following paragraphs describe the SSH servers
and the authentication options they provide.
Figure 4.1 The User Authentication section of the screen for SSH Communications SSH
server.
Authentication
Tables 4.1 through 4.3 describe the general authentication options for SSH
Communications SSH server.
Table 4.1 describes the general user-authentication options. Parameters
such as login grace time, number of retries, and delay between retries can be
configured.
Table 4.2 describes the user-authentication password options under the
password section. Parameters such as password authentication, empty password permissions, and keyboard interactive can be configured.
Table 4.3 describes the user authentication public key options under the
public key section. Parameters such as public key authentication, key directory, and authorization file can be configured.
Table 4.1
User-Authentication Options
OPTION
DESCRIPTION
Table 4.2
OPTION
DESCRIPTION
Password authentication
Keyboard interactive
Table 4.3
OPTION
DESCRIPTION
Public-key authentication
119
120
Chapter 4
Table 4.3
(continued)
OPTION
DESCRIPTION
User-key directory
Authorization file
Options in the authentication section are listed in Table 4.4, along with a
description of each option.
Table 4.4
Authentication
OPTION
DESCRIPTION
BannerMessageFile
PasswordGuesses
Authentication
Table 4.4
(continued)
OPTION
DESCRIPTION
AllowedAuthentication
RequiredAuthentication
HostbasedAuthForce
ClientHostnameDNSMatch
SshPAMClientPath
client is used
Figure 4.2 The User Authentication screen for VShell SSH server.
121
122
Chapter 4
Table 4.5
OPTION
DESCRIPTION
Required authentication
methodsPassword
Required authentication
methodsPublic Key
Required authentication
methodsPublic Key Uploads
Public-key folder
or
c:\cd Program Files\OpenSSH\ssh
c:\notepad sshd_config
The options for the authentication section for OpenSSH are described in
Table 4.6.
Authentication
Table 4.6
OPTION
DESCRIPTION
LoginGraceTime
PermitRootLogin
StrictModes
RSA Authentication
Publickey Authentication
AuthorizedKeysFile
Rhost Authentication
RhostsRSA Authentication
Hostbased Authentication
Password Authentication
PermitEmptyPasswords
Passwords
Password authentication is the basic method of authentication for SSH. SSH
servers support authentication for both Windows and Unix platforms. SSH
servers on Unix platforms have two methods for password authentication:
/etc/passwd or /etc/shadow
123
124
Chapter 4
Under the Authentication section, denoted by #Authentication, many settings are given that can be used for the SSH server. The option you are most
concerned with is the PasswordAuthentication setting. This setting needs to be
set to Yes in order for password authentication to be valid, which is the default.
Furthermore, if password authentication should be disabled in favor of other
authentication methods, this setting should be set to No and uncommented,
which means deleting the # from the beginning of the line. An example
follows:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no
Authentication
Enter the following command to show the contents of the SSH configuration
file for Commercial SSH:
#cd /etc/ssh2
#more sshd2_config
AllowedAuthentications
AllowedAuthentications
AllowedAuthentications
RequiredAuthentications
LoginGraceTime
AuthInteractiveFailureTimeout
publickey,password
hostbased,publickey,password
hostbased,publickey,keyboardpublickey,password
600
2
#
#
#
#
#
AllowedAuthentications
AllowedAuthentications
AllowedAuthentications
RequiredAuthentications
LoginGraceTime
AuthInteractiveFailureTimeout
publickey
hostbased,publickey,password
hostbased,publickey,keyboardpublickey,password
600
2
The process of enabling password authentication on Windows-based operating systems is equally simple; however, the process is different for OpenSSH
than Commercial SSH or VanDykes VShell SSH server. For OpenSSH installations on Windows environments, there exists a configuration file called
sshd_config located at Program Files\OpenSSH\ssh\. Enter the following
commands to show the contents of the OpenSSH configuration file:
C:\cd Program Files\OpenSSH\ssh\
C:\type sshd_config
125
126
Chapter 4
yes
yes
Similar to OpenSSH on Unix, yes must be present on the Password Authentication line in order for passwords to be used; however, password authentication is enabled by default. In order to disable the use of password, no must be
present. The following example disables password authentication:
PermitRootLogin
PasswordAuthentication
yes
no
Authentication
Figure 4.4 User Authentication section for SSH Communications SSH Server.
Host-Based Authentication
Host-based authentication is another method of authentication in a SSH environment. Each entity in a SSH architecture, either an SSH server or SSH client,
can contain a host key for identification. The host key is used to uniquely distinguish the client or server from any other entity. Furthermore, the host key is
unique only to the operating system and cannot be easily duplicated from one
machine to the next. Host-key-based authentication is used to replace IP
address authentication used in RSH (remote shell) authentication. Since an
127
128
Chapter 4
IP address can be easily spoofed, using an IP address as a method of authentication is extremely insecure. Furthermore, host keys cannot be easily spoofed
and can be used to uniquely authenticate a SSH server or a SSH client. Hostbased authentication is best suited for scripted environments, where username/password combinations cannot be used or are too cumbersome for the
required business use (for example, nightly encrypted backups). Table 4.7
shows the locations of the host keys in SSH servers.
Once the host keys have been located and identified, the public host keys,
denoted by the .pub extension, should be copied to the remote server. For
example, if a machine called AUM wants to connect to another machine called
OM with host-based authentication, the public key host key should be copied
to the OM SSH server. This will allow the OM SSH server to accept authentication from the AUM machine based on the host key itself, without any need
for a password. The following steps should be conducted in order to set up
host-based authentication with the AUM server and OM server.
1. Host AUM should generate a host key. (Depending on the type of operating system and environment, the syntax may be different.) The following is a list of the syntax depending on the environment:
ssh-keygen P Aum (OpenSSH)
ssh-keygen2 P Aum (SSH Communications)
2. This will create the private host key and the public host key. The public
host-key file is Aum.pub and the private host-key file is Aum.
3. Copy Aum.pub to the knownhost folder in /etc/ssh2 for SSH Communications SSH server and /etc/ssh/ssh_known_hosts for OpenSSH
SSHs server. For SSH Communications, copy Aum.pub to
/etc/ssh2/knownhosts; however, rename Aum.pub to the fully qualified DNS name in the following form: hostname.domain.ssh-dss.pub.
(A fully qualified domain name is a full DNS name of a machine on a
given network.) For example, if machine AUM belongs to the eNapkin
domain, its name should be changed to Aum.eNapkin.ssh-dss.pub. For
OpenSSH, just add the key to the authorized key file, as the following
shows:
#cd .ssh
#cat Aum.pub >> authorized_keys
root
Authentication
Table 4.7
SSH SOFTWARE
/etc/ssh2
Program Files\VShell\hostkey
OpenSSH server
/etc/ssh
publickey, hostbased
7. Test the configuration by resetting the SSH server and typing the following syntax:
ssh root@OM
Server Authentication
In addition to traditional host-based authentication for user access, a SSH
client can confirm the identification of a SSH server with host-key information.
When a SSH client first attempts to authenticate to a SSH server, the SSH
server sends its public host key to the client in order to identify itself. The
client can then accept and save the host key locally in order to authenticate or
verify the connection the next time the SSH client attempts to log in. The host
key accepted by the client is added to the host-key database that the SSH client
stores locally on the client machine. Each time the SSH client attempts to log in
to the SSH server, the client will compare the SSH servers host key with the
host key in the SSH clients host-key database to make sure it matches. If the
keys do not match, the SSH client can choose not to log in to the SSH server,
due to possible tampering with the SSH server or possibly a man-in-themiddle attack.
129
130
Chapter 4
Table 4.8
The Type of SSH Software and the Location of the Host Keys
SSH SOFTWARE
/root/.ssh2/hostkeys
SecureCRT
C:\DocumentsandSettings\Administrator\
Application Data\Van Dyke Technologies\
SecureCRT\HostKeyDatabase
OpenSSH client
/etc/ssh/hostkeys
Authentication
Figure 4.6 shows the host-key database for SSH Communications SSH
client. Similar to SecureCRT, this is the repository for the SSH client for all host
keys obtained after a connection is made to a SSH server. This host-key database will be referenced each time the SSH client connects to the same SSH
server to make sure the host keys match.
Public Keys
Public-key authentication is one of the best authentication methods provided
by SSH. Unlike password authentication, public-key authentication requires
each user to contain a public-key file in order to authenticate. The fact that
many corporate networks rely on user passwords, no matter how strong or
weak, to protect sensitive and propriety information leaves many networks
vulnerable to simple attacks. The following sidebar provides several reasons
why using passwords on sensitive systems may not be the best decision in
order to attain an acceptable level of security:
131
132
Chapter 4
WHY PASSWORDS MAY NOT PROVIDE THE BEST SECURITY
Passwords are often weak.
Passwords can be shared easily.
Brute-force attacks, the act of trying every password combination based
Now that you have seen some of the security issues with passwords, you
will learn about using public keys for authentication and why the use of keybased authentication can virtually eliminate many of the issues described previously. The following sidebar lists the strengths that public-key authentication
offers in a typical network environment, both internally to the network and
externally.
Key-based authentication in a SSH environment uses public and private
keys. The following is a summary of the steps required to generate a key pair
for SSH:
1. An authorized user must generate a public and private key pair.
2. The user has the option of password protecting the private key, which is
recommended in almost all environments.
3. The users public key needs to be securely uploaded to the SSH server,
usually stored in the users home directory. For example, the user
Kusum would have a public key stored in /home/Kusum/.ssh/ or
Documents and Settings\Kusum\.ssh of the SSH server.
4. Authorization, Identification, and authorized_keys files need to be
populated.
5. Public-key authentication needs to be configured on the SSH server,
which is enabled by default on many SSH installations.
That is it!
Authentication
STRENGTHS OF PUBLIC-KEY AUTHENTICATION
Key-based authentication supports industry best practice of two-factor
authentication.
Public/Private keys cannot be shared as easily as passwords (Public and
private keys can still be shared from one machine to the next!)
If a private key is stolen or compromised, the private key can be pass-
For key-based authentication to be implemented, each valid user must contain a public and private key pair. The process of creating a public and private
key pair is the responsibility of the SSH client, not the SSH server. The public
and private keys are stored on the local machinethe users machineand a
copy of the users public key is stored on the SSH server. To authenticate, the
user must contain both the public and private keys. The user must authenticate, using a password, to his or her local private key, which decrypts the
private-key file and enables it. Once authentication is granted, the public key
is used to authenticate to the SSH server. The SSH server receives the public
key and determines if the public key matches the same public key that the
server holds for that particular user. If the match is correct, the user is then
authenticated. The data flow for public-key authentication is illustrated in
Figure 4.7.
As noted in Step 1, creating a public and private key pair is the responsibility of the SSH client, not the SSH server. Since several different SSH clients
exist, I will address the process of creating a public and private key with each
of the following SSH clients:
VanDyke SecureCRT
133
134
Chapter 4
1. SSH password
decrypts
private key
SSH Client
- Holds SSH Public
and Private keys
SSH Server
- Holds SSH Public keys
SSH Communications
OpenSSH
VShell
Authentication
3. Enter the name of the key pair (I will call ours Shreya); then enter a
passphrase, and confirm the passphrase:
Enter file in which to save the key (/root//.ssh/id_dsa): Shreya
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
4. After you have confirmed the passphrase, both the public and private
keys should be generated. In this case, the names will be Shreya.pub for
the public-key file and Shreya for the private-key file. The key fingerprint will be displayed on the shell or command prompt:
Your identification has been saved in Shreya.
Your public key has been saved in Shreya.pub.
The key fingerprint is:
ed:1e:67:22:79:d8:81:c9:b4:ee:0d:f5:55:0d:cf:5c
Once you have made the key pairs, uploaded the public-key file to the
appropriate home directory, added the key to the authorized_keys file, and set
the correct permissions, you should be able to log in with the public key. Sample syntax follows on the client machine:
[Shreya@localhost]$ssh <SSH server IP address> -i Shreya
135
136
Chapter 4
If you attach a passphrase to the private key, the following text should
appear:
Enter passphrase for key Shreya:
2. Once you have copied the public key to the SSH Communications SSH
server in the users home directory, specifically in the .ssh2 folder in the
users home directory (/home/<username>/.ssh2/publickey.pub on
Unix and Documents and Settings\<username>\.ssh2\publickey.pub
on Windows), you need to add a public-key entry to the authorization
file, which is labeled Authorization, also in the users home directory on
the SSH server. The contents of the authorization file on the SSH server
should be Key, followed by the actual public-key name.
Key
SSH2-Shreya.pub
3. After the authorization file has been created on the SSH server, an identification file needs to be created on the SSH client, typically in the ssh2
folder in the users home directory (/home/<username>/.ssh2 for
Unix and Documents and Settings\<username>\.ssh2\ for Windows).
This file is used by the SSH client to indicate which private keys to use
for authentication. Furthermore, unlike OpenSSH, this file is used with
the i option to point to the correct private keys for authentication. For
Authentication
example, while OpenSSH uses i <privatekey> syntax, SSH Communications uses i identification for the syntax. The syntax to create
the identification file is as follows on the client:
echo IdKey SSH2-Shreya >> identification
4. After the identification file has been created on the SSH server, the permissions on the public-key and private-key pairs need to be protected
in order to be used. Set the following permission on the SSH client for
the appropriate key files that were generated.
[Shreya@localhost]$chmod 600 SSH2-Shreya
[Shreya@localhost]$chmod 600 SSH2-Shreya.pub
5. Once you have made the key pairs, uploaded the public-key files to the
appropriate home directory, added the entry to the authorization file,
and added the entry to the identification file, you should now be able to
log in with the public key. Be sure to use the identification file with the
i option, not the private-key file; otherwise you will receive a No further authentication methods available error. The following is sample
syntax:
[Shreya@localhost]$ssh2 SSH-Server i identification
137
138
Chapter 4
Using the preceding example, with Shreya as the OpenSSH private key, an
example authentication process is as follows:
ssh VshellServer p 22 i Shreya l shreya
Enter passphrase for key Shreya:
Authenticated with partial success
Shreya@VshellServers password:
C:\
Notice that after the key is authenticated, VShell asks for a password on the
VShell server. This happens only if both the password and public-key checkboxes are required on the VShell server. If public key was the only required
authentication method, a password prompt would not occur; however, this is
a great method of enforcing two-factor authentication, which should be
required for management purposes.
3. After the key has been generated, enter a passphrase, and confirm the
passphrase:
Key generated.
2048-bit dsa, kusum@localhost.com, Fri Aug 15 2003 11:17:00
Passphrase :
Again
:
Private key saved to /home/kusum/.ssh2/id_dsa_2048_a
Public key saved to /home/kusum/.ssh2/id_dsa_2048_a.pub
4. After you have confirmed your passphrase, both the public and private
keys should be generated. In this case, the names will be
id_dsa_2048_a.pub for the public-key file and id_dsa_2048_a for the
private-key file. The key should be automatically saved to the .ssh2
folder in the users hold directory in Unix (/home/<username>/
.ssh2/) and the users home folder in Windows (Documents and
Authentication
id_dsa_2048_a.pub
After the authorization file has been created on the SSH server, an identification file needs to be created on the SSH client, typically in the ssh2 folder in
the users home directory (/home/<username>/.ssh2 for Unix and Documents and Settings\<username>\.ssh2\ for Windows). This file is used by the
SSH client, with the i flag, to indicate the private keys to use in order to
authenticate. Be sure to use this file with the i option on the SSH client. The
syntax to create this file is as follows:
echo IdKey
Once you have made the key pairs, uploaded the public-key files to the
appropriate home directory, added the entry to the authorization file, and
added the entry to the identification file, you should be able to log in with the
public key. The following is a demonstration of the syntax:
ssh2 <SSH server IP address> -i identification
139
140
Chapter 4
2. Once the passphrases have been removed, we must convert our SSH
Communications SSH keys to the OpenSSH compatible format, using
the following commands:
[Shreya@localhost]$ssh-keygen2 -1 id_dsa_2048_a.pub >
id_dsa_2048_a_Open.pub
[Shreya@localhost]$ssh-keygen2 1 id_dsa_2048_a > id_dsa_2048_a_Open
3. Once you have copied the public key to the SSH server, using SFTP or
some alternative secure method (there is no automated tool to do this),
enter the following command on the OpenSSH server to add the newly
converted public key to the authorized key file, located in the users
home directory, on the OpenSSH server.
[Shreya@OpenSSHserver]$cat id_dsa_2048_a_Open.pub >>
/home/Shreya/.ssh/authorized_keys
5. You should now be able to authenticate, since you have converted your
SSH Communications SSH client key to OpenSSH format and have
added the key to the authorized key-list file:
/usr/bin/ssh SSH-Server i id_dsa_2048_a_Open
Authentication
accepts the OpenSSH key format; therefore, the converted OpenSSH key from
the previous section could also be used on a VShell SSH server. I will now
demonstrate how to use both an SSH Communications SSH key and a converted OpenSSH client key for VShell SSH servers.
1. Copy your SSH Communications key and OpenSSH public key-file to
the remote VShell SSH server, specifically in public-key folder located
at C:\ Program Files\VShell\PublicKey\%USER%.
2. Make sure public-key authentication is enabled on the remote VShell
SSH server.
3. From the client machine, connect to the VShell SSH server with the
following syntax.
ssh2 <VShell Server> -p 22 i identification l <username on VShell
server>
ssh <VShell Server> -p 22 i OpenSSHPrivatekey l <username on VShell
server>
Using the previous example, with id_dsa_2048_a and the SSH Communications key and id_dsa_2048_a_Open as the converted OpenSSH client key,
complete the following steps to authenticate to the VShell SSH server.
SSH Communications Client Key
ssh2 VshellServer p 22 i identification l <username>
Enter passphrase for key <username>:
Authenticated with partial success
Shreya@VshellServers password:
C:\
Notice that after the key is authenticated, VShell asks for a password on the
VShell server. This happens only if both the password and public-key checkboxes are required on the VShell server. If public key was the only required
authentication method, a password prompt would not occur; however, this is
a great method of enforcing two-factor authentication, which should be
required for management purposes.
141
142
Chapter 4
Authentication
11. After selecting Upload Public Key, a new display should appear. The
display should contain the name of the public key, the destination
folder for the key to be placed, which is the folder on the SSH server to
place the key, most likely /home/user/.ssh2, and the authorization file
to add the key to, such as authorization. After verifying that all the
items are correct, select Upload.
12. After selecting Upload, you will see a successful completion of the
upload, where you can select finish; however, if you want to require the
use of public keys only, you will have to go back and edit the
sshd2_config file to require only the use of public keys and to delete
password or host-based authentication. Also, if you receive an error in
the upload process, probably the SSH server you are attempting to connect to is not a SSH Communications SSH server, so the key-converting
process will have to be followed, listed as follows.
13. At this point, you should be redirected to the initial Key subcategory
screen. To confirm that the keys have been generated appropriately,
browse to Documents and Settings\<username>\Application
Data\SSH\UserKeys. There should be both the public key (*.pub) and
private key located in this folder. Also, the Key subcategory screen
should appear with the newly generated key in the Keys field, as
shown in Figure 4.9.
14. SSH Communications SSH keys have been generated!
143
144
Chapter 4
Figure 4.9 The private-key file name in SSH Communications SSH client.
After the creation process has been completed, the process of uploading the
public key is next. The following section demonstrates how to upload a
SSH Communications SSH client public-key and private-key pair to a SSH
Communications SSH server, an OpenSSH server, and a VanDyke VShell SSH
server.
Authentication
145
146
Chapter 4
Figure 4.10 The screen to change a passphrase with SSH Communications GUI client.
2. Once the passphrases have been removed, you must convert your SSH
Communications SSH keys to the OpenSSH compatible format, using
the following commands:
On the SSH client, use the OpenSSH ssh-keygen utility to convert
the keys:
ssh-keygen -i f SSH2.pub > SSH2Open.pub
ssh-keygen i f SSH > SSH2Open
3. Once you have copied the public key to the SSH server, using SFTP or
some alternative secure method (there is no automated tool to do this),
enter the following commands to send the newly converted public key
to the authorized key files on the SSH sever.
On the OpenSSH server:
cat SSH2Open.pub >> authorized_keys
Authentication
Figure 4.11 The SSH2 converted key in OpenSSH format in the SSH Communications
SSH GUI client.
Figure 4.12 The Quick Connection option with the Public Key Authentication option.
147
148
Chapter 4
Uncheck Password
5. On the SSH Communications SSH client, use Quick connect to authenticate with the public-key option for Authentication Method.
6. After selecting Connect, be logged-in with the SSH2 key to a VShell
SSH server using the SSH Communications SSH client.
Authentication
8. The location screen should appear next. Unless you have a particular
area to store the keys, it is recommended to key in the default location
(C:\Documents and Settings\Administrator\Application Data\
VanDyke\Identity); however, make sure to place NTFS permissions in
the folder to restrict access to Guests, Everyone, and other unauthorized groups. After selecting the location, click Finish.
9. You should a see a pop-up box, asking if you would like to use the key
as your global public key. Select No, since you may have multiple keys
with one default global key.
10. VanDyke SecureCRT public and private-key pairs have been generated!
After the creation process has been completed, the process of uploading
the public key is next. The following section demonstrates how to upload a
SecureCRT client public and private-key pairs to a VanDyke VShell SSH server,
a SSH Communications SSH server, and an OpenSSH server.
149
150
Chapter 4
8. You should now be able to use your public key to authenticate. To confirm, enable only public-key authentication on the VShell SSH server.
a. Select Start Programs VShell VShell.
b. Highlight the Authentication section.
c. Uncheck Password and check Public key for the required authentication methods. Be sure to uncheck the Allow 3 password attempts
checkbox, since the public key is already on the VShell SSH server.
9. On SecureCRT, select PublicKey for the Primary authentication method
and <None> for the Secondary authentication method. Be sure to
browse to the correct public key with the Properties button.
10. Select Connect and you will authenticate with your public key and then
receive a VShell SSH session.
OpenSSH
To use the SecureCRT Client public and private-key pair for an OpenSSH
server, complete the following steps.
1. Make sure your key pairs do not contain a passphrase. While it is
important to remove any passphrases during the conversation process,
make sure you add a passphrase to both the old key and the newly converted keys after the conversion process is completed.
a. Go to Start Programs SecureCRT SecureCRT.
b. Choose File Quick Connect Protocol (ssh2) Authentication
(Public Key).
c. Select Properties Change Passphrase.
d. Enter the current passphrase, and leave the new passphrase blank.
e. Select OK.
Authentication
2. Once the passphrases have been removed, you must convert your
SecureCRT keys to the OpenSSH compatible format. On the client
machine, use OpenSSHs ssh-keygen utility to convert the keys. The
keys are located at Documents and Settings\<username>\Application
Data\VanDyke. Use the following commands:
ssh-keygen -i f CRTpublickey.pub > CRTpublickeyOpen.pub
ssh-keygen i f CRTprivatekey > CRTprivatekeyOpen
3. Once you have copied the public key to the SSH server, using SFTP or
some alternative secure method, enter the following commands to send
the newly converted public key to the authorized key files on the SSH
server.
On the OpenSSH server:
cat CRTpublickeyOpen.pub >> authorized_keys
4. You should now be able to authenticate, since you have converted your
SecureCRT client key to OpenSSH format and have added the key to
the authorized key-list file:
/usr/bin/ssh OpenSSH-Server i CRTprivatekeyOpen
CRTpublickey.pub
151
152
Chapter 4
Primary: PublicKey
Secondary: Password
4. Select Connect.
5. You should now be logged in to a SSH Communications SSH server
using a SSH2 key generated from SecureCRT.
While the use of public keys for authentication purposes is by far the better
solution of password authentication, the process of making SSH client keys
interoperate with various SSH servers may not be an easy process in an enterprise environment. For optimal usage, it is better to use tools and utilities that
are interoperable with various platforms and technologies, and SSH is no different. The use of VShell SSH servers has a significant advantage, since it
accepts both OpenSSH keys and SSH2 keys without any need for any conversion from any client mentioned in this chapter. Similarly, using OpenSSH keys
as your primary key may be a good solution, since both OpenSSH and VShell
servers accept the OpenSSH format, leaving only one conversion required to
work with SSH2 servers. Nevertheless, the choice of the SSH client-key format
and SSH servers will depend on many items, not just the public-key conversation process. As best practice, it is a good idea to have both formats of your
public key made: one for OpenSSH and another for SSH2 formats.
SSH Agents
The SSH agent is a simple utility that allows end-users to handle passphrases
attached to public-key files in a simpler way. If multiple passphrases are being
used with multiple public keys, it may be cumbersome for the end-user to type
and retype all the passphrases several times. The SSH agent utility remembers
your passphrases for you after the first time you have authenticated with the
passphrase. It is a utility that remembers your private keys and provides the
authentication portion to other SSH connections. Therefore, after you initially
authenticate with your passphrase, the SSH agent will prevent subsequent
SSH sessions from asking you for your passphrase. The process to enable SSH
agents involves the following four steps:
Authentication
1. Execute the SSH agent with the shell of your choice (bash, csh, tcsh,
or ksh).
2. Receive a new SSH shell (automatically).
3. Add the private keys with SSH-add command.
4. Log in to SSH sessions with the passphrase (only the first time).
In order to enable the SSH agent for OpenSSH and SSH Communications,
execute the following steps:
OpenSSH:
ssh-agent bash
ssh-add <privatekeyfile> (e.g. ssh-add Shreya)
ssh i OpenSSHPrivateKey <IP Address>
SSH Communications:
ssh-agent2 bash
ssh-add2 <privatekeyfile> (e.g. ssh-add2 id_dsa_2048_a)
ssh2 i identification <IP Address>
Summary
This chapter discusses the various authentication options available in SSH. It
should be noted that many of the authentication options, such as password
attempts, are separate from the operating-system authentication options. For
example, the operating system could have a password-attempts threshold at 5,
while the SSH service has a password-attempts threshold at 3. While SSH
servers on both Windows and Unix platforms use the local username/password database for authentication, such as /etc/shadow or the SAM database,
the SSH servers can have additional or similar authentication options. Furthermore, while SSH servers are using the same password database, the actual
authentication options apply to different services. For example, to log on to a
Windows service requires the use of SMB, which may have authentication
options tied to it. These authentication options are separate from the authentication options that apply to the SSH service on the operating system, even
though both SMB and SSH are using the SAM database file.
While certain authentication options are discussed in detail in this chapter,
such as password, public-key, and host-based authentication, there are several
other authentications options, such as SecureID and Certificates, which are not
discussed. Both SecureID and Certificate-based authentication are strong
authentication methods but require the use of several other servers and/or
153
154
Chapter 4
devices, such as a RSA Ace server and a Certificate Authority, which are not
included with any SSH package. RSA Ace servers and/or a certificate authority require an additional amount of setup time and implemented architecture;
therefore, SecureID and Certificate-based authentication fall outside the scope
of this chapter.
The key things to focus on when it comes to SSH authentication are the functional and security requirements for the application. The following is a list of
questions and answers to ask when trying to determine which method of
authentication is acceptable and/or optimal.
Now that you understand all the authentication options with SSH and how
to use them across different SSH servers, you will now shift your focus to managing servers/devices that are SSH enabled. Knowing and using different
authentication methods in SSH is critical to fully understanding the security
implications that exist in terms of server/device management, as well as the
functional uses that SSH can enable in the process.
CHAPTER
5
SSH Management
Thus far, I have described SSH in terms of application servers or SSH client
applications. While using applications such as VanDyke Softwares VShell,
SSH Communications SSH, and OpenSSH, or core SSH server utilities, SSH
services can also be available without any of these applications. SSH services
are also available on network devices such as routers, switches, firewalls, load
balancers, and storage filers. These services on network devices provide the
same type of secure access that SSH applications provide. Furthermore, the
SSH services on these devices provide secure management capabilities while
replacing insecure clear-text protocols such as Telnet, FTP, and/or SNMP.
In addition to SSH services being available on network hardware, SSH services can be integrated with other security utilities. Utilities such as Chroot,
user restrictions, TCP wrappers, and IP access filters can be used with SSH to
complement and enhance the overall security of network management.
Secure management is often overlooked when it comes to security. Many
organizations and corporations deploy a strong perimeter defense with multiple firewalls and router-access control lists; however, they also use poor management protocols that weaken the entire network environment. For example,
for remote business travelers, the use of encryption to gain access to e-mail or
internal file servers is usually a requirement, either through SSH port forwarding (described in Chapters 6 and 7) or IPSec. In spite of this, many network administrators use Telnet to access perimeter devices such as routers,
firewalls, and switches in order to conduct remote management. The odd thing
155
156
Chapter 5
about this situation is that many organizations do not allow insecure protocols
such as IMAP and FTP for business travelers but do allow equally weak protocols such as Telnet for more sensitive actions such as router management.
One of the keys to deploying a secure environment is the use of encryption
whenever possible. In the case where encryption is unavailable, the use of mitigating security controls to compensate for the lack of encryption should be
used. For example, many network devices may not support standard encryption protocols such as SSH for remote management. While these devices cannot support encryption, other mitigating controls should be set, such as
access-control lists, which can limit access from a predefined set of IP
addresses and enforce two-factor authentication.
This chapter addresses the following features of SSH:
Network devices
Cisco routers
Cisco switches
Secure management
Management stations
Two-factor authentication
SOCKS Management
SSHUser restrictions
Network Devices
Our discussion of secure network devices will address the installation, setup,
and usage of SSH on the specified network devices in terms of secure management and secure networking. Our discussion will range from how to install
SSH on network devices to actually enabling and using SSH on a regular basis
on these same devices.
SSH Management
Cisco Routers
Cisco Internetworking Operating System (IOS) started to support the use of
SSH from version 12.0.5.S for servers and 12.1.3.T for SSH clients. Since then,
IOS 12.x and up has supported SSH version 1 only. While the use of SSH version 1 still has its insecurities, the replacement of Telnet on Cisco devices has
added tremendous security to the network device.
To use SSH on Cisco routers, complete the following steps:
1. Download the correct IOS to the router. Make sure you are downloading an IOS version that contains SSH support. Cisco SSH servers
require IPSec (DES or 3DES) encryption software image from IOS
12.1(1)T. For SSH clients, IOS 12.1(3)T is required.
2. Make sure a hostname and host domain have been configured for the
router. The following commands are not SSH commands but commands on the router that are required in order to use SSH.
Syntax:
Example:
Syntax:
Example:
3. Generate an RSA key pair for the router, which will automatically
enable SSH:
Router(config)# crypto key generate rsa
This command will enable both local and remote SSH authentication to
and from the router. When using the SSH client, be aware that it runs in
EXEC mode with no specific configuration on the router. Now that SSH
is enabled on the router, configure SSH appropriately.
4. Set the authentication timeout for SSH. The maximum timeout cannot
exceed 120 seconds, which is also the default; however, once the session
is established, the VTY timeout setting applies, not the SSH timeout setting. The following syntax sets the routers timeout session for SSH:
Syntax:
Example:
5. Set the authentication retries for SSH. The maximum number of retries
is five; however, the default is three. The following syntax sets the
routers authentication retries for SSH:
Syntax:
Example:
157
158
Chapter 5
6. To show and confirm the configuration results of the SSH server, enter
the following commands:
Router# show ip ssh
SSH Enabled version 1.5
Authentication timeout: 120 seconds; Authentication retries: 3
This command shows any connections that are established, the version,
the encryption, the state, and the username.
8. Once SSH is enabled and configured, it may be appropriate to prevent
any non-SSH connections to access the router, such as Telnet. It is
important to disable insecure protocols such as Telnet if a stronger and
more secure protocol is in place and provides the same type of access.
To require the use of SSH on terminal-line connections, enter the following command:
Router(config)# line vty 0 4
Router(config-line)# transport input ssh
9. Once SSH has been enabled on the Cisco router, enter the following
commands to connect to the SSH service on the router:
Syntax:
ssh l userid c <des | 3des> p <port number>
IP.Address/hostname
Example:
ssh l <username> c 3des <router.ip.address>
In addition to providing SSH access to a router, Cisco IOS provides terminalline access with SSH, which allows SSH access to non-SSH routers that have a
console or serial-port connection to an SSH-enabled router. A simple terminalline access configuration is illustrated in Figure 5.1.
Serial-Line
Router
non-SSH-Enabled
IPv4 Network
Connection
SSH Client
Figure 5.1 Terminal-line access.
Router
SSH-Enabled
SSH Management
To set up terminal-line SSH access, each line must be configured with its
own rotary, and SSH must be configured to use SSH when accessing the other
devices. The following steps walk you through this process.
1. Each line must be configured on the SSH-enabled router. Note that the
line number refers to the port number on the remote SSH server. For
example, line number 1 equates to port 2001, line number 2 equates to
port 2002, and line number 3 equates to port 2003. The following syntax
shows the router commands to enter a line number for SSH.
Syntax:
Example:
2. Disable the EXEC process of each line using the following syntax:
Router(config)# no exec
3. Define the login authentication option, which must be username/password, with the following syntax:
Syntax:
Example:
4. Define a group of lines that will be used when SSH is enabled using the
following syntax:
Syntax:
Example:
5. Define the use of SSH on the line using the transport input command,
as listed:
Router(config)# transport input ssh
6. Configure SSH for the TTY lines, the port number to connect to, and the
rotary group using the following syntax:
Syntax:
Example:
159
160
Chapter 5
Cisco Switches
Cisco Catalyst Operating System (CatOS) started to support the use of SSH
from version 6.1. Since then, CatOS 6.1 and up has supported SSH version 1
only. While the use of SSH version 1 still has its insecurities, the replacement of
Telnet on Cisco devices has added a tremendous amount of security to the
network device. SSH is supported on the following Cisco switches: Catalyst
3550, 4000, 5000, 6000, 8540, and 8510.
To use SSH on Cisco routers, complete the following steps.
1. Download the correct CatOS to the switch. Make sure you are downloading a CatOS version that holds SSH support. Cisco SSH servers
require the IPSec (DES or 3DES) encryption software image from
CatOS 6.1.
2. Generate the RSA Key with the following command:
Cat6509> (enable) set crypto key rsa 1024
4. After the key hash has been made, enable SSH with the following
command:
Cat6509> (enable) set ip permit enable ssh
5. Once SSH has been enabled on the Catalyst switch, enter the following
command to connect to the SSH services on the switch:
ssh c 3des v <switch ip address>
SSH Management
Figure 5.2 The SSH configuration screen of the Cisco VPN concentrator.
Table 5.1 lists and describes the various SSH configuration options available
on the configuration screen.
Table 5.1
OPTION
DESCRIPTION
Enable SSH
SSH Port
Maximum Sessions
Encryption Protocols
161
162
Chapter 5
After the SSH options have been set, select the Apply button to apply the
settings. SSH should now be enabled on the VPN concentrator on port 22 with
the following settings:
SSH Port22
Maximum Sessions4
Syntax:
Example:
3. Generate an RSA key pair for the firewall and save it with the following
commands:
PiX# ca generate rsa key 1024
PiX# CA save all
4. Select the interface on the firewall to use SSH. Most likely, this will be
the internal interface. The internal interface is called inside with an RFC
1918 address, as shown with the following syntax:
PiX# ssh 172.16.1.1 255.255.255.255 inside
5. Set the authentication timeout for SSH. The maximum timeout cannot
exceed 120 seconds, which is also the default; however, once the session
SSH Management
is established, the VTY timeout setting applies, not the SSH timeout setting. The following syntax sets the firewalls timeout session for SSH:
PiX# ssh timeout 60
6. Lastly, set the password for the firewall using the following syntax:
PiX# passwd superhardpasswordforl33th4x0rs
Once SSH has been enabled on the PIX firewall, enter the following
command to connect to the SSH services on the firewall, assuming pix
is the username:
ssh c 3des l pix v <ip.address.of.pix>
163
164
Chapter 5
example, if a NetApp filer holds the strongest level of CIFS and NTFS security,
be sure to use SSH on the filer also, since it will uphold the level of security
required for the device. To mitigate this issue and similar issues, NetApp has
created a module to support encrypted management for its Data ONTAP software. The module that supports SSH is called SecureAdmin.
NetApps SecureAdmin module supports SSH 1.x for command-line management. Using SecureAdmin, a remote administrator is authenticated with a
username/password combination on the filer. After authentication, the session is initialized on the filer, and host-based authentication is accomplished
through RSA public keys. The SSH 1.x daemon is executed with Java and RSA
libraries. Supported encryption algorithms are DES and 3DES, with a key-bit
range from 384 to 1024.
To set up SecureAdmin SSH on your NetApp filer, log in to the filer and gain
access to a valid shell. After getting access to a shell, complete the following
steps.
1. To configure the SSH server, enter the following command. This will
configure SSH and allow the administrator to set the key strength for
the RSA key, ranging from 384 bits to 1024 bits.
secureadmin setup f ssh
2. To enable SSH, enter the following command. This is a persistent command, so there is no need to re-enter the command after the server is
rebooted.
secureadmin enable ssh
3. To disable SSH, enter the following command. This is a persistent command, so there is no need to re-enter the command after the server is
rebooted.
secureadmin disable ssh
4. To show the status of the SSH session on SecureAdmin, enter the following command. This will show the current status of all SSH servers.
secureadmin status
Secure Management
Secure management is essential for an organization to meet an acceptable level
of security. While the devices mentioned previously support SSH, not all
devices in a network environment will support the use of SSH. For that reason,
you should examine some alternative management methods with SSH, using
SSH Management
Management servers
Two-factor authentication
SOCKS management
SSHUser Restrictions
Management Servers
Management servers are a fairly new idea in network management that is
slowly growing to be a standard in many networks. The use of a management
server is the restriction of management access to several systems/devices from
one or two management servers only, which are accessible throughout the
organization. The idea is to limit the broad management-level access to sensitive servers, such as database servers, from the entire organization and allow a
set number of IP addresses, which would be management servers. Furthermore, the idea is to encrypt or secure the connection to these sensitive servers
as much as possible.
From the preceding discussion, you know that SSH can be used for management on many network devices; however, what happens if SSH is not
available on certain management devices? Is the right solution to use Telnet,
thus lowering the security model of the network, or to allow only console
access, which adds an incredible amount of overhead to managing the system?
A good architecture management model is to deploy two to four management servers throughout the network. These systems can be any flavor of Unix
or Windows, as long as they are extremely secure. In fact, no services should
be listening on these management servers, and some type of host-based firewall should be deployed. Install SSH on the management servers, and require
the use of both passwords and public keys for authentication. Restrict access to
sensitive systems/devices on the network by allowing only the management
servers to have access. For example, if Web servers and database servers were
considered sensitive and on the 192.168.1.0 network segment, and if the internal network were on the 172.16.1.0 network segment, access would have to be
blocked from every server on the 172.16.1.0 network segment to the 192.168.1.0
network segment. Furthermore, access would have to be permitted to the
192.168.1.0 segment from the management servers that have been deployed in
the internal network. Figure 5.3 describes this architecture.
165
Database
server
Database
server
Database
server
Management
Server
Management
Server
Firewall
Database
server
Desktops
Desktops
Desktops
SSH Permitted
from authorized users
Encrypted Communication
with SSH
Internal Network
Desktops
166
Chapter 5
SSH Management
Two-Factor Authentication
A very good security practice is to use two-factor authentication, which is the
process of using two methods for authentication for a given entity. Two-factor
authentication provides an extra level of security in the case that a single
method of authentication such as a password is compromised. If a password is
compromised, an additional method of authentication is still required in order
to gain access to the entity. Also, since many passwords are very poor and can
be compromised with a variety of attacks, the use of two-factor authentication
mitigates many problems with using passwords.
SSH fully supports the use of two-factor authentication in any type of environment. While SSH can support two-factor authentication in a variety of
ways, concentrate now on deploying two-factor authentication with the use of
passwords and public-key files. As discussed in Chapter 4, public keys can be
generated on a per-user basis and used for authentication. In addition to providing the current key for authentication, a username/password combination
may be required on the remote SSH server. Therefore, once the user has
authenticated to the SSH server with his/her public key, he or she is prompted
for a password on the SSH server that correlates to the username that he/she
is attempting to log in with. This model enforces two-factor authentication by
requiring both public keys and passwords.
While the use of SSH on many network devices, described in the first half of
this chapter, is a great practice for device management, several SSH installations do not support two-factor SSH authentication but just require an SSH
username and SSH password to log in. While the session is still encrypted, the
loss of an SSH password may leave the network device vulnerable. For example, in many network environments passwords are shared between accounts.
A user may have an SSH password that is used to log in to the Cisco router, but
may also use the same password to FTP files back and forth to the FTP server
in the internal network. While the SSH session would be fully encrypted, the
FTP session would not be. If the FTP session were sniffed by an unauthorized
employee, the FTP password could be obtained and then attempted on the
SSH service on the router. If the user had used the same password, the router
would now be compromised, despite the use of SSH.
167
168
Chapter 5
Internal Network
Denied access
without valid
public key
Router
Management
Server
SSH
Attacker
Access to valid password
Desktops
Desktops
Desktops
Desktops
SSH Management
SOCKS Management
SOCKS is an Internet Engineering Task Force (IETF) standard used as a generic
proxy protocol for TCP/IP applications. SOCKS servers provide the ability to
accept requests from SOCKS clients and forward them to the appropriate
application server on behalf of the SOCKS client. The primary purpose of the
protocol is to enable nodes on one side of the SOCKS server to gain access to
hosts on the other side of the SOCKS server, allowing direct access from the
SOCKS clients to the application server.
In the example configuration in Figures 5.3 and 5.4, you examined a method
of using SSH and firewall rules to allow secure access to remote machines.
SOCKS uses a similar configuration; however, with the use of a SOCKS server,
the transitions between the clients on the right and the sensitive servers on the
left is more streamlined and less cumbersome than in the configurations in the
previous examples. In the architectural example with the management server
and two-factor authentication, a client first needs to authenticate to the SSH
server and gain a shell or command prompt on that device. After the
shell/command prompt has been attained, the client needs to make another
connection to the desired sensitive server in order to manage it. While this
process is straightforward and relatively easy, the use of a SOCKS proxy server
could cut the process in half by requiring only a connection from the client to
the SOCKS server. The SOCKS server would then be authorized to forward
that connection to the desired device and return the shell/command prompt
to the client. Figure 5.5 shows architecture similar to that in Figures 5.3 and 5.4
but with a SOCKS implementation. Notice that the architecture is very similar,
if not the same, but that access for the end-user is limited to one-step instead of
two or three steps for architecture in Figures 5.3 or 5.4.
There are two current installations of SOCKS: version 4 and version 5. Most
SSH clients support both versions. If a SOCKS server has been deployed in a
network environment, using any SSH client such as SecureCRT is very simple.
(For more detail about SSH and SOCKS, see Chapter 9.) See Figure 5.6 for
SecureCRT SOCKS setup.
169
Database
server
Database
server
Database
server
Database
server
Firewall
Desktops
Internal Network
Desktops
Desktops
170
Chapter 5
SSH Management
171
172
Chapter 5
Notice that not only is the Use firewall to connect option selected; the
hostname of the real server you would like to access, in the Hostname field, is
selected as well. Referring to Figure 5.5, the desktops on the right-hand side
are the machines using the SecureCRT application. The SOCKSv5 server is
172.16.1.1, which has been set up in your SecureCRT global option menu (see
Figure 5.6). Lastly, when an SSH session on the Web server, which is
192.168.1.100, is desired, the SecureCRT SSH client would connect to the
SOCKS server first, using the Use firewall to connect checkbox shown in
Figure 5.7, and then have the SOCKS server complete the connection on your
behalf and return the shell to your SecureCRT client.
The use of SOCKS and SSH for secure-management access reduces the number of authentication steps and streamlines the process for the end-user; however, the level of security and authentication methods required are not reduced
or affected in any way. This architecture not only maintains the level of security described in Figures 5.3 and 5.4, but also adds a level of usability for the
end-user.
Chroot
Chroot is a Unix-only system call that restricts users to files, folders, and binaries only in a specified directory. The best way to think of Chroot is as a virtual
sandbox, often called a chroot jail, where an application or user may operate.
SSH Management
SSHUser1,SSHUser2,kusum,rohan,shreya
FirewallAdmins,BackupAdmins,RouterAdmins
4. Uncomment the sftp-server subsystem entry, which allows SSH to initialize internal sftp-server. The following is an example:
Subsystem-sftp
internal://sftp-server
5. Edit the /etc/passwd file, changing the SSH users shells to /bin/sshdummy-shell. The following is an example:
SSHUser1:x:500:10:SSHUser1:/home/SSHuser1:/bin/ssh-dummy-shell
SSHUser2:x:500:10:SSHUser2:/home/SSHuser2:/bin/ssh-dummy-shell
Kusum:x:500:10:Kusum:/home/Kusum:/bin/ssh-dummy-shell
Shreya:x:500:10:Shreya:/home/Shreya:/bin/ssh-dummy-shell
Rohan:x:500:10:Rohan:/home/Rohan:/bin/ssh-dummy-shell
173
174
Chapter 5
The VShell User Access Control screen (see Figure 5.8) shows two separate
sections: the Name section and the Permissions section. The Name section is
the section where the user names the operating system that needs to be set.
The Permissions section sets the different types of permission that will be
allowed to each user, including Logon, Shell, Remote Execution, SFTP, Port
Forwarding, and Remote Port Forwarding.
Lets say you want to grant access to the SSH server for the Backup group,
to back up files on the SSH server. The Backup group is called Backup Operators and will need SFTP access but will not need shell access to the SSH server
(as shown in Figure 5.9). Complete the following steps to add the appropriate
connection filters:
1. Select the Add button.
2. Scroll down on the Windows Select User or Group menu and choose
the Backup Operations group.
3. Select the checkbox in the Allow column for the SFTP row.
4. Select the checkbox in the Allow column for the Remote Execution row.
5. Select the checkbox in the Deny column for the Shell row.
6. Now the Backup Operators group has full SFTP access to the SSH
server but does not have shell access to the server.
SSH Management
Figure 5.9 Access control permission for the Backup Operators group.
175
176
Chapter 5
Lets say you want to grant access to the SSH server for the Backup Operator account, known as BackupAdmin, to back up files on the SSH server. The
backup operator will need SFTP access but will not need shell access to the
SSH server. Also, besides allowing access to the Backup Operator account, you
want to make sure the backup operator does not use a personal account to log
in to the SSH server, which is called Sudhanshu. Complete the following steps
to add the appropriate connection filters:
1. Move the mouse inside of the Allow login from hosts.
2. Type BackupAdmin.
3. Move the mouse inside of the Deny login from hosts.
4. Type Sudhanshu.
5. Select the no option for the Permit User Terminal option.
6. Select Apply.
7. Now the Backup Operator account is allowed to make an SFTP
connection to the SSH server, but is not permitted to use the SSH
terminal session. Also, the backup operators personal account,
Sudhanshu, is fully restricted.
Note the use of patterns in Figure 5.11. For example, to permit any user with
admin in front of his or her username, such as adminSANFRAN, the following
syntax can be used: admin.*. Furthermore, to deny any user with test in front of
his or her username, such as test1234, test.* can be used as a pattern-matching
utility.
SSH Management
177
178
Chapter 5
Without TCP Wrappers
SSH Client
SSH Service
SSH Session
SSH Service
SSH Session
2. Configure and make the SSH server with the libwrap binary using the
following syntax:
#./configure with-libwrap
#make
#make install
3. Once the SSH server has compiled correctly, change directories to the
/etc directory using the following syntax:
#cd /etc
SSH Management
4. Edit the two TCP wrapper files, called hosts.allow and hosts.deny. The
TCP wrappers daemon always reads IP addresses or hostnames in
hosts.allow first. If it sees a match in hosts.allow, it will permit the IP
address or hostname. If it does not see a match in hosts.allow, it will
read the hosts.deny. This being the case, you want to put a deny all
rules in hosts.deny. If neither the hosts.allow nor hosts.deny file contains information, all IP addresses and hostnames will be allowed. The
following is the format required for the hosts.allow and hosts.deny
files, as well as examples of each:
Format
.
daemon : IP.address or hostname
Hosts.allow
sshd2: 10.1.0.
Hosts.deny
sshd2:ALL
5. The hosts.allow file would allow access to any IP address coming from
10.1.0.0 to 10.1.0.254. The hosts.deny file would deny access to every
other IP address.
179
180
Chapter 5
Lets say you want to deny access to the SSH server from the users network
(172.16.1.0/24) but permit access to the SSH server from the management network (10.1.0.0/24). Complete the following steps to add the appropriate connection filters:
1. Select the Add button.
2. Select Netmask for the Filter type.
3. Enter 172.16.1.0 for the Network.
4. Enter 255.255.255.0 for the Mask.
5. Enter Users network for the comment.
6. Select the Deny radio button under the Action section on the left side.
7. Select OK.
8. Select the Add button.
9. Select Netmask for the Filter type.
10. Enter 10.1.0.0 for the Network.
11. Enter 255.255.255.0 for the Mask.
12. Enter Management network for the comment.
13. Select the Allow radio button under the Action section on the left side.
14. Select OK.
SSH Management
181
182
Chapter 5
The SSH Communications Host Restrictions screen (see Figure 5.15) shows
two separate sections: the Allow login from hosts and the Deny login from
hosts.
Lets say you want to deny access to the SSH server from the users network
(172.16.1.0/24), but permit access to the SSH server from the management network (10.1.0.0/24). Both Allow and Deny fields use special syntax, denoted
with the \ symbol, to include variables, so each IP address does not need to be
entered. Complete the following steps to add the appropriate connection filters:
1. Move the mouse inside the Allow login from hosts.
2. Type 10\.1\.0\..*.
3. Move the mouse inside the Deny login from hosts.
4. Type 172\.16\.1\..
5. Select Apply.
Youre done. Now any IP address on the 172.16.1.0/24 network will be
restricted and all addresses on the 10.1.0.0/24 network will be permitted (as
shown in Figure 5.16).
Figure 5.15 The Host Restrictions screen of SSH Communications SSH server.
SSH Management
Summary
In this chapter, I introduce several options that SSH can provide to deploy and
maintain secure-management processes and procedures. Management methods are often targeted by attackers as an attack vector, creating a false sense of
security for many administrators who overlook management processes and
procedures.
Secure management involves sure-management networks, but also secure
management services on devices. I cover the use of SSH services in atypical
environments such as network devices/network hardware. Various types of
devices, including routers, switches, load balancers, storage appliances, VPN
servers, and firewalls, can provide SSH services on their respective network
hardware, eliminating the need for insecure protocols such as Telnet and
greatly improving the management of these devices. For example, a VPN
server that controls access to the internal network for external users and is
managed remotely with HTTP or Telnet negates many of the security issues of
the VPN server itself (encryption). Furthermore, storage devices that hold and
protect critical company data may use a clear-text protocol for management,
making admin-level access to the machine more vulnerable.
183
184
Chapter 5
This chapter demonstrates how SSH can secure both network devices and
management methods with the use of native SSH services on network devices
and the integration of SSH with other operating-system tools such as Chroot
and TCP Wrappers. The next chapter covers port forwarding and how an
SSH can be utilized as a remote-access solution rather than just a securemanagement solution. The next chapter expounds upon the definition of SSH
and how it can be utilized in so many ways.
PA R T
Two
Remote Access
Solutions
CHAPTER
6
SSH Port Forwarding
We have discussed several features, utilities, and benefits that SSH provides
with a single service or subsystem, but one of the most useful and powerful
features is port forwarding. Since port forwarding is such a strong feature of
SSH, two chapters are dedicated to it. This chapter addresses the basics of port
forwarding, such as what it is, how to set it up, and some of its basic requirements. The next chapter discusses the advanced usages of port forwarding
and how to use it in network architecture in order to optimize it.
Port forwarding is the ability of an SSH client to connect to an SSH server
and then forward other ports within the established SSH connection. Port forwarding is also referred to as SSH tunneling, where alternative TCP traffic is
sent over an encrypted SSH tunnel. The great part about port forwarding is
that it requires few to no changes on the SSH server, besides being enabled,
and it is fully functional on most default SSH2 installations.
For example, if an SSH connection is established between an SSH server and
an SSH client, another protocol/port, such as IMAP (port 143), could be tunneled within the SSH connection over port 22. Since port forwarding uses only
the existing SSH tunneling for communication, usually on port 22, only one
firewall rule is required to permit an unlimited number of ports to be tunneled
through the existing SSH session. SSH port forwarding not only requires fewer
firewall rules, which reduces the required number of ports allowed into the
internal network; it allows several insecure protocols to be secured, such as
mail (IMAP, POP3, and SMTP), file transfer (SMB, FTP, CIFS, and NFS), and
management (Telnet, VNC, and pcAnywhere). Figure 6.1 shows an example of
the tunneling process.
187
188
Chapter 6
IMAP
SSH Client
SSH Server
Mail Server
Figure 6.1 An established SSH connection with the IMAP protocol tunneled.
Before discussing port forwarding, lets examine two of the three types of
port forwarding: local and remote, also referred to as outgoing and incoming,
respectively.
an internal intranet Web server, which holds the intranet Web page. The following five simple steps are the only ones required in order to allow business
travelers secure access to the intranet from all different types of networks:
1. Install an SSH server listening on port 22.
2. Install a single rule on the firewall that allows connections on port 22 to
reach the SSH server.
3. Set up the SSH client to locally port forward port 80 to the intranet Web
server when a connection has been requested on its lookback interface
(127.0.0.1).
4. Connect to the SSH server with the SSH client, with the port-forward
rules enabled.
5. Open a Web browser and enter the lookback IP address (127.0.0.1); the
intranet Web site should be displayed.
Figure 6.2 shows the example architecture.
SSH Client
Step 1: Firewall
Internet
Firewall rule allows Port 22
from anywhere to SSH Server
(11.17.73.2)
11.17.73.1
Step 2: SSH client
Connection:
Firewall
11.17.73.2
172.16.1.1
Local Port Forward:
Port 80:172.16.1.100
11.17.73.2
Final Result
SSH client connects to
127.0.0.1 on port 80 with
their web browser and
receives the intranet
web server application
172.16.1.2
SSH Server
Internal Network
189
190
Chapter 6
A good example of remote port forwarding is the use of public FTP servers.
Although using FTP and port forwarding is a very tricky procedure, due to the
use of active FTP, it still can be done. Lets say that both internal employees
and external customers need to get files from an organizations public FTP
server. While the FTP server contains public information for the customers to
download, it also contains private information for employees to use. The network contains an FTP server, an SSH server, and an unlimited number of
employees and customers who need to access the FTP server. The use of SFTP
is a good alternative by the organization, but the organization does not want
to make its customers use SFTP, since SFTP clients do not come on most operating systems by default (it would be really nice if they did). The only requirement is that internal employees cannot use clear-text protocols to access
sensitive company information. To prevent the private information from being
sent over the Internet in clear-text, a remote port-forwarding session can be set
up. The following five simple steps are the only ones required in order to allow
customers to download information with FTP as well as to allow internal users
to download information with the use of encryption (shown in Figure 6.3):
1. Install an SSH server that listens on port 22.
2. Install an SSH client on the FTP server.
3. Set up the SSH client on the FTP server for a remote port-forwarding
session. Set up the session so that when the SSH client (the FTP server)
establishes a connection to the SSH server, a remote port-forwarding
session will be established that will make the SSH server listen on port
21 and redirect any connections to port 21 (on the SSH server) to port 21
on the FTP server.
4. Internal employees should FTP to the SSH server on port 21, which will
be forwarding to the FTP server on port 21 over the established SSH
session.
5. External public customers should make a regular FTP connection to the
FTP server on port 21, which will not be encrypted with SSH.
ENCRYPTED
FTP Server
11.17.73.100
Internal Employees
(172.16.1.10 - 172.16.1.254)
SSH Server
11.17.73.1
192
Chapter 6
SSH port forwarding is simple and straightforward. The theory behind port
forwarding is much like the process of simple TCP relaying. A TCP relay is the
ability to accept connections on a particular port and redirect them somewhere
else. For example, every connection on port 80 on a machines loopback
address (127.0.0.1) is relayed to port 80 on 172.16.1.100. The only difference
with SSH port forwarding is that the connection is redirected through an
established SSH session first and then replayed to the remote machine. Some
basic requirements must be met in order for port forwarding to work, such as
a valid connection from the SSH server to the remote server (the server receiving the relayed connection); however, that is not a separate configuration step
but an assumed requirement.
A key point to keep in mind regarding port forwarding is that protocols
such as IMAP, SMTP, and POP3 being tunneled are terminated at the SSH
server. For example, if a client is connecting to an SSH server and then port forwarding SMTP and IMAP over SSH to receive e-mail securely, the mail protocols will be tunneled from the SSH client to the SSH server; then the mail
protocols will be sent over their native protocols from the SSH server to the
mail server. The communication from the SSH server to the mail server will
not be under an SSH session. Figure 6.4 shows further details.
Notice in Figure 6.4 that the IMAP and SMTP protocols are protected from
the SSH client to the SSH server by the port-forwarding tunneling process;
then they communicate with their native protocols without any tunnels from
the SSH server to the mail server.
This chapter examines some of the basics of SSH port forwarding, specifically the following topics:
SSH
communication
IMAP, SMTP
No SSH
communication
SMTP
IMAP
SSH Client
SSH Server
Mail Server
Also, configuring local and remote SSH port forwarding on the following
SSH clients is explored:
The restriction of terminal and SFTP access usually means that the user has
the right to use the SSH session for port forwarding through the SSH server
but not for gaining access to the SSH server. Once the SSH session is established, any port-forwarding options on the SSH client will be applied; however, any port-forwarding rules need to be configured before the SSH session
has been established. If port-forwarding options are configured during or after
the SSH session has been established, the options will not be effective until the
session is fully re-established.
The second major concept of port forwarding is that most, if not all, configuration of port forwarding is conducted on the client, not on the server. For
example, if port forwarding is required between an SSH client and an SSH
server, the configuration for the incoming or outgoing SSH rules will be on the
193
194
Chapter 6
client. In the port-forwarding architecture, the server needs to allow port forwarding, but no specific configuration is required on the server.
internal Web server for an organization, which holds the companys intranet
application, you need to choose the IP address of the internal Web server. Keep
in mind that the SSH server must be able to communicate with this machine
natively, without any firewall, router ACLs, or networks preventing it from
communicating with the remote machine. If the IP address of the internal Web
server is 192.168.12.15, that will be the IP address of the remote server. After
the IP address of the remote server is specified, the remote port has to be
selected also. Unlike the local-port option, the remote-port option is dictated
by the remote server. For example, if the intranet Web application uses HTTP,
which is port 80, you must specify port 80 and the remote port. Furthermore,
if the remote server is a mail server and you are forwarding mail protocols,
you have to choose SMTP and POP3, which are ports 25 and 110.
Now that you have your local IP address (127.0.0.1), local port (80), remote
server IP address (192.168.12.15), and remote port (80), selected for your local
port-forwarding rule, you are ready to forward the HTTP protocol through the
SSH connection. The following steps walk you through the process of using
the local port-forwarding session by using an SSH server with two IP
addresses: one that faces externally to the Internet, 12.15.10.21, and one that
faces internally to the internal network, 192.168.12.1:
1. Having established your local port-forwarding rules, establish an SSH
connection to the SSH server on its external IP address (12.15.10.21)
using the required authentication options (see Figure 6.5).
195
196
Chapter 6
2. The SSH session is now established with the local port-forwarding rules
enabled. (To confirm, you can type netstat an on a command shell, and
your lookback IP address, 127.0.0.1, should be listening on port 80.)
Next, open your Web browser. In the URL section of your Web browser,
type 127.0.0.1 (see Figure 6.6).
3. Once your Web browser attempts a connection to your lookback
address, 127.0.0.1, on port 80 (by default, Web browsers connect on port
80), your port-forwarding rules will be triggered. The rules will dictate
that all connections to 127.0.0.1 on port 80 should be redirected through
the established SSH connection to 192.168.12.15 on port 80.
4. Assuming your SSH server can communicate with 192.168.12.15,
the connection is forwarded beyond your SSH server to the internal
Web server, on port 80. The internal Web server sends the results,
probably the intranets home page, to the SSH clients Web browser.
See Figure 6.7.
Note that the local port-forwarding connection from your SSH client to the
SSH server is fully encrypted with SSH, but the connection from the SSH
server to the local intranet server uses its native protocol, which would be
HTTP. For an example of how this works, see Figure 6.8.
Figure 6.7 The companys intranet Web page to the remote SSH client, sent after
requesting 127.0.0.1 on the URL of the Web browser.
12.16.10.21
192.168.10.1
SSH Client
172.16.10.21
SSH Server
Encrypted with SSH
Native Protocol (HTTP)
Figure 6.8 The SSH encrypted session and the native protocol (HTTP) session.
197
198
Chapter 6
12.16.10.21
SSH Client
172.16.10.21
(Running a native FTP
server on port 21)
192.168.10.1
FTP Client
199
200
Chapter 6
Similarly, if the SSH client is port forwarding to the SSH server, not to
another server that the SSH server may be connected to, the SSH server still
has no specific networking changes generated. For example, if the SSH server
is also acting as an FTP server on port 21 and an SSH client port forwards FTP
to the SSH server, there are no networking changes on the SSH server. Since
the SSH client is port forwarding to an existing service (port) on the SSH/FTP
server, the SSH servers networking configuration does not change but rather
continues to act as an SSH server as well as an FTP server.
If incoming (remote) port forwarding is being used on the SSH client, networking changes on the remote SSH server are generated. For example, if an
SSH client is using remote port forwarding on port 21 (FTP), the authenticated
and established SSH session will generate and start a service on port 21 on the
selected networking interfaces on the SSH server. In this architecture, the SSH
client waits for redirect packets from the SSH server. In this example, a remote
FTP client connects to the generated FTP service on the SSH server. Once the
SSH server receives the incoming packets from the FTP client, the SSH server
redirects and relays the packets to the SSH clients FTP service on port 21 on
behalf of the FTP client. Slightly different from the preceding example, the SSH
server is acting as a redirector on port 21 between the authenticated and established SSH client and the remote FTP client.
201
Internet
Firewall
25
172.16.11.1
Mail Relay
(192.168.0.10)
11.30.11.1
Hub
80.443
Windows
Terminal Server
(172.16.11.72)
3389
Mail Server
(172.16.11.8)
143
Webserver
(172.16.11.17)
Figure 6.11 The common architecture used for the example configurations of port forwarding.
Service Port XX
Internal Network
DMZ Network
External Network (Internet)
80
SSH Client 1
22
SSH Server
(11.30.11.21)
202
Chapter 6
DEVICE
DESCRIPTION
SSH Client 1
Internet
SSH Server
Firewall
Mail Relay
Hub
203
204
Chapter 6
Table 6.1
(continued)
DEVICE
DESCRIPTION
Web Server
Mail Server
Windows Terminal
Server
Now that the common architecture has been described and defined, lets
explore how to individually configure the SSH clients and SSH servers for port
forwarding. The following SSH servers and SSH clients will be discussed:
Command-line clients
OpenSSH client
SSH Communications
VanDyke Software
PuTTY
The listen-port or localport option designates the port to have the local operating system listen on. The host or remotehost option is the IP address of the
remote server that the SSH server is connected to. The port or remoteport
option is the port that the remote server is listening on. The specific -L options
to use, according to Figure 6.11, are the following for OpenSSH and SSH
Communications:
L
L
L
L
L
25:192.168.0.10:25
80:172.16.1.117:80
443:172.16.1.117:443
143:172.16.11.8:143
3389:172.16.11.72:3389
The specific -local options to use, according to Figure 6.11, are the following
for VanDyke Software:
local
local
local
local
local
25:192.168.0.10:25
80:172.16.1.117:80
443:172.16.1.117:443
143:172.16.11.8:143
3389:172.16.11.72:3389
205
206
Chapter 6
N OT E Do not confuse the listen-port option with the port option. The listenport option is the port that the SSH clients operating system will listen on, with
the loopback (127.0.0.1) interface, in order to relay the connection. The port
option is the port number on the remote server, which cannot be changed by
the SSH client.
The listen-port option can be any port on the SSH clients operating system.
For example, instead of using listen-port 80 for the local relay to the remote
Web server, the SSH client can use port 79. The remote connection will still be
on port 80, but the local forward will connect on port 79. In order to make the
connection, the Web browser has to point to port 79 instead of the default 80,
which is quite easy (for example, http://127.0.0.1:79). This flexibility works
well if multiple remote Web servers will be locally port forwarded, since only
one local port can be forwarded to one remote IP address. On the other hand,
the flexibility of the listen-port option is available only if the connecting client
application, such as a Web-browser client, is able to connect using a nonstandard port, such as 79. In some cases, such as with the Terminal Services client,
the client application cannot be configured to use a different connection port;
therefore, the local-port option must remain 3389 in order for the connection to
work correctly.
To connect to your SSH server in Figure 6.11 and forward all the local ports,
the following syntax should be used:
OPENSSH
ssh 11.30.11.21 l jum4nj1 p 22 L 25:192.168.0.10:25 L
80:172.16.11.17:80 L 443:172.16.11.17:443 L 143:172.16.11.8:143 L
3389:172.16.11.72:3389
SSH COMMUNICATIONS
ssh2 11.30.11.21 l jum4nj1 p 22 L 25:192.168.0.10:25 L
80:172.16.11.17:80 L 443:172.16.11.17:443 L 143:172.16.11.8:143 L
3389:172.16.11.72:3389
VANDYKE SOFTWARE
vsh 11.30.11.21 l jum4nj1 p 22 local 25:192.168.0.10:25 local
80:172.16.11.17:80 local 443:172.16.11.17:443 local
143:172.16.11.8:143 local 3389:172.16.11.72:3389
The first part of the syntax connects the SSH client to the SSH server
(11.30.11.21) on port 22, designated by the -p option, with the username of
jum4nj1, designated by the -l option. Once the SSH servers IP address and
port number have been designated, the local port-forwarding options need to
be set. As you can see, the syntax can be quite long if several port-forwarding
options are used. Different configuration files are ideal when more than one
port-forwarding option is required to be set. (Refer to the Unix Setup section in
Chapter 3, Secure Shell Clients, on how to set up different configuration
files.) Once the SSH client is authenticated and the SSH session is established,
the port-forwarding options will automatically be enabled. To confirm, type
netstat -an | more and the port-forwarded ports should be listening on the
loopback interface (127.0.0.1).
Once you have confirmed that the port-forwarded sessions are enabled, use
your client application to connect to your port-forwarded session. For example, to use the Windows Terminal Services port-forwarding session, execute
the terminal services client and enter 127.0.0.1 for the server IP address. Since
127.0.0.1 is listening on the SSH clients machine on port 3389, it will accept
this connection request from the client application and forward it to
172.16.11.72 via the SSH connection and the SSH server. Similarly, other clients,
such as mail clients and Web clients, will need to use the loopback interface
(127.0.0.1) to connect to the remote server via the SSH session.
207
208
Chapter 6
209
210
Chapter 6
Figure 6.14 shows the final result of the local port-forwarding options from
the preceding steps.
Continue to enter the rest of the local port-forwarding options by repeating
steps 6 through 12. Make sure the result looks like Figure 6.15.
Once all the outgoing tunnels have been entered, select OK. The outgoing
port-forwarding tunnels for SecureCRT have now been entered. Once the connection is established, the local port-forwarding tunnels will be available.
211
212
Chapter 6
Once the SSH connection is made with the remote port-forwarding settings,
the internal Web client should open his or her favorite Web browser and point
to the following URL: http://11.30.11.21:80. Also, on the SSH server itself, the
following URL can be used: http://127.0.0.1:80. This will display the Web site
on web.jum4nj1.com to both the internal Web client and the SSH server on the
encrypted SSH connection.
213
214
Chapter 6
Once the SSH connection is made with the remote port-forwarding settings,
the internal Web client should open the Web browser and point to the following URL: http://11.30.11.21:80. Also, on the SSH server itself, the following
URL can be used: http://127.0.0.1:80. This will display the Web site on
web.jum4nj1.com to both the internal Web client and the SSH server on the
encrypted SSH connection.
Once the SSH connection is made with the remote port-forwarding settings,
the internal Web client should open the Web browser and point to the following URL: http://11.30.11.21:80. Also, on the SSH server itself, the following
URL can be used: http://127.0.0.1:80. This will display the Web site on
web.jum4nj1.com to both the internal Web client and the SSH server on the
encrypted SSH connection.
215
216
Chapter 6
217
218
Chapter 6
installation has been completed. (See Chapter 1 for details on how to install an
SSH server.) SSH Communications provides the ability to restrict or permit
port forwarding, also known as tunneling, on the SSH server. For example, if
port forwarding is not desired, the tunneling settings can restrict access while
still allowing terminal and/or SFTP access. In addition to permitting or
restricting port forwarding, the ability to allow port forwarding for only a
specified set of users and denying everyone else is possible. Furthermore, the
ability to deny port forwarding for a set number of users and allow everyone
else is possible. Lastly, in addition to allowing and denying specific users
and/or groups, the SSH server can restrict port forwarding using ACLs based
on IP addresses and port numbers. For example, if port forwarding is not
desired to all internal machines but rather to a selected few, port forwarding
ACLs can be set to allow only certain IP addresses on certain ports to be accessible to port forwarding SSH clients. To view the tunnel configuration options
and configure these options on SSH Communications SSH server, perform the
following steps:
1. Change directories to /etc/sshd2:
#cd /etc/sshd2
yes
root, admin, system@Aum-sshserver\.com
yes
root, admin, system@Aum-sshserver\.com
backup, test
RemoteAccess
allow
allow
allow
allow
local.*%users
local.*%users
local.*%users
local.*%users
\i192.\.168\.0\.10%(25)
\i172.\.16\.11\.17%(80|443)
\i172.\.16\.11\.8%(143)
\i172.\.16\.11\.72%(3389)
These rules allow all users and groups to only port forward to 192.168.0.10
(port 25), 172.16.11.17 (port 80 and 443), 172.16.11.8 (port 143), and 172.16.11.72
(port 3389), while denying access to all other servers. Notice the syntax used
219
220
Chapter 6
for the port forwarding ACLs. A \i is required before the first octet of the IP
address, and a \ is required before every following octet. The complete syntax
is as follows:
ForwardACL argument
users
\iIP\.Address\.of\.server%(port|port|port)
DNS names can also be used for ForwardACL statements. For example, if
Aum.terminalserver.com is the destination server, on port 3389, the following
syntax can be used:
ForwardACL Allow .*%users Aum\.terminalserver\.com%3389
Note that once Allow rules are applied on the SSH server, all other servers
and/or devices will not be granted port-forwarding access. For example, only
the servers specifically allowed will be accessible by the SSH clients who are
port forwarding. All other servers will be denied by default unless otherwise
stated. (This denial makes any Deny rules redundant, since everything else
besides the server that has been allowed is denied automatically.) Furthermore,
any server port-forwarding filtering overrides any client port-forwarding
rules on the SSH clients themselves.
221
222
Chapter 6
223
224
Chapter 6
Figure 6.24 VShells filtering rules for port-forwarding according to Figure 6.11.
Figure 6.25 Access to the internal network, except for one server.
Make sure the Deny filter comes before the Allow filter, since filters are read
from top to bottom and are executed immediately once there is a match.
225
226
Chapter 6
client and enabled before the SSH connection has been established. While this
effort is relatively low and usually required only once, many new users are not
accustomed to the fact that no server-side configuration is required, only clientside configuration. The concept, while being relatively simple, confuses many
new SSH users, thinking that in addition to client-side configuration, some magical tricks need to be configured on the SSH server also, which could not be farther from the truth. Once the port-forwarding configuration has been enabled
on the SSH client, the port-forwarding tunnels should be fully functional.
The use of different SSH clients with port forwarding are also described in
this chapter. While many of the SSH clients provide similar, if not the same, features as one another, there are some subtle differences that should be reviewed
in order to select the best SSH client for your situation or organization.
While providing different functionality and usage, both local and remote
port forwarding offer benefits to the entire SSH architecture. The fact that most
TCP ports can be tunneled over an encrypted SSH session gives port forwarding and SSH a whole new identification. Instead of SSH being a solution for
only encrypted Telnet, SSH now becomes a viable solution for any insecure
TCP ports, especially mail protocols, such as POP3, IMAP, SMTP, intranet protocols, such as HTTP, and remote-management protocols, such as VNC, Windows Terminal server, X11, and pcAnywhere. Also, the most popular usage of
SSH, which is encrypted terminal access, becomes a completely secondary feature. SSH is often deployed only for its port-forwarding capabilities, ignoring
any terminal or SFTP access it may provide. Lastly, with its completely flexible
architecture, combined with its fully encrypted communication, SSH port forwarding provides the ability to access almost any machine over any hostile or
untrusted network with the full assurance of the safety and security of the
remote session. The fact that the SSH session is fully encrypted, provides twofactor authentication options, and still grants virtually full access to the
desired remote server or network makes SSH more flexible than other standard encryption applications.
Summary
This chapter discusses some of the networking basics of one of the more powerful features of SSH. Details on the port-forwarding architecture from both an
SSH-client and an SSH-server perspective are introduced and demonstrated.
From the initial discussion in the early sections of this chapter, you learn that
not only does port forwarding allow SSH to secure weak protocols, such as
mail protocols, file transfer protocols, and remote management protocols, but
that it also provides the same functionality that end-users are accustomed to.
Both remote and local port forwarding give SSH and SSH users an abundance
227
CHAPTER
7
Secure Remote Access
Remote access solutions in various organizations need to meet strict requirements in order to satisfy the needs of their end-users, which can range from
road warriors working from hotel rooms to technical administrators working
from home. While remote access solutions need to be available, functional, and
flexible, security concerns often get overlooked. For example, how many
remote users in your network use the following items to get access to company
resources?
229
230
Chapter 7
N OT E Any SSH server, SSH client, or e-mail client can be used for the secure
e-mail architecture. My example is a random selection from the different SSH
applications I have discussed thus far.
Administrators @home
Internet
Router
SSH Server
11.30.11.21
Firewall
SSH: 22
Mail Relay
11.30.11.22
SMTP: 25
Road Warriors at
client sites (LANs) or hotels
Internal
Network
POP3:110
Mail Server
172.16.1.100
232
Chapter 7
Now that the setup is complete, you can add the local port-forwarding
options:
13. Select Add to display the Port Forwarding options.
14. Enter Mail Relay for the Name field.
15. In the Local subsection, make sure Manually select local IP address on
which to allow connections is unchecked.
16. In the Local subsection, enter 25 for the Port field.
17. In the Remote subsection, make sure Destination host is different from
the SSH server is checked.
18. Enter 11.30.11.22 for the Hostname field.
19. In the Remote subsection, enter port 25 for the Port field.
20. Do not enter anything for the Application subsection.
21. Select OK.
Now that the Mail Relay local port-forwarding option is set up, the Mail
Server local port-forwarding option can be set:
22. Select Add to display the Port Forwarding options.
23. Enter Mail Server for the Name field.
24. In the Local subsection, make sure Manually select local IP address on
which to allow connections is unchecked.
25. In the Local subsection, enter 110 for the Port field.
26. In the Remote subsection, make sure Destination host is different from
the SSH server is checked.
a. Enter 11.30.11.22 for the Hostname field.
27. In the Remote subsection, enter port 110 for the Port field.
28. In the Application subsection, enter the path for Outlook Express. Once
the SSH session has been established, this option will open Outlook
Express automatically, requiring no interaction from the end-user.
While this option may seem trivial, requiring one fewer step for novice
end-users is significant. This option virtually allows one-step execution
for secure e-mail.
a. c:\Program Files\Outlook Express\msimn.exe
29. Select OK.
The result should look like Figure 7.2.
233
234
Chapter 7
After the SSH client has been completely installed, the e-mail client is ready
for the secure e-mail architecture.
b. For the Incoming mail server, enter 127.0.0.1. Remember, you have
already set up your our port-forwarding steps in the prior section.
Once the SSH session has been established, local ports will listen on
port 25 and 110. When Outlook Express attempts to connect to
127.0.0.1 on 110, it will be redirected by the SSH client to the e-mail
server of the SSH tunnel.
c. For the Outgoing mail server, enter 127.0.0.1.
d. Select Next.
8. Enter your account name given to you by your e-mail administrator,
such as Gandhi.
9. Enter your password, if you would like; however, I recommend you
leave this blank and allow the application to prompt you for authentication every time you log in. Select Next.
10. Click Finish. The e-mail client for secure e-mail has been completed.
11. To verify, highlight 127.0.0.1 in the account field and choose the Properties button on the right. Figures 7.3, 7.4, and 7.5 show how the General,
Servers, and Advanced tabs should look on your e-mail client.
235
236
Chapter 7
Once you have verified your setting, select OK and Close. You have completed the e-mail client setup for SSH.
237
238
Chapter 7
Once the SSH server has been established, Outlook Express should automatically open. You should automatically be prompted to log in with your correct password, as shown in Figure 7.8.
Once you have authenticated, your e-mail should be downloaded from the
e-mail server over the encrypted SSH tunnel.
Note that the e-mail communication will be going through its native protocols, such as SMTP and POP3, to and from the SSH server on the internal network; however, the e-mail communication will be encrypted in the SSH tunnel
from the SSH server, over the Internet, to the e-mail client.
Congratulations! You have just implemented a secure e-mail architecture
over the Internet.
on NetBIOS with SMB for file transfers to and from Windows servers and
clients. While the need for SMB is quite important, the attack threats of SMB
and NetBIOS greatly increase the security exposures in many Windows networks. While use of NetBIOS with SMB may be appropriate for internal networks, exposure of SMB file sharing to remote users and hostile networks,
such as the Internet, is not. Nevertheless, although SMB over the Internet is not
appropriate, remote users still need access to corporate file servers, including
Windows file servers. Secure remote access is where SSH can be used for
secure file access.
In addition to SMB, NFS (over TCP) also is exposed to many security threats
in an organization. NFS is a clear-text protocol. Authentication information, as
well as payload information, can be sniffed from this protocol. Also, as with
SMB, NFS is dangerous to use in hostile networks such as the Internet. NFS
vulnerability attacks are abundant; therefore, any use of this protocol can significantly increase the security risk of your organization. Nevertheless, as with
SMB, the security vulnerabilities with NFS do not make the desire to gain
remote file access over hostile networks any less demanding. While the security threats may be high with this protocol, the demand for remote file access
needs to be met. This is also where SSH can be used for secure file access.
The use of SSH can help mitigate some of the issues with vulnerable or
clear-text file transfer protocols by using port forwarding with an SSH server
to tunnel the SMB and NFS protocols over the Internet inside an SSH tunnel.
This not only protects against security attacks and unauthorized sniffing but
also offers the ability to enforce two-factor authentication with the SSH connection, thus increasing the overall security of the file transfer architecture.
In this section, I will demonstrate how to implement an SSH architecture
with port forwarding to support secure file transfer. The architecture I will be
using is shown in Figure 7.9.
Figure 7.9 shows an SSH server, listening on port 22 (SSH), and two internal
file servers. The two file servers include a Windows 2000 file server, listening
on port 445 (SMB over TCP), a Sun Solaris NFS file server, listening on port
2049 (NFS over TCP) and port 1026 (mountd). The SSH server is located in
Internet DMZ off the perimeter firewall, segmented from the internal network.
The corporate file servers are located inside the internal network, fully accessible to internal employees for file access.
The second example will assume that the SSH server is a Windows machine
running VanDyke Softwares VShell SSH server, that the SSH client is SSH
Communications SSH2 client running on a Unix platform for the road warriors, and that the file transfer clients are smbclients for SMB and mount for
NFS. Any SSH server or SSH client can be used. The example is a random
selection from the different SSH applications I have discussed thus far.
239
Internet
Administrators @home
Road Warriors at
client sites (LANs) or hotels
Router
445
Windows 2000
File Server
172.16.1.100
Firewall
22
SSH Server
11.30.11.21
Internal
Network
Sun Solaris
NFS File Server
172.16.1.150
2049
1026
240
Chapter 7
RULE
NUMBER
SOURCE
DESTINATION
SERVICE
ACTION
Any
SSH-Server
Port 22
Allow
SSH server
Port 445
Allow
SSH server
Port 2049
Port 1026
Allow
Any
Any
Any
Deny
241
242
Chapter 7
4. Since typing that very long command will become tedious over time,
create a configuration file for your local port-forwarding options:
a. Open a blank file (using Vi or Emacs, whichever you like. I recommend Vi, but you Emac lovers are outnumbering us Vi lovers).
b. Enter the following lines into the file. These lines specify the local
port-forwarding options:
LocalForward
LocalForward
LocalForward
445:172.16.1.100:445
2049:172.16.1.150:2049
1026:172.16.1.150:1026
Thats it! To verify that the SSH connection has executed the port forwards,
type netstat an on port 445, 2049, and 1026 should be listening on the local
interface, as shown in Figure 7.10.
Figure 7.10 Ports 445, 2049, and 1026 listening on the road warriors Unix system.
After the SSH client has been completely configured, the file server clients
are ready for the secure file server architecture.
243
244
Chapter 7
Figure 7.12 Local port-forwarding connections listening on ports 445, 2049, and 1026.
smbclient has very simple syntax: -U is for the username; -p is for the port
number. This command will connect to the local port on 445 and then be forwarded by the SSH session. After the connection reaches the Windows file
server, you should be prompted for a password. Use your Windows file server
password given to you by your Windows administrator and log in. After you
have entered the correct password, you will now be able to upload and download files from the Windows file server using simple Get and Put commands.
The results should look like Figure 7.13.
Figure 7.13 The results of file sharing with SSH with SMB and smbclient.
Notice a couple of things about Figure 7.13. First, observe that the connection is to the loopback interface. Second, check out the password prompt by
the remote Windows file server, which is still over the SSH tunnel. (This solves
problems of NTLM weaknesses also, which will not be discussed here.) Lastly,
mark the get file.txt command, which downloads the file called file.txt from
the remote Windows file server to the local Unix laptop, all over the encrypted
SSH session.
Once the change has been made and the services have been restarted, establish the session with the SSH server. Once the session has been established,
you can attempt to log in to the Solaris NFS file server. To transfer files to and
from the /home NFS share on the Solaris NFS file server, type the following
command:
#mount t nfs o tcp,port=2049 ,mountport=1026 127.0.0.1:/home /nfsmount
Mount is the actual protocol to access the NFS server, using port 1026 in this
example. The mount command has very simple syntax, where the IP address
of the NFS server is separated by a colon to the NFS share, followed by the
local path to mount the remote NFS share, such as /nfsmount in this example.
This command will connect to the local port on 2049 and 1026 and then be forwarded by the SSH session. After the connection reaches the Solaris NFS file
server, the NFS server will verify that you are allowed to mount this NFS
share. After it verifies you, the remote NFS share should be mounted to /nfsmount on your local Unix operating system.
245
246
Chapter 7
This scenario allows you to use NFS over an encrypted SSH tunnel over the
Internet.
N OT E All file sharing in the preceding examples, including SMB and NFS, will
use the native protocols from the SSH server to the file servers; however, the
file transfer protocols (SMB and NFS) will be encrypted in an SSH tunnel over
the Internet.
Congratulations! You have just implemented a secure file transfer architecture over the Internet.
Router
Linux
VNC Server
10.1.0.150
Windows 2000
Terminal Server
10.1.0.100
Firewall
Internal
Network
3389
Internet
5901
Administrators @home
22
SSH Server
11.30.11.21
5631
5632
pcAnywhere
10.1.0.200
248
Chapter 7
The third example will assume that the SSH server is a Unix machine running
SSH Communications SSH server, that the SSH client is SecureCRT running on
a Windows platform for the remote administrators, and that the management
clients are a Terminal Services client, VNC client, and a pcAnywhere client.
N OT E Any SSH server and SSH client can be used; my example is a random
selection from the different SSH applications I have discussed thus far.
RULE
NUMBER
SOURCE
DESTINATION
SERVICE
ACTION
Any
SSH server
Port 22
Allow
SSH server
Windows Terminal
server
Port 3389
Allow
SSH server
Port 5901
Allow
SSH server
Allow
Any
Any
Deny
Any
249
250
Chapter 7
Now that the terminal services local port-forwarding option is set up, the
Linux VNC server local port-forwarding option can be set.
21. Select Add to display the Port Forwarding options.
22. Enter VNC Server for the Name field.
23. In the Local subsection, make sure Manually select local IP address on
which to allow connections is unchecked.
24. In the Local subsection, enter 5901 for the Port field.
25. In the Remote subsection, make sure Destination host is different from
the SSH server is checked.
a. Enter 10.1.0.150 for the Hostname field.
26. In the Remote subsection, enter port 5901 for the Port field.
27. In the Application subsection, you can either leave it blank or enter the
path for the VNC client. If you decide to put in the path, it will execute
the VNC client automatically. If you leave it blank, you will have to execute the VNC client manually.
28. Select OK.
Now that the VNC local port-forwarding option is set up, the pcAnywhere
local port-forwarding option can be set.
29. Select Add to display the Port Forwarding options.
30. Enter pcAnywhere for the Name field.
31. In the Local subsection, make sure Manually select local IP address on
which to allow connections is unchecked.
32. In the Local subsection, enter 5631 for the Port field.
33. In the Remote subsection, make sure Destination host is different from
the SSH server is checked.
a. Enter 10.1.0.200 for the Hostname field.
34. In the Remote subsection, enter port 5631 for the Port field.
35. In the Application subsection, you can either leave it blank or enter the
path for the pcAnywhere client. If you decide to put in the path, it will
execute the pcAnywhere client automatically. If you leave it blank, you
will have to execute the pcAnywhere client manually.
36. Select OK.
Since pcAnywhere requires two ports, you will have to add a second local
port forward.
37. Select Add to display the Port Forwarding options.
38. Enter pcAnywhere2 Server for the Name field.
39. In the Local subsection, make sure Manually select local IP address on
which to allow connections is unchecked.
40. In the Local subsection, enter 5632 for the Port field.
41. In the Remote subsection, make sure Destination host is different from
the SSH server is checked.
a. Enter 10.1.0.200 for the Hostname field.
42. In the Remote subsection, enter port 5632 for the Port field.
43. You can leave the Application subsection blank.
44. Select OK.
The result should look like Figure 7.15.
After the SSH client has been completely installed, the management clients
are ready for the secure management architecture.
251
252
Chapter 7
Figure 7.17 Local port-forwarding connections listening on port 3389, 5631, 5632, and 5901.
253
254
Chapter 7
Once the utilities are loaded, you will be able to drag and drop files from the
terminal services session to your local machine over the SSH tunnel, making
remote management and file transfer available with just one shot. The results
should look like Figure 7.19.
Notice the 127.0.0.1 address in the upper left-hand corner in Figure 7.19.
Also, notice the results of the ipconfig command, which show the internal
address of the Windows terminal server. At this point, any usage of the operating system can be done, including managing other operating systems, from
this terminal, which occurs over a secure and encrypted SSH tunnel.
This scenario allows you to use Windows terminal services over an encrypted
SSH tunnel over the Internet.
This command connects the vncviewer client on port 5901 to the localhost.
3. Select OK.
Once vncviewer connects to the loopback address on port 5901, the SSH
connection will forward that request to the Linux VNC server over the encryption SSH tunnel. After the connection reaches the Linux VNC server, you
should see the login display and be prompted for your session password, as
shown in Figure 7.20.
255
256
Chapter 7
Notice that the loopback interface is used in Figure 7.20. In order to log in, you
need to use your VNC server password given to you by your VNC administrator, shown at the bottom of Figure 7.20. After you have entered the correct password, you will view the desktop and have access to the operating system as if
you were in front of the computer itself. The results should look like Figure 7.21.
Figure 7.21 The results of the Linux VNC server with SSH.
HKLM\SOFTWARE\Symantec\pcANYWHERE\
CurrentVersion\System
Value Data: 1
4. After making the registry changes on both the pcAnywhere server and
pcAnywhere client, reboot both machines.
5. On the pcAnywhere client machine, open pcAnywhere. Enter Start
Programs pcAnywhere.
6. Select the Remotes button.
7. Enter File New.
8. Select the Setting tab.
9. Enter 127.0.0.1 for the Network host PC to control or IP address:
option, as shown in Figure 7.22.
257
258
Chapter 7
259
Chapter 7
SSH/PPP Server
11.30.11.21
(ssh.ppp.server.com)
SSH/PPP Client
72.12.8.15
22
260
Internal
Network
Internet
Router
Firewall
In the architecture shown in Figure 7.24, the SSH server is also the PPP
server, which is a Linux RedHat 8.0 server running OpenSSH. Furthermore,
the client in the example is a regular RedHat 8.0 client machine, with no services installed or running. No special changes are required on the firewall,
except a rule that allows connections on port 22 to the SSH/PPP server. Once
an SSH/PPP client makes that connection, it will have a VPN inside the internal network.
If you see something similar to the following on the server, you know that
the PPP daemon is working correctly. The PPP daemon spits out information
to the screen that is not readable to end-users, but actually confirms that the
PPP daemon is running correctly. The following is just an excerpt from the output of the PPP daemon:
~ }#_!}!}!} }4}}&} } } } }%}&}-1L}}}(}e~~ }#_!}!}!} }4}}&} } } }
L}}}(}e~~ }#_!}!}!} }4}}&} } } } }%}&}-1L}}}(}e~~ }#_!}!}!}
}4}}&} }} } }%}&}-1L}}}(}e~~ }#_!}!}!} }4}}&} } } } }%}&}
1L}}}(}e~~ }#_!}!}!} }4}}&} } } } }%}&}-1L}}}(}e~~ }#_!}!}!}
To verify that su and sudo work correctly and have been configured appropriately, type the following commands on the server:
#su vpnmonkey
#sudo /usr/sbin/pppd noauth
If things are working correctly under sudo, you should see the following on
the server, which is the PPP daemon spitting out information to the screen that
is not readable to end-users, but actually confirms that the PPP daemon is running correctly. The following is just an excerpt of the output of the PPP daemon:
~ }#_!}!}!} }4}}&} } } } }%}&}-1L}}}(}e~~ }#_!}!}!} }4}}&} } } }
L}}}(}e~~ }#_!}!}!} }4}}&} } } } }%}&}-1L}}}(}e~~ }#_!}!}!}
}4}}&} }} } }%}&}-1L}}}(}e~~ }#_!}!}!} }4}}&} } } } }%}&}
1L}}}(}e~~ }#_!}!}!} }4}}&} } } } }%}&}-1L}}}(}e~~ }#_!}!}!}
Client Script
Next, you must configure a script on the VPN client to use SSH for the PPP
connection. This script was originally created on www.linuxorg.org by
authors of that site.
Before editing the script, you must define the variables that will need to be
customized according to the architecture. According to Figure 7.24, your
server hostname will be ssh.ppp.server.com, your server username will be
261
262
Chapter 7
#
# You will need to change these variables...
#
# This tells ssh to use unprivileged high ports, even though its
# running as root. This way, you dont have to punch custom holes
# through your firewall.
LOCAL_SSH_OPTS=-P
#
# The rest of this file should not need to be changed.
#
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11/:
#
# required commands...
#
PPPD=/usr/sbin/pppd
SSH=/usr/bin/ssh
if ! test -f $PPPD
if ! test -f $SSH
exit 3; fi
exit 4; fi
case $1 in
start)
# echo -n Starting vpn to $SERVER_HOSTNAME:
${PPPD} updetach noauth passive pty ${SSH} ${LOCAL_SSH_OPTS}
${SERVER_HOSTNAME} -l${SERVER_USERNAME} -o Batchmode=yes sudo ${PPPD}
nodetach notty noauth ipparam vpn ${CLIENT_IFIPADDR}:${SERVER_IFIPADDR}
# echo connected.
;;
stop)
# echo -n Stopping vpn to $SERVER_HOSTNAME:
PID=`ps ax | grep ${SSH} ${LOCAL_SSH_OPTS} ${SERVER_HOSTNAME} l${SERVER_USERNAME} -o | grep -v passive | grep -v grep | awk
{print $1}`
if [ ${PID} != ]; then
kill $PID
echo disconnected.
else
echo Failed to find PID for the connection
fi
;;
config)
echo SERVER_HOSTNAME=$SERVER_HOSTNAME
echo SERVER_USERNAME=$SERVER_USERNAME
echo SERVER_IFIPADDR=$SERVER_IFIPADDR
echo CLIENT_IFIPADDR=$CLIENT_IFIPADDR
;;
*)
echo Usage: vpn {start|stop|config}
exit 1
;;
esac
exit 0
263
264
Chapter 7
Save the script as wee-pee-en, or whatever you wish, and make it executable
(chmod a+x wee-pee-en). After the script is executable, enter the following
command on the client to use the wee-pee-en script and access the SSH/VPN
server over a trusted VPN connection:
#wee-pee-en start
If all goes well, you should see the following on the client:
Using interface ppp1
Connect: ppp1 <--> /dev/pts/1
local IP address 11.30.11.21
remote IP address 72.12.8.15
Thats it! This scenario allows anyone to use a PPP over an encrypted SSH
connection to create a secure VPN session over the Internet.
Summary
Using some of the basic techniques discussed in the last chapter, combined
with some advanced techniques described in this chapter, has allowed us to
use SSH as a fully fledged remote access solution that can support popular
remote access demands, such as e-mail, file transfer, and management. While
the configurations of each of these remote access demands slightly differ, the
basic principles of port forwarding apply to each of them.
Port forwarding is a powerful and very useful feature of SSH that almost
overshadows the terminal access that it provides. In fact, many SSH solutions
deployed in networks today are being deployed more for their port-forwarding
capabilities than for their remote terminal access capabilities. Furthermore, the
flexibility of SSH, which allows it to be used from both NATd networks and
non-NATd networks, makes it a very attractive remote access solution that
can support end-user security in any type of network environment, whether it
is from a hotel room, a home office, a customer site, a data center, or even a
wireless network at your local coffee shop.
The use of other applications, such as Outlook Express, Netscape Messenger, and Eudora, with SSH allows SSH to mitigate and solve security concerns
in other entities. In addition to securing other applications, the use of SSH with
existing, required, or standard protocols, such as SMB and NFSallow, allow it
to interoperate with existing networks quite easily with little to no effect on the
end-user. Lastly, its ability to support GUI applications allows SSH to provide
a truly secure remote management solution for the remote administrator.
Basic port forwarding and advance techniques allow SSH to be a fully functional and very inexpensive remote access solution that cannot be matched
with any other service, device, or protocol. Now that you fully understand
port forwarding, I will shift gears to other uses of SSH, such as general protocol replacement. In the next chapter, I will discuss how SSH should be used
instead of various other dangerous protocols, such as insecure R protocols.
265
PA R T
Three
Protocol Replacement
CHAPTER
8
SSH Versatility
SSH is a very versatile utility. Aside from all the uses I have discussed thus far,
SSH also provides the following functionality in a secure manner:
Terminal access
Secure chat
Secure backups
This chapter discusses many of the versatilities of SSH. Some of the utilities
previously listed are basic and come installed with a default installation of
SSH, such as terminal access and file sharing with the Secure File Transfer Protocol (SFTP). SSH can be used in conjunction with other utilities listed previously that are common in many network architectures but not necessarily
secure, such as chat and backups.
This chapter demonstrates how SSH can be used to replace several other
protocols, many of which are insecure protocols that greatly decrease the security posture of a network environment. For example, SSH can be used to
replace the dangerous protocols listed in Table 8.1.
269
270
Chapter 8
Table 8.1
SSH UTILITY
PROTOCOL
SFTP
IRC
RSync
Terminal Access
One of the most basic uses of SSH that I have only implied thus far is SSH terminal access. One of the primary reasons to install SSH is to provide secure terminal access. In order to replace the dangerous Berkeley R-protocols such as
RSH and Rlogin, SSH needs to be used. Furthermore, if other terminal emulators such as Telnet are used in addition to the Berkeley R-protocols, the level of
security across a network environment will be greatly reduced. SSH not only
provides the same level of access that RSH, Rlogin, and Telnet do, but it does
so in a secure manner through two-factor authentication, advanced authorization, and strong encryption.
SSH is often deployed for its secure terminal access, aside from the other
features such as port forwarding and SFTP discussed in the next section. When
dealing with remote management issues across the Internet or even insecure
internal networks, Telnet, RSH, rexec, and Rlogin can and will cripple an organizations security infrastructure by allowing any passive user from gaining
access to sensitive information, such as usernames, passwords, directory
structures, and so on.
For example, RSH, Rlogin, and Rexec are clear-text protocols that provide
some type of remote terminal emulation or remote execution service. All three
of these protocols can be sniffed with any traffic analyzer that can reveal
authentication and authorization information to an unauthorized user. This
can potentially allow unauthorized users to gain access to sensitive authentication information and either log in to systems and/or devices or execute
remote commands in an unauthorized fashion.
SSH Versatility
The following examples show a traffic analyzer program that will sniff the
connections among four protocols: RSH, Rlogin, Rexec, and finally the SSH
connection. The examples show how the use of three insecure protocols basically provides no security and how the use of SSH not only brings a great deal
of security, but also provides the same level of functionality. The architecture
for the example is shown in Figure 8.1.
RSH
RLOGIN
REXEC
SSH
Client
Server
Figure 8.1 Sample architecture for terminal access with RSH, Rlogin, Telnet, and SSH.
271
272
Chapter 8
SSH Versatility
273
274
Chapter 8
SSH Versatility
275
276
Chapter 8
SSH Versatility
This overview will allow you to understand the general uses of SFTP and
also allow your decision-making process to be as informed as possible,
depending on your business and security requirements for SFTP.
If the SFTP is not desired and only the use of the SSH service (shell or port
forwarding access) is desired, the SFTP subsystem can be easily disabled by
commenting out the Subsystem SFTP line. For example, in order to disable
the SFTP subsystem in OpenSSH, make sure the last two lines of your
sshd_config file look like the following:
# override default of no subsystems
# Subsystem sftp
/usr/libexec/openssh/sftp-server
Since you want to use the SFTP subsystem, make sure it is enabled (uncommented) in your /etc/ssh/sshd_config file. Now that you understand how to
enable/disable the SFTP subsystem, examine the different ways you can use it
with OpenSSH.
277
278
Chapter 8
#sftp 172.16.11.17 p 22 l <username>
#get CommodoreVic20.txt
#exit
Similarly, to upload a file to the SSH server, such as a file called Pitfall.txt,
enter the following commands:
#sftp 172.16.11.17 p 22 l <username>
#put Pitfall.txt
#exit
As with FTP, the command-line SFTP client will download or upload files to
and from the clients local directory; however, it will be conducted over an
encrypted session. In this case, OpenSSH is a very strong alternative for general management purposes for most organizations. Root-level users cannot
only log in to an OpenSSH server for command-line access, but they can use
the SFTP subsystem to transfer important and sensitive files and directories in
a secure and easy fashion.
SSH Versatility
placed on either operating system, an SFTP client might be capable of traversing outside the desired SFTP folder through the use of symbolic links on the
system or just plainly having those rights inertly form the operating system
itself.
No matter whether SSH is used for management purposes or for file-sharing
purposes, file access controls should be in place to restrict users to only their
home directory or a defined SFTP folder. To place appropriate file access controls, you need to use operating-system utilities as opposed to SSH utilities.
Tools such as chmod for Unix and Cacls.exe for Windows can be used to place
permission on individual files and folders. As you may have already guessed,
this endeavor can be an exhaustive challenge, since all the sensitive files for an
entire operating system need to be protected. Furthermore, some files, such as
/etc/passwd, need to be readable to all accounts on the system, whether they
are root-level accounts or just regular user accounts, which may not be the
ideal situation.
Since there is no function with OpenSSH to restrict SFTP access to a limited
number of files, aside from the operating systems access control, OpenSSH is
a very moderate solution for general file sharing for low-level or nonroot/non-admin level users. Since file-sharing servers will need to provide
access to several users and protect the operating system itself from these users,
using OpenSSHs SFTP subsystem will be a cumbersome process.
279
280
Chapter 8
only need access to their home directory, without using the SFTP subsystem
as a file server but rather as a complementary tool to SSH terminal access,
OpenSSH is a strong alternative.
For example, say the Engineering Department regularly needs to transfer
files, such as compiled binaries, source code, or configuration files, to and from
the home directory. If they are using SSH for secure terminal access, transferring
files with NFS, FTP, or even remote copy (RCP) would be counterproductive.
The security they would gain from the encrypted SSH connection would be cancelled out by the insecurity of the NFS, FTP, and RCP sessions. In this scenario,
the OpenSSH SFTP subsystem is a great alternative to NFS, FTP, and RCP.
Unlike the SFTP file-server model, SFTP does not add insecurity to the operating
system, since all the accounts on the system are using the operating system itself,
which includes all the directories, binaries, and configuration files, not just
accounts that should have access to one folder on the system, which is more difficult to restrict. In other words, all these accounts are authorized to roam
around the operating system according to their account type, which includes
viewing files from the command line or transferring files from SFTP.
While all SFTP users are redirected to the e:\ volume, which may be the core
SFTP directory, they are not restricted to e:\. This means that while the users
SFTP shell will begin at e:\, if they specify that they would like to access c:\
with their SFTP client, they will be allowed access to c:\, given that they have
the NTFS permissions to do so. This reason, among several others, is why the
author of the OpenSSH port to Windows stresses the fact that it should only be
used for administrative purposes, since file-system security is enforced not by
the OpenSSH SFTP subsystem but by the native NTFS permissions on the
operating system.
SSH Versatility
281
282
Chapter 8
5. Specify the port number in the Port Number field; the default is 22.
6. Select Password for the Authentication Method.
7. Select Connect.
8. Enter the correct password when prompted by the SFTP client.
9. Thats it! You can now drag and drop files to/from the SFTP server
with a Windows Explorer type of client. All files transferred from the
SFTP client to the SFTP server, using drag and drop, copy and paste, or
the option in the menu bar, are all encrypted.
Similarly, to upload a file to the SSH server, you can use the drag-and-drop,
copy-and-paste, or the menu bar options.
As with FTP GUI clients, the GUI SFTP client can download or upload files
to and from the clients local directory to and from the SSH server using a
encrypted session. In this case, VShells SFTP server is a very good solution for
general management purposes for most organizations. Administrator-level
users can log in to an SSH server for command-line access and also use the
SFTP subsystem to transfer important and sensitive files and directories in a
secure and easy fashion.
SSH Versatility
case, the SFTP access control features of VShell should be used. In order to
allow access to only the d:\share folder, which can be the root directory on the
corporate file server, to all accounts on the system, complete the following
steps:
1. Go to Start Programs VShell VShell.
2. Highlight the SFTP section.
3. Under SFTP options, select Add.
4. For the SFTP root field, type d:\share or simply browse to it using the
... button.
5. Type CorpFileServer for Alias.
6. Select Add on the right hand section.
7. Add the Everyone group.
8. Choose OK.
9. Select Apply.
Now all accounts on the operating system, or the domain, can have SFTP
access to the D:\share directory. In order to ensure that access to the rest of the
operating system is denied, complete the following steps:
1. Highlight the <Unrestricted> option in the SFTP section and select Edit.
2. Remove all accounts, including Everyone and any other accounts that
exist.
3. Enter any accounts, such as the administrator account, that you would
like to provide full SFTP access to the system. If no accounts need to be
added, select OK.
4. Select Apply.
Now no accounts, or only the administrator account, have unrestricted
access. Furthermore, every other account on the system or domain only has
access to D:\share, despite whatever NTFS permissions that account has. The
VShell access control lists override the NTFS permissions on the VShell server
when using SSH or SFTP subsystem. Figures 8.6 and 8.7 show the final result.
283
284
Chapter 8
Figure 8.6 VShell SFTP file-server permission for the Everyone group.
Figure 8.7 VShell SFTP file-server permission for the Administrators group.
SSH Versatility
want to allow everyone to have access to the SSH server as a corporate file server
only, using the SFTP subsystem, but no command-line or port-forwarding
access, this can be easily set with VShell by performing the following steps:
1. Choose the Access Control section.
2. Click Add.
3. Select the Everyone group and select OK.
4. Keep the Everyone group highlighted, and select Logon and SFTP for
the Allow permissions.
5. Keep the Everyone group highlighted, and select Shell, Remote Execution, Port Forwarding, and Remote Port Forwarding under the Deny
permissions.
6. Select Apply.
Now all accounts on the operating system or domain can access only the
SFTP subsystem, with no access to the command prompt or port forwarding.
Figure 8.8 shows the configuration settings.
As with the SFTP section, you can still allow the administrator account to
have access to everything, if you want it to. Figure 8.9 shows the administrator
account configuration settings.
285
286
Chapter 8
Encryption
Security
SSH Versatility
287
288
Chapter 8
SSH Versatility
289
290
Chapter 8
Now all accounts only have access to d:\share using SFTP, despite their
NTFS permissions. The SSH Communications SSH server access control lists
override the NTFS permissions on the SSH server when using SSH or SFTP
subsystem. In addition to general user access, you may want to allow the
administrator account, or equivalent power users, more access via SFTP. In
order to provide power users with more access, while still restricting general
SFTP users to the stated virtual directory, complete the following steps:
1. Highlight the Power Users section under SFTP server.
2. Select the Insert icon to add directories.
3. Type C:=C: and D:=D:.
4. Select Apply.
5. In the Power Users textbox, type administrator (or any other account
you wish to grant further access).
6. Select Apply.
Now the administrator account has full SFTP access to the SSH server, while
general users are still restricted to the d:\share directory, as shown in Figure 8.11.
SSH Versatility
Unlike VShell, SSH Communications SSH server does not provide such
specific access to the SFTPsubsystem. For example, if you want to allow all
users access to the SFTP subsystem only but no shell access, there is no obvious way to implement that with SSH Communications SSH server version
3.2.3. While you can allow or deny user accounts or hosts via the SSH server, it
is an all-or-nothing value, without specific options such as SFTP only. This
makes SSH Communications SFTP subsystem a little better than OpenSSH,
but it offers less control than VShell. For example, using SSH Communications SSH server, certain directories of the operating system can be exposed to
SFTP users, thus restricting access to sensitive directories such as winnt\system32. Furthermore, advanced power users can have more access than the
general accounts, granting a greater level of directory access. Nevertheless, in
a corporate file-server model, command-line or port-forwarding access to the
SSH server is highly undesirable and a security threat. Under the default
installations of SSH Communications SSH server, there is no easy way to
restrict certain users to SFTP only while allowing others access to both SFTP
and terminal sessions.
SSH Communications SSH server offers the ability to restrict operatingsystem accounts to only specific directories using SFTP without the need for
NTFS permissions. But it does not offer other restrictions on command-line or
port-forwarding access. So, while it still may be a good solution for SFTP,
291
292
Chapter 8
maybe it is not the best for a file server. Nevertheless, it is a very excellent solution for general file sharing for all users or corporate file servers. For more
information on secure file servers, see Chapter 10.
SSH Versatility
Table 8.2
MANAGEMENT
FILE
SHARING
AUTHORIZED
USERS
OpenSSH Installed
by default
Ability to upload/
download files
securely
Ability to allow
or deny desired
accounts only
VanDyke
Software
VShell
server
Ability to upload/
download files
securely
Ability to allow
or deny desired
accounts only
SSH
Installed by Ability to upload/
Commu- default
download files
nications
securely
SSH
server
Ability to allow
or deny desired
accounts only
Installed
by default
Secure Chat
The use of chat is becoming an increasingly popular tool in network environments. While chat was first used for local office gossip with a neighbor, it is
now being used to communicate legitimate corporate information among
employees. Chat offers great flexibility by allowing employees to work with
one another in an easy, simple, and, most important, quick fashion to get more
work done.
293
Chapter 8
Now that chat is more of a mainstream tool for business operations, the traversing of sensitive information between employees over an insecure channel
is not acceptable. For example, if a group of engineers is working on a piece of
code and participants need to send sample snippets of code to one another
using chat, an unauthorized user has the ability to capture that data, because
most chat programs use clear-text communication. Furthermore, chat can also
be used to transfer account information such as passwords, network information such as an IP address, and other sensitive information that should not be
disclosed to unauthorized users.
To use chat in organizations without affecting the integrity of the data, consider using SSH with chat. Chat with SSH will not be addressing popular
instant messaging programs such as AOL, MSN, or Yahoo!, since these programs use their own TCP ports that can just be port-forwarded over SSH for
security. Just like e-mail, file transfer, and management can be port-forwarded,
as you see in Chapters 6 and 7, any protocol, such as that used with AOL,
MNS, or Yahoo!, can also be port-forwarded in a similar manner. The discussion in this section will be limited to the use of chat in internal networks without the need for port forwarding. In the architecture for this example, IRC
servers run on common Unix shells and use that server as the chat interface.
Figure 8.12 shows the example architecture.
Internal
Network
22
294
SSH/Chat Server
172.16.6.100
Client: Neeraja
172.16.6.12
Client: Shreya
172.16.6.21
Client: Kusum
172.16.6.17
SSH Versatility
Secure chat with SSH uses the SSH server as the chat server also. So when
users connect to the SSH server and gain access to a shell, they can execute
their IRC client on the SSH shell and be connected to the IRC server, which is
running locally on the SSH server. Once the user is connected, he will have a
chat session under his SSH shell, which is all encrypted over the network.
Complete the following steps to create a secure chat solution with SSH and
your favorite IRC server:
1. Install SSH on 172.16.6.100.
2. Install your favorite IRC server on 172.16.6.100.
3. Create accounts for all three users on the chat server, including Kusum,
Shreya, and Neeraja.
295
Client: Shreya
172.16.6.21
Client: Kusum
172.16.6.17
Insecure
Connection
IRC Server
172.16.6.100
Client: Neeraja
172.16.6.12
Client: Shreya
172.16.6.21
Internal
Network
Figure 8.13 Insecure IRC architecture without SSH (left) and secure IRC architecture with SSH (right).
Client: Neeraja
172.16.6.12
Internal
Network
Client: Kusum
172.16.6.17
Secure
Connection
SSH/Chat Server
172.16.6.100
IRC Connection
296
Chapter 8
SSH Versatility
Secure Backups
Conducting backups in a network environment can be a very tricky item in
terms of security. Many organizations deploy encryption on data networks
such as SSH, IPSec, or SSL in order to protect sensitive data. The same organizations, however, may then conduct their backup architecture over a clear-text
protocol. In fact, many organizations forget to realize that backup networks
may be more sensitive than data networks, since they are direct repositories
for data, without the need to compromise a single server.
A popular method for backing up data in a network environment is Rysnc.
Rysnc is a protocol that offers an incremental file transfer and update process
(backup) from one entity to the next. Rsync offers the ability to transfer only
the differences of files between two entities in a given network, using a checksum process. These two items, combined with many others, make Rsysnc a
very attractive tool in a backup architecture.
While there are many benefits to using Rsync in a backup architecture,
Rsysnc is a clear-text protocol with limited authentication requirements. An
unauthorized user can capture the Rsysnc process and gain access to data,
account information, or even passwords. Therefore, in order to deploy a secure
backup architecture, SSH should be used in combination with Rsync. Rsync
with SSH will provide all the efficiencies and features that make Rsync so
attractive, but will also provide encryption and public-key authentication, mitigating two of the top-most security concerns with Rsync, which are clear-text
communication and limited authentication. The use of SSH with Rsync will
not only encrypt all communication between two entities, eliminating the ability for an unauthorized user to compromise and steal the Rsync communication process, but also implement public-key authentication, making it very
difficult for an unauthorized client to compromise the weak authentication
requirements of Rsync. The following section discusses the procedures to
implement a secure backup solution with Rsync and SSH.
Figure 8.14 shows the Rsysnc/SSH architectural example I will be using for
this section. The two servers are both Unix machines using OpenSSH. Notice
that there are two servers, one used for productions and one used for backups.
The production machine will be using Rsync with SSH to transfer files to the
backup server, which has an Rsysnc daemon listening on it.
297
298
Chapter 8
Production Server
Neeraja
192.168.10.21
Backup Server
Kusum
192.168.10.17
Complete the following steps to set up secure backup with Rsync and SSH:
1. Ensure that OpenSSH and Rsysnc are installed on the backup server.
Ports 22 (SSH) and 873 (Rsync) should be listening on the backup
server, if both daemons have been started.
2. Create a public and private-key pair on your backup server. You will
be using public and private keys to authenticate to the backup server,
instead of using usernames and passwords. Because this backup
procedure will be automated, do not enter a passphrase for the private
keys. You will be creating a DSA key pair (-t option), using 1024 bits
(-b option), with a blank passphrase (-N option):
[root@kusum]#ssh-keygen t dsa -b 1024 N
3. When asked to enter the file in which to save the key, enter backup.
4. Once the key has been created, you should have a backup.pub and
backup file.
5. Copy backup.pub from the backup server to the production server,
specifically in the production servers root directory (the user must be
root to do this). Make an .ssh folder and concatenate the contents of the
backup.pub file to the authorized keys files. (Chapter 4 discusses in
detail public-key authentication with SSH.) The following are the
contents:
[root@neeraja]#cd /root
[root@neeraja]#mkdir .ssh
[root@neeraja]#cat backup.pub > ./ssh/authorized_keys
[root@neeraja]#chmod 600 .ssh
6. The basics have now been set up! Now the rsync command can be used
to conduct the backups. The e option is a flag with Rsync to use SSH
as the encryption communication between the two entities. Unlike
other SSH usages, you dont need to use a subsystem or port forwarding with Rsysnc, but it is actually built in as an optional tool. Be sure to
SSH Versatility
7. Secure backup has now been implemented with SSH. In order to automate the process, enter a Cron job (automated scheduler) to execute the
secure backup procedure:
[root@neeraja]#crontab e
10 * * 0 /usr/bin/rsync p a e ssh/usr kusum:/usr
8. In addition to Rsync, tar can be used to back up files via SSH by using a
slightly different format. For example, to back up users home directory
on the production server (neeraja) to the backup server (kusum) using
tar, enter the following command:
[root@neeraja]#ssh kusum tar cfz - /home > /tmp/home.tar.gz
Summary
This chapter discusses the versatility of SSH. Whether you are using SSH for
secure terminal access, in order to replace RSH or Rlogin, for secure file transfer, in order to replace FTP, SMB, or NFS, for secure chat, in conjunction with
IRC, or as a secure backup solution, in conjunction with Rsync, there is no
doubt that SSH is a very versatile tool. Consider that other utilities or protocols
such as RSH, Rlogin, SMB, FTP, NFS, Rsync, and IRC have very little in common; however, all of those protocols can be replaced with a single installation
of SSH.
The versatility of SSH, combined with its strong encryption capabilities, its
strong authentication capabilities, and even its strong authorization and
integrity capabilities, makes it a powerful solution for several items, including
terminal access, file transfer, chat, and backups. This chapters focus is to
demonstrate the flexibility of SSH using different vendor implementations, as
well as to explore the lesser-known uses of SSH, such as secure chat and secure
backup.
The core point to learn from this chapter is that the versatility of SSH can
mitigate several of the security issues in your network while providing a solution for many core business functions, all with a single tool. While using a single version of SSH may not be desired due to capacity requirements, using a
single application that serves several purposes can help your complex environment become simpler and thus more secure. The ability to patch, maintain,
and support a single application across several systems is more manageable
299
300
Chapter 8
CHAPTER
9
Proxy Technologies in a
Secure Web Environment
The use of proxy servers in any network environment can simplify the operating environment for end-users. A proxy server is an application that places a
request on behalf of another entity. Most proxy servers in use today are Web
proxies, where a client machine attempts to access a certain Web server but
sends its request to the Web proxy server. The Web proxy server then sends the
request to the real Web server on behalf of the client. Once the response is
received from the Web server, the proxy server returns the request to the client.
The use of proxy technology can also be adapted to the SSH architecture.
This chapter focuses on the use of SSH, as I have discussed it thus far, in combination with proxy servers, SOCKS, dynamic port forwarding, wireless networks, and secure Web browsing. These topics allow me to demonstrate
another aspect of SSH while demonstrating the ability to optimize and utilize
its flexibility. As a result of this chapter, the use of SSH will expand beyond a
typical implementation into lesser-known methods of deployment, such as
secure Web browsing and secure wireless networks.
Using SSH in combination with proxy technologies allows networks to optimize the strong security features from SSH with multiple devices and operating systems across an organizations architecture. The use of proxy technology
301
302
Chapter 9
allows normally insecure sessions to be secure, while providing a single repository for SSH communication. The focuses of this chapter are the following:
Internet
Router
Firewall
SOCKS
Server
11.17.7.10
11.17.7.14
22
11.17.7.16
22
11.17.7.12
22
Remote Client
22
11.17.7.1
Figure 9.1 shows a remote client outside the internal network. To allow a
remote client to access multiple servers running SSH for management inside
an internal network or DMZ networks, you could create a rule in the firewall
that would allow access to every Web server or even to several hundred internal servers. Or you could use a SOCKS server to proxy all the requests from
the remote clients to the SSH servers, which requires only a single rule in the
firewall that would allow all remote clients to the SOCKS server on port 1080.
Figure 9.2 shows how this operates.
Currently, there are many solutions for SOCKS servers, from large enterprise SOCKS servers, capable of handling many requests, to very small SOCKS
servers, capable of only a limited capacity. For ease of illustration, consider
how to install a very simple SOCKS server. The SOCKS server to be demonstrated is SOCKServ, version 2.0, which can be freely downloaded from
www.geocities.com/SiliconValley/Heights/2517/sockserv.htm#intro. This is
a version 4 SOCKS server. To complete the example described in Figure 9.1, a
SOCKS server needs to be installed on 11.17.7.1, ensuring that SSH is listening
on all destination servers, including 11.17.7.10, 11.17.7.12, 11.17.7.14, and
11.17.7.16; then SSH clients need to be configured to use SOCKS.
303
Chapter 9
Internet
Router
Firewall
22
22
Remote Client
22
SOCKS
Server
22
304
4. Select OK.
5. Select Start.
As shown in Figure 9.3, SOCKServ is now installed and ready for SSH
connections.
To use the SOCKS server for SSH connections with SecureCRT, complete the
following steps:
1. Confirm that a SOCKS version 4 or version 5 server is installed.
2. Open up SecureCRT. Start Programs SecureCRT SecureCRT.
3. From the menu bar, select Options Global Options.
4. Select the Firewall section.
5. For the Type field, select SOCKS version 4 or version 5, depending on
what version you have installed, from the drop-down box.
6. For the Hostname or IP field, enter the IP address or hostname of the
SOCKS server. In this example, it is 11.17.7.1.
7. For the port field, enter the port number you have selected for the
SOCKS server. The default port is 1080.
8. Select OK.
The options should look like Figure 9.4.
305
306
Chapter 9
Now that you have SOCKS set up in your global options, you must configure each of your SSH connections to use the SOCKS firewall. Doing so will
make your SSH request go to the SOCKS server first and will let the SOCKS
server go to the server you requested on your behalf. To configure SSH connections to use the SOCKS server, compete the following steps:
1. Open SecureCRT, if it is not already open. Start Programs
SecureCRT SecureCRT.
2. For new connections, select File from the menu bar and select Quick
Connect. For hostname, be sure to enter the hostname or IP address of
the destination server you wish to reach, not the SOCKS server. For
example, according to Figure 9.1, you could enter 11.17.7.10, 11.17.7.12,
11.17.7.14, or 11.17.7.16.
3. Select the checkbox that states Use firewall to connect.
4. For existing saved connections, select File from the menu bar and select
Connect.
5. Highlight the connection you wish to edit; then right-click and select
Properties. Be sure to select the connection of the destination sever you
wish to reach, not the SOCKS server. For example, according to Figure
9.1, you could select 11.17.7.10, 11.17.7.12, 11.17.7.14, or 11.17.7.16.
6. The Connection section should have information about your saved
connections.
7. In the right-hand pane, select the checkbox that states Use firewall to
connect.
8. Select OK.
The options should look like Figure 9.5.
Again, be sure to keep the IP address and hostname fields to your desired
destination server. Once the checkbox has been selected to use the firewall
option, the SOCKS entry in your global settings will direct your connections to
the SOCKS server, which will carry your request to the specified hostname or
IP address that you have specified in your connection request. Once the setup
has been completed, you should be able to use your SOCKS server, with a single firewall rule, to access any appropriate SSH enabled server.
To use the SOCKS server for SSH connections with SSH Communications
SSH client, complete the following steps:
1. Open the SSH Secure Client. Start Programs SSH Secure Shell
Secure Shell Client.
2. From the menu bar, select Edit Settings.
3. Select the Firewall section.
4. For the Firewall URL field, enter the IP address or hostname of the
SOCKS server, in the following formatsocks://host:port. In this
example, it is socks://11.17.7.1:1080.
307
308
Chapter 9
309
310
Chapter 9
311
312
Chapter 9
All communication between the SSH client and the SSH server, no matter what applications are being used via the local SOCKS dynamic portforwarding option, are encrypted.
N OT E DNS traffic to and from Web clients is not encrypted, since Web Clients
are not SOCKS enabled; instead, they perform DNS lookup themselves over UDP
port 53.
Dynamic port forwarding allows the flexibility of a local SOCKS server port
to be used with all applications and the SSH client, while gaining the benefit of
secure communications on any applications to/from the SSH server. Also, this
model holds significantly less overhead than traditional local port forwarding
by not requiring the use of specific local ports to match remote ports, but
requiring only one local dynamic SOCKS port-forwarding option. Remember,
unlike regular port forwarding, where all applications are configured to use
the loopback address, dynamic port forwarding uses the real IP address for the
desired server, not 127.0.0.1. For example, mail clients use the real IP address
of the mail servers but use the SOCKS connection to access the real IP address.
Furthermore, when configuring the e-mail client, you still use the real hostname or IP address for the mail server but use the loopback address only for
the SOCKS menu. Figure 9.11 shows the dynamic port-forwarding architecture with Web browsers.
You may be asking yourself, with all the great uses for SSH and SOCKS,
why there is still so much use of local port forwarding or why dynamic portforwarding isnt more popular? These are great questions that have few
answers. Many SSH users are well aware of local and remote port forwarding,
but dynamic port forwarding still is not widely adopted. The following is a
short list of some positives and negatives of dynamic port forwarding with
SOCKS:
3.
127.0.0.1:1080
Client
1.
SSH Server:22
SSH
Server
4. SSH server
sends the
request to
the Internet.
314
Chapter 9
Most, if not all, Web, FTP, and e-mail applications are SOCKS aware.
Dynamic port forwarding is available by default with most commandline SSH technologies.
Besides its advantages, dynamic port forwarding has some drawbacks. The
following is a list regarding why dynamic port forwarding may not be usable
for your particular organization:
Most Web clients and e-mail clients support SOCKS, but several
applications and protocols, such as NFS and SMB, do not have
SOCKS-enabled clients.
Router
Firewall
6.12.11.30
Proxy/SSH server
Figure 9.12 Architecture required for secure Web browsing with proxy servers.
External Clients
Internet
Internal Clients
Internal Clients
Internal Clients
316
Chapter 9
Before you begin, briefly examine the architecture for proxy servers and
Web browsing. If you use a proxy server for Web browsing in your organization, you probably have your Web browser point to your proxy server for
requests. For example, with Internet Explorer, if you point to Tools Internet
Options Connections LAN Settings and Use a proxy server has a hostname or IP address, your Web browser is sending requests to your HTTP
proxy server first, and the proxy server is reaching out to the real Web site on
your behalf. With the use of SSH, the connection between the SSH client and
the proxy server, which is also an SSH server, is secured, so any Web communication is protected.
The first step is to deploy a proxy server in your internal network. Many
organizations have several proxy servers in their internal networks, either in
their DMZ network or their internal network itself. Either location is fine, as
long as all the internal clients can access the proxy server through firewalls
or router-access control lists. The second step is to install an SSH server on
the proxy server itself or to install an SSH server that has direct access to the
proxy server. In your example, you will be installing an SSH server on the
proxy server itself, but be aware that another server could be used solely for
the SSH server as well. Once you have installed an SSH server on the proxy
server, you should be ready to be setup for secure Web browsing. Assume that
your proxy server, with an IP address of 6.12.11.30, is listening on port 8080 for
all proxy requests. Also assume that your SSH server, also with an IP address
of 6.12.11.30, is listening on port 22 for all SSH connections. Now that you have
6.12.11.30 listening on port 8080 (HTTP proxy) and port 22 (SSH), you are
ready to begin.
The idea behind secure Web browsing is that the client will make a valid
connection to the SSH server using any SSH client. The SSH client, however,
will also be port-forwarding port 8080 on the SSH client to the SSH server.
Therefore, any connection made to port 8080 on the local SSH client will be forwarded to the SSH server on port 8080 over the existing SSH tunnel. Since the
SSH server will be listening for HTTP proxy connections on port 8080, any
request made on the SSH client on port 8080 will be forwarded to the HTTP
proxy server port, which is also port 8080, via SSH. As a result, the clients Web
traffic will be tunneled through SSH from the client to the proxy server, securing your Web communications. In addition to setting up port forwarding, the
clients Web browser will need to be configured to use port 8080 on its own
loopback address (127.0.0.1) for any HTTP requests. The client must use itself
(127.0.0.1) on port 8080 as its proxy server, which is really the port-forwarding
tunnel of SSH. Once port forwarding has been set up for port 8080 and the Web
browser has been configured (127.0.0.1) as the proxy server on port 8080, any
requests from the Web browser will be sent to the proxy server over SSH as
shown in Figure 9.13. Complete the following steps to set up SSH clients and
the Web browser with secure Web communication on a Unix client:
Figure 9.13 Proxy settings under Netscape for 127.0.0.1 on port 8080.
2. Open Netscape.
3. Select Edit from the menu bar and choose Preferences.
4. Expand the Advanced section in the left-hand pane.
5. Select Proxies under the Advanced section.
6. Select the Manual proxy configuration radio button.
7. For the HTTP Proxy: section, enter 127.0.0.1.
8. For the Port: section, enter 8080.
9. Select OK.
Complete the following steps to set up SSH clients and a Web browser with
secure Web communication on a Windows client.
1. Open SecureCRT or SSH Communications SSH client.
2. Configure sessions for the SSH server on 6.12.11.30, on port 22.
3. Enter the port-forwarding options to port forward all connections on
port 8080 to 6.12.11.30. See Figures 9.14 and 9.15.
317
318
Chapter 9
Figure 9.14 SecureCRT port-forwarding options for proxy connections over port 8080.
Figure 9.15 SSH Communications SSH clients port-forwarding options for proxy
connections over port 8080.
4. Save the sessions on the respective SSH clients and connect to the SSH
server with the port-forwarding options enabled.
5. Open Internet Explorer.
6. Select Tools from the menu bar; then select Internet Options.
7. Select the Connections tab.
8. Select the LAN Settings button at the bottom of the section.
9. Select the Proxy server checkbox and enter 127.0.0.1 for the Address
and 8080 for the Port.
10. Select OK. See Figure 9.16 for details.
Now that you have connected your SSH client to the SSH server (with your
port-forwarding options enabled) and your proxy setting in your Web browser
points to your own machine (127.0.0.1) on port 8080, you should be able to
securely browse the information superhighway by encrypting all traffic from
your client to your HTTP proxy server with SSH. Figure 9.17 shows the communication process.
Figure 9.16 Settings under Internet Explorer for the proxy settings over port 8080.
319
3.
127.0.0.1:8080
Client
2.
1.
6.12.11.30:8080
6.12.11.30:22
4.
SSH/Proxy
Server
5. Proxy server
sends the
request to
the Internet.
320
Chapter 9
321
322
Chapter 9
Edit your ~/.ssh/config file and add the following lines, replacing
http.proxy.server with the hostname or IP address of your HTTP
proxy server and port with the port, usually 80 or 8080, that your
HTTP proxy server is listening on.
ProxyCommand /usr/local/bin/corkscrew http.proxy.server port %h %p
Thats it! You will now be able to use OpenSSHs command-line client
through HTTP proxy servers to reach SSH servers.
323
324
Chapter 9
Internet
Router
Firewall
SSH/Proxy
"Chai-Tea"
Coffee Shop
Client
Figure 9.20 External wireless client model.
11.17.1.1
Internet
Router
Firewall
SSH Server
"Chai-Tea"
Coffee Shop
Client
11.30.6.12
Figure 9.21 Dynamic port forwarding used to secure wireless connections with SSH.
325
326
Chapter 9
The two preceding approaches provide a fast, easy, inexpensive, and secure
solution for wireless networks. While these solutions may not be relevant for
all wireless networks or requirements, SSH does solve two of the major
requirements for wireless users: secure Web browsing and secure e-mail.
Summary
The combination of SSH and proxy technology, whether it be HTTP proxies, a
SOCKS server, or dynamic port forwarding, gives SSH even more powerful
capabilities. The combination of these two technologies allows SSH to be used
very easily in insecure and inflexible networks, such as 802.11b wireless networks. Also, with the use of Web proxies or SOCKS, protocols that were very
difficult to secure unless large investments in security devices were purchased
are now easy to set up at a very low cost.
SSH and SOCKS demonstrate how SOCKS servers combined with SSH flexibility can simplify an SSH architecture while providing end-to-end SSH security. The ability to centralize SSH communications to a single destination,
which can then be dispersed to several locations, while providing the use of
SSH encryption to/from the entire connection, makes SSH and SOCKS an
attractive and simple solution in what could be a complex architecture.
Furthermore, the use of dynamic port forwarding, which creates a fully
functional SOCKS server on the local SSH client, adds an incredible amount of
flexibility to SSH. Since the use of dynamic port forwarding allows SSH clients
to have the benefit of SOCKS technology, or even proxy technology, without
the use of a secondary proxy or SOCKS server, it is a very attractive solution
that is not only easy to implement (with the need for just a single flag on a supporting SSH client), but easy to support as well (by requiring only a default
SSH server without extra configuration or plug-ins). The ability to secure Web,
FTP, and mail applications with a single port-forwarding rule without changing any aspects of the SSH server or the architecture it resides in makes
dynamic port forwarding a very strong feature of SSH.
The ability to use HTTP proxies with SSH allows SSH secure Web communication from insecure networks through a relatively easy process. Many organizations have deployed proxy servers probably for other reasons; however,
with the use of local port forwarding, the existing proxy servers can be used to
port forward local connections over secure tunnels to an existing (or new)
internal proxy server. This combination allows external employees, such as
employees who work from home or travel considerably, to use trusted internal
servers for sensitive communications, such as financial applications that are
only Web enabled.
Lastly, this chapter briefly describes how to use SSH technologies with
HTTP proxies and dynamic port forwarding to secure 802.11b wireless networks. The details learned from the previous section of this chapter can be
used not only in traditional wired networks but also in newly emerging networks with strong security issues, such as wireless ones. While wireless and
SSH do have scalability draw-backs, SSH can secure a wireless network with
relatively low overhead, low cost, and high performance without the need to
redesign any type of network or network segment.
The next chapter provides a discussion of SSH case studies. This chapter
provides various real-world examples on how SSH can be used to solve several critical functionality and security issues within an organization. Furthermore, the chapter will discuss many of the key aspects, features, and functions
discussed in the previous chapters, while highlighting the most powerful and
useful functions.
327
CHAPTER
10
SSH Case Studies
When Trinity needed to hack into the Zion mainframe in order to save the
world in the motion picture Matrix Reloaded, what utility does she use? Thats
right, she uses SSH. If this book has shown you one thing, it should be that not
only can SSH be used to save the world; it should be regarded as a gift from the
gods. Seriously, while Trinity demonstrates one of the many benefits of SSH,
which is secure terminal access to a mainframe system, the most important aim
of this book is to demonstrate the flexibility of SSH when properly optimized.
In order to fully demonstrate SSHs flexibility, lets examine three case studies in this chapter. These are real-world situations in which SSH is used to
significantly improve the functionality and/or the security of a particular
architecture. The following are the three case studies:
A problem
Business requirements
Configuration
Results checklist
329
330
Chapter 10
Business Requirements
The business requirements provided by the Ace Tomato Company are as
follows:
Must be accessible from all types of networks, including NATd networks, remote offices, hotel rooms, behind internal proxy servers, and
organizations that allow only TCP port 80 and 443 outbound
Must be able to provide easy access to e-mail and intranet servers from
internal networks, DMZ networks, and extranets
Must require only a single action from novice end-users for e-mail
Secure remote access is one of the premier reasons to use SSH, especially
with its port-forwarding feature. Despite the fact that port forwarding will be
used, the type of SSH solution chosen for this particular architecture is very
important, since not all SSH solutions can meet all of the preceding requirements with the same level of simplicity.
For your solution, you will choose to use the VShell SSH server due to its
ability to provide secure file-sharing access without the need for additional
file-system restrictions, such as NTFS or Unix file-system security. Since
remote access to e-mail, file sharing, and intranet Web pages are the only
requirements, VShell also provides the ability to easily restrict command-line
access to the SSH server, a feature that must be enabled for all users to secure
the SSH server itself. Furthermore, since your remote-access solution requires
access behind internal proxy servers, SecureCRT is a great solution, since it can
connect through proxy servers using a CONNECT string, as discussed in
Chapter 9. Lastly, SecureCRT also offers the ability to automatically execute
other applications, such as e-mail clients, once an SSH connection has been
established. This will meet the requirement that states that all novice users
should have only one step to access e-mail.
In addition to SecureCRT, SSH Communications SFTP client will be used to
access the SFTP session on the Windows file server, since SecureCRT does not
have a built-in SFTP client. This will require an additional step for file-sharing
access; however, that does not break any of the preceding requirements. The
following list states the utilities that will be used:
331
Internet
Remote Clients
Remote Clients
SSH Server
VShell
11.17.6.12
Firewall
E-mail SMTP
Server (Relay)
192.168.1.100
E-mail POP3
Server
172.16.1.150
File Server
VShell
172.16.1.100
INTERNAL NETWORK
Intranet Web
Server
172.16.1.200
332
Chapter 10
All devices in Figure 10.1 are part of the existing architecture, except for
items in italics, which are the VShell SSH server off the perimeter firewall and
the installation of VShell on the internal file server. With only the need for two
additional items, the architecture for remote access with SSH is quite simple.
In addition to the architecture, the perimeter firewall in Figure 10.1 needs to
be modified. The firewall needs to allow external remote clients to access the
SSH server on port 443. Why are you choosing port 443 instead of the default
port 22? Remember from the requirements lists that the remote-access solutions must be accessible in networks that allow only outbound access on TCP
ports 80 and 443. Also, remote clients need to connect through proxy servers
that almost always listen on ports 80 and 443 and usually do not allow you to
proxy any other ports (These restrictions would eliminate other VPN solutions
such as IPSec-based VPNs, which needs UDP 500 to be allowed outbound).
Next, the firewall has to allow access from the SSH server, located in a DMZ off
one leg of the firewall, to port 25 on the SMTP server (mail relay), port 80 on
the internal intranet server, port 110 on the mail server, and port 22 on the Windows file server. Table 10.1 shows the firewall rules that need to be deployed
for the remote-access solution.
Table 10.1
RULE
SOURCE
DESTINATION
PORT
ACTION
COMMENT
ANY
SSH server
443
Allow
Allow any
remote access
client to access
the SSH server
on port 443
SSH server
E-mail SMTP
server (Relay)
25
Allow
SSH server
E-mail POP3
server
110
Allow
333
334
Chapter 10
Table 10.1
(continued)
RULE
SOURCE
DESTINATION
PORT
ACTION
COMMENT
SSH server
Intranet Web
server
80
Allow
SSH server
File server
22
Allow
Configuration
Now that the product selection and architecture have been set up for SSH, its
time to examine the configuration options, which are the most important
steps.
3. The Key Generation Wizard should appear. After reading through the
introduction wizard page, select Next.
4. The Key type screen should appear next. This screen gives you the
option of selecting a DSA or RSA key type. After selecting your preferred key type, select Next.
5. The Passphrase screen should appear next. This screen allows you to set
a passphrase that will protect the private key. The passphrase will need
to be entered in order to decrypt the private key. The screen allows you
to set a comment, possibly with identification information of the public
and private-key pair.
6. The Key length screen should appear next. This screen allows you to
set the key length, anywhere between 512 and 2048. Generally, the
higher the key length, the stronger the security; however, it will have
a greater performance penalty.
7. The Generation screen should appear next. This screen initiates the
process of actually creating the key. Move the mouse around in order to
create the key. Once the process is completed, select Next.
8. The location screen should appear next. Unless you have a particular
area to store the keys, it is recommended to key the keys in the default
location (C:\Documents and Settings\Administrator\Application
Data\VanDyke\Identity); however, make sure to place NTFS permissions on the folder to restrict access to Guests, Everyone, and other
unauthorized groups. After you select the location, click Finish.
9. You should see a pop-up box asking if you would like to use the key as
your global public key. Select No since you may have multiple keys
with one single default global key.
10. VanDyke SecureCRT public and private-key pairs have been generated!
After the creation process has been completed, uploading the public key is
next. The following section demonstrates how to upload a SecureCRT client
public and private-key pair to a VanDyke VShell SSH server. Using a SecureCRT public and private-key pair on VanDyke Softwares SSH server is quite
simple, as the following steps show:
1. Open up SecureCRT (Start Programs Secure CRT Secure CRT).
2. Make a valid connection to the VShell SSH server using the Quick
Connection option.
335
336
Chapter 10
3. Once a valid connection has been established, go back to the quick connect menu (File Quick Connect). Under the authentication section,
there should be two drop-down boxes. The Primary method should be
Password. For the Secondary methods, choose PublicKey and select the
Properties button to the right.
4. The Public Key Properties menu should appear. Make sure the Use
Global Public Key Setting radio button is selected and Use identify file
radio button is also selected. After you have confirmed this, select the
... button and browse to the location of your public key; then select
the public-key file.
5. After you have selected your public-key file, select the Upload button
to upload the public key to the VShell SSH server.
6. When SecureCRT has established a connection, it will ask you to
authenticate using your username and password on the VShell SSH
server. Enter the valid username and password and select OK.
7. Once the username and password are authenticated, the public key will
be uploaded to the VShell SSH server.
8. You should now be able to use your public key to authenticate. To confirm, enable only public-key authentication on the VShell SSH server.
a. Select Start Programs VShell VShell.
b. Highlight the Authentication section.
c. Uncheck Password and check Public key for the required authentication methods. Be sure to uncheck the Allow 3 password attempts
checkbox, since the public key is already on the VShell SSH server.
9. On SecureCRT, select PublicKey for the Primary authentication method
and <None> for the secondary authentication method. Be sure to
browse to the correct public key with the Properties button.
10. Select Connect and you will authenticate with your public key and
then receive a VShell SSH session.
Now that username/password and public-key authentication have been
configured on SecureCRT, ensure that the VShell server is configured to
require both username/password and public-key authentication, as shown in
Figure 10.2.
Figure 10.2 VShell SSH server requiring both username/password and public keys for
authentication.
Now that the authentication requirement has been completed, you need to
ensure that the proper port-forwarding items have been configured. Figure
10.3 shows the correct port-forwarding options to be used in order to meet
the requirement to access e-mail, file sharing, and Web servers. Be sure to
select the appropriate e-mail client for the application setting in the mail portforwarding option.
Lastly, ensure that the CONNECT string is configured appropriately if any
SecureCRT client ever needs to connect via a proxy server, as shown in Figure
10.4. Remember to remind users to check the Use firewall to connect option
when they need to access the SSH server via a proxy server.
Now that SecureCRT has been configured for both authentication and portforwarding requirements, SSH Communications SFTP client needs to be configured in order to support the file-sharing requirement. Since SFTP will be
port forwarding via the SSH connection to/from the file servers SSH server,
very little configuration needs to be done on the SFTP client, aside from pointing the IP address to 127.0.0.1 on port 22, as shown in Figure 10.5.
337
338
Chapter 10
339
340
Chapter 10
Second, set the cipher options for the VShell server. Under VShells General
section, there is a subsection called Cipher. Ensure that 3DES has been
checked. This will meet the encryption requirement listed previously.
Lastly, set the port-forwarding filters for the VShell server. Under VShells
Port Forwarding section, you will need to ensure that only port forwarding
can be allowed to the identified e-mail, Web, and file servers. This setting is
optional, since the firewall will block any port-forwarding connections by SSH
clients that are not allowed; however, this step adds an extra level of security.
The port-forwarding filters are shown in Figure 10.7.
The configuration on the VShell SSH server is minimal when compared
with the primary SSH server. Because the VShell SSH server is being used only
for its SFTP subsystem on the file server (172.16.1.100), only access control and
SFTP need to be configured.
First, set the access-control options for the VShell server on the file server.
Under VShells Access Control section, you will need to ensure that everyone has access to connect to the SSH server, but only for SFTP, as shown in
Figure 10.8.
Figure 10.8 Access Control setting on the file servers VShell service.
341
342
Chapter 10
Next, set the SFTP options for the SFTP subsystem on the file server. The file
servers root-file directory is called Common and is located on a separate
500GB hard drive labeled X, which will be the partition (drive) for the SFTP
root directory. Using VShell SFTP will limit all remote-access clients to that
directory only and any subdirectories and/or files, as shown in Figure 10.9.
The last order of business is to configure the other clients to use the established SSH connection for communication. While limited space does not allow
each step to be described in detail (see Chapter 7 for more detailed steps), the
basic idea is to use the loopback interface, 127.0.0.1, for each IP address of the
desired server and port, as shown in Table 10.2.
Table 10.2
Client Specifications
SERVICE
IP ADDRESS
PORT
Mail Relay
127.0.0.1
25
Mail Server
127.0.0.1
110
SFTP
127.0.0.1
22
Web (http://127.0.0.1)
127.0.0.1
80
Results Checklist
After the client setup has been completed, the requirements of case study # 1
will have all been met, as described in Table 10.3.
Table 10.3
BUSINESS REQUIREMENT
RESULTS
343
344
Chapter 10
The Problem
Virtucon needs to provide secure wireless connectivity for all its internal users.
All buildings on the Virtucon campus should be equipped with wireless
(802.11) connectivity for all employees, including conference rooms, outdoor
lunch areas, and internal cubes and offices.
Business Requirements
The following are the business requirements provided by Virtucon:
Must require only a single action from novice end-users for e-mail and
external Web access
Secure wireless connectivity for internal employees is a must in many organizations. Despite the overwhelming number of security exposures in 802.11
wireless networks, many organizations cannot afford to ignore wireless for
much longer. This case study focuses on how to use SSH to secure wireless
(802.11) networks.
The key requirements from an architecture perspective will be the ability for
the SSH server to access the core Internet connection for Virtucon and the ability to access the e-mail servers. Since command-line access to the SSH server is
not desired, command-line access will need to be restricted. Furthermore,
since dynamic port forwarding will be used on the SSH clients (port forwarding via SOCKS), you will need to ensure that all Web and e-mail clients have
SOCKS support. Figure 10.10 shows the architecture to fulfill the requirements.
All devices in Figure 10.10 are part of the existing architecture, except for
SSH Communications SSH server off the perimeter firewall. Notice that the
wireless-access point is not inside the internal network, but segments into
another zone. This protects the corporate internal networks by creating a
defense in-depth mode. If any compromise were to occur on the wireless network or on the SSH server connected to the wireless network, the internal corporate network would still be protected. The wireless-access points in this
architecture are used as bridges to connect the wireless clients to the SSH
server. With only the need for one additional item, the architecture for secure
wireless access with SSH is quite simple.
In addition to the architecture, the perimeter firewall in Figure 10.10 needs
to be slightly modified. The firewall needs to allow the SSH server to access the
mail-relay server and the internal e-mail server. The firewall needs to allow the
SSH server access to the Internet, since the SSH clients will be using the SSH
server to browse the Web. Table 10.4 shows the firewall rules that need to be
deployed for the secure wireless solution.
345
346
Chapter 10
E-mail SMTP
Server (Relay)
192.168.1.100
Internet
INTERNAL NETWORK
Firewall
SSH Server
6.12.11.30
Wireless
Access Point
Wireless Clients
Wireless Clients
E-mail POP3
Server
172.16.1.150
RULE
SOURCE
DESTINATION
PORT
ACTION
COMMENT
SSH Server
Internet
80,443
Allow
SSH server
E-mail SMTP
server (Relay)
25
Allow
SSH server
E-mail POP3
server
110
Allow
Rule 1 on the firewall is the most obvious; allow the SSH server to access the
Internet. (Depending on which firewall you have deployed, make sure you do
not allow the SSH server access to the entire network, specifically to the internal network, but full outbound access to the Internet only). The next two rules
are in place for port-forwarding reasons. Since the wireless SSH clients will be
using the SSH server and port forwarding to access the e-mail, the SSH server
will need to be allowed access to all of the other servers.
Configuration
Now that the architecture and firewall rules have been set up for SSH, the configuration options need to be examined.
347
348
Chapter 10
All communication between the wireless SSH client to the SSH server,
through the wireless-access point, is encrypted with SSH. This allows the flexibility of a local SOCKS server port (dynamic port forwarding) to be used with
any applications that support SOCKS, while gaining the benefit of secure communications on any applications to and from the SSH server.
In addition to setting up SOCKS for Web and e-mail clients, be sure to keep
in mind that the basic idea is to use the loopback interface, 127.0.0.1, for the
SOCKS address, shown in the preceding example, and to use the servers real
address for the regular client configurations. Table 10.5 shows the configurations for SSH clients according to Figure 10.10.
Table 10.5
SERVICE
IP ADDRESS
Mail Relay
192.168.1.100
127.0.0.1:1080
Mail Server
172.16.1.150
127.0.0.1:1080
Web
Any
127.0.0.1:1080
349
350
Chapter 10
To support the requirement that novice users have one-step access to e-mail
and Web browsing, the two preceding SSH commands can be scripted quite
easily into a Windows batch file or a Unix shell script. This will allow novice
Windows users to double-click the batch file (.bat) and be prompted for a password only for access. Similarly, novice Unix users will have to single-click or
simply execute the shell script from the command line. To create the two
scripts, copy and paste the preceding SSH syntax and paste it into a blank file.
In Windows, save the file as ssh.bat; in Unix, save the file as ssh.sh. Then you
are done. Once novice users execute that script, the SSH command will be executed, and the end-user will be prompted only for a password.
Second, set the user settings for the SSH server. Under the SSH servers User
Restrictions section, under User Authentication, ensure that Allow login for
users states the domain, a forward slash, and an asterisk, such as Virtucon/*
(described further in Chapter 2). This will enable all users that belong to the
Virtucon domain to authenticate. Also, ensure that Permit user terminal is set
to No or Admin, which will restrict terminal access to all users or allow only
admin users to gain terminal access, as shown in Figure 10.14. This will allow
wireless clients to port forward with the SSH server but restrict the clients to
terminal access.
Results Checklist
After the server setup has been completed, the requirements of case study #2
will have all been met, as described in Table 10.6.
351
352
Chapter 10
Table 10.6
BUSINESS REQUIREMENT
RESULTS
The Problem
MicroHat needs to provide secure access to the corporate Microsoft Windows
file server to the engineering department, while using only Linux Red Hat
workstations.
Business Requirements
The business requirements provided by MicroHat are as follows:
One of the major advantages of SSH, aside from its port-forwarding options,
is its SFTP subsystem. Many, if not all organizations, need, have, and support
file servers. Many of these file servers contain sensitive information used to
support and fuel organizations. This case study focuses on how to use SSH for
a secure file server for organizations that use the Windows operating system for
file servers and use Unix, or more specifically Linux, for client workstations.
To implement a secure file server, you need one core requirement from the
SSH server: to encrypt all file-transfer connections that use SMB. The following lists the utilities you will be using in order to satisfy MicroHats business
requirements:
353
354
Chapter 10
Configuration
The paragraphs that follow examine two types of configuration: SSH server
configuration and SSH client configuration.
3. Stop and restart the OpenSSH service using the following commands:
c:\net stop OpenSSH Server
c:\net start OpenSSH Server
Now the Windows file server has an OpenSSH server running on the system, with all users in the engineering group having access to the D partition.
Linux Clients
Linux Clients
INTERNAL NETWORK
355
356
Chapter 10
3. After the correct password is entered, you will have SFTP prompt to
upload and download files from the Windows file server over a secure
channel, as shown in the following syntax:
sftp>
To connect to the Windows file server using smbclient and port forwarding
on the Linux clients, complete the following steps:
1. Change directories to /usr/bin, where the SSH client is located, shown
with the following syntax:
#cd /usr/bin
3. After the correct password has been entered, you will have a valid SSH
prompt on the Window file server, which would be the d:\ prompt
from the cygdrive entered earlier. Furthermore, you will have a portforwarding session enabled on your local Linux workstation, using port
445, to the remote Windows file server, also using port 445.
4. After the SSH session and port-forwarding entries have been enabled,
open a different shell on the Linux client. Type the appropriate smbclient syntax that connects to your loopback interface (127.0.0.1), which
will then be port forwarded to the remote SMB service (the Windows
file servers protocol for file transfer) over the encrypted SSH tunnel:
#smbclient \\\\127.0.0.1\\D -U administrator p 445
Now all engineering users can use SSH port forwarding to use smbclient,
which allows access to the Windows file server in a secure and encrypted
manner.
Results Checklist
After the setup has been completed, the requirements of case study #3 will
have all been met, as described in Table 10.7.
Table 10.7
BUSINESS REQUIREMENT
RESULTS
357
358
Chapter 10
Summary
This chapter presents three case studies that describe several of the key items
discussed in this book. The chapter begins with secure remote access, one of
the strongest and most powerful uses of SSH. SSH has provided the ability
for secure remote access since SSH version 2 was developed. The chapter
then shifts to a more recent problem that SSH has been able to solve. Insecure
wireless (802.11) connectivity is a new issue that many organizations are
unprepared for. Wireless networks brought so much ease and flexibility to
end-users, but devastated corporate security architecture and policies. Even
though SSH was developed long before wireless networks were introduced,
due to SSHs flexibility, secure wireless connectivity with SSH has become relatively easy. Lastly, the third case study focuses on a very straightforward feature of SSH, which is providing secure file access among different operating
systems. The key idea behind this case study is to demonstrate that SSH is not
a Unix-only tool, although most of its history resides in the Unix world, but a
utility that can work in both the Windows world and the Unix world. While
different operating systems provide different types of file-sharing protocols,
such as SMB and NFS, without a lot of security, SSH is not only able to bridge
the gap between different systems when it comes to dependable file sharing,
but is also able to offer such functionality in a secure manner.
Epilogue
360
Epilogue
management. While many organizations secure many aspects of their architecture, some architects forget how important management security becomes,
especially when considering that management connections hold advanced
privileges. Chapters 6 and 7 are dedicated to one of the strongest features of
SSH: port forwarding. SSHs ability to port forward any TCP port gives it the
ability to provide security to many insecure entities such as mail, file transfer,
management, and so on. Chapter 8 shows how to use SSH in some of the typical means, such as an RSH or Rlogin replacement, and then demonstrates how
to use it with file transfer and secure backups. Lastly, Chapter 9 discusses the
use of SSH and SOCKS and dynamic port forwarding. This chapter shows
how to use two existing features of SSH and how to make SSH architecture
more streamlined with the use of SOCKS or how to apply SSH architecture to
new dangerous technologies such as wireless networks.
To best summarize SSH, I have to refer to the opening paragraph of this
book, which states that SSH can be described in many different ways. It can be
described as a protocol, an encryption tool, a client/server application, or a
command interface. Along with its various descriptions, SSH provides various
functions with a single package. SSHs diverse set of services, and the ability to
provide those services in a secure manner, have allowed it to become a staple
in many enterprise networks.
All in all, I have discussed a lot of faces of SSH in this book, each of which
can add, establish, or support functionally and security requirements in any
architecture. Whether SSH will be used as a Telnet replacement or as a utility
to secure 90 percent of your network architecture, it has the ability to be
deployed so that it is flexible and optimal to your organization.
Mahatma Gandhi once said, I have nothing new to teach the world, truth
and non-violence are as old as the hills. Although Gandhi was always ahead
of his time, you probably never thought his words would be applied to SSH.
Gandhi showed the world how an old idea can be used to overcome the
biggest challenges when it is applied in an optimal way. Similarly, all the core
encryption features, flexibility techniques, functionality methods, and security
utilities discussed in this book are not new to SSH but have always existed.
This book is just a tool to help both novice and expert SSH users familiarize
themselves with SSH and to demonstrate the many ways to optimize it.
Index
A
access control options, 77
Accessible Directories option, 69
AFS tokens, 37
AFSTokenPassing option, 37
agent forwarding, 45
Algorithms option, 72
AllowAgentForwarding option, 45
AllowedAuthentication option, 98
AllowedAuthentications option,
47, 63
AllowGroups option, 49
AllowHosts option, 48, 65
AllowSHosts option, 48
AllowTcpForwarding option, 63
AllowTcpForwardingForGroups
option, 46
AllowTcpForwardingForUsers
option, 46, 63
AllowUsers option, 49, 66
AllowX11Forwarding option, 46
Appearance option, 106, 108
AppGate, 113115
ARP pollution, 5
authentication. See also passwords;
public-key authentication
AFS tokens, 37
allowed methods, specifying, 47,
63, 98, 121
banner messages, 120
challenge/response, 37
checking user permissions, 35, 44
configuration directory, 59
failed attempt limits, 122
failure timeout, 64
forcing DNS match, 121
host-based, 127129
internal, 38
Kerberos, 37
keyboard retries, 64
login grace time, 59, 119, 123
login time before failure, 34
matching hostname and DNS
entry, 47
method, specifying, 76
361
362
Index
authentication (continued)
OpenSSH, 122123
options, 118119
PAM client location, 47, 121
permission checking, 123
public-key, enabling, 35
public-key folder location, 122
re-key interval, 96
required methods, 47, 121122
retry limits, 76, 119
rhosts, 36, 123
root login, enabling, 123
RSA, 35, 123
server, 129131
SSH server, 120121
submethods, 64
time limits, 122
triggers, 7980
two-factor, 167168
Unix, 120121, 122123
user key directory, 60
valid types, specifying, 47
VShell SSH server, 121122
Windows, 119120, 122123
Authentication option, 105
AuthenticationSuccessMsg
option, 95
AuthInteractiveFailureTimeout
option, 64
AuthKbdint.NumOptional
option, 64
AuthKbdint.Optional option, 64
AuthKbdint.Required option, 64
AuthKbdint.Retries option, 64
authorization file location,
specifying, 45
AuthorizationFile option, 45
AuthorizedKeysFile option, 35, 123
authorizing users, 279280, 287, 292
B
background connection, setting, 95
backups, 297299
banner messages, 38, 47, 53, 120
Banner option, 38
BannerMessageFile option, 47,
53, 120
batch mode, enabling, 95
BatchMode option, 95
C
-c switch, 92
challenge/response authentication, 37
challengeresponseauthentication
option, 37
chat, 293296
CheckMail option, 43
Chroot restrictions, 50, 172173
ChRootGroups option, 50
ChRootUsers option, 50
Cipher option, 73, 105
Ciphers option, 42, 57, 96
Cisco PIX firewalls, 162163
Cisco routers, 157159
Cisco switches, 160
Cisco VPN concentrator, 160162
clear-text data interception, 5
clients. See also command-line clients
port forwarding, local, 205215
port forwarding, overview, 193199
port forwarding, remote, 213216
products and providers, 1415
Index
363
364
Index
delay, disabling, 96
DenyGroups option, 49
DenyHosts option, 48, 65
DenySHosts option, 48
DenyTcpForwardingForGroups
option, 46
DenyTcpForwardingForUsers
option, 46, 63
DenyUsers option, 49, 66
Disconnect idle session after
__ minutes option, 70
DontReadStdin option, 95
dynamic port forwarding
SOCKS proxy servers, 310314
wireless networks, 326326
E
e-mail
checking for, 43
e-mail client setup, 232234
executing, 237238
overview, 230
SSH client setup, 232234
SSH server setup, 232
Emulation option, 108
Enable Compression option, 75
Enable Keep Alives option, 70
encryption
architecture, 1314
ciphers, 42, 57, 7273, 96
command-line clients, 92
compatibility with existing
algorithms, 1314
hostkey checking, enabling, 96
MACs (Message Authentication
Codes), 42, 57
Index
G
GatewayPorts option, 97
Generate Host Key option, 71
Global Options option, 106107
GoBackground option, 95
GUI clients. See clients (GUI)
H
help file, 89
hijacking sessions, 5
host key, 71
host restrictions, 48, 65, 181183
Hostbased Authentication
option, 123
HostbasedAuthForceClientHostnameDNSMatch option, 47
HostCertificateFile option, 61
HostKeyFile option, 45, 6061
Hostname option, 105
HTTP proxies
Web browsing, 321323
wireless networks, 324
I
-i switch, 91
identification files, 96
identity file location, 45
IdentityFile option, 45, 96
idle timeout, 44, 53, 70
IdleTimeOut option, 44, 53
IgnoreRhosts option, 36, 48
IgnoreRootRhosts option, 48
IgnoreUserKnownHosts option, 36
installing
command-line clients, 8994
GUI clients, 98
OpenSSH client, 8994
365
366
Index
installing (continued)
Secure Shell Communications
client, 8994
VShell SSH, 2729
installing OpenSSH
OpenBSD 3.1, 18
Red Hat Linux 8.0, package based,
1718
Red Hat Linux 8.0, RPM based,
1617
Windows 2000 server, 1923
installing SSH2
OpenBSD 3.1, 2324
Red Hat Linux 8.0, 2324
Windows 2000, 2427
integrity, SSH features, 6
K
keep alives, 41, 56, 70, 96
KeepAlive option, 41, 56, 96
Kerberos, 37
Kerberos Authentication option, 37
KerberosOrLocalPasswd option, 37
KerberosTgtPassing option, 37
KerberosTicketCleanup option, 37
key pairs, creating, 132135, 142144
key pairs, uploading to
OpenSSH server, 145147
SSH Communications SSH server,
144145
VShell SSH server, 147149
L
-L switch, 91
LDAPServers option, 62
Limit failed attempts to option, 76
Index
367
368
Index
passwords (continued)
guessing, 120
limitations, 132
prompting, 95
retry limits, 47, 63
pcAnywhere, 257259
permissions
associating with users, 77
checking, 35, 44, 123
Permissions option, 77
PermitEmptyPasswords option, 36,
44, 59, 123
PermitRootLogin option, 35, 49,
66, 123
PermitUserEnvironment option, 38
PermitUserTerminal option, 66
PKI option, 61
PKIDisableCRLs option, 62
port forwarding
architecture, 189, 201204
for clients, 193199
configuring, 201204
dynamic, SOCKS proxy servers,
310314
dynamic, wireless networks,
326326
enabling, 91, 97
for servers, 200201
port forwarding, local
command-line clients, 205207
definition, 188
example, 188189
GUI SSH clients, 207208
PuTTY, 211212
SecureCRT, 209211
for SSH clients, 205215
Index
369
370
Index
Index
overview, 169172
SSH connection filters, 179181
SSH host restrictions, 181183
user access controls, 173175
user restrictions, 172176
SOCKS proxy servers
configuring, 305310
dynamic port forwarding, 310314
installing, 304305
overview, 302304
SOCKS server ID, specifying, 96
SOCKS version 5, enabling, 96
SocksServer option, 96
SocksServers option, 62
spoofing IP addresses, 5
SSH
advantages, 11
version 1 versus SSH2, 4
version restriction, 33
SSH agents, 152153
SSH client key pairs, uploading to
OpenSSH server, 145147
SSH Communications SSH server,
144145
VShell SSH server, 147149
SSH client keys with
OpenSSH server, 140
SSH Communications SSH
server, 139
VShell SSH server, 140141
SSH Communications
authentication types, 100
built-in SFTP client, 103
connecting to, 99
global settings, 101102
log session, 103104
profile settings, 100101
SSH Communications client. See
command-line clients
371
372
Index
Challengeresponseauthentication,
37
Compression, 38
Host-key section, 3334
Ignore Rhosts, 36
IgnoreUserKnownHosts, 36
Kerberos Authentication, 37
KerberosOrLocalPasswd, 37
KerberosTgtPassing, 37
KerberosTicketCleanup, 37
ListenAddress, 33
location, specifying, 50
Logging section, 34
LoginGraceTime, 34
PasswordAuthentication, 36
passwords (Kerberos), 3637
PermitEmptyPasswords, 36
PermitRootLogin, 35
PermitUserEnvironment, 38
Port, 33
PrintLastLog, 38
PrintMotd, 38
Protocol, 33
PubkeyAuthentication, 35
rhost configuration, 36
RhostAuthentication, 36
RhostsRSAAuthentication, 36
RSAAuthentication, 35
Server key section, 34
StrictModes, 35
Subsystem sftp, 38
UseLogin, 38
UserPrivilegeSeparation, 38
viewing, 32
X11 forwarding, 37
sshd2_config file options, Unix
AllowAgentForwarding, 45
AllowedAuthentications, 47
Index
AllowGroups, 49
AllowHosts, 48
AllowSHosts, 48
AllowTcpForwardingForGroups, 46
AllowTcpForwardingForUsers, 46
AllowUsers, 49
AllowX11Forwarding, 46
Authentication section, 4647
AuthorizationFile, 45
BannerMessageFile, 47
CheckMail, 43
Chrooted Environment section, 50
ChRootGroups, 50
ChRootUsers, 50
Ciphers, 42
Crypto section, 42
DenyGroups, 49
DenyHosts, 48
DenySHosts, 48
DenyTcpForwardingForGroups, 46
DenyTcpForwardingForUsers, 46
DenyUsers, 49
encryption, 42
ForcePTTYAllocation, 40
General section, 40
Host Restrictions section, 4748
HostbasedAuthForceClientHostnameDNSMatch, 47
HostKeyFile, 45
IdentityFile, 45
IdleTiimeOut, 44
IgnoreRhosts, 48
IgnoreRootRhosts, 48
KeepAlive, 41
ListenAddress, 41
LoginGraceTime, 44
MAC, 42
MaxBroadcastPerSecond, 41
MaxConnections, 41
Network section, 4041
NoDelay, 41
PasswordGuesses, 47
PermitEmptyPasswords, 44
PermitRootLogin, 49
Port, 41
PrintMotd, 43
PublicHostKeyFile, 45
QuietMode, 40
RandomSeedFile, 45
RekeyIntervalSeconds, 42
RequiredAuthentications, 47
RequireReverseMapping, 41
SFTP, 51
SSH1 Compatibility section, 4950
Ssh1Compatibility, 50
Sshd1ConfigFile, 50
Sshd1Path, 50
SshPAMClientPath, 47
StrictModes, 44
Subsystem Definitions section,
5051
subsystem-sftp, 51
SyslogFacility, 40
Tunneling section, 46
User Public Key Authentication
section, 4445
User Restrictions section, 4849
UserConfigDictionary, 43
UserKnownHosts, 43
Users section, 4344
VerboseMode, 40
viewing, 39
sshd2_config file options, Windows
Accessible Directories, 69
AllowedAuthentications, 63
AllowHosts, 65
373
374
Index
PKI, 61
PKIDisableCRLs, 62
Port, 55
PublicHostKeyFile, 60
RandomSeedFile, 57
RekeyIntervalSeconds, 57
RequiredAuthentications, 64
RequireReverseMapping, 55
ResolveClientHostname, 55
Server Certificate Configuration
section, 6162
Server Public Key Configuration
section, 6061
Sftp-AdminDirList, 69
Sftp-AdminUsers, 69
Sftp-DirList, 68
Sftp-Home, 68
Sftplogcategory, 68
SocksServers, 62
Subsystem Definitions section,
6769
subsystem-sftp, 68
TerminalProvider, 53
Tunneling section, 6263
User Authentication section, 59
User Authentication-Password
section, 58
User Authentication-Public Key
section, 5859
User key directory, 60
User Restrictions section, 6566
UserConfigDirectory, 59
Users section, 5759
viewing, 5152
Sshd1ConfigFile option, 50
Sshd1Path option, 50
Ssh1MaskPasswordLength
option, 97
Index
SshPAMClientPath option, 47
Ssh1Path option, 97
standard input, disabling, 95
StrictHostKeyChecking option, 96
StrictModes option, 35, 44, 123
Subsystem sftp option, 38
subsystem-sftp option, 51, 68
SyslogFacility option, 40
T
TCP_NODELAY socket options,
41, 56
terminal access
overview, 270271
Rexec (Remote Execution), 273274
Rlogin (Remote Login), 272273
RSH (remote shell), 271272
SSH advantages, 274275
terminal provider, 53
terminal session access, 66
TerminalProvider option, 53
Test Filter option, 80, 83
Time authentication after option, 76
Trace option, 109110
triggers, 7980
TrustX11Applications option, 97
tuning SSH. See optimizing SSH
tunneling, 97
tunneling options, 46, 6263
two-factor authentication, 6, 167168
U
UDP broadcasts per second, 41, 55
UseLogin option, 38
user access controls, 173175
User Authentication-Password section option, 58
375
376
Index