Chapter 1 SSH Configuration
When configuring SSH, go to these sections
for information you are interested:
l
SSH Overview
l
SSH Server and Client Configuration
Task List
l
Displaying and Maintaining
SSH Configuration
l
Comparison of SSH Commands
with the Same Functions
l
SSH Configuration Examples
1.1 SSH Overview
1.1.1 Introduction to SSH
Secure Shell (SSH) is a protocol that
provides secure remote login and other security services in insecure network
environments. In an SSH connection, data are encrypted before being sent out
and decrypted after they reach the destination. This prevents attacks such as plain
text password interception. Besides, SSH also provides powerful user authentication
functions that prevent attacks such as DNS and IP spoofing.
SSH adopts the client-server model. The
device can be configured as an SSH client or an SSH server. In the former case,
the device establishes a remote SSH connection to an SSH server. In the latter
case, the device provides connections to multiple clients.
Furthermore, SSH can also provide data
compression to increase transmission speed, take the place of Telnet or provide
a secure “channel” for FTP.
Caution:
l
Currently, when functioning as an SSH server, an
S3100 switch supports SSH2 and SSH1.
l
When functioning as an SSH client, an S3100
switch supports only SSH2.
l
Unless otherwise noted, SSH refers to SSH2
throughout this document.
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. Normally you cannot use the private key through
the public key.
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 data 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.
Both Revest-Shamir-Adleman Algorithm (RSA)
and Digital Signature Algorithm (DSA) are asymmetric key algorithms. RSA is
used for data encryption and signature, whereas DSA is used for adding
signature.
Currently, SSH
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 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.
|
|
Data exchange
|
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 go on to the key and algorithm negotiation. If not, the server
breaks the TCP connection.
All the packets
above are transferred in plain text.
l
The server and the client send algorithm
negotiation packets to each other, which contain public key algorithm lists
supported by the server and the client, encrypted algorithm list, message
authentication code (MAC) algorithm list, and compressed algorithm list.
l
The server and the client calculate the final
algorithm according to the algorithm lists supported.
l
The server and the client generate the session
key and session ID based on the Diffie-Hellman (DH) exchange algorithm and the
host key pair.
l
Then, the server and the client get the same
session key and use it for data encryption and decryption to secure data
communication.
The negotiation steps are as follows:
l
The client sends an authentication request to
the server. The authentication request contains username, authentication type,
and authentication-related information. For example, if the authentication type
is password, the content is the password.
l
The server starts to authenticate the user. If
authentication fails, the server sends an authentication failure message to the
client, which contains the list of methods used for a new authentication process.
l
The client selects an authentication type from
the method list to perform authentication again.
l
The above process repeats until the
authentication succeeds, or the connection is torn down when the authentication
times reach the upper limit.
SSH provides two
authentication methods: password authentication and publickey authentication.
l
In password authentication, the client encrypts
the username and password, encapsulates them into a password authentication
request, and sends the request to the server. Upon receiving the request, the
server decrypts the username and password, compares them with those it
maintains, and then informs the client of the authentication result.
l
The publickey authentication method
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 publickey authentication request containing
its user name, public key and algorithm. The server verifies 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.
IV. Session request
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. The client sends a session request to the server,
which processes the request and establishes a session.
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.
Many devices can act as the SSH server and
client. This document describes two cases:
l
The H3C switch acts as the SSH server to
cooperate with software that supports the SSH client functions.
l
The H3C switch acts as the SSH server to
cooperate with another H3C switch that acts as an SSH client.
Complete the following tasks to configure the
SSH server and clients:
The session establishment between an SSH
client and the SSH server involves five stages. Similarly, SSH server
configuration involves five aspects, as shown in the following table.
Table 1-2
Complete the following tasks to configure the SSH
server:
The SSH server needs
to cooperate with an SSH client to complete the interactions between them. For
SSH client configuration, refer to Configuring the SSH Client.
1.3.1 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.
Table 1-3 Follow these steps to configure the user
interface for SSH clients:
|
To do...
|
Use the command...
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter user interface view of one or more
user interfaces
|
user-interface vty first-number [ last-number ]
|
—
|
|
Configure the authentication mode as
scheme
|
authentication-mode scheme [ command-authorization ]
|
Required
By default, the user interface authentication
mode is password.
|
|
Specify the supported protocol(s)
|
protocol inbound { all |ssh | telnet }
|
Optional
By default, both Telnet and SSH are
supported.
|
Caution:
l
If you have configured a user interface to
support SSH protocol, you must configure AAA authentication for the user
interface by using the authentication-mode scheme command to ensure
successful login.
l
On a user interface, if the authentication-mode
password or authentication-mode none command has been executed, the protocol
inbound ssh command is not available. Similarly, if the protocol inbound
ssh command has been executed, the authentication-mode password and authentication-mode
none commands are not available.
1.3.2 Configuring the SSH Management Functions
The SSH server provides a number of management
functions. Some functions can prevent illegal operations such as malicious
password guess, further guaranteeing the security of SSH connections.
Table 1-4
Follow these steps to configure SSH management
functions:
|
To do...
|
Use the command...
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Set the SSH
authentication timeout time
|
ssh server
timeout seconds
|
Optional
By
default, the SSH authentication timeout time is 60 seconds.
|
|
Set the number
of SSH authentication retry attempts
|
ssh server
authentication-retries times
|
Optional
By
default, the number of SSH authentication retry attempts is 3.
|
|
Set the RSA server key update interval
|
ssh server rekey-interval hours
|
Optional
By default, the system does not update the
RSA server keys.
|
|
Configure a login header
|
header shell text
|
Optional
By default, no login header is
configured.
|
Caution:
l You can configure a login header only when the service type is stelnet.
For configuration of service types, refer to Specifying a Service Type for an SSH User.
l For details of the header command, refer to the corresponding
section in Login Command.
Follow these steps to configure the SSH
server to be compatible with SSH1 clients:
|
To do...
|
Use the command...
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
