- Table of Contents
-
- 01-Fundamentals Configuration Guide
- 00-Preface
- 01-CLI configuration
- 02-RBAC configuration
- 03-Login management configuration
- 04-FTP and TFTP configuration
- 05-File system management configuration
- 06-Configuration file management configuration
- 07-Software upgrade configuration
- 08-ISSU configuration
- 09-Emergency shell configuration
- 10-Automatic configuration
- 11-Device management configuration
- 12-MDC configuration
- 13-TCL configuration
- 14-License management
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 03-Login management configuration | 926.91 KB |
Contents
Logging in through the console port for the first device access
Logging in through the console/AUX port locally
Configuring none authentication for console/AUX login
Configuring password authentication for console/AUX login
Configuring scheme authentication for console/AUX login
Configuring common console/AUX user interface settings
Configuring Telnet login on the device
Using the device to log in to a Telnet server
Configuring SSH login on the device
Using the device to log in to an SSH server
Displaying and maintaining CLI login
Accessing the device through SNMP·
Configuring SNMPv1 or SNMPv2c access
Configuring command authorization
Configuring command accounting
The first time you access the device, you can only log in to the CLI of the default MDC through the console port. After login, you can create non-default MDCs, change console login parameters, or configure other login methods including console login, AUX login, Telnet login, SSH login, and SNMP access.
Non-default MDCs have no console or AUX port. To log in to a non-default MDC for the first time, you must log in to the default MDC and then switch to the non-default MDC using the switchto mdc command. After you log in to a non-default MDC, you can configure Telnet login, SSH login, or SNMP access. Then, administrators of the default MDC and those of the non-default MDC can access the non-default MDC through Telnet, SSH, or SNMP.
Table 1 Login methods at a glance
|
Login method |
Default settings and minimum configuration requirements |
|
|
|
||
|
By default, login through the console port is enabled, no username or password is required, and the user role network-admin is assigned. After login, configure password or scheme authentication mode to improve device security. By default, login through the AUX port is enabled and requires a password, but no password is configured. To use the AUX port for login, complete the following configuration tasks: · Log in through any other method and configure a password for password authentication, or change the authentication mode and configure parameters for the new authentication mode. · Assign a user role (network-operator by default). |
||
|
By default, Telnet login is disabled. To Log in through Telnet, complete the following configuration tasks: · Enable the Telnet server function. · Assign an IP address to a Layer 3 interface and make sure the interface and the Telnet client can reach each other. · Configure an authentication mode for VTY login users. By default, password authentication is used but no password is configured. · Assign a user role to VTY login users (network-operator by default). |
||
|
By default, SSH login is disabled. To log in through SSH, complete the following configuration tasks: · Enable the SSH server function and configure SSH attributes. · Assign an IP address to a Layer 3 interface and make sure the interface and the SSH client can reach each other. · Configure scheme authentication for VTY login users (password authentication by default). · Assign a user role to VTY login users (network-operator by default). |
||
|
By default, SNMP access is disabled. To access the device through SNMP, complete the following configuration tasks: · Assign an IP address to a Layer 3 interface, and make sure the interface and the NMS can reach each other. · Configure SNMP basic parameters. |
||
The first time you access the device, you can only log in to the CLI through the console port.
To log in through the console port:
1. Connect the DB-9 female connector of the console cable to the serial port of the PC.
2. Connect the RJ-45 connector of the console cable to the console port of the device.
|
|
IMPORTANT: · Identify the mark on the console port and make sure you are connecting to the correct port. · The serial ports on PCs do not support hot swapping. If the switch has been powered on, always connect the console cable to the PC before connecting it to the switch, and when you disconnect the cable, first disconnect it from the switch. |
Figure 1 Connecting a terminal to the console port
3. If the PC is off, turn on the PC.
4. On the PC, launch the terminal emulation program, create a connection that uses the serial port connected to the device, and set the port properties so the port properties match the following console port default settings:
¡ Bits per second—9600 bps
¡ Flow control—None
¡ Parity—None
¡ Stop bits—1
¡ Data bits—8
Figure 2 through Figure 4 show the configuration procedure on Windows XP HyperTerminal. On Windows Server 2003, add the HyperTerminal program first, and then follow this procedure to log in to the device. On Windows Server 2008, Windows 7, Windows Vista, or another operating system, obtain a third-party terminal control program first, and then follow the user guide or online help to log in to the device.
Figure 2 Creating a connection

Figure 3 Specifying the serial port used to establish the connection

Figure 4 Setting the properties of the serial port

5. Power on the device and press Enter as prompted.
Figure 5 Device CLI
6. At the default user view prompt <H3C>, enter commands to configure the device or view the running status of the device. To get help, enter ?.
By default, you can log in to the CLI only through the console port. To facilitate device management, you can log in to the device through the console port and configure other login methods, including Telnet, SSH, and AUX.
To prevent illegal access to the CLI and control user behaviors, you can configure login authentication, assign user roles, configure command authorization and command accounting, and use ACLs to filter unauthorized logins.
This chapter describes how to configure and use CLI login methods, including login authentication, user roles, and common user interface settings. For more information about command authorization, command accounting, and unauthorized access filtering, see "Controlling user access."
CLI overview
CLI user interfaces
The device uses user interfaces (also called "lines") to manage CLI sessions and monitor user behaviors. You can configure access control settings, including login authentication and user role, 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 |
|
Console user interface |
Console port. |
|
AUX user interface |
AUX port. |
|
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.
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
Every user interface has an absolute number and a relative number for identification.
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 console, 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. The number format is user interface type + number. The console and AUX user interfaces corresponding to the console and AUX ports on the MPU in slot 0 are CON 0 and AUX 0. The console and AUX user interfaces corresponding to the console and AUX ports on the MPU in slot 1 are CON 1 and AUX 1. VTY user interfaces are numbered starting from 0 and incrementing by 1. For example, the first VTY user interface is VTY 0 and the second VTY user interface is VTY 1.
Login authentication modes
You can configure login authentication to prevent illegal access to the device CLI.
The device supports the following login authentication modes:
· None—Requires no authentication. This mode is insecure.
· Password—Requires password authentication. You must provide the correct password at login.
· Scheme—Uses the AAA module to provide local or remote login authentication. You must provide a username and password at login.
Different login authentication modes require different configurations on the user interfaces, as shown in Table 3.
Table 3 Configuration required for different login authentication modes
|
Authentication mode |
Configuration tasks |
|
|
None |
Set the authentication mode to none. |
|
|
Password |
1. Set the authentication mode to password. 2. Set a password. |
|
|
Scheme |
1. Set the authentication mode to scheme. 2. Configure login authentication methods in ISP domain view. For more information, see Security Configuration Guide. |
|
User roles
A user is assigned one or more user roles at login, and a user can access only commands permitted by the assigned user roles. For more information about user roles, see "Configuring RBAC."
The device assigns user roles based on the login authentication mode and login method:
· If none or password authentication is used, the device assigns user roles according to the user role configuration made on the user interface.
· If scheme authentication is used:
¡ For an SSH login user who uses publickey or password-publickey authentication, the device assigns user roles according to the user role configuration made on the user interface.
¡ For other users, the device assigns user roles according to the user role configuration made on the AAA module. For remote AAA authentication users, if the AAA server does not assign any user role to a user and the default user role function is disabled, the user cannot log in.
Logging in through the console/AUX port locally
You can connect a terminal to the console or AUX port of the device to log in and manage the device, as shown in Figure 6. For the login procedure, see "Logging in through the console port for the first device access."
Figure 6 Logging in through the console or AUX port

By default, console login is enabled and does not require authentication. To improve device security, configure the password or scheme authentication mode and assign user roles as required immediately after you log in to the device for the first time.
By default, login through the AUX port is enabled and requires a password, but no password is configured. To log in to the device locally through the AUX port, you must log in to the device through any other method and configure AUX login first.
To configure console/AUX login, complete the following tasks:
|
Task |
Remarks |
|
Configuring login authentication: · Configuring none authentication for console/AUX login |
Required. Configure one authentication mode as required. |
|
Optional. |
The console/AUX login configuration is effective only for users who log in after the configuration is made.
Configuring none authentication for console/AUX login
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter console/AUX user interface view. |
user-interface { aux | console } first-number [ last-number ] |
N/A |
|
3. Enable none authentication mode. |
authentication-mode none |
By default, the authentication mode is none for the console user interface and password for the AUX user interface. |
|
4. Assign a user role. |
user-role role-name |
The default is as follows: · network-admin for a console user interface user of the default MDC. · network-operator for an AUX user interface user of the default MDC. Non-default MDCs do not support console or AUX login. |
The next time you attempt to log in through the console or AUX port, you do not need to provide any username or password, as shown in Figure 7 and Figure 8.
Figure 7 Accessing the CLI through the console port without authentication

Figure 8 Accessing the CLI through the AUX port without authentication

Configuring password authentication for console/AUX login
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter console/AUX user interface view. |
user-interface { aux | console } first-number [ last-number ] |
N/A |
|
3. Enable password authentication. |
authentication-mode password |
By default, the authentication mode is none for the console user interface and password for the AUX user interface. |
|
4. Set a password. |
set authentication password { hash | simple } password |
By default, no password is set. |
|
5. Assign a user role. |
user-role role-name |
The default is as follows: · network-admin for a console user interface user of the default MDC. · network-operator for an AUX user interface user of the default MDC. Non-default MDCs do not support console or AUX login. |
The next time you attempt to log in through the console/AUX port, you must provide the configured login password, as shown in Figure 9 and Figure 10.
Figure 9 Password authentication interface for console login

Figure 10 Password authentication interface for AUX login

Configuring scheme authentication for console/AUX login
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter console/AUX user interface view. |
user-interface { aux | console } first-number [ last-number ] |
N/A |
|
3. Enable scheme authentication. |
authentication-mode scheme |
By default, the authentication mode is none for the console user interface and password for the AUX user interface. |
To use scheme authentication, you must also configure login authentication methods in ISP domain view. For more information, see Security Configuration Guide.
The next time you attempt to log in through the console or AUX port, you must provide the configured login username and password, as shown in Figure 11 and Figure 12.
Figure 11 Scheme authentication interface for console login

Figure 12 Scheme authentication interface for AUX login

Configuring common console/AUX user interface settings
Some common settings configured for a console or AUX user interface take effect immediately and can interrupt the current session. To avoid repeated re-logins, use a login method different from console/AUX login to log in to the device before you change console/AUX user interface settings.
To log in through the console/AUX port after the configuration is complete, change the terminal settings on the configuration terminal to match the console/AUX port settings on the device.
To configure common settings for a console/AUX user interface:
|
Step |
Command |
|
|
N/A |
||
|
2. Enter console/AUX user interface view. |
N/A |
|
|
3. Set the baud rate. |
speed speed-value |
By default, the baud rate is 9600 bps. |
|
4. Specify the parity check mode. |
parity { even | mark | none | odd | space } |
The default is none, namely, no parity check. |
|
5. Specify the number of stop bits. |
stopbits { 1 | 1.5 | 2 } |
The default is 1. The device does not support the 1.5 keyword. Stop bits indicate the end of a character. The more the stop bits, the slower the transmission. |
|
6. Specify the number of data bits for each character. |
databits { 5 | 6 | 7 | 8 } |
The default is 8. The setting depends on the character coding type. For example, you can set it to 7 if standard ASCII characters are to be sent, and set it to 8 if extended ASCII characters are to be sent. |
|
7. Define a shortcut key for starting a terminal session. |
activation-key character |
By default, pressing Enter starts the terminal session. |
|
8. Define a shortcut key for terminating tasks. |
escape-key { character | default } |
By default, pressing Ctrl+C terminates a task. |
|
9. Configure the flow control mode. |
flow-control { hardware | none | software } |
By default, the flow control mode is none. |
|
10. Specify the terminal display type. |
terminal type { ansi | vt100 } |
By default, the terminal display type is ANSI. The device supports two terminal display types: ANSI and VT100. To ensure proper display on the terminal, set the display type of both the device and the terminal to VT100. Otherwise, when a command line has more than 80 characters, an anomaly such as cursor positioning error or abnormal terminal display might occur. |
|
11. Set the maximum number of lines to be displayed on a screen. |
screen-length screen-length |
By default, a screen displays 24 lines at most. |
|
12. Set the size of the command history buffer. |
history-command max-size value |
|
|
13. Set the session idle-timeout timer. |
idle-timeout minutes [ seconds ] |
The default is 10 minutes. If there is no interaction between the device and the user within the idle-timeout interval, the system automatically terminates the user connection on the user interface. If you set the idle-timeout timer to 0, the session will never be aged out. |
Logging in through Telnet
You can Telnet to the device to remotely manage the device, or use the device as a Telnet client to Telnet to other devices to manage them.
By default, Telnet login is disabled on the device. To log in to the device through Telnet, you must first log in to the device through any other method, enable the Telnet server, and configure Telnet login authentication on the device.
Configuring Telnet login on the device
|
Task |
Remarks |
|
Configuring login authentication: · Configuring none authentication for Telnet login |
Required. Configure one authentication mode as required. |
|
Optional. |
The Telnet login configuration is effective only for users who log in after the configuration is made.
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 function is disabled. |
|
3. Enter one or multiple VTY user interface views. |
user-interface vty first-number [ last-number ] |
N/A |
|
4. Enable none authentication mode. |
authentication-mode none |
By default, password authentication is enabled for VTY user interfaces. |
|
5. (Optional.) Assign a user role. |
user-role role-name |
By default, a VTY user interface user of the default MDC is assigned the user role network-operator, and a VTY user interface user of a non-default MDC is assigned the user role mdc-operator. |
The next time you attempt to Telnet to the device, you do not need to provide any username or password, as shown in Figure 13. 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.
Figure 13 Telnetting to the device without authentication

Configuring password 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 function is disabled. |
|
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 | simple } password |
By default, no password is set. |
|
6. (Optional.) Assign a user role. |
user-role role-name |
By default, a VTY user interface user of the default MDC is assigned the user role network-operator, and a VTY user interface user of a non-default MDC is assigned the user role mdc-operator. |
The next time you attempt to Telnet to the device, you must provide the configured login password, as shown in Figure 14. 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.
Figure 14 Password authentication interface for Telnet login

Configuring scheme 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 function is disabled. |
|
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, password authentication is enabled for VTY user interfaces. |
To use scheme authentication, you must also configure login authentication methods in ISP domain view. For more information, see Security Configuration Guide.
The next time you attempt to Telnet to the CLI, you must provide the configured login username and password, as shown in Figure 15. 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.
Figure 15 Scheme authentication interface for Telnet login

Configuring common VTY user interface settings
For a VTY user interface, you can specify a command that is to be automatically executed when a user logs in. After executing the specified command and performing the incurred task, the system automatically disconnects the Telnet session. Before you configure this function and save the configuration, make sure you can access the CLI through a different user interface.
Typically, you configure the auto-execute command telnet X.X.X.X command on the device so the device redirects a Telnet user to the host at X.X.X.X. In this case, the connection to the current device is closed when the user terminates the Telnet connection to X.X.X.X.
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 |
By default, terminal service is enabled. |
|
4. Specify the protocols for the user interfaces to support. |
protocol inbound { all | pad | ssh | telnet } |
By default, Telnet and SSH are supported. The device does not support the pad keyword. This configuration is effective only for users who log in to the user interfaces after the configuration is made. |
|
5. Define a shortcut key for terminating tasks. |
escape-key { character | default } |
By default, pressing Ctrl+C terminates a task. |
|
6. Specify the terminal display type. |
terminal type { ansi | vt100 } |
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 |
By default, up to 24 lines is displayed on a screen. A value of 0 disables the function. |
|
8. Set the size of command history buffer. |
history-command max-size value |
By default, the buffer saves 10 history commands. |
|
9. Set the idle-timeout timer. |
idle-timeout minutes [ seconds ] |
By default, the idle-timeout interval is 10 minutes for all user interfaces. If there is no interaction between the device and the user within the idle-timeout interval, the system automatically terminates the user connection on the user interface. If you set the idle-timeout timer to 0, the session will never be aged out. |
|
10. Specify a command to be automatically executed when users log in to the user interfaces. |
auto-execute command command |
By default, no automatically executed command is specified. |
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 16 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. (Optional.) Specify the source IPv4 address or source interface for outgoing Telnet packets. |
telnet client source { interface interface-type interface-number | ip ip-address } |
By default, no source IPv4 address or source interface is specified, and the primary IPv4 address of the outbound interface is used as the source address for outgoing Telnet packets. |
|
3. Exit to user view. |
quit |
N/A |
|
4. Use the device to log in to a Telnet server. |
· Log in to an IPv4 Telnet server: · Log in to an IPv6 Telnet
server: |
Use either command. |
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 plain text password interception. For more information, see Security Configuration Guide.
You can use an SSH client to log in to the device for remote management, or use the device as an SSH client to log in to an SSH server.
By default, SSH login is disabled on the device. To log in to the device through SSH, you must log in to the device through any other method and configure SSH login on the device first.
Configuring SSH login on the device
This section provides the configuration procedure for when the SSH client authentication method is password. For more information about SSH and publickey authentication configuration, see Security Configuration Guide.
To configure SSH login 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. Create an SSH user and specify the authentication mode. |
ssh user username service-type stelnet authentication-type { password | { any | password-publickey | publickey } assign publickey keyname } |
By default, no SSH user is configured on the device. |
|
|
5. Enter one or multiple VTY user interface views. |
user-interface vty first-number [ last-number ] |
N/A |
|
|
6. Enable scheme authentication. |
authentication-mode scheme |
By default, password authentication is enabled for VTY user interfaces. |
|
|
7. (Optional.) Specify the protocols for the user interfaces to support. |
protocol inbound { all | pad | ssh | telnet } |
By default, Telnet and SSH are supported. The device does not support the pad keyword. This configuration is effective only for users who log in to the user interfaces after the configuration is made. |
|
|
8. Exit to system view. |
quit |
N/A |
|
|
9. (Optional.) Configure common settings for VTY user interfaces. |
N/A |
|
|
Using the device to log in to an 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 17 Logging in to an SSH client from the device

Perform the following tasks in user view:
|
Task |
Command |
|
Log in to an IPv4 SSH server. |
ssh2 server |
|
Log in to an IPv6 SSH server. |
ssh2 ipv6 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
Execute display commands in any view and the other commands in user view.
|
Task |
Command |
Remarks |
|
Display information about the user interfaces that are being used. |
display users |
N/A |
|
Display information about all user interfaces the device supports. |
display users all |
N/A |
|
Display user interface information. |
display user-interface [ num1 | { aux | console | vty } num2 ] [ summary ] |
N/A |
|
Display the source IPv4 address or interface configured for the device to use for outgoing Telnet packets when serving as a Telnet client. |
display telnet client |
N/A |
|
Release a user interface. |
free user-interface { num1 | { aux | console | vty } num2 } |
Multiple users can log in to the device to simultaneously configure the device. When necessary, you can execute this command to release some connections. You cannot use this command to release the connection you are using. |
|
Lock the current user interface. |
lock |
By default, the system does not lock any user interface. |
|
Send messages to user interfaces. |
send { all | num1 | { aux | console | vty } num2 } |
N/A |
You can run SNMP on 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. However, the device and the NMS must use the same SNMP version. For more information about SNMP, see Network Management and Monitoring Configuration Guide.
By default, SNMP access is disabled. To access the device through SNMP, you must log in to the device through any other method and configure SNMP access.
Configuring SNMPv3 access
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable the SNMP agent. |
snmp-agent |
By default, the SNMP agent is disabled. |
|
3. (Optional.) Create or update MIB view information. |
snmp-agent mib-view { excluded | included } view-name oid-tree [ mask mask-value ] |
By default, the device has four views, all of which are named ViewDefault: · View 1 includes MIB subtree iso. · View 2 does not include subtree snmpUsmMIB. · View 3 does not include subtree snmpVacmMIB. · View 4 does not include subtree snmpModules.18. |
|
4. Create an SNMPv3 group. |
snmp-agent group v3 group-name [ authentication | privacy ] [ read-view view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl acl-number | acl ipv6 ipv6-acl-number ] * |
By default, no SNMPv3 group exists. |
|
5. Create an SNMPv3 user. |
snmp-agent usm-user v3 user-name group-name [ remote { ip-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] [ { cipher | simple } authentication-mode { md5 | sha } auth-password [ privacy-mode { aes128 | des56 } priv-password ] ] [ acl acl-number | acl ipv6 ipv6-acl-number ] * |
To send informs to an SNMPv3 NMS, you must use the remote ip-address option to specify the IP address of the NMS. |
Configuring SNMPv1 or SNMPv2c access
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable the SNMP agent. |
snmp-agent |
By default, the SNMP agent is disabled. |
|
3. (Optional.) Create or update MIB view information. |
snmp-agent mib-view { excluded | included } view-name oid-tree [ mask mask-value ] |
By default, the device has four views, all of which are named ViewDefault: · View 1 includes MIB subtree iso. · View 2 does not include subtree snmpUsmMIB. · View 3 does not include subtree snmpVacmMIB. · View 4 does not include subtree snmpModules.18. |
|
4. Configure the SNMP 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 view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl acl-number | acl ipv6 ipv6-acl-number ] * b. snmp-agent usm-user { v1 | v2c } user-name group-name [ acl acl-number | acl ipv6 ipv6-acl-number ] * |
Use either approach. The username in approach 2 is equivalent to the community name used in approach 1, and must be the same as the community name configured on the NMS. By default, no SNMP group or SNMP community exists. |
Use ACLs to prevent unauthorized access and configure command authorization and accounting to monitor and control user behaviors. For more information about ACLs, see ACL and QoS Configuration Guide.
Controlling Telnet/SSH logins
Use basic ACLs (2000 to 2999) to filter Telnet and SSH logins by source IP address. Use advanced ACLs (3000 to 3999) to filter Telnet and SSH logins by source and/or destination IP address. Use Ethernet frame header ACLs (4000 to 4999) to filter Telnet and SSH logins by source MAC address.
If an applied ACL does not exist or has no rules, no user login restriction is applied. If the ACL exists and has rules, only users permitted by the ACL can access the device through Telnet or SSH.
Configuration procedures
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
Apply an ACL to filter Telnet logins. |
· telnet server acl acl-number · telnet server ipv6 acl [ ipv6 ] acl-number |
By default, no ACL is used to filter Telnet logins. |
To control SSH logins:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
Apply an ACL to filter SSH logins. |
· ssh server acl acl-number · ssh server ipv6 acl [ ipv6 ] acl-number |
By default, no ACL is used to filter SSH logins. For more information about these two commands, see Security Command Reference. |
Configuration example
Network requirements
Configure the device in Figure 19 to permit only Telnet packets sourced from Host A and Host B.

Configuration procedure
# Configure an ACL to permit packets sourced from Host A and Host B.
<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
# Apply the ACL to filter Telnet logins.
[Sysname] telnet server acl 2000
Controlling SNMP access
Use a basic ACL (2000 to 2999) to control SNMP access 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 control SNMP access, configure ACLs as required and complete the following configuration:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Apply the ACL to an SNMP community, group, or user. |
·
SNMP
community: ·
SNMPv1/v2c group: ·
SNMPv3 group: · SNMPv1/v2c user: ·
SNMPv3 user: |
For more information about SNMP, see Network Management and Monitoring Configuration Guide. |
Configuration example
Network requirements
Configure the device in Figure 20 to allow Host A and Host B to access the device through SNMP.

Configuration procedure
# Create an ACL to permit packets sourced from Host A and Host B.
<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 command authorization
By default, commands are available for a user depending only on that user's user roles. When the authentication mode is scheme, you can configure the command authorization function to further control access to commands.
After you enable command authorization, a command is available for a user only if the user has the commensurate user role and is authorized to use the command by the AAA scheme.
This section provides the procedure for configuring command authorization. To make the command authorization function take effect, you must configure a command authorization method in ISP domain view. For more information, see Security Configuration Guide.
Configuration procedure
To configure command authorization:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter user interface view. |
user-interface { first-number1 [ last-number1 ] | { aux | console | vty } first-number2 [ last-number2 ] } |
N/A |
|
3. Enable scheme authentication. |
authentication-mode scheme |
By default, the authentication mode is none for the console user interface and password for the AUX user interface. |
|
4. Enable command authorization. |
command authorization |
By default, command authorization is disabled, and the commands available for a user only depend on the user role. |
Configuration example
Network requirements
Configure the device in Figure 21 so a user can use Host A to log in to the device and execute only commands that are authorized by the HWTACACS server or, when the HWTACACS server is not available, the device itself.

Configuration procedure
# Assign IP addresses to relevant interfaces and make sure the device and the HWTACACS server can reach each other and the device and Host A can reach each other. (Details not shown.)
# Enable the Telnet server.
<Device> system-view
[Device] telnet server enable
# Enable scheme authentication for user interfaces VTY 0 through VTY 15.
[Device] user-interface vty 0 15
[Device-ui-vty0-15] authentication-mode scheme
# Enable command authorization for the user interfaces.
[Device-ui-vty0-15] command authorization
[Device-ui-vty0-15] quit
# Configure an HWTACACS scheme that uses the HWTACACS server at 192.168.2.20:49 for authentication and authorization, uses the shared key expert, and removes domain names from usernames sent to the HWTACACS server. (In this example the HWTACACS server provides authentication and authorization services at port 49.)
[Device] hwtacacs scheme tac
[Device-hwtacacs-tac] primary authentication 192.168.2.20 49
[Device-hwtacacs-tac] primary authorization 192.168.2.20 49
[Device-hwtacacs-tac] key authentication expert
[Device-hwtacacs-tac] key authorization expert
[Device-hwtacacs-tac] server-type standard
[Device-hwtacacs-tac] user-name-format without-domain
[Device-hwtacacs-tac] quit
# For the system-predefined domain system, configure the authentication method for login users and the command authorization method to use the HWTACACS scheme and, if the HWTACACS server is unavailable, use local authentication and local authorization as the backup.
[Device] domain system
[Device-isp-system] authentication login hwtacacs-scheme tac local
[Device-isp-system] authorization command hwtacacs-scheme tac local
[Device-isp-system] quit
# Create local user monitor, set the password to 123, assign the Telnet service, and set the default privilege level to 1.
[Device] local-user monitor class manage
[Device-luser-manage-monitor] password cipher 123
[Device-luser-manage-monitor] service-type telnet
[Device-luser-manage-monitor] authorization-attribute level 1
Configuring command accounting
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.
When command accounting is disabled, the accounting server does not record the commands executed by users. If command accounting is enabled but command authorization is not, every executed command is recorded on the HWTACACS server. If both command accounting and command authorization are enabled, only authorized commands that are executed are recorded on the HWTACACS server.
This section provides only the procedure for configuring command accounting. To make the command accounting function take effect, you must configure a command accounting method in ISP domain view. For more information, see Security Configuration Guide.
Configuration procedure
To configure command accounting:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter user interface view. |
user-interface { first-number1 [ last-number1 ] | { aux | console | vty } first-number2 [ last-number2 ] } |
N/A |
|
3. Enable scheme authentication. |
authentication-mode scheme |
By default, the authentication mode is none for the console user interface and password for the AUX user interface. |
|
4. Enable command accounting. |
command accounting |
By default, command accounting is disabled, and the accounting server does not record the commands executed by users. |
Configuration example
Network requirements
To monitor and control user operations on the device in Figure 22, configure the device to send commands executed by users to the HWTACACS server.

Configuration procedure
# Enable the Telnet server.
<Device> system-view
[Device] telnet server enable
# Enable command accounting for user interface Console 0.
[Device] user-interface console 0
[Device-ui-console0] command accounting
[Device-ui-console0] quit
# Enable command accounting for user interfaces VTY 0 through VTY 15.
[Device] user-interface vty 0 15
[Device-ui-vty0-15] command accounting
[Device-ui-vty0-15] quit
# Configure an HWTACACS scheme that uses the HWTACACS server at 192.168.2.20:49 for accounting, uses the shared key expert, and removes domain names from usernames sent to the HWTACACS server. (In this example the HWTACACS server provides accounting services at port 49.)
[Device] hwtacacs scheme tac
[Device-hwtacacs-tac] primary accounting 192.168.2.20 49
[Device-hwtacacs-tac] key accounting expert
[Device-hwtacacs-tac] user-name-format without-domain
[Device-hwtacacs-tac] quit
# Configure the command accounting method for the system-predefined domain system to use the HWTACACS scheme.
[Device] domain system
[Device-isp-system] accounting command hwtacacs-scheme tac
[Device-isp-system] quit


