Table Of Contents

Configuring Users and Common Roles

Role-Based Authorization

About Roles

Configuring Roles and Profiles

Configuring Rules and Features for Each Role

Modifying Profiles

Configuring the VSAN Policy

Modifying the VSAN Policy

Role Distributions

About Role Databases

Locking the Fabric

Committing Role-Based Configuration Changes

Discarding Role-Based Configuration Changes

Enabling Role-Based Configuration Distribution

Clearing Sessions

Database Merge Guidelines

Displaying Role-Based Information

Displaying Roles When Distribution is Enabled

Configuring Common Roles

Mapping of CLI Operations to SNMP

Configuring User Accounts

About Users

Characteristics of Strong Passwords

Configuring Users

Logging Out Users

Displaying User Account Information

Configuring SSH Services

About SSH

Generating the SSH Server Key-Pair

Specifying the SSH Key

Overwriting a Generated Key-Pair

Clearing SSH Hosts

Enabling SSH or Telnet Service

Displaying SSH Protocol Status

SSH Authentication Using Digital Certificates

Recovering the Administrator Password

Using the CLI with Network-Admin Privileges

Power Cycling the Switch

Default Settings

Configuring Users and Common Roles

---

The CLI and SNMP use common roles in all switches in the Cisco MDS 9000 Family. You can use the CLI to modify a role that was created using SNMP and vice versa.

Users, passwords, and roles for all CLI and SNMP users are the same. A user configured through the CLI can access the switch using SNMP (for example, the Fabric Manager or the Device Manager) and vice versa.

This chapter includes the following sections:

•Role-Based Authorization

•Role Distributions

•Configuring Common Roles

•Configuring User Accounts

•Configuring SSH Services

•Recovering the Administrator Password

•Default Settings

Role-Based Authorization

Switches in the Cisco MDS 9000 Family perform authentication based on roles. Role-based authorization limits access to switch operations by assigning users to roles. This kind of authentication restricts you to management operations based on the roles to which you have been added.

When you execute a command, perform command completion, or obtain context sensitive help, the switch software allows the operation to progress if you have permission to access that command.

This section includes the following topics:

•About Roles

•Configuring Roles and Profiles

•Configuring Rules and Features for Each Role

•Configuring the VSAN Policy

About Roles

Each role can contain multiple users and each user can be part of multiple roles. For example, if role1 users are only allowed access to configuration commands, and role2 users are only allowed access to debug commands, then if Joe belongs to both role1 and role2, he can access configuration as well as debug commands.

---

Note If you belong to multiple roles, you can execute a union of all the commands permitted by these roles. Access to a command takes priority over being denied access to a command. For example, suppose you belong to a TechDocs group and you were denied access to configuration commands. However, you also belong to the engineering group and have access to configuration commands. In this case, you will have access to configuration commands.

---

---

Tip Any role, when created, does not allow access to the required commands immediately. The administrator must configure appropriate rules for each role to allow access to the required commands.

---

Configuring Roles and Profiles

To create an additional role or to modify the profile for an existing role, follow these steps:

	Command	Purpose
Step 1	switch# config t	Enters configuration mode.
Step 2	switch(config)# role name techdocs switch(config-role)#	Places you in the mode for the specified role (techdocs). Note The role submode prompt indicates that you are now in the role submode. This submode is now specific to the techdocs group.
	switch(config)# no role name techdocs	Deletes the role called techdocs.
Step 3	switch(config-role)# description Entire Tech Docs group	Assigns a description to the new role. The description is limited to one line and can contain spaces.
	switch(config-role)# no description	Resets the description for the Tech Docs group.

---

Note Only users belonging to the network-admin role can create roles.

---

Configuring Rules and Features for Each Role

Up to 16 rules can be configured for each role. The user-specified rule number determines the order in which the rules are applied. For example, rule 1 is applied before rule 2, which is applied before rule 3, and so on. A user not belonging to the network-admin role cannot perform commands related to roles.

For example, if user A is permitted to perform all show commands, user A cannot view the output of the show role command if user A does not belong to the network-admin role

The rule command specifies operations that can be performed by a specific role. Each rule consists of a rule number, a rule type (permit or deny), a command type (for example, config, clear, show, exec, debug), and an optional feature name (for example, FSPF, zone, VSAN, fcping, or interface).

---

Note In this case, exec commands refer to all commands in the EXEC mode that do not fall in the show, debug, and clear command categories.

---

Modifying Profiles

To modify the profile for an existing role, follow these steps:

	Command	Purpose
Step 1	switch# config t	Enters configuration mode.
Step 2	switch(config)# role name sangroup switch(config-role)#	Places you in role configuration submode for the existing role sangroup.
Step 3	switch(config-role)# rule 1 permit config switch(config-role)# rule 2 deny config feature fspf switch(config-role)# rule 3 permit debug feature zone switch(config-role)# rule 4 permit exec feature fcping	Allows users belonging to the sangroup role to perform all configuration commands except fspf config commands. They can also perform zone debug commands and the fcping EXEC mode command.
Step 4	switch(config-role)# no rule 4	Deletes rule 4, which no longer permits the sangroup to perform the fcping command.

In Step 3, rule 1 is applied first, thus permitting sangroup users access to all config commands. Rule 2 is applied next, denying FSPF configuration to sangroup users. As a result, sangroup users can perform all other config commands, except fspf configuration commands.

---

Note The order of rule placement is important. If you had swapped these two rules and issued the deny config feature fspf rule first and issued the permit config rule next, you would be allowing all sangroup users to perform all configuration commands because the second rule globally overrode the first rule.

---

Configuring the VSAN Policy

Configuring the VSAN policy requires the ENTERPRISE_PKG license (see Chapter 3, "Obtaining and Installing Licenses").

You can configure a role so that it only allows tasks to be performed for a selected set of VSANs. By default, the VSAN policy for any role is permit, which allows tasks to be performed for all VSANs. You can configure a role that only allows tasks to be performed for a selected set of VSANs. To selectively allow VSANs for a role, set the VSAN policy to deny, and then set the configuration to permit or the appropriate VSANs.

---

Note Users configured in roles where the VSAN policy is set to deny cannot modify the configuration for E ports. They can only modify the configuration for F or FL ports (depending on whether the configured rules allow such configuration to be made). This is to prevent such users from modifying configurations that may impact the core topology of the fabric.

---

---

Tip Roles can be used to create VSAN administrators. Depending on the configured rules, these VSAN administrators can configure MDS features (for example, zone, fcdomain, or VSAN properties) for their VSANs without affecting other VSANs. Also, if the role permits operations in multiple VSANs, then the VSAN administrators can change VSAN membership of F or FL ports among these VSANs.

---

Users belonging to roles in which the VSAN policy is set to deny are referred to as VSAN-restricted users.

Modifying the VSAN Policy

To modify the VSAN policy for an existing role, follow these steps:

	Command	Purpose
Step 1	switch# config t	Enters configuration mode.
Step 2	switch(config)# role name sangroup switch(config-role)#	Places you in role configuration submode for the sangroup role.
Step 3	switch(config)# vsan policy deny switch(config-role-vsan)	Changes the VSAN policy of this role to deny and places you in a submode where VSANs can be selectively permitted.
	switch(config-role)# no vsan policy deny	Deletes the configured VSAN role policy and reverts to the factory default (permit).
Step 4	switch(config-role-vsan)# permit vsan 10-30	Permits this role to perform the allowed commands for VSANs 10 through 30.
	switch(config-role-vsan)# no permit vsan 15-20	Removes the permission for this role to perform commands for VSANs 15 to 20. So, the role is now permitted to perform commands for VSAN 10 to 14, and 21 to 30.

Role Distributions

Role-based configurations use the Cisco Fabric Services (CFS) infrastructure to enable efficient database management and to provide a single point of configuration for the entire fabric (see Chapter 6, "Using the CFS Infrastructure").

The following configurations are distributed:

•Role names and descriptions

•List of rules for the roles

•VSAN policy and the list of permitted VSANs

This section includes the following topics:

•About Role Databases

•Locking the Fabric

•Committing Role-Based Configuration Changes

•Discarding Role-Based Configuration Changes

•Enabling Role-Based Configuration Distribution

•Clearing Sessions

•Database Merge Guidelines

•Displaying Role-Based Information

•Displaying Roles When Distribution is Enabled

About Role Databases

Role-based configurations use two databases to accept and implement configurations.

•Configuration database—The database currently enforced by the fabric.

•Pending database—Your subsequent configuration changes are stored in the pending database. If you modify the configuration, you need to commit or discard the pending database changes to the configuration database. The fabric remains locked during this period. Changes to the pending database are not reflected in the configuration database until you commit the changes.

Locking the Fabric

The first action that modifies the database creates the pending database and locks the feature in the entire fabric. Once you lock the fabric, the following situations apply:

•No other user can make any configuration changes to this feature.

•A copy of the configuration database becomes the pending database along with the first change.

Committing Role-Based Configuration Changes

If you commit the changes made to the pending database, the configuration is committed to all the switches in the fabric. On a successful commit, the configuration change is applied throughout the fabric and the lock is released. The configuration database now contains the committed changes and the pending database is now cleared.

To commit role-based configuration changes, follow these steps:

	Command	Purpose
Step 1	switch# config t switch(config)#	Enters configuration mode.
Step 2	switch(config)# role commit vsan 3	Commits the role-based configuration changes.

Discarding Role-Based Configuration Changes

If you discard (abort) the changes made to the pending database, the configuration database remains unaffected and the lock is released.

To discard role-based configuration changes, follow these steps:

	Command	Purpose
Step 1	switch# config t switch(config)#	Enters configuration mode.
Step 2	switch(config)# role abort	Discards the role-based configuration changes and clears the pending configuration database.

Enabling Role-Based Configuration Distribution

To enable role-based configuration distribution, follow these steps:

	Command	Purpose
Step 1	switch# config t switch(config)#	Enters configuration mode.
Step 2	switch(config)# role distribute	Enables role-based configuration distribution.
	switch(config)# no role distribute	Disables role-based configuration distribution (default).

Clearing Sessions

To forcibly clear the existing role session in the fabric, issue the clear role session command from any switch that is part of the initiated session.

---

Caution Any changes in the pending database are lost when you issue this command.

---

switch# clear role session

Database Merge Guidelines

Fabric merge does not modify the role database on a switch. If two fabrics merge, and the fabrics have different role databases, the software generates an alert message.

See the "CFS Merge Support" section on page 6-8 for detailed concepts.

•Verify that the role database is identical on all switches in the entire fabric.

•Be sure to edit the role database on any switch to the desired database and then commit it. This synchronizes the role databases on all the switches in the fabric.

Displaying Role-Based Information

Use the show role command to display rules configured on the switch. The rules are displayed by rule number and are based on each role. All roles are displayed if the role name is not specified. See Example 39-1.

Example 39-1 Displays Information for All Roles

switch# show role 

Role: network-admin

Description: Predefined Network Admin group. This role cannot be modified

Access to all the switch commands

Role: network-operator

Description: Predefined Network Operator group. This role cannot be modified

Access to Show commands and selected Exec commands

Role: svc-admin

Description: Predefined SVC Admin group. This role cannot be modified

Access to all SAN Volume Controller commands

Role: svc-operator

Description: Predefined SVC Operator group. This role cannot be modified

Access to selected SAN Volume Controller commands

Role: TechDocs

  vsan policy: permit (default)

Role: sangroup

  Description: SAN management group

  vsan policy: deny

  Permitted vsans: 10-30

  ---------------------------------------------

  Rule    Type    Command-type      Feature

  ---------------------------------------------

    1.   permit    config                   *

    2.     deny    config                fspf

    3.   permit     debug                zone

    4.   permit      exec              fcping

Displaying Roles When Distribution is Enabled

Use the show role command to display the configuration database.

Use the show role status command to display whether distribution is enabled for role configuration, the current fabric status (locked or unlocked), and the last operation performed. See Example 39-2.

Example 39-2 Displays the Role Status Information

switch# show role status

Distribution: Enabled

Session State: Locked

Last operation (initiated from this switch): Distribution enable

Last operation status: Success

Use the show role pending command to display the pending role database.

Example 39-3 displays the output of the show role pending command by following this procedure:

1. Create the role called myrole using the role name myrole command.

2. Issue the rule 1 permit config feature fspf command.

3. Issue the show role pending command to see the output.

Example 39-3 Displays Information on the Pending Roles Database

switch# show role pending

Role: network-admin

Description: Predefined Network Admin group. This role cannot be modified

Access to all the switch commands

Role: network-operator

Description: Predefined Network Operator group. This role cannot be modified

Access to Show commands and selected Exec commands

Role: svc-admin

Description: Predefined SVC Admin group. This role cannot be modified

Access to all SAN Volume Controller commands

Role: svc-operator

Description: Predefined SVC Operator group. This role cannot be modified

Access to selected SAN Volume Controller commands

Role: TechDocs

  vsan policy: permit (default)

Role: sangroup

  Description: SAN management group

  vsan policy: deny

  Permitted vsans: 10-30

  ---------------------------------------------

  Rule    Type    Command-type      Feature

  ---------------------------------------------

    1.   permit    config                   *

    2.     deny    config                fspf

    3.   permit     debug                zone

    4.   permit      exec              fcping

Role: myrole

  vsan policy: permit (default)

  ---------------------------------------------

  Rule    Type    Command-type      Feature

  ---------------------------------------------

    1.   permit    config                fspf

Use the show role pending-diff command to display the differences between the pending and configuration role database. See Example 39-4.

Example 39-4 Displays the Differences Between the Two Databases

switch# show role pending-diff

    +Role: myrole

    +  vsan policy: permit (default)

    +  ---------------------------------------------

    +  Rule    Type    Command-type      Feature

    +  ---------------------------------------------

    +    1.   permit    config                fspf

Configuring Common Roles

The CLI and SNMP in all switches in the Cisco MDS 9000 Family use common roles. You can use SNMP to modify a role that was created using the CLI and vice versa (see Figure 39-1).

Figure 39-1 Common Roles

Each role in SNMP is the same as a role created or modified through the CLI (see the "Role-Based Authorization" section).

Each role can be restricted to one or more VSANs as required.

You can create new roles or modify existing roles using SNMP or the CLI.

•SNMP—Use the CISCO-COMMON-ROLES-MIB to configure or modify roles. Refer to the Cisco MDS 9000 Family MIB Quick Reference.

•CLI—Use the role name command.

Mapping of CLI Operations to SNMP

SNMP has only three possible operations: GET, SET, and NOTIFY. The CLI has five possible operations: DEBUG, SHOW, CONFIG, CLEAR, and EXEC.

---

Note NOTIFY does not have any restrictions like the syslog messages in the CLI.

---

Table 39-1 explains how the CLI operations are mapped to the SNMP operations.

Table 39-1 CLI Operation to SNMP Operation Mapping 

CLI Operation	SNMP Operation
DEBUG	Ignored
SHOW	GET
CONFIG	SET
CLEAR	SET
EXEC	SET

Example 39-5 shows the privileges and rules mapping CLI operations to SNMP operations for a role named my_role.

Example 39-5 Displays CLI Operation to SNMP Operation Mapping

switch# show role name my_role

Role:my_role

  vsan policy:permit (default)

  ---------------------------------------------

  Rule    Type    Command-type      Feature

  ---------------------------------------------

    1.   permit     clear                   *

    2.     deny     clear                 ntp

    3.   permit    config                   *

    4.     deny    config                 ntp

    5.   permit     debug                   *

    6.     deny     debug                 ntp

    7.   permit      show                   *

    8.     deny      show                 ntp

    9.   permit      exec                   *

---

Note Although CONFIG is denied for NTP in rule 4, rule 9 allows the SET to NTP MIB objects because EXEC also maps to the SNMP SET operation.

---

Configuring User Accounts

Every Cisco MDS 9000 Family switch user has the account information stored by the system. Your authentication information, user name, user password, password expiration date, and role membership are stored in your user profile.

The tasks explained in this section enable you to create users and modify the profile of an existing user. These tasks are restricted to privileged users as determined by your administrator.

This section includes the following topics:

•About Users

•Characteristics of Strong Passwords

•Configuring Users

•Logging Out Users

•Displaying User Account Information

About Users

The passphrase specified in the snmp-server user option and the password specified username option are synchronized (see the "SNMPv3 CLI User Management and AAA Integration" section on page 31-3).

By default, the user account does not expire unless you explicitly configure it to expire. The expire option determines the date on which the user account is disabled. The date is specified in the YYYY-MM-DD format.

---

Note You can configure up to a maximum of 256 users on a switch.

---

---

Tip The following words are reserved and cannot be used to configure users: bin, daemon, adm, lp, sync, shutdown, halt, mail, news, uucp, operator, games, gopher, ftp, nobody, nscd, mailnull, rpc, rpcuser, xfs, gdm, mtsuser, ftpuser, man, and sys.

---

---

Note User passwords are not displayed in the switch configuration file.

---

---

Tip If a password is trivial (short, easy-to-decipher), your password configuration is rejected. Be sure to configure a strong password as shown in the sample configuration. Passwords are case-sensitive. "admin" is no longer the default password for any Cisco MDS 9000 Family switch. You must explicitly configure a strong password.

---

---

Caution Cisco MDS SAN-OS does not support all numeric user names, whether created with TACACS+ or RADIUS, or created locally. Local users with all numeric names cannot be created. If an all numeric user name exists on an AAA server and is entered during login, the user is not logged in.

---

---

Tip To issue commands with the internal keyword for troubleshooting purposes, you must have an account that is a member of the network-admin group.

---

Characteristics of Strong Passwords

A strong password has the following characteristics:

•At least eight characters long

•Does not contain many consecutive characters (such as "abcd")

•Does not contain many repeating characters (such as "aaabbb")

•Does not contain dictionary words

•Does not contain proper names

•Contains both upper- and lower-case characters

•Contains numbers

The following are examples of strong passwords:

•If2CoM18

•2004AsdfLkj30

•Cb1955S21

---

Note Clear text passwords can only contain alphanumeric characters. The dollar sign ($) is not allowed.

---

Configuring Users

To configure a new user or to modify the profile of an existing user, follow these steps:

	Command	Purpose
Step 1	switch# config t	Enters configuration mode.
Step 2	switch(config)# username usam password abcd123AAA expire 2003-05-31	Creates or updates the user account (usam) along with a password (abcd123AAA) that is set to expire on 2003-05-31. The password is limited to 64 characters. Note User account names must contain non-numeric characters.
	switch(config)# username msam password 0 abcd12AAA role network-operator	Creates or updates the user account (msam) along with a password (abcd12AAA) specified in clear text (indicated by 0). The password is limited to 64 characters. Note User account names must contain non-numeric characters.
	switch(config)# username user1 password 5 !@*asdsfsdfjh!@df	Specifies an encrypted (specified by 5) password (!@*asdsfsdfjh!@df) for the user account (user1).
Step 3	switch(config)# username usam role network-admin	Adds the specified user (usam) to the network-admin role.
	switch(config)# no username usam role vsan-admin	Deletes the specified user (usam) from the vsan-admin role.
Step 4	switch(config)# username admin sshkey ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtjIHrIt/3dDeohix6JcRSI YZ0EOdJ3l5RONWcwSgAuTUSrLk 3a9hdYkzY94fhHmNGQGCjVg+8cbOxyH4Z1jcVFcrDogtQT+Q8d veqts/8XQhqkNAFeGy4u8TJ2Us oreCU6DlibwkpzDafzKTpA5vB6FmHd2TI6Gnse9FUgKD5fs=	Specifies the SSH key for an existing user account (admin).
	switch(config)# no username admin sshkey ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtjIHrIt/3dDeohix6JcRSI YZ0EOdJ3l5RONWcwSgAuTUSrLk 3a9hdYkzY94fhHmNGQGCjVg+8cbOxyH4Z1jcVFcrDogtQT+Q8d veqts/8XQhqkNAFeGy4u8TJ2Us oreCU6DlibwkpzDafzKTpA5vB6FmHd2TI6Gnse9FUgKD5fs=	Deletes the SSH key for the user account (admin).
Step 5	switch(config)# username usam ssh-cert-dn usam-dn dsa	Specifies an SSH X.509 certificate distinguished name and DSA algorithm to use for authentication for an existing user account (usam).
	switch(config)# username user1 ssh-cert-dn user1-dn rsa	Specifies an SSH X.509 certificate distinguished name and RSA algorithm to use for authentication for an existing user account (user1).
	switch(config)# no username admin ssh-cert-dn admin-dn dsa	Removes the SSH X.509 certificate distinguished name for the user account (admin).

Logging Out Users

To log out another user on the switch, use the clear user command.

In the following example, the user named vsam is logged out from the switch.

switch# clear user vsam

Use the show users command to view a list of the logged in users (see Example 39-6).

Example 39-6 Displays All Logged in Users

switch# show users 

admin    pts/7        Jan 12 20:56 (10.77.202.149)

admin    pts/9        Jan 12 23:29 (user.example.com)

admin    pts/10       Jan 13 03:05 (dhcp-10-10-1-1.example.com)

admin    pts/11       Jan 13 01:53 (dhcp-10-10-2-2.example.com)

Displaying User Account Information

Use the show user-account command to display configured information about user accounts. See Examples 39-7 to 39-8.

Example 39-7 Displays Information for a Specified User

switch# show user-account user1 

user:user1

        this user account has no expiry date

        roles:network-operator 

no password set. Local login not allowed

Remote login through RADIUS is possible

Example 39-8 Displays Information for All Users

switch# show user-account 

show user-account 

user:admin

        this user account has no expiry date

        roles:network-admin 

user:usam

        expires on Sat May 31 00:00:00 2003

        roles:network-admin network-operator 

user:msam

        this user account has no expiry date

        roles:network-operator 

user:user1

        this user account has no expiry date

        roles:network-operator 

no password set. local login not allowed

Remote login through RADIUS is possible 

Configuring SSH Services

The Telnet service is enabled by default on all Cisco MDS 9000 Family switches. Before enabling the SSH service, generate a server key-pair (see the "Generating the SSH Server Key-Pair" section).

Use the ssh key command to generate a server key.

---

Caution If you are logging in to a switch through SSH and you have issued the aaa authentication login default none command, you must enter one or more key strokes to log in. If you press the Enter key without entering at least one keystroke, your log in will be rejected.

---

This section includes the following topics:

•About SSH

•Generating the SSH Server Key-Pair

•Specifying the SSH Key

•Overwriting a Generated Key-Pair

•Clearing SSH Hosts

•Enabling SSH or Telnet Service

•Displaying SSH Protocol Status

•SSH Authentication Using Digital Certificates

About SSH

SSH provides secure communications to the Cisco SAN-OS CLI. You can use SSH keys for the following SSH options:

•SSH1

•SSH2, using RSA

•SSH2 using DSA

Generating the SSH Server Key-Pair

Be sure to have an SSH server key-pair with the appropriate version before enabling the SSH service. Generate the SSH server key-pair according to the SSH client version used. The number of bits specified for each key-pair ranges from 768 to 2048.

The SSH service accepts three types of key-pairs for use by SSH versions 1 and 2.

•The rsa1 option generates the RSA1 key-pair for the SSH version 1 protocol.

•The dsa option generates the DSA key-pair for the SSH version 2 protocol.

•The rsa option generates the RSA key-pair for the SSH version 2 protocol.

---

Caution If you delete all of the SSH keys, you cannot start a new SSH session.

---

To generate the SSH server key-pair, follow these steps:

	Command	Purpose
Step 1	switch# config t	Enters configuration mode.
Step 2	switch(config)# ssh key rsa1 1024 generating rsa1 key..... generated rsa1 key	Generates the RSA1 server key-pair.
	switch(config)# ssh key dsa 1024 generating dsa key..... generated dsa key	Generates the DSA server key-pair.
	switch(config)# ssh key rsa 1024 generating rsa key..... generated rsa key	Generates the RSA server key-pair.
	switch(config)# no ssh key rsa 1024 cleared RSA keys	Clears the RSA server key-pair configuration.

Specifying the SSH Key

You can specify an SSH key to log in using the SSH client without being prompted for a password. You can specify the SSH key in three different formats:

•Open SSH format

•IETF SECSH format

•Public Key Certificate in PEM format

To specify or delete the SSH key in OpenSSH format for a specified user, follow these steps:

	Command	Purpose
Step 1	switch# config t switch(config)#	Enters configuration mode.
Step 2	switch(config)# username admin sshkey ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtjIHrIt/3dDeohix6JcRSIYZ 0EOdJ3l5RONWcwSgAuTUSrLk3a9hdYkzY94fhHmNGQGCjVg+8cbO xyH4Z1jcVFcrDogtQT+Q8dveqts/8XQhqkNAFeGy4u8TJ2UsoreC U6DlibwkpzDafzKTpA5vB6FmHd2TI6Gnse9FUgKD5fs=	Specifies the SSH key for the user account (admin).
	switch(config)# no username admin sshkey ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtjIHrIt/3dDeohix6JcRSIYZ 0EOdJ3l5RONWcwSgAuTUSrLk3a9hdYkzY94fhHmNGQGCjVg+8cbO xyH4Z1jcVFcrDogtQT+Q8dveqts/8XQhqkNAFeGy4u8TJ2UsoreC U6DlibwkpzDafzKTpA5vB6FmHd2TI6Gnse9FUgKD5fs=	Deletes the SSH key for the user account (admin).

To specify or delete the SSH key in IETF SECSH format for a specified user, follow these steps:

	Command	Purpose
Step 1	switch# copy tftp://10.10.1.1/secsh_file.pub bootflash:secsh_file.pub	Downloads the file containing the SSH key in IETF SECSH format.
Step 2	switch# config t switch(config)#	Enters configuration mode.
Step 3	switch(config)# username admin sshkey file bootflash:secsh_file.pub	Specifies the SSH key for the user account (admin).
	switch(config)# no username admin sshkey file bootflash:secsh_file.pub	Deletes the SSH key for the user account (admin).

To specify or delete the SSH key in PEM-formatted Public Key Certificate form for a specified user, follow these steps:

	Command	Purpose
Step 1	switch# copy tftp://10.10.1.1/cert.pem bootflash:cert.pem	Downloads the file containing the SSH key in PEM-formatted Public Key Certificate form.
Step 2	switch# config t switch(config)#	Enters configuration mode.
Step 3	switch(config)# username admin sshkey file bootflash:cert.pem	Specifies the SSH key for the user account (usam).
	switch(config)# no username admin sshkey file bootflash:cert.pem	Deletes the SSH key for the user account (usam).

Overwriting a Generated Key-Pair

If the SSH key-pair option is already generated for the required version, you can force the switch to overwrite the previously generated key-pair.

To overwrite the previously generated key-pair, follow these steps:

	Command	Purpose
Step 1	switch# config t	Enters configuration mode.
Step 2	switch(config)# ssh key dsa 768 ssh key dsa 512 dsa keys already present, use force option to overwrite them switch(config)# ssh key dsa 512 force deleting old dsa key..... generating dsa key..... generated dsa key	Tries to set the server key-pair. If a required server key-pair is already configured, use the force option to overwrite that server key-pair. Deletes the old DSA key and sets the server key-pair using the new bit specification.

Clearing SSH Hosts

The clear ssh hosts command clears the existing list of trusted SSH hosts and reallows you to use SCP/SFTP along with the copy command for particular hosts.

When you use SCP/SFTP along with the copy command, a list of trusted SSH hosts are built and stored within the switch (see Example 39-9).

Example 39-9 Using SCP/SFTP to Copy Files

switch# copy scp://abcd@10.10.1.1/users/abcd/abc 

bootflash:abc The authenticity of host '10.10.1.1 (10.10.1.1)' 

can't be established.

RSA1 key fingerprint is 01:29:62:16:33:ff:f7:dc:cc:af:aa:20:f8:20:a2:db.

Are you sure you want to continue connecting (yes/no)? yes

Added the host to the list of known hosts

(/var/home/admin/.ssh/known_hosts). [SSH key information about the host is

stored on the switch]

abcd@10.10.1.1's password:

switch#

If a host's SSH key changes before you use SCP/SFTP along with the copy command, you will receive an error (see Example 39-10).

Example 39-10 Using SCP/SFTP to Copy Files—Error Caused by SSH Key Change

switch# copy scp://apn@10.10.1.1/isan-104

bootflash:isan-ram-1.0.4

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that the RSA1 host key has just been changed.

The fingerprint for the RSA1 key sent by the remote host is

36:96:ca:d7:29:99:79:74:aa:4d:97:49:81:fb:23:2f.

Please contact your system administrator.

Add correct host key in /mnt/pss/.ssh/known_hosts to get rid of this

message.

Offending key in /mnt/pss/.ssh/known_hosts:2

RSA1 host key for 10.10.1.1 has changed and you have requested strict

checking.

Enabling SSH or Telnet Service

By default, the SSH service is disabled.

To enable or disable the SSH service, follow these steps:

	Command	Purpose
Step 1	switch# config t	Enters configuration mode.
Step 2	switch(config)# ssh server enable updated	Enables the use of the SSH service.
	switch(config)# no ssh server enable updated	Disables (default) the use of the SSH service and resets the switch to its factory defaults.

Displaying SSH Protocol Status

Use the show ssh server command to display the status of the SSH protocol (enabled or disabled) and the versions that are enabled for that switch (see Example 39-11).

Example 39-11 Displays SSH Protocol Status

switch# show ssh server 

ssh is enabled

version 1 enabled

version 2 enabled

Use the show ssh key command to display the server key-pair details for the specified key or for all keys, (see Example 39-12).

Example 39-12 Displays Server Key-Pair Details

switch# show ssh key  
rsa1 Keys generated:Sun Jan 13 07:16:26 1980

1024 35

fingerprint:

1024 67:76:02:bd:3e:8d:f5:ad:59:5a:1e:c4:5e:44:03:07

could not retrieve rsa key information

dsa Keys generated:Sun Jan 13 07:40:08 1980

ssh-dss 
AAAAB3NzaC1kc3MAAABBAJTCRQOydNRel2v7uiO6Fix+OTn8eGdnnDVxw5eJs5OcOEXOyjaWcMMYsEgxc9ada1NElp
8Wy7GPMWGOQYj9CU0AAAAVAMCcWhNN18zFNOIPo7cU3t7d0iEbAAAAQBdQ8UAOi/Cti84qFb3kTqXlS9mEhdQUo0lH
cH5bw5PKfj2Y/dLR437zCBKXetPj4p7mhQ6Fq5os8RZtJEyOsNsAAABAA0oxZbPyWeR5NHATXiyXdPI7j9i8fgyn9F
NipMkOF2Mn75Mi/lqQ4NIq0gQNvQOx27uCeQlRts/QwI4q68/eaw=

fingerprint:

512 f7:cc:90:3d:f5:8a:a9:ca:48:76:9f:f8:6e:71:d4:ae

---

Note If you are logging in to a switch through SSH and you have issued the aaa authentication login default none CLI command, you must enter one or more key strokes to log in. If you press the Enter key without entering at least one keystroke, your log in will be rejected.

---

SSH Authentication Using Digital Certificates

SSH authentication on the Cisco MDS 9000 Family switches provide X.509 digital certificate support for host authentication. An X.509 digital certificate is a data item that vouches for the origin and integrity of a message. It contains encryption keys for secured communications and is "signed" by a trusted certification authority (CA) to verify the identity of the presenter. The X.509 digital certificate support provides either DSA or RSA algorithms for authentication.

The certificate infrastructure uses the first certificate that supports the Secure Socket Layer (SSL) and is returned by the security infrastructure, either through query or notification. Verification of certificates is successful if the certificates are from any of the trusted CAs.

You can configure your switch for either SSH authentication using an X.509 certificate or SSH authentication using a Public Key Certificate, but not both. If either of them is configured and the authentication fails, you will be prompted for a password.

For more information on CAs and digital certificates, see Chapter 34, "Configuring Certificate Authorities and Digital Certificates."

Recovering the Administrator Password

You can recover the administrator password using one of two methods:

•From the CLI with a user name that has network-admin privileges.

•Power cycling the switch.

The following topics included in this section:

•Using the CLI with Network-Admin Privileges

•Power Cycling the Switch

Using the CLI with Network-Admin Privileges

If you are logged in to, or can log into, switch with a user name that has network-admin privileges and then recover the administrator password, follow these steps:

---

Step 1 Use the show user-accounts command to verify that your user name has network-admin privileges.

switch# show user-account

user:admin

        this user account has no expiry date

        roles:network-admin

user:dbgusr

        this user account has no expiry date

        roles:network-admin network-operator

Step 2 If your user name has network-admin privileges, issue the username command to assign a new administrator password.

switch# config t

switch(config)# username admin password <new password>

switch(config)# exit

switch#

Step 3 Save the software configuration.

switch# copy running-config startup-config

---

Power Cycling the Switch

If you cannot start a session on the switch that has network-admin privileges, you must recover the administrator password by power cycling the switch.

---

Caution This procedure disrupts all traffic on the switch. All connections to the switch will be lost for 2 to 3 minutes.

---

---

Note You cannot recover the administrator password from a Telnet or SSH session. You must have access to the local console connection. See the "Starting a Switch in the Cisco MDS 9000 Family" section on page 5-2 for information on setting up the console connection.

---

To recover a administrator password by power cycling the switch, follow these steps:

---

Step 1 For Cisco MDS 9500 Series switches with two supervisor modules, remove the supervisor module in
slot 6 from the chassis.

---

Note On the Cisco MDS 9500 Series, the password recovery procedure must be performed on the active supervisor module. Removing the supervisor module in slot 6 ensures that a switchover will not occur during the password recovery procedure.

---

Step 2 Power cycle the switch.

Step 3 Press the Ctrl-] key sequence when the switch begins its Cisco SAN-OS software boot sequence to enter the switch(boot)# prompt mode.

Ctrl-] 

switch(boot)#

Step 4 Change to configuration mode.

switch(boot)# config terminal

Step 5 Issue the admin-password command to reset the administrator password.

switch(boot-config)# admin-password <new password>

For information on strong passwords, see the "Characteristics of Strong Passwords" section.

Step 6 Exit to the EXEC mode.

switch(boot-config)# exit

switch(boot)#

Step 7 Issue the load command to load the Cisco SAN-OS software.

switch(boot)# load bootflash:m9500-sf1ek9-mz.2.1.1a.bin

---

Caution If you boot a system image that is older than the image you used to store the configuration and do not use the install all command to boot the system, the switch erases the binary configuration and uses the ASCII configuration. When this occurs, you must use the init system command to recover your password.

---

Step 8 Log in to the switch using the new administrator password.

switch login: admin

Password: <new password>

Step 9 Reset the new password to ensure that is it is also the SNMP password for Fabric Manager.

switch# config t

switch(config)# username admin password <new password>

switch(config)# exit

switch#

Step 10 Save the software configuration.

switch# copy running-config startup-config

Step 11 Insert the previously removed supervisor module into slot 6 in the chassis.

---

Default Settings

Table 39-2 lists the default settings for all switch security features in any switch.

Table 39-2 Default Switch Security Settings 

Parameters	Default
Roles in Cisco MDS Switches	Network operator (network-operator).
AAA configuration services	Local.
Authentication port	1821.
Accounting port	1813.
Preshared key communication	Clear text.
RADIUS server time out	1 (one) second.
RADIUS server retries	Once.
TACACS+	Disabled.
TACACS+ servers	None configured.
TACACS+ server timeout	5 seconds.
AAA server distribution	Disabled.
VSAN policy for roles	Permit.
User account	No expiry (unless configured).
Password	None.
Accounting log size	250 KB.
SSH service	Disabled.
Telnet service	Enabled.