- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 02-Login management configuration | 459.44 KB |
Logging in to the switching engine from the access controller engine
Configuring management IP addresses
Configuring none authentication for Telnet login
Configuring password authentication for Telnet login
Configuring scheme authentication for Telnet login
Configuring common settings for VTY user interfaces (optional)
Setting the DSCP value for outgoing Telnet packets when the device acts as the Telnet server
Using the device to log in to a Telnet server
Setting the DSCP value for outgoing Telnet packets when the device acts as the Telnet client
Configuring the SSH server on the device·
Using the device as an SSH client to log in to the SSH server
Displaying and maintaining CLI login
Logging in to the Web interface
Displaying and maintaining Web login
HTTP login configuration example
HTTPS login configuration example
Configuring SNMPv1 or SNMPv2c settings
Configuring source IP-based Telnet login control
Configuring source/destination IP-based Telnet login control
Configuring source MAC-based Telnet login control
Telnet login control configuration example
Configuring source IP-based SNMP login control
SNMP login control configuration example
Configuring source IP-based Web login control
Web login control configuration example
Login overview
This chapter describes the available CLI login methods and their configuration procedures.
Login methods at a glance
You can access the switching engine by using the methods shown in Table 1.
|
Login method |
Default setting and configuration requirements |
|
|
|
|
By default, login through OAP is enabled, no username or password is required, and the user privilege level is 3. |
|
|
By default, Telnet service is enabled. The default Telnet settings are as follows: · Username admin. · Password admin. · IP address 192.168.0.101. · User privilege level 3. |
|
|
By default, SSH service is disabled. To use SSH service, complete the following configuration tasks: · Enable the SSH function and configure SSH attributes. · Assign an IP address to a VLAN interface (the default IP address for VLAN-interface 1 is 192.168.0.101) and make sure the interface and the SSH client can reach each other. · Enable scheme authentication for VTY login users (scheme authentication is enabled by default). · Specify a user privilege level for VTY login users (0 by default). |
|
|
By default, Web login is enabled. The default Web login settings are as follows: · Username admin. · Password admin. · IP address 192.168.0.101. · User privilege level 3. |
|
|
By default, SNMP login is disabled. To use SNMP service, complete the following configuration tasks: · Assign an IP address to a VLAN interface (the default IP address for VLAN-interface 1 is 192.168.0.101), and make sure the interface and the NMS can reach each other. · Configure SNMP basic parameters. |
User interfaces
The device uses user interfaces (also called "lines") to control CLI logins and monitor CLI sessions. You can configure access control settings, including authentication, user privilege, and login redirect on user interfaces. After users are logged in, their actions must be compliant with the settings on the user interfaces assigned to them.
Users are assigned different user interfaces, depending on their login methods, as shown in Table 2.
Table 2 CLI login method and user interface matrix
|
User interface |
Login method |
|
AUX user interface |
OAP |
|
Virtual type terminal (VTY) user interface |
Telnet or SSH |
User interface assignment
The device automatically assigns user interfaces to CLI login users, depending on their login methods. Each user interface can be assigned to only one user at a time. If no user interface is available, a CLI login attempt will be rejected.
The device provides one AUX user interfaces and 16 VTY user interfaces. For a CLI login, the device always picks the lowest numbered user interface from the idle user interfaces available for the type of login.
For example, four VTY user interfaces (0 to 3) are configured, of which VTY 0 and VTY 3 are idle. When a user Telnets to the device, the device assigns VTY 0 to the user and uses the settings on VTY 0 to authenticate and manage the user.
User interface identification
A user interface can be identified by an absolute number, or the interface type and a relative number.
An absolute number uniquely identifies a user interface among all user interfaces. The user interfaces are numbered starting from 0 and incrementing by 1 and in the sequence of AUX and VTY user interfaces. You can use the display user-interface command without any parameters to view supported user interfaces and their absolute numbers.
A relative number uniquely identifies a user interface among all user interfaces that are the same type. For example, the AUX user interface is AUX 0.
A relative number uniquely identifies a user interface among all user interfaces that are the same type. The number format is user interface type + number. The user interfaces are numbered starting from 0 and incrementing by 1. For example, the first AUX user interface is AUX 0, and the second AUX user interface is AUX 1.
Logging in through OAP
You can log in to the switching engine from the access controller engine through Open Application Platform (OAP).
H3C Open Application Architecture provides an open interface for third-party vendors to develop and integrate value-added applications into H3C products. These applications are called "OAP applications" and can apply to one of the following forms:
· A standalone network device.
· A card that can be installed in a network device.
· An application program running on a network device.
An OAP application runs its own operating system. You can log in to the operating system of an OAP application to install features. For example, you can install security features and voice features to provide security and voice services for users.
Logging in to the switching engine from the access controller engine
You can log in to the CLI of the access controller engine through the console port, and then switch to the CLI of the switching engine. To return to the CLI of the access controller engine, press Ctrl+K.
To log in to the switching engine from the access controller engine:
|
Task |
Command |
Remarks |
|
Log in to the switching engine from the access controller engine. |
oap connect slot 0 |
Available in user view of the access controller engine. |
Configuring management IP addresses
From the OAA perspective, the access controller engine and the switching engine are integrated on the same device. For an SNMP UDP domain-based NMS, however, the access controller engine and the switching engine are independent SNMP agents. The two agents reside on the same managed object physically, but they belong to different systems and manage their respective MIB objects.
To use an NMS to manage the access controller engine and the switching engine from the same user interface:
1. Obtain the management IP addresses of the two SNMP agents. The management IP address of an SNMP agent is the IP address of its VLAN-interface 1.
2. Configure the other SNMP agent's management IP address on each SNMP agent.
3. Guarantee the connectivity between the two management IP addresses.
By default, both the access controller engine and the switching engine are configured with the other SNMP agent's management IP address. You can manage them on the same user interface.
For more information about how to manage the access controller engine and the switching engine from the same user interface, see H3C WX5540E Access Controller Switching Engine Web-Based Configuration Guide.
Configuration procedure
To configure a management IP address:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Configure a management IP address. |
oap management-ip ip-address slot slot-number |
The defaults are as follows: · 192.168.0.100/24 for the access controller engine. 192.168.0.101/24 for the switching engine. |
Configuration example
In this example, the device names of the access controller engine and the switching engine are AC and device_LSW, respectively.
# On the access controller engine, assign an IP address to VLAN-interface 1.
<AC>system-view
[AC]interface Vlan-interface 1
[AC-Vlan-interface1]ip address 192.168.0.100 24
# Log in to the switching engine, and configure the management IP address of the access controller engine on the switching engine.
<AC>oap connect slot 0
Connected to OAP!
<device_LSW>system-view
[device_LSW]oap management-ip 192.168.0.100 slot 1
# Assign an IP address to VLAN-interface 1 on the switching engine.
<device_LSW>system-view
[device_LSW]interface Vlan-interface 1
[device_LSW-Vlan-interface1]ip address 192.168.0.101 24
# Return to the access controller engine, and configure the management IP address of the switching engine on the access controller engine.
<AC>system-view
[AC]oap management-ip 192.168.0.101 slot 0
Resetting the OAP system
|
|
CAUTION: The reset operation might cause data loss and service interruption. Before performing this operation, save the service data of the operating system and shut down the operating system. |
If the operating system of the switching engine fails or cannot operate correctly, you can reset the OAP system from the access controller engine to correct the problem.
To reset the system of the firewall module:
|
Task |
Command |
Remarks |
|
Reset the OAP system |
oap reboot slot 0 |
Available in the user view of the access controller engine. |
Logging in through Telnet
You can Telnet to the device through a VTY user interface for remote management, or use the device as a Telnet client to Telnet to other devices, as shown in Figure 1.

By default, you can Telnet to the switching engine by using the following parameters:
· Username admin.
· Password admin.
· IP address 192.168.0.101.
After login, you are assigned the user privilege level 3.
Table 3 shows the Telnet server and client configuration required for a successful Telnet login.
Table 3 Telnet server and Telnet client configuration requirements
|
Object |
Requirements |
|
Telnet server |
Assign an IP address to a Layer 3 interface, and make sure the Telnet server and client can reach each other. Configure the authentication mode and other settings. |
|
Telnet client |
Run the Telnet client program. Obtain the IP address of the Layer 3 interface on the server. Configure other settings. |
To control Telnet access to the device when the device acts as a Telnet server, you can configure authentication and user privilege levels for Telnet users. By default, password authentication applies to Telnet login, but no login password is configured. To allow Telnet access to the device after you enable the Telnet server, you must configure a password.
The following are authentication modes available for controlling Telnet logins:
· None—Requires no authentication and is insecure.
· Password—Requires a password for accessing the CLI. If your password was lost, log in to the device through OAP and re-set the password.
· Scheme—Uses the AAA module to provide local or remote authentication. You must provide a username and password for accessing the CLI. If the password configured in the local user database was lost, log in to the device through OAP and re-set the password. If the username or password configured on a remote server was lost, contact the server administrator for help.
Table 4 Configuration required for different Telnet login authentication modes
|
Authentication mode |
Configuration tasks |
Reference |
|
None |
Set the authentication mode to none for the VTY user interface. |
|
|
Password |
Enable password authentication on the VTY user interface. Set a password. |
|
|
AAA |
Enable scheme authentication on the VTY user interface. Configure local or remote authentication settings. To configure local authentication: 1. Configure a local user and specify the password. 2. Configure the device to use local authentication. To configure remote authentication: 1. Configure the RADIUS or HWTACACS scheme on the device. 2. Configure the username and password on the AAA server. 3. Configure the device to use the scheme for user authentication. |
Configuring none authentication for Telnet login
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable Telnet server. |
telnet server enable |
By default, the Telnet server is enabled. |
|
3. Enter one or multiple VTY user interface views. |
user-interface vty first-number [ last-number ] |
N/A |
|
4. Enable the none authentication mode. |
authentication-mode none |
By default, authentication mode for VTY user interfaces is password. |
|
5. Configure the command level for login users on the current user interfaces. |
user privilege level level |
By default, the default command level is 0 for VTY user interfaces. |
|
6. Configure common settings for the VTY user interfaces. |
See "Configuring common settings for VTY user interfaces (optional)." |
Optional. |
The next time you attempt to Telnet to the device, you do not need to provide any username or password. If the maximum number of login users has been reached, your login attempt fails and the message "All user interfaces are used, please try later!" appears.
Configuring password authentication for Telnet login
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable Telnet. |
telnet server enable |
By default, the Telnet service is enabled. |
|
3. Enter one or multiple VTY user interface views. |
user-interface vty first-number [ last-number ] |
N/A |
|
4. Enable password authentication. |
authentication-mode password |
By default, password authentication is enabled for VTY user interfaces. |
|
5. Set a password. |
set authentication password [ hash ] { cipher | simple } password |
By default, no password is set. |
|
6. Configure the user privilege level for login users. |
user privilege level level |
The default level is 0. |
|
7. Configure common settings for VTY user interfaces. |
See "Configuring common settings for VTY user interfaces (optional)." |
Optional. |
The next time you attempt to Telnet to the device, you must provide the configured login password. If the maximum number of login users has been reached, your login attempt fails and the message "All user interfaces are used, please try later!" appears.
Configuring scheme authentication for Telnet login
Follow these guidelines when you configure scheme authentication for Telnet login:
· To make the command authorization or command accounting function take effect, apply an HWTACACS scheme to the intended ISP domain. This scheme must specify the IP address of the authorization server and other authorization parameters.
· If the local authentication scheme is used, use the authorization-attribute level level command in local user view to set the user privilege level on the device.
· If a RADIUS or HWTACACS authentication scheme is used, set the user privilege level on the RADIUS or HWTACACS server.
To configure scheme authentication for Telnet login:
|
Step |
Command |
Remarks |
|
|
1. Enter system view. |
system-view |
N/A |
|
|
2. Enable Telnet. |
telnet server enable |
By default, the Telnet service is enabled. |
|
|
3. Enter one or multiple VTY user interface views. |
user-interface vty first-number [ last-number ] |
N/A |
|
|
4. Enable scheme authentication. |
authentication-mode scheme |
By default, local authentication is adopted. If local authentication is used and password control is enabled, a user must change the password after being logged in for the first time. If NTP synchronization is also configured, H3C recommends waiting for 10 minutes before changing the password to make sure the NTP synchronization is finished before the password is created. |
|
|
5. Enable command authorization. |
command authorization |
Optional. By default, command authorization is disabled. The commands available for a user only depend on the user privilege level. If command authorization is enabled, a command is available only if the user has the commensurate user privilege level and is authorized to use the command by the AAA scheme. |
|
|
6. Enable command accounting. |
command accounting |
Optional. By default, command accounting is disabled. The accounting server does not record the commands executed by users. Command accounting allows the HWTACACS server to record all executed commands that are supported by the device, regardless of the command execution result. This function helps control and monitor user behaviors on the device. If command accounting is enabled and command authorization is not enabled, every executed command is recorded on the HWTACACS server. If both command accounting and command authorization are enabled, only the authorized and executed commands are recorded on the HWTACACS server. |
|
|
7. Exit to system view. |
quit |
N/A |
|
|
8. Apply an AAA authentication scheme to the intended domain. |
a.
Enter ISP domain view: b.
Apply an AAA scheme to the domain: c.
Exit to system view: |
Optional. By default, local authentication is used. For local authentication, configure local user accounts. For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme on the device and configure authentication settings (including the username and password) on the server. For more information about AAA configuration, see Security Configuration Guide. |
|
|
9. Create a local user and enter local user view. |
local-user user-name |
By default, no local user exists. |
|
|
10. Set a password. |
password { cipher | simple } password |
By default, no password is set. |
|
|
11. Specify the command level of the local user. |
authorization-attribute level level |
Optional. By default, the command level is 0. |
|
|
12. Specify Telnet service for the local user. |
service-type telnet |
By default, no service type is specified. |
|
|
13. Exit to system view. |
quit |
N/A |
|
|
14. Configure common settings for VTY user interfaces. |
See "Configuring common settings for VTY user interfaces (optional)." |
Optional. |
|
The next time you attempt to Telnet to the CLI, you must provide the configured login username and password. If you are required to pass a second authentication, you must also provide the correct password to access the CLI. If the maximum number of login users has been reached, your login attempt fails and the message "All user interfaces are used, please try later!" appears.
Configuring common settings for VTY user interfaces (optional)
You might be unable to access the CLI through a VTY user interface after configuring the auto-execute command command on it. Before you configure the command and save the configuration, make sure you can access the CLI through a different user interface.
To configure common settings for VTY user interfaces:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter one or multiple VTY user interface views. |
user-interface vty first-number [ last-number ] |
N/A |
|
3. Enable the terminal service. |
shell |
Optional. By default, terminal service is enabled. |
|
4. Enable the user interfaces to support Telnet, SSH, or both of them. |
protocol inbound { all | ssh | telnet } |
Optional. By default, both Telnet and SSH are supported. The configuration takes effect the next time you log in. |
|
5. Define a shortcut key for terminating tasks. |
escape-key { default | character } |
Optional. By default, pressing Ctrl+C terminates a task. |
|
6. Configure the type of terminal display. |
terminal type { ansi | vt100 } |
Optional. By default, the terminal display type is ANSI. |
|
7. Set the maximum number of lines to be displayed on a screen. |
screen-length screen-length |
Optional. By default, a screen displays 24 lines. A value of 0 disables the function. |
|
8. Set the size of command history buffer. |
history-command max-size value |
Optional. By default, the buffer saves 10 history commands. |
|
9. Set the idle-timeout timer. |
idle-timeout minutes [ seconds ] |
Optional. The default idle-timeout is 10 minutes for all user interfaces. The system automatically terminates the user's connection if there is no information interaction between the device and the user within the timeout time. Setting idle-timeout to 0 disables the timer. |
|
10. Specify a command to be automatically executed when a user logs in to the user interfaces. |
auto-execute command command |
Optional. By default, no automatically executed command is specified. The command auto-execute function is typically used for redirecting a Telnet user to a specific host. After executing the specified command and performing the incurred task, the system automatically disconnect the Telnet session. |
Setting the DSCP value for outgoing Telnet packets when the device acts as the Telnet server
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Set the DSCP value for outgoing Telnet packets when the device acts as the Telnet server. |
telnet server dscp dscp-value |
The default DSCP value is 48. |
Using the device to log in to a Telnet server
You can use the device as a Telnet client to log in to a Telnet server. If the server is located in a different subnet than the device, make sure the two devices have routes to reach each other.
Figure 2 Telnetting from the device to a Telnet server

To use the device to log in to a Telnet server:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Specify a source IPv4 address or source interface for outgoing Telnet packets. |
telnet client source { interface interface-type interface-number | ip ip-address } |
Optional. By default, no source IPv4 address or source interface is specified. The IP address of the outbound interface is used as the source IPv4 address. |
|
3. Exit to user view. |
quit |
N/A |
|
4. Use the device to log in to a Telnet server. |
telnet remote-host [ service-port ] [ source { interface interface-type interface-number | ip ip-address } ] |
N/A |
Setting the DSCP value for outgoing Telnet packets when the device acts as the Telnet client
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Set the DSCP value for outgoing Telnet packets when the device acts as the Telnet client. |
telnet client dscp dscp-value |
The default DSCP value is 16. |
Logging in through SSH
SSH offers a secure approach to remote login. By providing encryption and strong authentication, it protects devices against attacks such as IP spoofing and plaintext password interception. You can log in to the device acting as an SSH server for remote management, as shown in Figure 3. You can also use the device as an SSH client to log in to an SSH server.

Table 5 shows the SSH server and client configuration required for a successful SSH login.
Table 5 SSH server and client requirements
|
Device role |
Requirements |
|
SSH server |
Assign an IP address to a Layer 3 interface, and make sure the interface and the client can reach each other. Configure the authentication mode and other settings. |
|
SSH client |
If the host operates as an SSH client, run the SSH client program on the host. Obtain the IP address of the Layer 3 interface on the server. |
To control SSH access to the device acting as an SSH server, configure authentication and user privilege level for SSH users.
By default, password authentication is adopted for SSH login, but no login password is configured. To allow SSH access to the device after you enable the SSH server, you must configure a password.
Configuring the SSH server on the device
Follow these guidelines when you configure the SSH server:
· To make the command authorization or command accounting function take effect, apply an HWTACACS scheme to the intended ISP domain. This scheme must specify the IP address of the authorization server and other authorization parameters.
· If the local authentication scheme is used, use the authorization-attribute level level command in local user view to set the user privilege level on the device.
· If a RADIUS or HWTACACS authentication scheme is used, set the user privilege level on the RADIUS or HWTACACS server.
The SSH client authentication method is password in this configuration procedure. For more information about SSH and publickey authentication, see Security Configuration Guide.
To configure the SSH server on the device:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Create local key pairs. |
public-key local create { dsa | rsa } |
By default, no local key pairs are created. |
|
3. Enable SSH server. |
ssh server enable |
By default, SSH server is disabled. |
|
4. Enter one or more VTY user interface views. |
user-interface vty first-number [ last-number ] |
N/A |
|
5. Enable scheme authentication. |
authentication-mode scheme |
By default, password authentication is enabled on VTY user interfaces. |
|
6. Enable the user interfaces to support Telnet, SSH, or both of them. |
protocol inbound { all | ssh | telnet } |
Optional. By default, both Telnet and SSH are supported. |
|
7. Enable command authorization. |
command authorization |
Optional. By default, command authorization is disabled. The commands available for a user only depend on the user privilege level. If command authorization is enabled, a command is available only if the user has the commensurate user privilege level and is authorized to use the command by the AAA scheme. |
|
8. Enable command accounting. |
command accounting |
Optional. By default, command accounting is disabled. The accounting server does not record the commands executed by users. Command accounting allows the HWTACACS server to record all executed commands that are supported by the device, regardless of the command execution result. This function helps control and monitor user behaviors on the device. If command accounting is enabled and command authorization is not enabled, every executed command is recorded on the HWTACACS server. If both command accounting and command authorization are enabled, only the authorized and executed commands are recorded on the HWTACACS server. |
|
9. Exit to system view. |
quit |
N/A |
|
10. Apply an AAA authentication scheme to the intended domain. |
a.
Enter the ISP domain view: b.
Apply the specified AAA scheme to the domain: c.
Exit to system view: |
Optional. For local authentication, configure local user accounts. For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme on the device and configure authentication settings (including the username and password) on the server. For more information about AAA configuration, see Security Configuration Guide. |
|
11. Create a local user and enter local user view. |
local-user user-name |
By default, no local user exists. |
|
12. Set a password for the local user. |
password { cipher | simple } password |
By default, no password is set. |
|
13. Specify the command level of the user. |
authorization-attribute level level |
Optional. By default, the command level is 0. |
|
14. Specify SSH service for the user. |
service-type ssh |
By default, no service type is specified. |
|
15. Exit to system view. |
quit |
N/A |
|
16. Create an SSH user, and specify the authentication mode for the SSH user. |
ssh user username service-type stelnet authentication-type { password | { any | password-publickey | publickey } assign publickey keyname } |
N/A |
|
17. Configure common settings for VTY user interfaces. |
See "Configuring common settings for VTY user interfaces (optional)." |
Optional. |
Using the device as an SSH client to log in to the SSH server
You can use the device as an SSH client to log in to an SSH server. If the server is located in a different subnet than the device, make sure the two devices have routes to reach each other.
Figure 4 Logging in to an SSH server from the device

To use the device as an SSH client to log in to an SSH server, perform the following tasks in user view:
|
Task |
Command |
Remarks |
|
Log in to an IPv4 SSH server. |
ssh2 server |
The server argument represents the IPv4 address or host name of the server. |
To work with the SSH server, you might need to configure the SSH client. For information about configuring the SSH client, see Security Configuration Guide.
Displaying and maintaining CLI login
|
Task |
Command |
Remarks |
|
Display information about the user interfaces that are being used. |
display users [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
|
Display information about all user interfaces the device supports. |
display users all [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
|
Display user interface information. |
display user-interface [ num1 | { aux | vty } num2 ] [ summary ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
|
Display the configuration of the device when it serves as a Telnet client. |
display telnet client configuration [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
|
Release a user interface. |
free user-interface { num1 | { aux | vty } num2 } |
Available in user view. Multiple users can log in to the system to simultaneously configure the device. You can execute the command to release the connections established on the specified user interfaces. You cannot use this command to release the connection you are using. |
|
Lock the current user interface. |
lock |
Available in user view. By default, the system does not automatically lock a user interface. |
|
Send messages to the specified user interfaces. |
send { all | num1 | { aux | vty } num2 } |
Available in user view. |
The device provides a built-in Web server for you to configure the device through a Web browser. Web login is enabled by default. The default Web login settings are as follows:
· Username admin.
· Password admin.
· IP address 192.168.0.101.
· User privilege level 3.
To configure Web login, log in through OAP and perform the following configuration tasks:
· Enable HTTP or HTTPS service.
· Configure the IP address of a Layer 3 interface, and make sure the interface and the configuration terminal can reach each other.
· Configure a local user account for Web login.
The device supports HTTP 1.0 and HTTPS for transferring webpage data across the Internet.
HTTPS uses SSL to encrypt data between the client and the server for data integrity and security, and is more secure than HTTP. You can define a certificate attribute-based access control policy to allow only legal clients to access the device.
HTTP login and HTTPS login are separate login methods. To use HTTPS login, you do not need to configure HTTP login.
Table 6 shows the basic Web login configuration requirements.
Table 6 Basic Web login configuration requirements
|
Object |
Requirements |
|
Device |
Configure an IP address for a Layer 3 interface. Configuring routes to make sure the interface and the PC can reach each other.
Perform either or both of the following tasks: |
|
PC |
Install a Web browser. Obtain the IP address of the device's Layer 3 interface. |
Configuring HTTP login
|
Step |
Command |
Remarks |
|
1. Specify a fixed verification code for Web login. |
web captcha verification-code |
Optional. By default, a Web user must enter the verification code indicated on the login page to log in. This command is available in user view. |
|
2. Enter system view. |
system-view |
N/A |
|
3. Enable the HTTP service. |
ip http enable |
By default, HTTP service is enabled. |
|
4. Configure the HTTP service port number. |
ip http port port-number |
Optional. The default HTTP service port is 80. If you execute the command multiple times, the last one takes effect. |
|
5. Associate the HTTP service with an ACL. |
ip http acl acl-number |
Optional. By default, the HTTP service is not associated with any ACL. Associating the HTTP service with an ACL enables the device to allow only clients permitted by the ACL to access the device. |
|
6. Set the Web connection timeout time. |
web idle-timeout minutes |
Optional. By default, the Web connection timeout time is 10 minutes. |
|
7. Set the size of the buffer for Web login logging. |
web logbuffer size pieces |
Optional. By default, the buffer can store up to 512 logs. |
|
8. Create a local user and enter local user view. |
local-user user-name |
By default, no local user is configured. |
|
9. Configure a password for the local user. |
password { cipher | simple } password |
By default, no password is configured for the local user. |
|
10. Specify the command level of the local user. |
authorization-attribute level level |
No command level is configured for the local user. |
|
11. Specify the Telnet service type for the local user. |
service-type web |
By default, no service type is configured for the local user. |
|
12. Set the DSCP value for IP to use for HTTP packets. |
ip http dscp dscp-value |
Optional. The default DSCP value is 16. |
|
13. Exit to system view. |
quit |
N/A |
|
14. Create a VLAN interface and enter its view. |
interface vlan-interface vlan-interface-id |
If the VLAN interface already exists, the command enters its view. |
|
15. Assign an IP address and subnet mask to the interface. |
ip address ip-address { mask | mask-length } |
By default, no IP address is assigned to the interface. |
Configuring HTTPS login
The device supports the following HTTPS login modes:
· Simplified mode—To make the device operate in this mode, you only need to enable HTTPS service on the device. The device will use a self-signed certificate (a certificate that is generated and signed by the device itself, rather than a CA) and the default SSL settings. This mode is simple to configure but has potential security risks.
· Secure mode—To make the device operate in this mode, you must enable HTTPS service on the device, specify an SSL server policy for the service, and configure PKI domain-related parameters. This mode is complicated to configure but provides higher security.
For more information about SSL and PKI, see Security Configuration Guide.
Follow these guidelines when you configure HTTPS login:
· If the HTTPS service and the SSL VPN service use the same port number, they must have the same SSL server policy. Otherwise, only one of the two services can be enabled.
· If the HTTPS service and the SSL VPN service use the same port number and the same SSL server policy, disable the two services before you modify the SSL server policy, and re-enable them after the modification. Otherwise, the SSL server policy does not take effect.
To configure HTTPS login:
|
Step |
Command |
Remarks |
|
1. Specify a fixed verification code for Web login. |
web captcha verification-code |
Optional. By default, a Web user must enter the verification code indicated on the login page to log in. This command is available in user view. |
|
2. Enter system view. |
system-view |
N/A |
|
3. Associate the HTTPS service with an SSL server policy. |
ip https ssl-server-policy policy-name |
Optional. By default, the HTTPS service is not associated with any SSL server policy, and the device uses a self-signed certificate for authentication. If you disable the HTTPS service, the system automatically de-associates the HTTPS service from the SSL service policy. Before re-enabling the HTTPS service, associate the HTTPS service with an SSL server policy first. If the HTTPS service has been enabled, any changes to the SSL server policy associated with the HTTP service that is enabled do not take effect. |
|
4. Enable the HTTPS service. |
ip https enable |
By default, HTTPS is disabled. Enabling the HTTPS service triggers an SSL handshake negotiation process. During the process, if the local certificate of the device exists, the SSL negotiation succeeds, and the HTTPS service can be started properly. If no local certificate exists, a certificate application process will be triggered by the SSL negotiation. Because the application process takes much time, the SSL negotiation often fails and the HTTPS service cannot be started normally. In that case, execute the ip https enable command multiple times to start the HTTPS service. |
|
5. Associate the HTTPS service with a certificate attribute-based access control policy. |
ip https certificate access-control-policy policy-name |
Optional. By default, the HTTPS service is not associated with any certificate-based attribute access control policy. Associating the HTTPS service with a certificate-based attribute access control policy enables the device to control the access rights of clients. You must configure the client-verify enable command in the associated SSL server policy. If not, no clients can log in to the device. The associated SSL server policy must contain at least one permit rule. Otherwise, no clients can log in to the device. For more information about certificate attribute-based access control policies, see Security Configuration Guide. |
|
6. Specify the HTTPS service port number. |
ip https port port-number |
Optional. The default HTTPS service port is 443. |
|
7. Associate the HTTPS service with an ACL. |
ip https acl acl-number |
By default, the HTTPS service is not associated with any ACL. Associating the HTTPS service with an ACL enables the device to allow only clients permitted by the ACL to access the device. |
|
8. Specify the authentication mode for users trying to log in to the device through HTTPS. |
web https-authorization mode { auto | manual } |
Optional. By default, a user must enter the correct username and password to log in through HTTPS. When the auto mode is enabled: · If the user's PKI certificate is correct and not expired, the CN field in the certificate is used as the username to perform AAA authentication. If the authentication succeeds, the user automatically enters the Web interface of the device. · If the user's PKI certificate is correct and not expired, but the AAA authentication fails, the device shows the Web login page. The user can log in to the device after entering correct username and password. |
|
9. Set the Web user connection timeout time. |
web idle-timeout minutes |
Optional. By default, the Web connection timeout time is 10 minutes. |
|
10. Set the size of the buffer for Web login logging. |
web logbuffer size pieces |
Optional. By default, the buffer can store up to 512 logs. |
|
11. Create a local user and enter local user view. |
local-user user-name |
By default, no local user is configured. |
|
12. Configure a password for the local user. |
password { cipher | simple } password |
By default, no password is configured for the local user. |
|
13. Specify the command level of the local user. |
authorization-attribute level level |
By default, no command level is configured for the local user. |
|
14. Specify the Web service type for the local user. |
service-type web |
By default, no service type is configured for the local user. |
|
15. Exit to system view. |
quit |
N/A |
|
16. Create a VLAN interface and enter its view. |
interface vlan-interface vlan-interface-id |
If the VLAN interface already exists, the command enters its view. You could replace this VLAN interface with any other Layer 3 interface as appropriate. |
|
17. Assign an IP address and subnet mask to the interface. |
ip address ip-address { mask | mask-length } |
By default, no IP address is assigned to the interface. |
Displaying and maintaining Web login
|
Task |
Command |
Remarks |
|
Display information about Web users. |
display web users [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
|
Display HTTP state information. |
display ip http [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
|
Display HTTPS state information. |
display ip https [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
HTTP login configuration example
Network requirements
As shown in Figure 5, configure the device to allow the PC to log in over the IP network by using HTTP.

Configuration procedure
1. Configure the device:
# Create VLAN 999, and add GigabitEthernet 1/0/1 (the interface connected to the PC) to VLAN 999.
<Sysname> system-view
[Sysname] ip http enable
[Sysname] vlan 999
[Sysname-vlan999] port GigabitEthernet 1/0/1
[Sysname-vlan999] quit
# Assign the IP address 192.168.0.58 and the subnet mask 255.255.255.0 to VLAN-interface 999.
[Sysname] interface vlan-interface 999
[Sysname-VLAN-interface999] ip address 192.168.0.58 255.255.255.0
[Sysname-VLAN-interface999] quit
# Create a local user named admin, and set the password to admin for the user. Specify the Web service type for the local user, and set the command level to 3 for this user.
[Sysname] local-user admin
[Sysname-luser-admin] service-type web
[Sysname-luser-admin] authorization-attribute level 3
[Sysname-luser-admin] password simple admin
2. Verify the configuration:
# On the PC, run the Web browser. Enter the IP address of the device in the address bar. The Web login page appears, as shown in Figure 6.

# Enter the user name, password, verify code, select English, and click Login. The homepage appears. After login, you can configure device settings through the Web interface.
HTTPS login configuration example
Network requirements
As shown in Figure 7, to prevent unauthorized users from accessing the device, configure the device as the HTTPS server and the host as the HTTPS client, and request a certificate for each of them.

Configuration procedure
This example assumes that the CA is named new-ca, runs Windows Server, and is installed with the SCEP add-on. This example also assumes that the device, host, and CA can reach one other.
1. Configure the device (HTTPS server):
# Configure a PKI entity, configure the common name of the entity as http-server1, and the FQDN of the entity as ssl.security.com.
<Device> system-view
[Device] pki entity en
[Device-pki-entity-en] common-name http-server1
[Device-pki-entity-en] fqdn ssl.security.com
[Device-pki-entity-en] quit
# Create a PKI domain, specify the trusted CA as new-ca, the URL of the server for certificate request as http://10.1.2.2/certsrv/mscep/mscep.dll, authority for certificate request as RA, and the entity for certificate request as en.
[Device] pki domain 1
[Device-pki-domain-1] ca identifier new-ca
[Device-pki-domain-1] certificate request url http://10.1.2.2/certsrv/mscep/mscep.dll
[Device-pki-domain-1] certificate request from ra
[Device-pki-domain-1] certificate request entity en
[Device-pki-domain-1] quit
# Create RSA local key pairs.
[Device] public-key loc al create rsa
# Retrieve the CA certificate from the certificate issuing server.
[Device] pki retrieval-certificate ca domain 1
# Request a local certificate from a CA through SCEP for the device.
[Device] pki request-certificate domain 1
# Create an SSL server policy myssl, specify PKI domain 1 for the SSL server policy, and enable certificate-based SSL client authentication.
[Device] ssl server-policy myssl
[Device-ssl-server-policy-myssl] pki-domain 1
[Device-ssl-server-policy-myssl] client-verify enable
[Device-ssl-server-policy-myssl] quit
# Create a certificate attribute group mygroup1, and configure a certificate attribute rule, specifying that the DN in the subject name includes the string of new-ca.
[Device] pki certificate attribute-group mygroup1
[Device-pki-cert-attribute-group-mygroup1] attribute 1 issuer-name dn ctn new-ca
[Device-pki-cert-attribute-group-mygroup1] quit
# Create a certificate attribute-based access control policy myacp. Configure a certificate attribute-based access control rule, specifying that a certificate is considered valid when it matches an attribute rule in certificate attribute group myacp.
[Device] pki certificate access-control-policy myacp
[Device-pki-cert-acp-myacp] rule 1 permit mygroup1
[Device-pki-cert-acp-myacp] quit
# Associate the HTTPS service with SSL server policy myssl.
[Device] ip https ssl-server-policy myssl
# Associate the HTTPS service with certificate attribute-based access control policy myacp.
[Device] ip https certificate access-control-policy myacp
# Enable the HTTPS service.
[Device] ip https enable
# Create a local user named usera, set the password to 123, specify the Web service type, and specify the user privilege level 3. A level-3 user can perform all operations supported by the device.
[Device] local-user usera
[Device-luser-usera] password simple 123
[Device-luser-usera] service-type web
[Device-luser-usera] authorization-attribute level 3
2. Configure the host (HTTPS client):
On the host, run the IE browser, and then enter http://10.1.2.2/certsrv in the address bar and request a certificate for the host as prompted.
3. Verify the configuration:
Enter https://10.1.1.1 in the address bar, and select the certificate issued by new-ca. When the Web login page of the device appears, enter the username usera and password 123 to log in to the Web management page.
For more information about PKI configuration commands, SSL configuration commands, and the public-key local create rsa command, see Security Command Reference.
You can use an NMS to access the device MIB and perform GET and SET operations to manage and monitor the device. The device supports SNMPv1, SNMPv2c, and SNMPv3, and can work with various network management software products, including IMC. For more information about SNMP, see Network Management and Monitoring Configuration Guide.
By default, SNMP access is disabled. To enable SNMP access, log in to the device through any other method.
Configuring SNMP login
Connect the PC (the NMS) and the device to the network, making sure they can reach each other, as shown in Figure 8.

|
IMPORTANT: This document describes only the basic SNMP configuration procedures on the device. To make SNMP work correctly, make sure the SNMP settings (including the SNMP version) on the NMS are consistent with those on the device. |
Prerequisites
· Assign an IP address to a Layer 3 interface on the device.
· Configure routes to make sure the NMS and the Layer 3 interface can reach each other.
Configuring SNMPv3 settings
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable the SNMP agent. |
snmp-agent |
Optional. By default, the SNMP agent is disabled. You can enable SNMP agent with this command or any command that begins with snmp-agent. |
|
3. Configure an SNMP group and specify its access right. |
snmp-agent group v3 group-name [ authentication | privacy ] [ read-view read-view ] [ write-view write-view ] [ notify-view notify-view ] [ acl acl-number ] |
By default, no SNMP group is configured. |
|
4. Add a user to the SNMP group. |
snmp-agent usm-user v3 user-name group-name [ [ cipher ] authentication-mode { md5 | sha } auth-password [ privacy-mode { 3des | aes128 | des56 } priv-password ] ] [ acl acl-number ] |
N/A |
Configuring SNMPv1 or SNMPv2c settings
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable the SNMP agent. |
snmp-agent |
Optional. By default, the SNMP agent is disabled. You can enable SNMP agent with this command or any command that begins with snmp-agent. |
|
3. Create or update MIB view information. |
snmp-agent mib-view { excluded | included } view-name oid-tree [ mask mask-value ] |
Optional. By default, the MIB view name is ViewDefault and OID is 1. |
|
4. Configure SNMP NMS access right. |
·
(Approach 1) Specify the SNMP NMS access right
directly by configuring an SNMP community: · (Approach 2) Configure an SNMP group and add a user to the SNMP group: a. snmp-agent group { v1 | v2c } group-name [ read-view read-view ] [ write-view write-view ] [ notify-view notify-view ] [ acl acl-number ] b. snmp-agent usm-user { v1 | v2c } user-name group-name [ acl acl-number ] |
Use either approach. The direct configuration approach is for SNMPv1 or SNMPv2c. The community name configured on the NMS should be consistent with the username configured on the agent. The indirect configuration approach is for SNMPv3. |
NMS login example
Network requirements
Configure the device and network management station so you can remotely manage the device through SNMPv3.
Figure 9 Network diagram

Configuration procedure
1. Configure the device:
# Assign an IP address to the device. Make sure the device and the NMS can reach each other. (Details not shown.)
# Enter system view.
<Sysname> system-view
# Enable the SNMP agent.
[Sysname] snmp-agent
# Configure an SNMP group.
[Sysname] snmp-agent group v3 managev3group
# Add a user to the SNMP group.
[Sysname] snmp-agent usm-user v3 managev3user managev3group
2. Configure the NMS:
Make sure the NMS has the same SNMP settings, including the username as the device. If not, the device cannot be discovered or managed by the NMS.
Use the network management station to discover, query, and configure the device. For more information, see the NMS manual.
To harden device security, use ACLs to prevent unauthorized logins. For more information about ACLs, see ACL and QoS Configuration Guide.
Controlling Telnet logins
Use a basic ACL (2000 to 2999) to filter Telnet traffic by source IP address. Use an advanced ACL (3000 to 3999) to filter Telnet traffic by source and/or destination IP address. Use an Ethernet frame header ACL (4000 to 4999) to filter Telnet traffic by source MAC address.
To access the device, a Telnet user must match a permit statement in the ACL applied to the user interface.
Configuring source IP-based Telnet login control
|
Command |
Remarks |
|
|
1. Enter system view. |
system-view |
N/A |
|
2. Create a basic ACL and enter its view, or enter the view of an existing basic ACL. |
acl number acl-number [ name name ] [ match-order { config | auto } ] |
By default, no basic ACL exists. |
|
3. Configure an ACL rule. |
rule [ rule-id ] { deny | permit } [ counting | fragment | logging | source { sour-addr sour-wildcard | any } | time-range time-range-name ] * |
By default, a basic ACL does not contain any rule. |
|
Exit the basic ACL view. |
quit |
N/A |
|
5. Enter user interface view. |
user-interface [ type ] first-number [ last-number ] |
N/A |
|
6. Use the ACL to control user logins by source IP address. |
acl acl-number { inbound | outbound } |
· inbound: Filters incoming packets. · outbound: Filters outgoing packets. |
Configuring source/destination IP-based Telnet login control
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
Create an advanced ACL and enter its view, or enter the view of an existing advanced ACL. |
acl number acl-number [ name name ] [ match-order { config | auto } ] |
By default, no advanced ACL exists. |
|
3. Configure an ACL rule. |
rule [ rule-id ] { permit | deny } rule-string |
N/A |
|
4. Exit advanced ACL view. |
quit |
N/A |
|
5. Enter user interface view. |
user-interface [ type ] first-number [ last-number ] |
N/A |
|
6. Use the ACL to control user logins by source and destination IP addresses. |
acl acl-number { inbound | outbound } |
· inbound: Filters incoming packets. outbound: Filters outgoing packets. |
Configuring source MAC-based Telnet login control
Ethernet frame header ACLs apply to Telnet traffic only if the Telnet client and server are located in the same subnet.
To configure source MAC-based Telnet login control:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Create an Ethernet frame header ACL and enter its view. |
acl number acl-number [ name name ] [ match-order { config | auto } ] |
By default, no Ethernet frame header ACL exists. |
|
3. Configure an ACL rule. |
rule [ rule-id ] { permit | deny } rule-string |
N/A |
|
4. Exit Ethernet frame header ACL view. |
quit |
N/A |
|
5. Enter user interface view. |
user-interface [ type ] first-number [ last-number ] |
N/A |
|
6. Use the ACL to control user logins by source MAC address. |
acl acl-number inbound |
inbound: Filters incoming packets. |
Telnet login control configuration example
Network requirements
As shown in Figure 10, configure an ACL on the device to permit only incoming Telnet packets sourced from Host A and Host B.

Configuration procedure
# Configure basic ACL 2000, and configure rule 1 to permit packets sourced from Host B, and rule 2 to permit packets sourced from Host A.
<Sysname> system-view
[Sysname] acl number 2000 match-order config
[Sysname-acl-basic-2000] rule 1 permit source 10.110.100.52 0
[Sysname-acl-basic-2000] rule 2 permit source 10.110.100.46 0
[Sysname-acl-basic-2000] quit
# Reference ACL 2000 in user interface view to allow Telnet users from Host A and Host B to access the Device.
[Sysname] user-interface vty 0 4
[Sysname-ui-vty0-4] acl 2000 inbound
Configuring source IP-based SNMP login control
Use a basic ACL (2000 to 2999) to control SNMP logins by source IP address. To access the requested MIB view, an NMS must use a source IP address permitted by the ACL.
Configuration procedure
To configure source IP-based SNMP login control:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Create a basic ACL and enter its view, or enter the view of an existing basic ACL. |
acl number acl-number [ name name ] [ match-order { config | auto } ] |
By default, no basic ACL exists. |
|
3. Create an ACL rule. |
rule [ rule-id ] { deny | permit } [ counting | fragment | logging | source { sour-addr sour-wildcard | any } | time-range time-range-name ] * |
N/A |
|
4. Exit the basic ACL view. |
quit |
N/A |
|
5. Apply the ACL to an SNMP community, group or user. |
·
SNMPv1/v2c community: ·
SNMPv1/v2c group: ·
SNMPv3 group: ·
SNMPv1/v2c user: ·
SNMPv3 user: |
For more information about SNMP, see Network Management and Monitoring Configuration Guide. |
SNMP login control configuration example
Network requirements
As shown in Figure 11, configure the device to allow only NMS users from Host A and Host B to access.

Configuration procedure
# Create ACL 2000, and configure rule 1 to permit packets sourced from Host B, and rule 2 to permit packets sourced from Host A.
<Sysname> system-view
[Sysname] acl number 2000 match-order config
[Sysname-acl-basic-2000] rule 1 permit source 10.110.100.52 0
[Sysname-acl-basic-2000] rule 2 permit source 10.110.100.46 0
[Sysname-acl-basic-2000] quit
# Associate the ACL with the SNMP community and the SNMP group.
[Sysname] snmp-agent community read aaa acl 2000
[Sysname] snmp-agent group v2c groupa acl 2000
[Sysname] snmp-agent usm-user v2c usera groupa acl 2000
Configuring Web login control
Use a basic ACL (2000 to 2999) to filter HTTP/HTTPS traffic by source IP address for Web login control. To access the device, a Web user must use an IP address permitted by the ACL.
You can also log off suspicious Web users who have been logged in.
Configuring source IP-based Web login control
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Create a basic ACL and enter its view, or enter the view of an existing basic ACL. |
acl number acl-number [ name name ] [ match-order { config | auto } ] |
By default, no basic ACL exists. |
|
3. Create rules for this ACL. |
rule [ rule-id ] { deny | permit } [ counting | fragment | logging | source { sour-addr sour-wildcard | any } | time-range time-range-name ] * |
N/A |
|
Exit the basic ACL view. |
quit |
N/A |
|
5. Associate the HTTP service with the ACL. |
ip http acl acl-number |
Configure either or both of the commands. HTTP login and HTTPS login are separate login methods. To use HTTPS login, you do not need to configure HTTP login. |
|
6. Associate the HTTPS service with the ACL. |
ip https acl acl-number |
Logging off online Web users
|
Task |
Command |
Remarks |
|
Log off online Web users. |
free web-users { all | user-id user-id | user-name user-name } |
Available in user interface view. |
Web login control configuration example
Network requirements
As shown in Figure 12, configure the device to allow only Web users from Host B to access.

Configuration procedure
# Create ACL 2000, and configure rule 1 to permit packets sourced from Host B.
<Sysname> system-view
[Sysname] acl number 2030 match-order config
[Sysname-acl-basic-2030] rule 1 permit source 10.110.100.52 0
# Associate the ACL with the HTTP service so only Web users from Host B are allowed to access the device.
[Sysname] ip http acl 2030
