Chapter 1 SSH Configuration
When configuring SSH, go to these sections for information you are
interested in:
l
SSH2.0 Overview
l
Configuring the Device
as an SSH Server
l
Configuring the Device
as an SSH Client
l
Displaying and
Maintaining SSH
l
SSH Server
Configuration Examples
l
SSH Client
Configuration Examples
1.1 SSH2.0 Overview
Secure Shell
(SSH) offers an approach to securely logging into a remote device. By
encryption and strong authentication, it protects devices against attacks such
as IP spoofing and plain text password interception.
The device can not only work as an SSH
server to support connections with SSH clients, but also work as an SSH client
to allow users to establish SSH connections with a remote device acting as the
SSH server.
Currently, when
acting as an SSH server, the device supports two SSH versions: SSH2 and SSH1. When
acting as an SSH client, the device supports SSH2 only.
Algorithm is a set of transformation rules
for encryption and decryption. Information without being encrypted is known as
plain text, while information that is encrypted is known as cipher text.
Encryption and decryption are performed using a string of characters called a
key, which controls the transformation between plain text and cipher text, for
example, changing the plain text into cipher text or cipher text into plain text.
Figure
1-1 Encryption and decryption
Key-based algorithm is usually classified
into symmetric key algorithm and asymmetric key algorithm.
Asymmetric key algorithm means that a key
pair exists at both ends. The key pair consists of a private key and a public
key. The public key is effective for both ends, while the private key is
effective only for the local end.
Asymmetric key algorithm encrypts data
using the public key and decrypts the data using the private key, thus ensuring
data security.
You can also use the asymmetric key
algorithm for digital signature. For example, user 1 adds his signature to the
data using the private key, and then sends the data to user 2. User 2 verifies
the signature using the public key of user 1. If the signature is correct, this
means that the data originates from user 1.
Revest-Shamir-Adleman Algorithm (RSA) and
Digital Signature Algorithm (DSA) are both asymmetric key algorithms. RSA can
be used for data encryption and signature, whereas DSA is used for signatures
only.
Currently, SSH2
supports both RSA and DSA.
The session establishment between an SSH
client and the SSH server involves the following five stages:
Table 1-1
Stages in establishing a session between the SSH
client and the server
|
Stages
|
Description
|
|
Version negotiation
|
SSH1 and SSH2 are supported. The two
parties negotiate a version to use.
|
|
Key and algorithm negotiation
|
SSH supports multiple algorithms. The two
parties negotiate an algorithm for communication.
|
|
Authentication
|
The SSH server authenticates the client
in response to the client’s authentication request.
|
|
Session request
|
This client sends a session request to
the server.
|
|
Interactive session
|
The client and the server start to
communicate with each other.
|
l
The server opens port 22 to listen to connection
requests from clients.
l
The client sends a TCP connection request to the
server. After the TCP connection is established, the server sends the first
packet to the client, which includes a version identification string in the
format of “SSH-<primary protocol version number>.<secondary
protocol version number>-<software version number>”. The primary
and secondary protocol version numbers constitute the protocol version number,
while the software version number is used for debugging.
l
The client receives and resolves the packet. If
the protocol version of the server is lower but supportable, the client uses
the protocol version of the server; otherwise, the client uses its own protocol
version.
l
The client sends to the server a packet that
contains the number of the protocol version it decides to use. The server
compares the version carried in the packet with that of its own to determine
whether it can cooperate with the client.
l
If the negotiation is successful, the server and
the client proceed with key and algorithm negotiation; otherwise, the server
breaks the TCP connection.
All the packets
involved in the above steps are transferred in plain text.
l
The server and the client send key algorithm
negotiation packets to each other, which include the supported public key
algorithm list, encryption algorithm list, MAC algorithm list, and compression
algorithm list.
l
Based on the received algorithm negotiation
packets, the server and the client figure out the algorithms to be used.
l
The server and the client use the DH key
exchange algorithm and parameters such as the host key pair to generate the
session key and session ID.
Through the above steps, the server and the
client get the same session key, which is to be used to encrypt and decrypt
data exchanged between the server and the client later. The server and the
client use session ID in the authentication stage.
Caution:
Before the negotiation, the server must have already generated the
RSA and DSA key pairs, which are mainly used for generating the session key.
l
The client sends to the server an authentication
request, which includes the username, authentication method and information
related to the authentication method (the password in the case of password
authentication).
l
The server authenticates the client. If the
authentication fails, the server informs the client by sending a message, which
includes a list of available methods for re-authentication.
l
The client selects a method from the list to
initiate another authentication.
l
The above process repeats until the
authentication succeeds or the authentication times timeout and the session is
torn down.
SSH provides two authentication methods:
password authentication and publickey authentication.
In password authentication:
l
The client encrypts the username and password,
encapsulates them into a password authentication request, and sends the request
to the server.
l
Upon receiving the request, the server decrypts
the username and password, compares them against those it maintains, and then
informs the client of the authentication result.
In publickey authentication:
l
The server authenticates clients using digital
signatures. Currently, the device supports two publickey algorithms to
implement digital signatures: RSA and DSA. The client sends to the server
a public authentication request containing its user name, public key and
algorithm. The server validates the public key. If the public key is invalid,
the authentication fails; otherwise, the server generates a digital signature
to authenticate the client, and then sends back a message to inform the success
or failure of the authentication.
Besides password authentication and publickey authentication, SSH
provides another two authentication methods:
l
password-publickey: Performs both password authentication and publickey authentication
of the client. A client running SSH1 client only needs to pass either type of
the two, while a client running SSH2 client must pass both of them to login.
l
any: Performs
either password authentication or publickey authentication. The client tries
publickey authentication first.
After passing authentication, the client
sends a session request to the server, while the server listens to and
processes the request from the client. If the client passes authentication, the
server sends back to the client an SSH_SMSG_SUCCESS packet and goes on to the
interactive session stage with the client. Otherwise, the server sends back to
the client an SSH_SMSG_FAILURE packet, indicating that the processing fails or
it cannot resolve the request.
In this stage, the server and the client
exchanges data in this way:
l
The client encrypts and sends the command to be
executed to the server.
l
The server decrypts and executes the command,
and then encrypts and sends the result to the client.
l
The client decrypts and displays the result on
the terminal.
l
During interactive session, the client can send
the commands to be performed by pasting the text, which must be within 2000
bytes. It is recommended that the text pasted be commands in the same view;
otherwise, the server may not be able to perform the commands.
l
If the text exceeds 2000 bytes, you can upload
the configuration file to the server and use the configuration file to restart
the server so that the server executes the commands.
1.2 Configuring the Device as an SSH Server
Complete the following tasks to configure
an SSH server:
As a client uses
either RSA or DSA algorithm for authentication and different clients may
support different algorithms, the server needs to generate both RSA and DSA key
pairs for successful authentication.
1.2.2
Enabling SSH Server
Follow these steps
to enable SSH server:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable the SSH server function
|
ssh server enable
|
Required
Disabled by default
|
1.2.3 Configuring the User Interfaces for
SSH Clients
An SSH client accesses the device through a
VTY user interface. Therefore, you need to configure the user interfaces for SSH
clients to allow SSH login. Note that the configuration takes effect at the
next login.
Follow these steps to configure the
protocols for the current user interface to support:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter user interface view of one or more
user interfaces
|
user-interface vty number [ ending-number ]
|
Required
|
|
Set the login authentication method to scheme
|
authentication-mode scheme [ command-authorization ]
|
Required
By default, the authentication mode is password.
|
|
Specify the protocols for the user
interfaces to support
|
protocol inbound { all | ssh | telnet }
|
Optional
All protocols are supported by default.
|
Caution:
l
For detailed information about the authentication-mode
and protocol inbound commands, refer to Login Commands.
l
If you configure a user interface to support
SSH, be sure to configure the corresponding authentication method with the authentication-mode
scheme command.
l
For a user interface configured to support SSH,
you cannot configure the authentication-mode password command and the authentication-mode
none command.
1.2.4 Configuring RSA and DSA Keys
For successful SSH login, you must create
the RSA or DSA key pairs first.
Follow these steps to create an RSA or DSA
key pair:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Create the
local RSA key pair
|
public-key
local create rsa
|
Required
Use either
command.
By default,
there is neither RSA key pair nor DSA key pair.
|
|
Create the
local DSA key pair
|
public-key
local create dsa
|
Caution:
l
Configuration of the rsa local-key-pair
create and public-key local create dsa command can survive a reboot.
You only need to configure it once.
l
The length of an RSA server/host key is in the
range 512 to 2048 bits. With SSH2, however, some clients require that the keys
generated by the server must not be less than 768 bits.
l
The length of a DSA host key is in the range 512
to 2048 bits. With SSH2, nevertheless, some clients require that the keys
generated by the server must not be less than 768 bits.
You can display or export the local RSA or
DSA host key for setting the host key on the remote end.
Follow these steps to display or export an
RSA or DSA host key:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Display the local RSA host key on the
screen in a specified format, or export it to a specified file
|
public-key local export rsa { openssh | ssh1 | ssh2 } [ filename
]
|
Required
Use either command.
|
|
Display the local DSA host key on the
screen in a specified format, or export it to a specified file
|
public-key local export dsa { openssh | ssh2 } [ filename ]
|
Follow these steps to destroy an RSA or DSA
key pair:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Destroy
the local RSA key pair
|
public-key
local destroy rsa
|
Required
Use either
command.
|
|
Destroy
the local DSA key pair
|
public-key
local destroy dsa
|
1.2.5 Configuring a Client Public Key
This configuration
task is only necessary for SSH users using publickey authentication.
For an SSH user that uses publickey
authentication to login, the server must be configured with the client RSA or
DSA host public key in advance, and the corresponding private key for the
client must be specified on the client.
You can manually configure or import the
publickey public key from a public key file. In the former case, you can manually
copy the client’s public key configuration to the server. In the latter
case, the system automatically converts the public key to a string coded using
the PKCS standard. Before importing the public key, you must upload the public
key file (in binary) to the server through FTP or TFTP.
Caution:
l
When the device functions as the SSH server, you
cannot use Secure CRT 4.07 to upload the client public key to the server.
l
You can configure at most 20 client pubic keys
on an SSH server.
I. Configuring a client public key
manually
Follow these steps to configure the client
public key manually:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
System-view
|
—
|
|
Enter public key view
|
public-key peer keyname
|
—
|
|
Enter public key code view
|
public-key-code begin
|
—
|
|
Configure a client public key
|
Enter the content of the public key
|
Required
The content must be a hexadecimal string
that is generated randomly by the SSH-supported client software and coded compliant
to PKCS. Spaces and carriage returns are allowed between characters.
|
|
Return from public key code view to
public key view
|
public-key-code end
|
—
When you exit public key code view, the
system automatically saves the public key.
|
|
Return from public key view to system
view
|
peer-public-key end
|
—
|
II. Importing a client public key
from a public key file
Follow these steps to import a public key
from a public key file:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Import the public key from a public key
file
|
public-key peer keyname import sshkey filename
|
Required
|
This configuration allows you to create an SSH
user and specify the service type and authentication method.
Follow these steps to configure an SSH
user:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Create an
SSH user, and specify the service type and authentication method
|
For
stelnet users
|
ssh
user username
service-type stelnet authentication-type {
password | { any | password-publickey | publickey
} assign publickey keyname }
|
Required
Use either
command.
|
|
For all
users or sftp users
|
ssh
user username
service-type { all | sftp } authentication-type
{ password | { any | password-publickey | publickey
} assign publickey keyname work-directory directory-name
}
|
Caution:
l
After passing AAA authentication, an AAA user
without SSH user account still can log on to the server using password
authentication and Stelnet or SFTP service.
l
An SSH server supports up to 1024 SSH users.
l
The service type of an SSH user can be Stelnet
or SFTP. stelnet, or the secure Telnet protocol, refers to the
traditional SSH service. For information about stelnet, refer to SSH2.0 Overview. sftp
represents the secure FTP protocol. For information about sftp, refer to
SFTP Overview.
l
For successful login through SFTP, you must set
the user service type to sftp or all.
l
You can set the service type of an SSH user to stelnet
or all if the user does not need SFTP service.
l
As SSH1 does not support service type sftp,
if the client uses SSH1 to log in to the server, you must set the service
type to stelnet or all on the server. Otherwise, the client will
fail to log in successfully.
l
The working folder of an SFTP user is subject to
the user authentication method. For a user using only password authentication,
the working folder is the AAA authorized one. For a user using only publickey
authentication or using both the publickey and password authentication
methods, the working folder is the one set by using the ssh user command.
l
The configured authentication method takes
effect when the user logs in next time.
For users
using publickey authentication:
l
You must configure on the device the
corresponding username and public keys.
l
After login, the commands available for a user
are determined by the user privilege level, which is configured with the user
privilege level command on the user interface. By default, the command
privilege level is 0.
For users using password authentication:
l
You can configure the accounting information
either on the device or on the remote authentication server (such as RADIUS
authentication server).
l
After login, the commands available to a user
are determined by AAA authorization.
1.2.7 Setting the SSH Management Parameters
SSH management includes:
l
Enabling the SSH server to be compatible with
SSH1
l
Setting the server key pair update interval,
applicable to users using SSH1 client.
l
Setting the SSH user authentication timeout
period
l
Setting the maximum number of SSH authentication
attempts
Setting the above parameters can help avoid
malicious guess at and cracking of the keys and usernames, securing your SSH
connections.
Follow these steps to set the SSH
management parameters:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable the SSH server to work with SSH1.x
clients
|
ssh server compatible-ssh1x enable
|
Optional
By default, the SSH server can work with
SSH1.x clients.
|
|
Set the RSA server key pair update
interval
|
ssh server rekey-interval hours
|
Optional
0 by default, that is, the RSA server key
pair is not updated.
|
|
Set the SSH user authentication timeout
period
|
ssh server authentication-timeout time-out-value
|
Optional
60 seconds by default
|
|
Set the maximum number of SSH
authentication attempts
|
ssh server authentication-retries times
|
Optional
3 by default
|
Authentication will fail if the number of authentication attempts
(including both publickey and password authentication) exceeds that specified
in the ssh server authentication-retries command.
1.3 Configuring the Device as an SSH Client
Complete the following tasks to configure
an SSH client:
This configuration task allows you to
specify a source IP address or interface for the client to access the SSH
server, improving service manageability.
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Specify a source IP address or interface
for the SSH client
|
Specify a source IPv4 address or
interface for the SSH client
|
ssh client source { ip ip-address | interface interface-type
interface-number }
|
Required
By default, the address of the interface
decided by the routing is used to access the SSH server
|
|
Specify a source IPv6 address or
interface for the SSH client
|
ssh client ipv6 source { ipv6 ipv6-address | interface interface-type
interface-number }
|
When the device connects to the SSH server
as an SSH client, you can configure whether the device supports first-time
authentication.
l
With first-time authentication, when an SSH
client not configured with the server host public key accesses the server for
the first time, the user can continue accessing the server, and save the host
public key on the client for use in subsequent authentications.
l
Without first-time authentication, a client not
configured with the server host public key will be denied of access to the
server. To access the server, a user must configure in advance the server host
public key locally and specify the public key name for authentication.
Follow these steps to enable the device to
support first-time authentication:
|
To do...
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable the device to support first-time
authentication
|
ssh client first-time enable
|
Optional
By default, first-time authentication is
supported on a client.
|
II. Disable first-time
authentication
For successful authentication of an SSH cl
