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
|
