Chapter 1 SSH
Terminal Service
1.1.1 Introduction
to SSH
Secure shell (SSH) provides secure
communication and powerful authentication for remote user login to a switch
over an insecure network, thus preventing assaults such as IP address spoofing,
plain-text password interception.
Acting as an SSH server, a switch allows
for the connections of multiple SSH clients. Through SSH Client, a user can
establish a connection to a switch or UNIX host running SSH Server.
Figure 1-1 and Figure 1-2 shows two ways to establish SSH connection between client and server.
l
Establishing SSH connection through a LAN
Figure 1-1 Establish SSH connection through a LAN
l
Establishing SSH connection through a WAN
Figure 1-2
Establish SSH connection through a WAN
At present, the
device supports two SSH versions: SSH2 and SSH1. Unless otherwise noted, SSH
refers to SSH2 throughout this document.
The communication process between a SSH client
and server goes through the following five stages.
1)
Version negotiation stage:
l
The client sends a TCP connection request to the
server.
l
When a TCP connection is established, the two
ends begin to negotiate an SSH version.
l
If they get a successful negotiation, they go to
the key negotiation stage. Otherwise the server terminates the TCP connection.
2)
Key and algorithm negotiation stage:
l
The server and the client send key algorithm
negotiation packets to each other, which include the supported server-side
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.
3)
Authentication negotiation stage:
l
The client sends its username information to the
server.
l
The server starts to authenticate the user. If
the user is configured as having no authentication on the server, the following
step is skipped and the session request stage starts directly.
l
The server authenticates the user in some way
(see the following note), till the authentication succeeds or the connection is
terminated due to authentication timeout.
SSH provides two kinds
of authentication: password authentication and RSA authentication.
(1) Password
authentication works as follows:
l
The client sends the username and password to
the server.
l
The server compares the received username and
password against those configured locally. The user passes the authentication
if the server finds a match for both username and password.
(2) RSA
authentication works as follows:
l
Configure the RSA public key of the client at
the server.
l
The client sends the member module of its RSA
public key to the server.
l
The server checks the validity of the member
module. If it is valid, the server generates a random number, which is sent to
the client after being encrypted with RSA public key of the client.
l
Both the server and the client calculate
authentication data by using the random number and session ID.
l
The client sends the authentication data it calculates
to the server.
l
The server compares the received authentication
data with the authentication data on itself. If they are identical, the
authentication succeeds.
4)
Session request stage. The client sends a session
request to the server, which processes the request and establish a session.
5)
Interactive session stage. Both ends exchange
data till the session ends.
The following table describes SSH Server
configuration tasks.
Table 1-1 SSH2.0 Server configuration tasks
Table 1-2 Configure user interface(s) to support specified protocol(s)
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Enter the view of one or multiple user
interfaces
|
user-interface [ type-keyword ] number [ ending-number ]
|
Required
|
|
Set the login authentication method
|
authentication-mode scheme [ command-authorization ]
|
Required
|
|
Configure the user interface(s) to
support specified 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, to ensure a successful login to the user interface, you
must configure AAA authentication for the user interface by using the authentication-mode
scheme command.
l
For a user interface, if you have executed the authentication-mode
password or authentication-mode none command, the protocol
inbound ssh command cannot be executed; if you have executed the protocol
inbound ssh command, neither of the authentication-mode password and
authentication-mode none commands can be executed.
This configuration task is used to generate
or destroy the server's RSA key pairs, which are named in the format of switch name
plus "_Host", and switch name plus "_Server", for example, H3C_Host
and H3C_Server.
After you issue the rsa local-key-pair create
command, the system prompts you to input a key length.
l
In SSH1.x, the key length is in the range of 512
to 2,048 (bits).
l
In SSH2.0, the key length is in the range of
1024 to 2048 (bits). To keep compatible with SSH1.x, SSH2.0 allows client keys
to be 512 to 2,048 bits in length. But the server's key length must not be shorter
than 1,024 bits; otherwise, clients cannot be authenticated.
Table 1-3 Generate or destroy local RSA
key pairs
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Generate local RSA key pairs
|
rsa local-key-pair create
|
Required
|
|
Destroy local RSA key pairs
|
rsa local-key-pair destroy
|
Optional
|
Caution:
l
For a successful SSH login, you must first generate
the RSA key pairs of the server.
l
You just need to execute the rsa
local-key-pair create command once, and need not execute the command again
after the system is rebooted.
l
If you re-execute the rsa local-key-pair
create command, the system will ask whether you want to replace the original
key pairs with new ones.
l
For a fabric made up of multiple devices, you
need to execute the rsa local-key-pair create command on the management
device to ensure that all devices in the fabric have the same local RSA key
pairs.
After the rsa
local-key-pair create command is executed, you can execute the display rsa
local-key-pair public command, which will display:
l
Two public keys (in H3C_Host and H3C_Server) if
the switch works in SSH1.x-compatible mode.
l
Only one public key (in H3C_Host) if the switch
works in SSH2.0 mode.
Table 1-4 Create an SSH user
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Create an SSH user
|
ssh user username
|
Required
|
For an SSH user
created by using this command, if you do not specify an authentication type by
using the ssh user authentication-type command for this user, this SSH
user adopts the default authentication type. On the other hand, if the default
authentication type is not specified, you need to specify an authentication
type for this SSH user.
For a new user, you must specify the authentication
type. Otherwise, the user cannot access the switch.
Table 1-5 Configure authentication type for a user
|
Operation
|
Command
|
Description
|
|
Enter
system view
|
system-view
|
—
|
|
Specify a
default authentication type for SSH users
|
ssh
authentication-type default { password |
rsa | password-publickey | all }
|
At least
one required;
By
default, no authentication type is specified for an SSH user, and the user
can not access the switch.
|
|
Configure
authentication type for an SSH user
|
ssh
user username authentication-type
{ password | password-publickey | rsa| all }
|
Note that:
l
The ssh authentication-type default command
is used to configure the default authentication type for all SSH users.
l
The ssh user username authentication-type
command is used to configure an authentication type for a specific SSH user.
l
When both commands are configured with different
authentication types, for the specific user (user specified by the username argument),
the authentication type specified by the ssh user username
authentication-type command will take effect instead of that specified for
all SSH users.
Caution:
l
If RSA authentication type is configured
for a user, the RSA public key of the client user must be configured on the
switch.
l
By default, no authentication type is specified
for a new user, and the new user cannot access the switch.
l
For the password-publickey authentication
type: SSH1 client users can access the switch as long as they pass any of the
two kinds of authentications. SSH2 client users can access the switch only when
they pass both kinds of authentications.
l
For the password authentication type, username
should be consistent with the valid user name defined in AAA; for the RSA
authentication type, username is the SSH local user name, so that there
is no need to configure a local user in AAA.
l
If the default authentication type for SSH users
is password and local AAA authentication is adopted, you need not use the ssh
user command to create an SSH user. Instead, you can use the local-user command
to create a user name and its password and then set the service type of the
user to SSH.
l
If the default authentication type for SSH users
is password and remote authentication (RADIUS authentication, for example) is
adopted, you need not use the ssh user command to create an SSH user,
because it is created on the remote server. And the user can use its username
and password configured on the remote server to access the network.
l
If you use the ssh user username authentication-type
command to specify an authentication type for an inexistent SSH user, the
system will create the SSH user automatically.
l
If the RSA authentication type is specified, you
can use the user privilege level command to set the level of the commands
available to the SSH users logging into the server. Additionally, the command
levels accessible to the users adopting RSA authentication are the same.
l
If the password authentication type is
specified, the command levels accessible to SSH users logging into the server
are determined through AAA. In this case, the command level may vary with users.
The configuration of SSH management
includes the setting of authentication timeout time, authentication retry
times, server key update interval, and SSH compatible mode. After the
configuration, the SSH management function is able to prevent illegal activities
such as malicious password guessing, thus ensure the security of SSH
connections.
Table 1-6 Configure
SSH management
|
Operation
|
Command
|
Description
|
|
Enter
system view
|
system-view
|
—
|
|
Set SSH
authentication timeout time
|
ssh
server timeout seconds
|
Optional
By
default, the timeout time is 60 seconds.
|
|
Set SSH authentication retry times
|
ssh server authentication-retries times
|
Optional
By default, the number of retry times is
3.
|
|
Set server key update interval
|
ssh server rekey-interval hours
|
Optional
By default, the system does not update
server keys.
|
|
Configure SSH server to be compatible
with SSH1.x clients
|
ssh server compatible-ssh1x enable
|
Optional
By default, SSH server is compatible with
SSH1.x clients.
|
On the switch, you can configure a client public
key (generated randomly on a client) for a client user. This configuration is
not required for password authentication type.
There are two methods to configure a client
public key for a user.
1)
Manual configuration
First, perform the following operations on
a client:
l
Use the SSH1.5/2.0 client software to randomly
generate a RSA key pair.
l
Use the SSHKEY.exe program to transform the
public key in the RSA key pair to PKCS (public-key cryptography standards) format.
Then, perform the following operations on
the server:
Table 1-7 Configure client public key for a user
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Enter public key view
|
rsa peer-public-key keyname
|
Required
|
|
Enter public key edit view to input a
client public key
|
public-key-code begin
|
—
|
|
Configure the
client public key
|
Enter the content of the public key
|
Required
When you input the key data, spaces are
allowed between the characters you input (because the system can remove the
spaces automatically); you can also press <Enter> to continue your
input at the next line. But the key you input should be a hexadecimal digit
string coded in the public key format.
|
|
Return to public key view from public key
edit view
|
public-key-code end
|
The system saves the public key data you
input when exiting public key edit view.
|
|
Return to system view from public key
view
|
peer-public-key end
|
—
|
|
Assign a client public key to an SSH user
|
ssh user username assign rsa-key keyname
|
Required
Keyname is
the name of an existing public key. If the user has already been assigned with
a public key, the newly assigned public key overwrites the old one.
|
l
The above method requires you to transform the
format of the public key on the client, and then manually configure the
transformed public key on the server. So, the method is relatively more
complex.
l
If you use the ssh user username assign
rsa-key command to assign an public key for an inexistent SSH user, the
system will create the SSH user automatically.
l
When configuring the public key for a client
manually, you can copy the local host public key configuration on the client
and then paste it to the server.
2)
Automatic configuration
First, perform the following operations on
a client:
l
Use the SSH1.5/2.0 client software to randomly
generate a RSA key pair.
l
Use FTP/TFTP to transfer the corresponding public
key file to the Flash memory of the server.
Then, perform the following operations on
the server:
Table 1-8 Automatic configuration
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Transform the format of the key in a client
public key file and automatically configure a client public key on the server
|
rsa peer-public-key keyname import sshkey filename
|
filename must
be consistent with the name of a public key file in the Flash memory.
|
The above method
does not require you to manually configure a public key. So the method is
relatively simple and is the recommended method.
VII. Specifying
a source IP address/interface for the SSH server
You can perform the following
configurations to specify a source IP address or a source interface for the SSH
server, thus enhancing traffic manageability.
Table 1-9 Specify a source IP address/interface
for the SSH server
