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 chapter’s focus is common authentication methods used in SSH, primarily
passwords, host-based authentication, and public keys. The chapter
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.
SSH Communications’ SSH server (Windows)
SSH Communications’ SSH server offers a few options for authentication.
Open the SSH Server configuration screen (Start ➪ Programs ➪ SSH Secure
Shell Server ➪Configuration) and highlight the User Authentication section of
the screen. See Figure 4.1 for the authentication screen.
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
Login grace time Sets the amount of time the user has to complete
the authentication process. Specifically, from the
time the user initiates the connection to the time
the user enters a username/password or privatekey
password
Retries – Number of Retries Stipulates the number of times a user can attempt
to log in
Retries – Delay between tries Specifies the duration between retries
Table 4.2 User-Authentication Password Options
OPTION DESCRIPTION
Password authentication Allows, requires, or denies password
authentication
Permit empty passwords Enables blank passwords to be used for accounts
Keyboard interactive Permits keyboard-interactive authentication with
password authentication
Table 4.3 User-Authentication Public-Key Options
OPTION DESCRIPTION
Public-key authentication Allows, requires, or denies public-key
authentication.
Table 4.3 (continued)
OPTION DESCRIPTION
User-key directory Specifies the directory where the user’s public key
will be stored. The default is %D\.ssh2, which is
the users’ home directory in the .ssh2 folder (for
example, /home//.ssh2 on Unix and
Documents and Settings\\.ssh2 on
Windows).
Authorization file Stores a valid list of public keys that will be
authorized for public-key authentication. The
default is the authorization file, which is stored in
the users’ home directory (for example,
/home//.ssh2 on Unix and
Documents and Settings\\.ssh2 on
Windows).
SSH Communications’ SSH Server (Unix)
The SSH server for Unix offers authentication options similar to the Windows
platform. One difference is that the Windows Server configuration screen is
simply a GUI that points to the SSH configuration file, which is sshd2_config;
the Unix version of the SSH Communications’ server does not use a GUI but
directly uses the configuration file itself. To view the authentication options,
enter the following commands.
#cd /etc/ssh2
#more sshd2_config
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 Denotes the location of the file that contains the
banner message, such as “The only way to win is
not to play.” Default path is
/etc/ssh2/ssh_banner_message.
PasswordGuesses Specifies the number of attempts a user has in
order to enter the correct password.
Table 4.4 (continued)
OPTION DESCRIPTION
AllowedAuthentication Indicates the types of authentication methods that
are allowed by the SSH server. Options include
hostbased, publickey, password, and PAM.
RequiredAuthentication Names the types of authentication methods
required by the SSH server. Options include
hostbased, publickey, password, and PAM.
HostbasedAuthForce Forces a DNS match for authentication. Possible
ClientHostnameDNSMatch choices are yes and no.
SshPAMClientPath States the location of the PAM client, if a PAM
client is used
VShell SSH Server
VanDyke Software’s VShell SSH server offers a few options for authentication.
Open the VShell configuration screen (Start ➪ Programs ➪ VShell ➪ VShell)
and highlight the Authentication section of the screen. (See Figure 4.2.)
Table 4.5 describes the general authentication options for VShell.
Table 4.5 Authentication Options for VShell
OPTION DESCRIPTION
Limit failed attempts to Restricts the number of failed attempts a user can
have before the session is disconnected.
Time authentication after Sets the amount of time the user has to complete
the authentication process. Specifically, from the
time the user initiates the connection to the time
the user enters a username/password or privatekey
password.
Required authentication Requires a password for authentication.
methods—Password
Required authentication Requires a public key for authentication.
methods—Public Key
Required authentication Sets the number of times a user can log in with
methods—Public Key Uploads only a password in order to upload a public key.
The feature is very useful if public-key
authentication is the only method for
authentication, giving the user a method to upload
a public key.
Public-key folder Specifies the location where the users’ public keys
will be stored. The default is Program Files\VShell\
Publickey\.
OpenSSH (Unix and Windows)
OpenSSH server offers similar authentication options to those of VShell and
SSH Communications’ SSH server. To view the authentication options, enter
the following commands:
#cd /etc/ssh
#more sshd_config
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.
Table 4.6 Authentication Options for OpenSSH
OPTION DESCRIPTION
LoginGraceTime Specifies the amount of time the user has to
complete the authentication process. Specifically,
from the time the user initiates the connection to
the time the user enters a username/password or
private key password.
PermitRootLogin Allows (yes) or disallows (no) the root user to log
in to the SSH session. Best practice is to restrict
root access and have authorized users ‘su’ to root.
StrictModes Enables (yes) or disables (no) the checking of a
user’s permission in his or her home directory and
rhosts files before accepting authentication. This
should be set to yes to protect against worldwriteable
files in home directories.
RSA Authentication Allows RSA authentication.
Publickey Authentication Allows public-key authentication; possible values
are yes and no.
AuthorizedKeysFile Names the path to the authorized key-validation
file on the SSH server. The default is
.ssh/authorized_keys, which is the users’ home
directory in the .ssh folder (for example,
/home//.ssh/authorized_keys on
Program Files\OpenSSH\.ssh on Windows).
Rhost Authentication Permits rhosts authentication for RSH
RhostsRSA Authentication Allows rhosts authentication from RSA host keys
Hostbased Authentication Authorizes host-based authentication
Password Authentication Enables (yes) or disables (no) password
authentication
PermitEmptyPasswords Allows (yes) or disallows (no) the use of blank
passwords
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
■■ PAM (Pluggable Authentication Module)
Similarly, password authentication on Windows supports the use of the
SAM (Security Accounts Manager) database file, located at %System-
Root%\winnt\system32\config, or the NTDS.DIT database file, located at
%SystemRoot%\NTDS\ntds.dit.
Despite the database files that SSH supports, the location and type of operating
system is irrelevant to the actual setup and usage of passwords. It should
be noted that password authentication is enabled by default on most, if not all,
SSH servers. However, it is important to know how to disable/enable password
authentication in order to possibly disable it in favor of stronger authentication,
such as public-key authentication.
To enable password authentication, the process is quite simple. For a SSH
server installation on a Unix environment, there exists a configuration file
called sshd2_config (Commercial SSH) and sshd_config (OpenSSH). Both configuration
files are quite similar. Sshd_config is usually located in /etc/ssh,
and sshd2_config is located /etc/sshd2. Enter the following command to
show the contents of the OpenSSH configuration file:
#cd /etc/ssh
#more sshd_config
An abbreviated portion of the output is listed as follows:
# Authentication:
#LoginGraceTime 600
#PermitRootLogin yes
#StrictModes yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
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
Enter the following command to show the contents of the SSH configuration
file for Commercial SSH:
#cd /etc/ssh2
#more sshd2_config
An abbreviated portion of the output follows:
## Authentication
## publickey and password allowed by default
# AllowedAuthentications publickey,password
# AllowedAuthentications hostbased,publickey,password
# AllowedAuthentications hostbased,publickey,keyboard-
# RequiredAuthentications publickey,password
# LoginGraceTime 600
# AuthInteractiveFailureTimeout 2
Under the Authentication section, denoted by ##Authentication, are many
settings that can be set for the SSH server. The option you are most concerned
with is the AllowedAuthentications setting. This setting by default accepts
both password and public keys. In order for password authentication to be
valid, password must be written on this line, even though that is the default
setting. Furthermore, if password authentication is not required or desired,
simply remove password from all the AllowedAuthentications lines, which
disables the use of passwords for authentication. As with OpenSSH, be sure to
uncomment the line, which means deleting the # at the beginning. Refer to the
following example to disable password for authentication:
## Authentication
## publickey and password allowed by default
AllowedAuthentications publickey
# AllowedAuthentications hostbased,publickey,password
# AllowedAuthentications hostbased,publickey,keyboard-
# RequiredAuthentications publickey,password
# LoginGraceTime 600
# AuthInteractiveFailureTimeout 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 VanDyke’s 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
The following is an abbreviated portion of the output:
PermitRootLogin yes
PasswordAuthentication 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 yes
PasswordAuthentication no
Enabling password authentication with VanDyke Software’s VShell is also
quite easy. Using the configuration tool (Start ➪ Programs ➪ VShell ➪ VShell),
there is an Authentication section for the Authentication options. Under the
Authentication section, you will see many options that can be set. One of the
options is Required authentication methods. Under this option are two checkboxes:
one for Password and one for Public Key. Simply click the checkbox for
Password and hit the Apply button in the lower right-hand corner. Password
authentication has now been enabled for all SSH users on the server. If password
authentication is not required or desired, simply uncheck the Password
checkbox and select the Public Key checkbox, which means public-key configuration
must take place (discussed in the following section). Figure 4.3 shows
VShell’s Authentication menu.
Similarly, enabling password authentication for SSH Communications’ SSH
server on Windows platforms is quite easy. Using the configuration menu
(Start ➪ Programs ➪ SSH Secure Shell Server ➪ Configuration), there is a
User Authentication section for the Authentication options. Under the User
Authentication section, you will see many options that can be set. One of the
options is Password authentication. Under this option are three choices in
the drop-down menu. In order to permit password authentication, simply
set the drop-down menu to Allow and select Apply on the lower-half of the
menu. Password authentication has now been enabled for all SSH users on
the server. If password authentication is not required or desired, simply
select Deny from the drop-down menu and hit Apply. Be sure to configure
public-key configuration in order for authentication to occur (discussed in the
following section). Figure 4.4 shows the SSH User Authentication menu.
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
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
SSH’s 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
4. On the OM server, create a file called named .shosts. Place Aum
.eNapkin.com and the username, such as root. The following
is an example:
Aum.eNapkin.com root
Table 4.7 Types of SSH Software and the Locations of the Host Keys
SSH SOFTWARE HOST KEY LOCATION
SSH Communications’ server (Unix) /etc/ssh2
SSH Communications’ server (Windows) Program Files\SSH Secure Shell Server
VShell SSH server Program Files\VShell\hostkey
OpenSSH server /etc/ssh
5. Configure the OM SSH server to accept host-based authentication by
editing the configuration file. Edit sshd2_config to enable host keys for
authentication for SSH Communications’ SSH server:
## Authentication
## publickey and password allowed by default
AllowedAuthentications publickey, hostbased
6. To enable host-based authentication for OpenSSH, edit the sshd_config
file and change the line to yes:
HostbasedAuthentication yes
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 server’s host key with the
host key in the SSH client’s 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.
Table 4.8 The Type of SSH Software and the Location of the Host Keys
SSH SOFTWARE HOST KEY LOCATION
SSH Communications’ client (Unix) /root/.ssh2/hostkeys
SSH Communications’ client (Windows) Documents and Settings\Administrator\
Application Data\SSH\HostKeys
SecureCRT C:\DocumentsandSettings\Administrator\
Application Data\Van Dyke Technologies\
SecureCRT\HostKeyDatabase
OpenSSH client /etc/ssh/hostkeys
The server-authentication process protects against pure IP-address based
verifications, where a SSH client would trust a SSH server based solely on its
IP address. Since IPv4 networks are susceptible to IP address spoofing,
reliance on IP addresses for identification is not secure. Public host keys for
SSH servers offer an excellent method for a SSH client to verify and authenticate
the SSH server that they will be communicating with. Table 4.8 shows the
location of the host-key database for SSH clients.
SecureCRT and SSH Communications’ SSH clients both show the host-key
database on their respective client GUI, as shown in Figures 4.5 and 4.6.
Figure 4.5 shows the host-key database for 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.
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:
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 user’s public key needs to be securely uploaded to the SSH server,
usually stored in the user’s 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!
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 machine—the user’s machine—and a
copy of the user’s 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:
■■ OpenSSH (Unix and Windows)
■■ SSH Communications (Unix and Windows Command Line)
■■ SSH Communications (Windows GUI)
■■ VanDyke SecureCRT
Furthermore, I will demonstrate how to convert specific SSH client keys to
fit a particular SSH server. For example, OpenSSH keys are not interpretable to
SSH Communications’ SSH servers by default. While it would be very nice if
all public and private keys could be used from one SSH server to the other, the
reality is that you need to modify your public and private keys in order to use
them across multiple environments. The SSH servers you will make your
client keys interoperable with are the following:
■■ SSH Communications
■■ OpenSSH
■■ VShell
NOTE In the following sections, the use of ssh, ssh-keygen, ssh.exe, and
ssh-keygen.exe refers to OpenSSH SSH clients. Furthermore, the use of ssh2,
ssh-keygen2, ssh2.exe, and ssh-keygen2.exe refers to SSH Communications’ SSH
clients. Lastly, the use of vsh.exe and vcp.exe refers to VanDyke Software SSH
clients.
Creating Keys with OpenSSH
To create keys with the OpenSSH client, complete the following steps on the
client machine.
1. Change directories to the location of the ssh-keygen binary:
cd /usr/bin
C:\cd “Program Files”\OpenSSH\bin
2. Create a DSA key pair:
#ssh-keygen -d
c:\Program Files\OpenSSH\ssh-keygen.exe -d
Generating public/private dsa key pair.
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
5. OpenSSH client keys have been generated!
After the creation process has been completed, copy the OpenSSH client key
to the SSH server, specifically to the .ssh folder in the users’ home directory
(for example, /home//.ssh/PublicKey.pub. The following section
demonstrates how to use an OpenSSH key on an OpenSSH server, a SSH
Communications’ SSH server, and a VanDyke VShell SSH server.
How to Use an OpenSSH Key on an OpenSSH Server
After the OpenSSH public key has been securely uploaded to the SSH server,
typically in the users’ home directory (/home/Shreya/.ssh/Shreya.pub or
Program Files\OpenSSH\.ssh\Shreay.pub), you also need to append the key
to the authorized key-list file, which is labeled authorized_keys in the users’
home directory (/home//.ssh/authorized_keys). Example syntax
is as follows on the server machine:
[Shreya@OpenSSH]$cat Shreya.pub >> /home//.ssh/authorized_keys
Furthermore, 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 key
files generated on the client machine:
[Shreya@localhost]$chmod 600 Shreya
[Shreya@localhost]$chmod 600 Shreya.pub
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 -i Shreya
If you attach a passphrase to the private key, the following text should
appear:
Enter passphrase for key ‘Shreya’:
After entering your passphrase, you should be logged in to the SSH
connection:
[Shreya@OpenSSH Shreya]$
How to Use an OpenSSH Key on SSH Communications’
SSH Server
To use an OpenSSH key on SSH Communications’ SSH server, the key must be
converted to the SSH2 format, using the following commands.
1. Convert your OpenSSH client key to the SSH Communications’ SSH
compatible format. To convert the keys, you must set a blank
passphrase for the private key (ssh-keygen -p -f Shreya). After the key
conversation is complete, make sure you go back and set a passphrase
for both the old OpenSSH key and the newly converted SSH2 key. Use
the following commands to convert the key on the client machine:
[Shreya@localhost]$ssh-keygen -e -f Shreya.pub > SSH2-Shreya.pub
[Shreya@localhost]$ssh-keygen –e –f Shreya > SSH2-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//.ssh2/publickey.pub on
Unix and Documents and Settings\\.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//.ssh2 for
Unix and Documents and Settings\\.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
example, while OpenSSH uses “–i ” 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
How to Use an OpenSSH Key on a VShell SSH Server
Using an OpenSSH client key for a VShell SSH server is more straightforward
than the previous section. Since VShell SSH servers accept the OpenSSH key
format, it is not necessary to convert OpenSSH keys to any other format, which
saves valuable time and a lot of potential headache! Since you have an
OpenSSH client key, I will demonstrate how to use the OpenSSH key for
VShell SSH servers.
1. Copy the 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:
ssh -p 22 –i OpenSSHPrivatekey –l server>example authentication process is as follows:
ssh VshellServer –p 22 –i Shreya –l shreya
Enter passphrase for key ‘Shreya’:
Authenticated with partial success
Shreya@VshellServer’s 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.

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
■■ Secure Shell Communications
■■ OpenSSH
■■ GUI SSH clients
■■ 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-Secure’s 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, Secure-
CRT does contain an HTTP proxy tunnel that is very easily configurable but
not so simple on SSH Commutations’ SSH client. Furthermore, MindTerm’s
FTP-to-SFTP bridging capability provides an easy method for connecting non-
SSH 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.
Command-Line SSH Clients
Secure Shell Communications (www.ssh.com) and OpenSSH (www.openssh
.org) produce two of the most-used command-line clients for both Windows
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
#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 OpenSSH’s binary. The
following help should appear:
Usage: ssh2 [options] [user@]host[#port] [command]
Options:
-l login_name Log in using this user name.
-n Redirect input from /dev/null.
+a Enable authentication agent forwarding.
-a Disable authentication agent forwarding.
+x Enable X11 connection forwarding (treat X11 clients as
UNTRUSTED).
+X Enable X11 connection forwarding (treat X11 clients as
TRUSTED).
-x Disable X11 connection forwarding.
-i file Identity file for public key authentication
-F file Read an alternative configuration file.
-t Tty; allocate a tty even if command is given.
-v Verbose; display verbose debugging messages.
Equal to ‘-d 2’
-d level Set debug level.
-V Display version string.
-q Quiet; don’t display any warning messages.
-f[o] Fork into background after authentication.
With optional ‘o’ argument, goes to “one-shot” mode.
-e char Set escape character; ‘none’ = disable (default: ~).
-c cipher Select encryption algorithm. Multiple -c options are
allowed and a single -c flag can have only one cipher.
-m MAC Select MAC algorithm. Multiple -m options are
allowed and a single -m flag can have only one MAC.
-p port Connect to this port. Server must be on the same port.
-S Don’t request a session channel.
-L listen-port:host:port Forward local port to remote address
-R listen-port:host:port Forward remote port to local address
-g Gateway ports, i.e. remote hosts may connect to locally
forwarded ports.
+g Don’t gateway ports.
+C Enable compression.
-C Disable compression.
-4 Use IPv4 to connect.
-6 Use IPv6 to connect.
-o ‘option’ Process the option as if it was read from a
configuration file.
-1[ti] Choose ssh1-protocol fallback type.
-h Display this help.
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
cdwivedi’s password:
Authentication successful.
Last login: Thurs June 12 05:52:06 2003 from 172.16.11.17
As an alternative, the same command can be written without any switches,
using SSH defaults:
ssh cdwivedi@10.0.0.3#22
–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
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
Remote port forwarding can also be conducted; it is discussed further in
Chapter 6. The following is an example of remote port forwarding:
ssh 10.0.0.3 –l cdwivedi –R 139:127.0.0.1:139
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. Let’s 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
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’.
cdwivedi’s 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 user’s
password. The following is an example of the –q switch:
ssh 10.0.0.3 –q
root’s password:
SSH Client Configuration File
Now that I have covered the switches that may be used with the SSH client, I’ll
discuss the configuration file itself. Table 3.1 describes where the configuration
file can be located, depending on the operating system and type of SSH client.
The SSH client configuration file is divided into the following categories:
■■ General
■■ Network
■■ Crypto
■■ User Public Key Authentication
■■ Tunneling
■■ SSH1 Compatibility
■■ Authentication
Each of these categories is explored in the paragraphs that follow.
Table 3.1 Location of Configuration Files
CLIENT WINDOWS OS UNIX OS
OpenSSH \Program Files\OpenSSH\etc /etc/ssh_config
SSH Communications \Program Files\SSH Secure Shell /etc/ssh2/ssh2_config
\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, Quiet-
Mode, 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 Fields in the General Section
FIELD DESCRIPTION
VerboseMode Displays verbose information of the SSH session
QuietMode Displays warning messages
DontReadStdin Disables input for Standard input
BatchMode Enables/Disables batch-mode processing
Compression Enables/Disables compression
GoBackground Sends the connection to the background
EscapeChar Sets the ESC character for the session
PasswordPrompt Type of Password prompt
AuthenticationSuccessMsg Displays success message after login
SetRemoteEnv Sets environment variables for the session
Table 3.3 Fields in the Network Section
FIELD DESCRIPTION
Port Sets the port to connect to
NoDelay Enables/Disables the delay process
KeepAlive Keeps the connection active
SocksServer The network ID of SOCKS server
UseSocks5 Support for SOCKS version 5
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 Fields in the Crypto Section
FIELD DESCRIPTION
Ciphers Specifies which Ciphers can be used
MACs Specifies which MACs can be used
StrictHostKeyChecking Enables hostkey checking server validation
RekeyIntervalSeconds Interval length for re-keying the session
User Public Key Authentication
The Public Key Authentication section of the configuration file simply specifies
the location and name of the user’s public key to use for authentication.
The fields in the Public Key Authentication section are described in Table 3.5.
Table 3.5 Fields in the Public key Authentication Section
FIELD DESCRIPTION
IdentityFile Name of identification file
RandomSeedFile Name of random_seed file
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 Fields in Tunnel Section
FIELD
TUNNELING DESCRIPTION
GatewayPorts Allow interfaces to act as a gateway
ForwardAgent Enable/Disable forwarding of packets
ForwardX11 Enable/Disable X11 emulation
TrustX11Applications Options to trust/distrust X11
TUNNELS SET UP UPON LOGIN
LocalForward Local port forwarding setting (143:IP:143)
LocalForward Local port forwarding setting (25:IP:25)
RemoteForward Remote port forwarding setting (22:IP:23)
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 Enable/Disable SSH1 support
Ssh1Path The path to use for SSH1. The default is
/usr/local/bin/ssh1
Ssh1MaskPasswordLength Enable/Disable masking for the password length
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 Specifies the authentication types allowed, such as
password, public key, or all of the above
GUI SSH Clients
Secure Shell Communications (www.ssh.com), VanDyke Software, PuTTY,
AppGate, and WinSCP are several of the vendors that provide graphical user
interfaces (GUIs) for SSH clients. Since there are several GUI clients on the
market, the following section examines some of the optimal features of the
GUI SSH clients. Also, since the GUI clients are primarily available for
Windows, the following section focuses on Windows 2000 and Windows XP.
Table 3.9 shows where the SSH clients can be purchased and/or downloaded.
Table 3.9 Web Sites Where SSH Clients Are Available
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.
Table 3.10 Authentication Types
AUTHENTICATION TYPE DESCRIPTION
Password Username and password combination
Public Key Public and Private-key authentication
SecureID RSA SecureID tokens for authentication*
PAM Pluggable authentication module**
* Requires RSA ACE server.
** The pluggable authentication module is a Unix authentication method that integrates various authentication
methods into one.
SSH Communications offers different settings on SSH clients. Using the
Menu bar, open the settings menu by selecting Edit ➪ Settings.
Under the settings menu, there should be two sections: Profile Settings and
Global Settings. Under profile and global settings, there should be several
more options. In the following sections, each option is examined individually
and its purpose and usage described.
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 Options Under the Profile Settings Section
SETTING DESCRIPTION AND USAGE
Connection The following describes the options on each of the sections to the
left. The options within those sections are also explained.
- Host Name: DNS name or IP address of the remote SSH server.
- User Name: Username of the account to log in with.
- Port Number: Port number that the SSH server is listening on.
- Authentication Methods: Authentication types that can be used
in order to log in to the SSH server. Options can be password,
public key, SecureID, and PAM.
- Encryption Algorithm: Sets the type of cryptography to be used
for the session.
-MAC Algorithm: Sets the type of hashes to be used when hashing
the data being sent across the network. Options can be MD5 or
SHA1. (The option chosen must be supported by the SSH server.)
- Compression: Enables compression on the connection. The valid
choice for compression in only zlib.
Table 3.11 (continued)
SETTING DESCRIPTION AND USAGE
Terminal Answerback: Set the type of emulator to receive from the
SSH server. Valid choices range from VT100 to xterm.
- Connect Through Firewall: This checkbox determines if the
connection will be taken through a SOCKS or proxy server.
- Request Tunnels Only (Disable Terminal): Enables/Disables the
terminal window from appearing. If this is enabled, the user will
not receive a command-line shell to execute commands, but only
the session itself to port forward to.
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 Allows the cosmetic appearance to be modified.
Keyboard Changes the keyboard functions.
Tunneling Provides the ability to secure X11 connections via the SSH
connection by tunneling the X11 packets inside SSH.
- Outgoing: Sets Outgoing tunnels for the session (discussed
more in the port-forwarding chapter).
- Incoming: Sets Incoming tunnels for the session (discussed
more in the port-forwarding chapter).
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 Options Under the Global Settings
SETTING DESCRIPTION AND USAGE
Appearance Sets some of the cosmetic items to display by default, such as
profiles, hostname, color, and font.
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.
Table 3.12 (continued)
SETTING DESCRIPTION AND USAGE
Host Key Identifies the SSH server. The host key is a virtual fingerprint of
the server. The use of host keys protects against IP address
attacks on IPv4 networks, such as Man-in-the-Middle and
spoofing attacks.
Public Key Provides support for a certificate-based authentication system.
Infrastructure The options can include certificates from SSH clients, certificates
(PKI) from integrated directory services architecture, such as LDAP, or
using hardware devices.
- Certificates: Allows the SSH client to import, enroll, view, delete,
or change the passphrase of a certificate.
- LDAP: Provides LDAP directory integration with PKI certificates.
- PKCS #11: Provides a certificate-based system to access
hardware devices.
File Transfer Configures Secure FTP and Secure Copy. Options that can be
configured are the display types of Icons, the display of hidden or
root directories, and the ability to confirm the deletion or
overwriting of a file on the SFTP server. Also, allows the
configuration of the default file viewing application of an
extension that is not available for a particular file.
Firewall Configures SOCKS firewall operability. For example,
socks://172.16.1.100:1117 would be used to make an SSH
connection via a SOCKS server (172.16.1.100) on port 1117.
Security Configures basic security options, such as the option to clear the
host name upon exit or deleting the contents of the clipbook
upon exit.
Printing Sets the options for printing, such as fonts, margins, and
header/footer information.
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.
VanDyke Software’s SecureCRT
VanDyke Software has an SSH client called SecureCRT. Open the SSH client
and initiate a simple SSH connection by selecting Start ➪ Programs ➪ Secure-
CRT 4.0 ➪ SecureCRT 4.0.
After you select the shortcut, SecureCRT will automatically open its Quick
Connect menu (see Figure 3.4) to begin an SSH connection.
The field options shown in Table 3.13 are available in the Quick Connect
display.
Table 3.13 Field Options in the Quick Connect Display
FIELD DESCRIPTION
Protocol Option to use SSH1, SSH2, or other non-SSH connections,
such as Telnet, Rlogin, serial interfaces, or TAPI.
Hostname The fully qualified host name for DNS resolution, such as
sshserver.Aum.com. The dot notation of an IP address can also
be used (for example, 10.8.15.47).
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 The username used on the remote SSH server.
Cipher The encryption algorithm used for the SSH connection.
Available options are DES, 3DES, RC4, and Blowfish.
Authentication Authentication mechanism to be used for the SSH connection.
Possible choices are RSA authentication (requires RSA ACE
server on the server side of the connection), password, and TIS
(requires TIS firewall server on the server side of the
connection).
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 Settings Under Global Options
SETTING DESCRIPTION AND USAGE
Options Mouse settings:
- Copy
- Paste
- Hide Mouse
Dialogs—Various Dialog information settings
Other— Various appearance settings.
Appearance Various appearance settings, including color, menu/tool bar
options, margin settings, and so on.
Firewall Enables an SSH session via a SOCKS server, version 4 or
version 5, or a proxy server. Both SOCKS and proxy servers can
be used to relay an SSH connection to a device on behalf of an
SSH client, discussed further in Chapter 9.
Type:
- SOCKS (v4 or v5) with or without authentication.
- Generic Proxy: Can be used on most proxy servers.
Parameters (SOCKS):
- Hostname or IP: DNS name or IP address of SOCKS server.
- Port: Port number that the SOCKS service is listening on
(default is 1080).
Parameters (Generic Proxy):
- Hostname or IP: DNS name or IP address of the proxy server
- Port: Port number that the proxy service is listening on. Note:
If your remote SSH server is listening on port 22 and all
outbound traffic is allowed via a proxy server only, consider
changing the SSH server to port 443 and using the proxy
server to proxy the SSH connection (discussed in detail in
Chapter 9).
- Prompt: This field should be filled with the information that
SecureCRT should expect from the proxy server.
Table 3.14 (continued)
SETTING DESCRIPTION AND USAGE
- Command: This field should be filled with the information
that SecureCRT should provide to the proxy server once the
connection with the proxy server is established. For example,
to connect to an SSH server listening on port 443 via a proxy
server, check the firewall checkbox in the login screen and
enter the following text in the command field: CONNECT
%h:%p HTTP/1.0\r\n\r\n.
SSH1 Allows the use of a pubic key, instead of a password, to
authenticate an SSH server.
Create Identity File: Allows the ability to create a public and
private-key file.
SSH2 Allows the use of a public key, instead of a password, to
authenticate an SSH server, discussed further in Chapter 4.
- Create Identity File: Allows the ability to create a public and
private-key file.
- Use Certificate: Allows the use of X.509 certificate-based
authentication, instead of a password or public key. Requires
the use of a Certificate Authority.
-Agent: Add keys to agent: Allow the use of the SecureCRT
agent, which allows the ability to connect to multiple SSH
servers with a single public key.
Enable OpenSSH agent forwarding: Allow the ability to connect
to an SSH server via an intermediate server.
- Host Keys: Host keys are public keys used to identify the SSH
server. The host key is virtually a fingerprint of the server. The
use of host keys protects against IP-address attacks on IPv4
networks, such as Man-in-the-Middle and spoofing attacks.
Printing Set the options for printing, such as fonts, margins, and
header/footer information.
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”.
SecureCRT offers different settings to be enabled once a session has been
established. Once a connection has been enabled with the Quick Connect
dialog, open the session options menu using the Menu bar; select Options ➪
Session Options.
Under the settings menu are seven sections: Connection, Emulation,
Appearance, Options, File Transfer, Log File, and Printing. Under each of the
sections are several more sections that can be used to configure the client. I will
select options individually and describe the purpose and usage of each.
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 Session Options Settings and Descriptions
SECTION USAGE AND DESCRIPTION
Connection Connection-specific information can be configured under this
section.
Logon Scripts
- Automate Logon: Creates a script to automate the login
process to an SSH server.
- Logon Scripts: Allows the Secure CRT client to run automatic
scripts to be used when logging on to a remote SSH server.
SSH2
- Use Compression: Enables compression on the connection.
- Cipher: Encryption algorithm to be used for the connection.
- MAC: Sets the type of hashes to be used when hashing the
data being sent across the network.
- SSH Server: Sets the type of SSH server being used on the
remote server. Options are: Auto Detect, which is the best
option; DataFellows, SSH Communications, and Standard.
Port Forwarding
- Locally sets outgoing tunnels for the session (discussed more
in Chapters 6 and 7).
- Remote: Set Incoming tunnels for the session (discussed
more in Chapters 6 and 7).
X11
Allows the ability to secure X11 connections via the SSH
connection by tunneling the X11 packets inside SSH
Emulation Sets options and properties for emulated terminals with
Secure CRT.
Appearance Sets cosmetic appearances for the session.
Options Sets keyboard options for the session.
File Transfer Allows the specific location to be set for the Upload and
Download of file with the Xmodem and Zmodem utilities.
- Xmodem: File transfer utility that supports error detection
during transfer. Note: Xmodem functionality is required on the
remote server.
- Zmodem: File transfer utility to download and upload files.
Note: Zmodem functionality is required on the remote server.
Table 3.15 (continued)
SECTION USAGE AND DESCRIPTION
Log File Allows the location of the log file to set to a specific location.
Note: Logging must be enabled with “File > Log Session” or
“File > Raw Log Session.”
Printing Allows printing information to be configured.
File-transfer capabilities are partially available via the SecureCRT
client. Another client, SecureFX, is the fully supported SFTP/SCP client for
VanDyke Software. Some utilities, such as Zmodem and Xmodem, allow basic
file-transfer options, located under the Transfer menu bar.
To further automate Secure CRT, ActiveX scripting is available with
VBScript and Jscript by selecting Script ➪ Run.
Any VB script, Microsoft Java script, and even certain Perl scripts can be
loaded from the client’s machine to the SecureCRT SSH client, to be executed
within the SSH session.
Secure CRT also offers the ability to create and use public keys for authentication
instead of passwords. To use a public key for authentication, a key must
be generated. Use the utilities under the Tools menu, which can create keys for
SecureCRT clients.
1. Select Tools ➪ Create Public Key. This creates a public key for the user.
2. Select Tools ➪ Public-key Assistant. This manages the public key for the
current user on the remote SSH server.
To use a created public key that has been uploaded on the remote SSH
server, the PublicKey option needs to be set under the Authentication dropdown
box in the Connection or Quick Connect dialog.
The last options I will discuss for SecureCRT are Log Session and Trace. The
log options simply log the entire SSH session, including commands, outputs,
and inputs, to a log file. There are two options with Log Session: formatted,
which only logs selected items; or Raw, which logs everything in an unformatted
fashion. The log file can be saved locally on the client machine for
viewing at a later date. The Log Session option is also located at the file menu
bar. Open the SSH client and complete the following steps:
1. Select File ➪ Open ➪ Quick Connect.
2. Choose File ➪ Log Session or File ➪ Raw Log Session.
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.
Table 3.16 Options for PuTTY Settings and Descriptions
SETTING DESCRIPTION AND USAGE
Session Configurations for the specific SSH session.
- Host Name (or IP address): Fully qualified DNS name or dot
notation of IP address of the SSH server.
- Port: Port that the remote SSH server is listening on, typically
port 22.
- Protocol: Since PuTTY can be used for various items, the SSH
radio box should be used for SSH connections.
- Saved Sessions: Provides the ability to save a session or load
a session that has been saved beforehand.
- Logging: Provides the ability to log the SSH session.
Terminal Allows the ability to set specific options for the terminal
session of the SSH connection.
Windows Allows the ability to make cosmetic changes to the SSH
connection.
Connection Allows the ability to set session specific information, such as
terminal type and username.
Proxy:
Settings to configure to enable an SSH connection via a proxy
server (either a Web proxy (HTTP) or a SOCKS server).
SSH:
SSH specific settings.- Remote Command: Commands to
automatically to send to the SSH server after the session has
been established.
- Protocol Options: Options for SSH 1 or 2, compression, and
pseudo-terminals.
- Encryption Options: Options for encryption algorithms to use
for the SSH connection, including AES, Blowfish, 3DES, and
DES.
- Auth: Authentication settings for the session, including
keyboard (password) or key options.
- Tunnels: X11 and Port forwarding options for the SSH
sessions. Supports both Local and Remote forwarding
(discussed further in the port-forwarding chapter).
- Bugs: Allows the ability to configure options to subvert
problems in the SSH connection, specifically in the
SSH server.
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 Options for WinSCP Settings
OPTION DESCRIPTION AND USAGE
Session Configurations for the specific SSH session.
- Host Name: Fully qualified DNS name or dot notation of IP
address of the remote SSH server.
- Port Number: Port number the SSH server is listening on,
usually port 22.
- User name: Username on the remote SSH server to log in with.
- Password: Password on the remote SSH server, which
correlates to the username used in the Username field.
- Private-key file: If key authentication is being used instead
of a password, the location of the private key file to use for
authentication.
- Stored Session: Options to load stored sessions that have been
saved or to create new sessions.
- Logging (Advanced Option): Enabled logging SSH session to
local files.
Table 3.17 (continued)
OPTION DESCRIPTION AND USAGE
Shell (Advanced Allows various items to be customized with the Shell, including
Option) the Shell itself, the return code submitted, and Unix or
Windows types of displays.
Directories Specifies the path for the local and remote directories.
- Remote Directory: Path of the remote directory (of the
remote SSH server) to display in the right-hand panel of
WinSCP (for example, /home/ssh or d:\ssh\share).
- Local Directory: Path to local directory to be displayed in
the left-hand panel of WinSCP.
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 Specifies the SSH options that can be used, such as protocol
version, encryption type, authentication type, and bugs.
- Protocol Options: Options for SSH 1 or 2, and compression.
- Encryption Options: Options for encryption algorithms to
use for the SSH connection, including AES, Blowfish, 3DES,
and DES.
- Authentication (Advanced Option): Authentication settings for
the session, including keyboard (password), or key options.
- Bugs (Advanced Options) Allows the ability to configure
options to subvert problems in the SSH connection, specifically
in the SSH server.
Preferences Allows the display to be customized.
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
Win32 and Solaris: www.javasoft.com/products/
Macintosh: www.apple.com/java/
Other platforms: http://java.sun.com/cgi-bin/java-ports.cgi
After downloading and installing the JVM, follow the directions in
MindTerm’s readme.txt file to install the client. In many environments, the following
command can be used to install the client:
java -jar mindterm.jar
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 MindTerm’s prompts.
Table 3.18 MindTerm Prompts and Description of Usage
PROMPT DESCRIPTION
SSH Server/Alias Alias or dot notation of the IP address
Save as alias Name to save the connection using an alias
Do you want to add this host to Yes or No option to save the host file of the
your set of Known hosts (check remote SSH server
fingerprint)
Login Username to log in to the remote SSH server
Password Password to use for the remote SSH server,
correlating to the username used
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 of SSH Client
SETTINGS DESCRIPTION
File > Create Keypair Allows the ability to create a public/private key
pair for authentication, instead of using a
password
File > Edit/Convert Keypair Allows the ability to edit or convert the key to a
different format
File > Capture to File Enables logging of the SSH session
Setting > Preferences Allows the ability to set session-specific options
such as:
- Protocol: SSH1 or SSH2, or auto detect
- Cipher: Encryption algorithm to be used
- Mac: Hash algorithm to be used
- Compression: Level of compression to be used
Plugins > SFTP file transfer Allows the ability to transfer files with the
remote SSH server over the SFTP protocol
Plugins > SCP file transfer Allows the ability to transfer files with the
remote SSH server over the SCP protocol
Plugins > FTP to SFTP bridge Allows the ability to bridge an SFTP connection
to an FTP connection. For example, if a client is
connected to an SSH server with MindTerm and
the “FTP to SFTP bridge” is enabled, any other
machine that makes an FTP connection to the
SSH client with be able to view the contents of
the folder on the remote SFTP server (FTP client
> SSH client (with MindTerm bridge enabled) >
SFTP server).
Tunnels > Basic Allows the ability to set local port-forwarding
tunnels
Tunnels > Advances Allows the ability to set remote port-forwarding
options
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).

SSH Servers

There are three main SSH servers that provide different types of functionality
and usage: OpenSSH, SSH Communications’ SSH server, and VanDyke Software’s
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:
■■ OpenSSH server
■■ Unix and Windows
■■ SSH Communications’ SSH server
■■ Unix
■■ *Windows
■■ VanDyke’s Software VShell SSH server
■■ Windows
OpenSSH
OpenSSH servers are available on both Windows and Unix environments. The
Windows version is actually a port of OpenSSH’s 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
NOTE All lines in the sshd_config file that are changed must be
uncommented (the # must be deleted from the beginning of the line).
The first section I present is the simple network configuration:
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
Table 2.1 Options in the sshd_config File
OPTION DESCRIPTION
Port Sets the port number for SSH to listen on. The
default port is 22; however, listening on several
ports, including other nonstandard ports, such as
80, 443, or 8080, may be optimal, since business
travelers may not be able to make outbound
connections on port 22, but since port 80 or 443
are usually available. To listen on multiple ports, add
the following lines:
Port 22
Port 80
Port 443
Port 8080
Protocol Allows the usage of only SSH version 1, SSH version
2, or both. Since SSH version 1 is more insecure, it
may be a good option to only use version 2;
however, several devices do not support SSH
version 2 yet. To use only SSH version two, add the
following line:
Protocol 2
ListenAddress Sets the IP address to have the SSH daemon listen
on. The default, which is 0.0.0.0, enables the SSH
services on all interfaces. If there are interfaces
where SSH should not be listening, such as the
external interface of a firewall, remove 0.0.0.0
and add the appropriate IP addresses. To listen on
only select interfaces, addl the following lines:
ListenAddress 172.16.1.1
ListenAddress 192.168.0.1
The next section discusses the host-key section. The host-key section discusses
parameters around the SSH server’s host key, which is the fingerprint
used to identify the SSH server.
# HostKey for protocol version 1
# HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_dsa_key
This section of the sshd_config file is fairly straightforward. It simply states
the location of the host-key file for both the SSH version 1 format and the SSH
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 specifics on the server key. The KeyRegenerationInterval is
the time, in seconds, to regenerate the server key; the ServerKeyBits is the
number of bits to be used.
The next section addresses logging:
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
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 The amount of time the user has to complete the
authentication process. Specifically, from the time
the user initiates the connection to the time the
user enters his or her username/password or
public/private key password.
Table 2.2 (continued)OPT
OPTION DESCRIPTION
PermitRootLogin Option to allow (yes) or disallow (no) the root user
to log in to the SSH session. Best practice is to
restrict root access and have only users ‘su’ or ‘sudo’
to root. Also, if the root account must be able to log
in directly, the value of “nopwd” can allow root to
log in directly, but only with public-key
authentication.
StrictModes Enables (yes) or disables (no) the checking of a
users’ permission in their home directory and rhosts
files before accepting authentication. This should be
set to yes to protect against world-writeable files in
home directories.
RSAAuthentication Option to allow RSA authentication.
PubkeyAuthentication Option to allow public-key authentication; possible
values are yes and no.
AuthorizedKeysFile The directory where the user’s public key will be
stored. The default is .ssh/authorized_keys, which is
the users’ home directory in the .ssh folder (for
example, /home//.ssh/authorized_keys
on Program Files\OpenSSH\.ssh on Windows).
Under the authentication section in the ssh_config file is an authentication
option for using rhosts with RSH. While rhosts usage is not recommended due
to its poor security standards, the following lines address rhost configuration
options:
# rhosts authentication should not be used
#RhostsAuthentication no
# Don’t read the user’s ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# For this to work you will also need host keys in
/etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
Table 2.3 describes the rhost authentication options available for the SSH
server.
Table 2.3 Rhost Configuration Options
OPTION DESCRIPTION
RhostAuthenication To allow rhosts authentication
Ignore Rhosts To ignore (yes) or read (no) rhosts files in the users
home directory, stored in .rhosts or .shosts files
RhostsRSAAuthenication To attempt rhosts authentication from RSA host keys
HostbasedAuthenication Enable (yes) or disable (no) host-based
authentication under SSH version 2
IgnoreUserKnownHosts Ignore (no) or read (yes) the known hosts file in the
users’ home directory
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 Password and Kerberos Options
OPTION DESCRIPTION
PasswordAuthentication To enable (yes) or disable (no) password
authentication.
PermitEmptyPasswords To allow (yes) or disallow (no) the use of blank
passwords.
Table 2.4 (continued)OPT
OPTION DESCRIPTION
ChallengeResponse Enable (yes) or disable (no) challenge/response
Authentication authentication. Challenge/Response authentication
occurs when the server sends the client a challenge;
the client’s response will determine if authentication
is allowed.
Kerberos Authentication To enable (yes) or disable (no) Kerberos
authentication, which involves session tickets.
KerberosOrLocalPasswd To permit (yes) Kerberos or local-system passwords
for authentication.
KerberosTicketCleanup To enable (yes) or disable (no) the ability to
automatically delete the Kerberos ticket upon logout.
AFSTokenPassing To enable (yes) or disable (no) the ability to use AFS
tokens for authentication.
KerberosTgtPassing To enable (yes) or disable (no) the ability to use
Kerberos Ticket Granting Tickets for authentication.
The next section of the sshd_config file addresses X11 options that can be
used with forwarding:
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
X11 forwarding can be enabled or disabled in this section of the sshd_config
file. If X11 forwarding is enabled, the offset can be set, where 10 is the default,
and the option to use the localhost can be enabled, which is the most typical
installation of X11 forwarding. Using the localhost to forward X11 connections
allows all X11 traffic to prorogate from the local machine.
The last section of the sshd_config file addresses a variety of options that can
be set with the service, such as printing, banner information, and subsystems:
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#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 Miscellaneous Options for the SSH Server
OPTION DESCRIPTION
PrintMotd Enables (yes) or disables (no) any text located in
the motd (Message of the day) file (/etc/motd) to
be displayed at login. This is very useful since
messages can be displayed to all users who are
logging in to the system, such as system downtime,
security issues, and so on.
PrintLastLog Enables (yes) or disables (no) information to be
displayed to the screen about the last time a user
logged in to the service.
UseLogin Enables (yes) or disables (no) the authentication
process to be handled internally using
/usr/bin/login instead of the SSH utility.
UserPrivilegeSeparation Enables/Disables the use of separate privileges for
users using the SSH service.
PermitUserEnvironment Allow (yes) or disallow (no) users to have their
environment variables loaded after authentication.
Compression Enable (yes) or disable (no) compression of the SSH
transmission process.
Banner Path to the file that holds the banner messages that
will be displayed after login.
Subsystem sftp Path to the secure file transfer subsystem.
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:
HostKey /ssh/ssh_host_key
HostDSAKey /ssh/ssh_host_dsa_key
PidFile /ssh/sshd.pid
Protocol 2
Port 22
PermitRootLogin yes
PasswordAuthentication yes
IgnoreRhosts yes
IgnoreUserKnownHosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication 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.
SSH Communications’ SSH server
SSH Communications’ SSH servers are also available on both Windows and
Unix environments. The sshd2_config file is used by SSH Communications’
SSH server for all configuration management for the service. The Windows
version has a different configuration utility, which uses a graphical user interface
(GUI) to display and report changes to the sshd2_config configuration
file. On the other hand, the Unix version provides only the sshd2_config file
for configuration management without any extra configuration tools. Since the
Unix and Windows versions provide different configuration utilities, I address
the sshd2_config file first, since both platforms either rely (Unix) or refer (Windows)
to this file for configuration; then I address the Windows GUI for configuration
management.
SSH Communications’ SSH Server: Unix
To view the configuration file, enter the following commands:
#cd /etc/ssh2
#more sshd2_config
SSH Communications’ sshd2_config file is similar to the sshd_config file of
OpenSSH; however, there are many differences that distinguish the two. The
following paragraphs discuss the various sections of the sshd2_config file.
General
The general section of the sshd2_config file should look similar to the following:
## General
# VerboseMode no
# QuietMode yes
# ForcePTTYAllocation no
# SyslogFacility AUTH
# SyslogFacility LOCAL7
Table 2.6 describes the general options available for the SSH server.
Table 2.6 Options in the General Section of the ssch2_config File (Unix)
OPTION DESCRIPTION
VerberosMode Enables (yes) or disables (no) the SSH session’s
debugging and connection related information to be
displayed to standard output
QuietMode Enables (yes) or disables (no) the SSH session’s
warning and error messages to be displayed to
standard output
ForcePTTYAllocation Enables (yes) or disables (no) the ability to force
allocation of PTTY sessions
SyslogFacility Identifies the Syslog code to use when logging a
message from SSH, such as Daemon, Auth, and
Local
Network
The network section of the sshd2_config file should look like the following:
Port 22
# ListenAddress any
# RequireReverseMapping no
# MaxBroadcastsPerSecond 0
# MaxBroadcastsPerSecond 1
# NoDelay yes
# KeepAlive yes
# MaxConnections 50
# MaxConnections 0
Table 2.7 describes the network options available for the SSH server.
Table 2.7 Options in the Network Section (Unix)
OPTION DESCRIPTION
Port Sets the port number for SSH to listen on. Default
port is 22; however, listening on several ports,
including other nonstandard ports, such as 80, 443,
or 8080, may be optimal since business travelers
may not be able to make outbound connections on
port 22, but since port 80 or 443 is usually available.
To listen on multiple ports, add the following lines:
Port 22
Port 80
Port 443
Port 8080
ListenAddress Sets the IP address to have the SSH daemon listen
on. The default, which is 0.0.0.0, enables the SSH
services on all interfaces. If there are interfaces
where SSH should not be listening, such as the
external interface of a firewall, remove 0.0.0.0
and add the appropriate IP addresses. To listen on
only select interfaces, add the following lines:
ListenAddress 172.16.1.1
ListenAddress 192.168.0.1
RequireReverseMapping Enables (yes) or disables (no) the requirement of
DNS lookups to succeed, in order to work with
AllowHost and DenyHost entries. If enabled and the
DNS lookup fails, the request is denied. If disabled
and the DNS lookup fails, the IP address in
AllowHosts and DenyHosts is checked.
MaxBroadcastPerSecond Identifies the number of UDP broadcasts the server
should handle per second. The default value, which
is zero, has no broadcast handled.
NoDelay Enables (yes) or disables (no) the socket option for
TCP_NODELAY.
KeepAlive Enables (yes) or disables (no) whether the SSH
server should send KeepAlive packets to the SSH
clients. This value helps prevent hanging sessions by
determining if the client on the other side is still
running and hasn’t crashed or blue-screened.
MaxConnections Identifies the number of concurrent connections the
SSH server will handle. If the value is set to zero, the
number of concurrent connections is unlimited.
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 Options in the Crypto Section (Unix)
OPTION DESCRIPTION
Ciphers Lists the types of cipher-text to be used when
encrypting the SSH session. Triple-DES (3DES),
Blowfish, Arcfour, Twofish, CAST – 128, and DES are
supported. More global options can be set, such as
Any, Anystd, anycipher, and anystdcipher. Any and
anystd allows standard ciphers; anycipher allows
any ciphertext; anystdcipher allows any cipher listed
in the IETS SSH draft. The entry of none offers no
cipher.
MACs Message Authentication Code (MAC) is a hash
algorithm used to verify the integrity of the data
before and after transmission. The algorithms
supported are SHA1, MD5, SHA1-96, and MD5-96.
Multiple MACs can also be set.
RekeyIntervalSeconds Specifies the amount of time before the key
exchange 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.
Users
The Users section of the sshd2_config file should look like the following:
# PrintMotd yes
# CheckMail yes
# UserConfigDirectory “%D/.ssh2”
# UserConfigDirectory “/etc/ssh2/auth/%U”
# UserKnownHosts yes
# LoginGraceTime 600
# PermitEmptyPasswords no
# StrictModes yes
# IdleTimeOut 1h
Table 2.9 describes the various miscellaneous options available for the SSH
server.
Table 2.9 Miscellaneous Options in the User Section (Unix)
OPTION DESCRIPTION
PrintMotd Enables (yes) or disables (no) any text located in
the motd (Message of the Day) file (/etc/motd) to
be displayed at log in. This is very useful since
messages can be displayed to all users who are
logging in to the system, such as system downtime,
legal statements, and security issues.
CheckMail Enables (yes) or disables (no) the ability of the SSH
server to check for new mail after the user has been
authenticated.
UserConfigDirectory Identifies the locations of user-specific configuration
data, such as keys and identification files. The
default is the .ssh2 folder in the users’ home
directory, such as /home//.ssh2 or
Documents and Settings\\.ssh2. More
than one location can be identified for configuration
data.
UserKnownHosts Identifies the locations of user-specific known host
file. The default is the .ssh2 folder in the users’
home directory, such as /home//.ssh2
or Documents and Settings\\.ssh2.
More than one location can be identified.
Table 2.9 (continued)
OPTION DESCRIPTION
LoginGraceTime The amount of time, in seconds, the user has to
compete the login process after initiating an
authentication request. Values range from zero, no
limit, to 600 seconds.
PermitEmptyPasswords Allows (yes) or rejects (no) the ability for users to
have empty passwords. In most situations, this
should be no.
StrictModes Enables (yes) or disables (no) the checking of a
users’ permission in their home directory and rhosts
files before accepting authentication. This should be
set to yes to protect against world-writeable files in
home directories.
IdleTimeOut The amount of time, in minutes, the session can
remain unused before it is automatically closed. A
setting of zero specifies no timeout, which may be
ideal in certain backup processes.
User Public Key Authentication
The User Public Key Authentication section of the sshd2_config file should
look like the following:
# HostKeyFile hostkey
# PublicHostKeyFile hostkey.pub
# RandomSeedFile random_seed
# IdentityFile identification
# AuthorizationFile authorization
# AllowAgentForwarding yes
Table 2.10 describes the User Public Key options available for the SSH server.
Table 2.10 Options in the User Public Key Authentication Section (Unix)
OPTION DESCRIPTION
HostKeyFile Identifies the location of the private host-key file.
The default is called hostkey, located on the local
file system.
PublicHostKeyFile Identifies the location of the public host-key file. The
default is called hostkey.pub, located on the local
file system.
RandomSeedFile Identifies the location of the random seed file. This
file is used to generate randomness for the SSH
server.
IdentityFile Identifies the location of the identity file, usually
name identification. It is located in the users’ home
directory on the SSH client. This file is used by the
SSH client to indicate which private keys are
authorized for use during the process of
authentication. For example, if a user has two
private keys for authentication, such as
id_dsa_2048_a and id_rsa_2048_a, the contents of
the identification file will look like the following:
IdKey id_dsa_2048_a
IdKey id_rsa_2048_a
Note: The private keys listed in the identification file
need to be in the users’ home directory also,
discussed further in Chapter 4.
AuthorizationFile Identifies the location of the authorization file,
usually name authorization and located in the users’
home directory on the SSH server. This file is used
by the SSH server to indicate which public keys are
authorized for acceptance during the process of
authentication. For example, if a user has two public
keys for authentication, such as id_dsa_2048_a.pub
and id_rsa_2048_a.pub, the contents of the
authorization file will look like the following:
Key id_dsa_2048_a.pub
Key id_rsa_2048_a.pub
Note: The public keys listed in the authorization file
need to be in the users’ home directory also,
discussed further in Chapter 4.
AllowAgentForwarding Enables (yes) or disables (no) the SSH agent utility
to forwarded logins remotely over SSH. This option
uses the ssh-agent2 binary, a program that stores
private keys for automated authentication.
Tunneling
The Tunneling section of the sshd2_config file should look similar to the
following:
# AllowX11Forwarding yes
# AllowTcpForwarding yes
# AllowTcpForwardingForUsers sjl, cowboyneal@slashdot\.org
# DenyTcpForwardingForUsers 2[[:isdigit:]]*4,peelo
# AllowTcpForwardingForGroups priviliged_tcp_forwarders
# DenyTcpForwardingForGroups coming_from_outside
Table 2.11 describes the tunneling options available for the SSH server.
Table 2.11 Options in the Tunneling Section (Unix)
OPTION DESCRIPTION
AllowX11Forwarding Enables (yes) or disables (no) the ability for X11
applications to forward over SSH.
AllowTcpForwardingForUsers Enables specific users to forward ports, both
locally and remotely. This setting accepts
usernames and patterns, such as DNS patterns.
DenyTcpForwardingForUsers Disables the ability for specific users to forward
ports, both locally and remotely. This setting
accepts usernames and patterns, such as DNS
patterns.
AllowTcpForwardingForGroups Enables groups to forward ports, both locally
and remotely. This setting accepts usernames
and patterns, such as DNS patterns.
DenyTcpForwardingForGroups Disables the ability for specific groups to
forward ports, both locally and remotely. This
setting accepts usernames and patterns, such
as DNS patterns.
Authentication
The Authentication section of the sshd2_config file should look like the
following:
# BannerMessageFile /etc/ssh2/ssh_banner_message
# BannerMessageFile /etc/issue.net
# PasswordGuesses 3
# AllowedAuthentications hostbased,publickey,password
# AllowedAuthentications publickey,pam-1@ssh.com
# 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 Options in the Authentication Section (Unix)
OPTION DESCRIPTION
BannerMessageFile Identifies the location of the file that contains the
text to be displayed before the client logs in to the
SSH server. This is very useful for legal disclaimers.
PasswordGuesses Identifies the number of attempts a user is given
before being disconnected if valid authentication is
not submitted.
AllowedAuthentications Identifies the types of authentication methods that
are valid. Options include password, publickey, and
hostbased.
RequiredAuthentications Identifies the types of authentication methods
required for authentication. If the value is empty,
any values in AllowedAuthentication will be
honored.
HostbasedAuthForce Requires an exact match of the SSH client’s
ClientHostnameDNSMatch hostname and the client’s DNS entry.
SshPAMClientPath Identifies the location of the SSH PAM client to use
in order for PAM authentication to take place. The
default location is /usr/local/bin/ssh-pam-client.
Host Restrictions
The Host Restrictions section of the sshd2_config file should look like the
following:
#AllowHosts localhost, foobar.com, friendly.org
##AllowHosts t..l.\..*
## AllowHosts ([[:digit:]]{1\,3}\.){3}[[:digit:]]{1\,3}
## AllowHosts \i.*
##
# DenyHosts evil\.org, aol\.com
# AllowSHosts trusted\.host\.org
# DenySHosts not\.quite\.trusted\.org
# IgnoreRhosts no
# IgnoreRootRHosts no
Table 2.13 describes the Host Restrictions options available for the SSH server.
Table 2.13 Options in the Host Restrictions Section (Unix)
OPTION DESCRIPTION
AllowHosts Identifies the only hostnames, IP addresses, and/or
patterns allowed to log in to the SSH server
DenyHosts Identifies the hostnames, IP addresses, and/or
patterns not allowed to log in to the SSH server
AllowSHosts Identifies the hosts that are allowed hostbased
authentication, based on /etc/shosts.equiv and
AllowSHosts entries
DenySHosts Identifies the hosts that are not allowed hostbased
authentication, based on /etc/shosts.equiv and
AllowSHosts entries
IgnoreRhosts Enables (yes) or disables (no) the ability to allow
only global configuration files (hosts.equiv and
shosts.equiv)
IgnoreRootRHosts Enables (yes) or disables (no) the ability to allow
only root’s global configuration files (hosts.equiv
and shosts.equiv)
Users Restrictions
The Users Restrictions section of the sshd2_config file should look like the
following:
# AllowUsers sj.*,s[[:isdigit:]]*,s(jl|amza)
# DenyUsers skuuppa,warezdude,31373
# DenyUsers don@untrusted\.org
# AllowGroups staff,users
# DenyGroups guest
# PermitRootLogin nopwd
PermitRootLogin no
Table 2.14 describes the Users Restrictions options available for the SSH
server.
Table 2.14 Options in the Users Restrictions Section (Unix)
OPTION DESCRIPTION
AllowUsers Identifies the only users allowed to log in to the SSH
server. This entry can contain a list of users,
separated by a comma, or a pattern-matching
variable.
DenyUsers Identifies the users not allowed to log in to the SSH
server. This entry can contain a list of users,
separated by a comma, or a pattern-matching
variable.
AllowGroups Identifies the only groups allowed to log in to the
SSH server. This entry can contain a list of groups,
separated by a comma, or a pattern-matching
variable.
DenyGroups Identifies the groups not allowed to log in to the
SSH server. This entry can contain a list of groups,
separated by a comma, or a pattern-matching
variable.
PermitRootLogin Enables (yes) or disables (no) the ability for the root
user to log in to the SSH server. As best practice, this
setting should be set to no, forcing admin-users to
su (switch user) to root. If the root account must be
able to log in directly, the value of “nopwd” can
allow root to log in directly, but with only public-key
authentication.
SSH1 Compatibility
The SSH1 Compatibility section of the sshd2_config file should look similar to
the following:
# Ssh1Compatibility
# Sshd1Path
# Sshd1ConfigFile /etc/sshd_config_alternate
Table 2.15 describes the SS1 Compatibility options available for the SSH
server.
Table 2.15 Options in the SSH1 Compatibility Section (Unix)
OPTION DESCRIPTION
Ssh1Compatibility Enables (yes) or disables (no) compatibility with
SSH version 1, which is an entirely different
implementation of SSH when compared with SSH
version 2. SSH version 1 is insecure, but may be
required.
Sshd1Path Identifies the location of the SSH version 1 binary
(for example, /usr/local/sbin/sshd1).
Sshd1ConfigFile Identifies the location of the SSH version 1
configuration file (for example, /etc
/ssh1/sshd1_config).
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 ftp,guest
# ChRootGroups guest
Table 2.16 describes the Chroot options available for the SSH server.
Table 2.16 Options in the Chrooted Environment Section (Unix)
OPTION DESCRIPTION
ChRootUsers Identifies the users that should be limited to their
home directories, thus chroot users
ChRootGroups Identifies the groups that should be limited to their
home directories, thus chroot groups
Subsystem Definitions
The Subsystem Definitions section of the sshd2_config file should look like the
following:
subsystem-sftp sftp-server
Table 2.17 describes the SFTP options available for the SSH server.
Table 2.17 Options in the Subsystem Definitions Section (Unix)
OPTION DESCRIPTION
subsystem-sftp Identifies the path for the SFTP (secure file transfer
protocol) subsystem to be used with SSH (usually
located in /usr/local/bin)
SSH Communications’ SSH server: Windows
SSH Communications’ SSH server in a Windows environment still uses the
sshd2_config file; however, a GUI is included with the package, which is the
recommended method of management. In this section, I discuss both the contents
of the sshd2_config file, location in Program Files\SSH Secure Shell
Server, and GUI management tool, located at Start ➪ Programs ➪ SSH Secure
Shell Server ➪ Configuration.
To view the contents of the sshd2_config file, the file that is used to configure
the SSH server, enter the following commands:
C:\cd “Program Files\SSH Secure Shell Server”
C:\notepad sshd2_config
To view the configuration GUI, browse to the following shortcut:
Start ➪ Programs ➪ SSH Secure Shell Server
The configuration screen shows the subheadings on the left that are the
same subsections in the sshd2_config file above. The GUI is just a graphical
tool to modify the sshd2_config file. I will examine both the GUI tool and the
sshd2_config file.
The first screen that appears using the GUI tool is the SSH server settings, as
shown in Figure 2.1. This screen provides information about server status,
event log, and default settings. Server status allows you to start or stop the
server by simply clicking the button. This button starts or stops a service associated
with SSH, which is called SSH Secure Shell 2. The next button, View
Event Log, opens the Windows Event Log in order to view any error or warning
messages from SSH. Lastly, the Restore Default Settings button reinstates
default settings on the SSH server.
The Windows version of sshd2_config file is similar to the Unix version;
however, many differences distinguish the two versions. The following sections
address the Windows sshd2_config file.
General Settings
The general section of the sshd2_config file should look like the following:
## General settings
MaxConnections 0
EventLogFilter error, warning
IdleTimeout 0
BannerMessageFile “”
TerminalProvider “cmd.exe”
DoubleBackspace yes
# ProtocolVersionString
The general section of the SSH configuration GUI should look like Figure 2.2.
Table 2.18 describes the General options available for the SSH server.
Table 2.18 Options from the General Section of the sshd2_config File (Windows)
.OPTION DESCRIPTION
MaxConnections Identifies the number of concurrent connections the
SSH server will handle. If the value is set to zero, the
number of concurrent connections is unlimited.
EventLogFilter Identifies the filter for Windows Event Log settings.
Possible filters can be error, warning, and
information.
IdleTimeout The amount of time, in minutes, the session can
remain unused before it is automatically closed. A
setting of zero specifies no timeout, which may be
ideal in certain backup processes.
BannerMessageFile Identifies the location of the file containing text to
be displayed before the client logs in to the server.
This is very useful for legal disclaimers.
TerminalProvider Identifies the executable that will provide terminal
access to the remote user, which is usually the
command prompt program (cmd.exe).
Network Settings
The network section of the sshd2_config file should look like the following:
Port 443
ListenAddress 0.0.0.0
RequireReverseMapping no
ResolveClientHostName yes
MaxBroadcastsPerSecond 0
NoDelay yes
KeepAlive yes
The network section of the SSH configuration GUI should look like Figure 2.3.
Table 2.19 describes the Network options available for the SSH server.
Table 2.19 Options in the Network Section (Windows)
OPTION DESCRIPTION
Port Sets the port number for SSH to listen on. Default
port is 22; however, listening on several ports,
including other nonstandard ports, such as 80, 443,
or 8080, may be optimal since business travelers
may not be able to make outbound connections on
port 22, but since port 80 or 443 is usually
accessible. To listen on multiple ports, add the
following lines:
Port 22
Port 80
Port 443
Port 8080
ListenAddress Sets the IP address to have the SSH daemon listen
on. The default, which is 0.0.0.0, will enable the
SSH services on all interfaces. If there are interfaces
where SSH should not be listening, such as the
external interface of a firewall, remove 0.0.0.0
and add the appropriate IP addresses. To listen on
only select interfaces, add the following lines:
ListenAddress 172.16.1.1,192.168.0.1
ListenAddress 10.0.0.1
RequireReverseMapping Enables (yes) or disables (no) the requirement of
DNS lookups to succeed, in order to work with
AllowHost and DenyHost entries. If enabled and the
DNS lookup fails, the request is denied. If disabled
and the DNS lookup fails, the IP address in
AllowHosts and DenyHosts is checked.
ResolveClientHostname Enables (yes) or disables (no) the server resolving
(sshd2_config file only) (via DNS) the client’s IP address.
MaxBroadcastPerSecond Identifies the number of UDP broadcasts the server
(sshd2_config file only) should handle per second. The default value, which
is zero, has no broadcast handled.