2014, Brocade Communications Systems, Inc. All Rights Reserved.
Brocade, the B-wing symbol, Brocade Assurance, ADX, AnyIO, DCX, Fabric OS, FastIron, HyperEdge, ICX, MLX, MyBrocade, NetIron,
OpenScript, VCS, VDX, and Vyatta are registered trademarks, and The Effortless Network and the On-Demand Data Center are trademarks
of Brocade Communications Systems, Inc., in the United States and in other countries. Other brands and product names mentioned may be
trademarks of others.
Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any
equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document
at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be
currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in
this document may require an export license from the United States government.
The authors and Brocade Communications Systems, Inc. assume no liability or responsibility to any person or entity with respect to the
accuracy of this document or any loss, cost, liability, or damages arising from the information contained herein or the computer programs that
accompany it.
The product described by this document may contain open source software covered by the GNU General Public License or other open
source license agreements. To find out which open source software is included in Brocade products, view the licensing terms applicable to
the open source software, and obtain a copy of the programming source code, please visit http://www.brocade.com/support/oscd.
The document conventions describe text formatting conventions, command syntax conventions, and
important notice formats used in Brocade technical documentation.
Text formatting conventions
Text formatting conventions such as boldface, italic, or Courier font may be used in the flow of the text
to highlight specific words or phrases.
Format
bold text
italic text
Courier font
Description
Identifies command names
Identifies keywords and operands
Identifies the names of user-manipulated GUI elements
Identifies text to enter at the GUI
Identifies emphasis
Identifies variables and modifiers
Identifies paths and Internet addresses
Identifies document titles
Identifies CLI output
Identifies command syntax examples
Command syntax conventions
Bold and italic text identify command syntax components. Delimiters and operators define groupings of
parameters and their logical relationships.
Convention
bold textIdentifies command names, keywords, and command options.
valueIn Fibre Channel products, a fixed value provided as input to a command
[ ]Syntax components displayed within square brackets are optional.
option is printed in plain text, for example, --show WWN.
Default responses to system prompts are enclosed in square brackets.
{ x | y | z }A choice of required parameters is enclosed in curly brackets separated by
x | yA vertical bar separates mutually exclusive elements.
< >Nonprinting characters, for example, passwords, are enclosed in angle
...
\
vertical bars. You must select one of the options.
In Fibre Channel products, square brackets may be used instead for this
purpose.
brackets.
Repeat the previous element, for example, member[member...].
Indicates a “soft” line break in command examples. If a backslash separates
two lines of a command input, enter the entire command at the prompt without
the backslash.
Notes, cautions, and warnings
Notes, cautions, and warning statements may be used in this document. They are listed in the order of
increasing severity of potential hazards.
NOTE
A note provides a tip, guidance, or advice, emphasizes important information, or provides a reference
to related information.
ATTENTION
An Attention statement indicates potential damage to hardware or data.
CAUTION
A Caution statement alerts you to situations that can be potentially hazardous to you or cause
damage to hardware, firmware, software, or data.
DANGER
A Danger statement indicates conditions or situations that can be potentially lethal or
extremely hazardous to you. Safety labels are also attached directly to products to warn of
these conditions or situations.
Visit the Brocade website to locate related documentation for your product and additional Brocade
resources.
You can download additional publications supporting your product at www.brocade.com.
• Adapter documentation is available on the Downloads and Documentation for Brocade Adapters
page. Select your platform and scroll down to the Documentation section.
• For all other products, select the Brocade Products tab to locate your product, then click the Brocade
product name or image to open the individual product page. The user manuals are available in the
resources module at the bottom of the page under the Documentation category.
To get up-to-the-minute information on Brocade products and resources, go to MyBrocade. You can
register at no cost to obtain a user ID and password.
Release notes are available on MyBrocade under Product Downloads.
White papers, online demonstrations, and data sheets are available through the Brocade website.
Brocade resources
Getting technical help
You can contact Brocade Support 24x7 online, by telephone, or by e-mail.
For product support information and the latest information on contacting the Technical Assistance
Center, go to http://www.brocade.com/services-support/index.html.
Use one of the following methods to contact the Brocade Technical Assistance Center.
OnlineTelephoneE-mail
Preferred method of contact for nonurgent issues:
• My Cases through MyBrocade
• Software downloads and licensing
tools
• Knowledge Base
Required for Sev 1-Critical and Sev
2-High issues:
• Continental US: 1-800-752-8061
• Europe, Middle East, Africa, and
Asia Pacific: +800-AT FIBREE
(+800 28 34 27 33)
• For areas unable to access toll
free number: +1-408-333-6061
• Toll-free numbers are available in
many countries.
To send feedback and report errors in the documentation you can use the feedback form posted with
the document or you can e-mail the documentation team.
Quality is our first concern at Brocade and we have made every effort to ensure the accuracy and
completeness of this document. However, if you find an error or an omission, or you think that a topic
needs further development, we want to hear from you. You can provide feedback in two ways:
• Through the online feedback form in the HTML documents posted on www.brocade.com.
• By sending your feedback to documentation@brocade.com.
Provide the publication title, part number, and as much detail as possible, including the topic heading
and page number if applicable, as well as your suggestions for improvement.
● What’s new in this document ......................................................................................... 17
● How command information is presented in this guide.....................................................17
What’s new in this document
This document includes the information from IronWare software release 08.0.10d. The following table
lists the enhancements for FastIron release 08.0.10d.
Summary of enhancements in FastIron release 08.0.10dTABLE 1
FeatureDescriptionDescribed in
TTL enhancementThe no-ttl-decrement option
disables the TTL decrement
and the packets will be
forwarded without
decrementing TTL for the
traffic matched by the policy.
See Configuring the route map on page
147.
How command information is presented in this guide
For all new content, command syntax and parameters are documented in a separate command
reference section at the end of the publication.
In an effort to provide consistent command line interface (CLI) documentation for all products, Brocade
is in the process of preparing standalone Command References for the IP platforms. This process
involves separating command syntax and parameter descriptions from configuration tasks. Until this
process is completed, command information is presented in two ways:
• For all new content included in this guide, the CLI is documented in separate command pages. The
new command pages follow a standard format to present syntax, parameters, usage guidelines,
examples, and command history. Command pages are compiled in alphabetical order in a separate
command reference chapter at the end of the publication.
• Legacy content continues to include command syntax and parameter descriptions in the chapters
where the features are documented.
If you do not find command syntax information embedded in a configuration task, refer to the command
reference section at the end of this publication for information on CLI syntax and usage.
● TCP Flags - edge port security....................................................................................... 78
Supported security access features
Lists security access features supported on FastIron devices.
The following table lists the individual Brocade FastIron switches and the security access features they
support. These features are supported in the Layer 2 and Layer 3 software images, except where
explicitly noted.
FeatureICX 6430ICX 6450FCXICX 6610ICX 6650FSX 800
FSX 1600
Authentication, Authorization and
Accounting (AAA): RADIUS, TACACS
ACACS+
AAA support for console commands08.0.0108.0.0108.0.0108.0.0108.0.0108.0.0108.0.10
Web management is not supported in Release 8.0.00a and later releases. If web management is
enabled, you must configure the no web-management command to disable it.
NOTE
For all Brocade devices, RADIUS Challenge is supported for 802.1x authentication but not for login
authentication. Also, multiple challenges are supported for TACACS+ login authentication.
Securing access methods
The following table lists the management access methods available on a Brocade device, how they
are secured by default, and the ways in which they can be secured.
Ways to secure management access to Brocade devices TABLE 2
Access methodHow the access method is
Serial access to the
CLI
Access to the
Privileged EXEC and
CONFIG levels of the
CLI
Telnet accessNot securedRegulate Telnet
secured by default
Not securedEstablish passwords
Not securedEstablish a password
Ways to secure the
access method
for management
privilege levels
for Telnet access to
the CLI
Establish passwords
for management
privilege levels
Set up local user
accounts
Configure TACACS/
TACACS+ security
Configure RADIUS
security
access using ACLs
See page
Setting passwords for
management privilege
levels on page 32
Setting a Telnet
password on page 32
Setting passwords for
management privilege
levels on page 32
Local user accounts on
page 35
TACACS and TACACS+
security on page 42
RADIUS security on page
58
Using an ACL to restrict
Telnet access on page
23
Allow Telnet access
only from specific IP
addresses
Restrict Telnet access
based on a client MAC
address
You can restrict access to management functions from remote sources, including Telnet and SNMP.
The following methods for restricting remote access are supported:
• Using ACLs to restrict Telnet or SNMP access
• Allowing remote access only from specific IP addresses
• Allowing Telnet and SSH access only from specific MAC addresses
• Allowing remote access only to clients connected to a specific VLAN
• Specifically disabling Telnet or SNMP access to the device
NOTE
Web management is not supported in Release 8.0.00a and later releases. If web management is
enabled, you must configure the no web-management command to disable it.
The following sections describe how to restrict remote access to a Brocade device using these
methods.
ACL usage to restrict remote access
You can use standard ACLs to control the following access methods to management functions on a
Brocade device:
• Telnet
• SSH
• SNMP
Consider the following to configure access control for these management access methods.
1. Configure an ACL with the IP addresses you want to allow to access the device.
2. Configure a Telnet access group, SSH access group, and SNMP community strings. Each of these
configuration items accepts an ACL as a parameter. The ACL contains entries that identify the IP
addresses that can use the access method.
The following sections present examples of how to secure management access using ACLs. Refer to
the Rule-Based IP ACLs chapter for more information on configuring ACLs.
Using an ACL to restrict Telnet access
To configure an ACL that restricts Telnet access to the device, enter commands such as the following.
The num parameter specifies the number of a standard ACL and must be from 1 - 99.
The commands above configure ACL 10, then apply the ACL as the access list for Telnet access. The
device allows Telnet access to all IP addresses except those listed in ACL 10.
The num parameter specifies the number of a standard ACL and must be from 1 - 99.
These commands configure ACL 12, then apply the ACL as the access list for SSH access. The
device denies SSH access from the IP addresses listed in ACL 12 and permits SSH access from all
other IP addresses. Without the last ACL entry for permitting all packets, this ACL would deny SSH
access from all IP addresses.
NOTE
In this example, the command ssh access-group 10 could have been used to apply the ACL
configured in the example for Telnet access. You can use the same ACL multiple times.
Using ACLs to restrict SNMP access
To restrict SNMP access to the device using ACLs, enter commands such as the following.
NOTE
The syntax for using ACLs for SNMP access is different from the syntax for controlling Telnet and SSH
using ACLs.
device(config)#access-list 25 deny host 10.157.22.98 log
device(config)#access-list 25 deny 10.157.23.0 0.0.0.255 log
device(config)#access-list 25 deny 10.157.24.0 0.0.0.255 log
device(config)#access-list 25 permit any
device(config)#access-list 30 deny 10.157.25.0 0.0.0.255 log
device(config)#access-list 30 deny 10.157.26.0/24 log
device(config)#access-list 30 permit any
device(config)#snmp-server community public ro 25
device(config)#snmp-server community private rw 30
device(config)#write memory
Syntax:snmp-server communitystring [ ro | rw ] num
The string parameter specifies the SNMP community string the user must enter to gain SNMP access.
The ro parameter indicates that the community string is for read-only ("get") access. The rw parameter
indicates the community string is for read-write ("set") access.
The num parameter specifies the number of a standard ACL and must be from 1 - 99.
These commands configure ACLs 25 and 30, then apply the ACLs to community strings.
ACL 25 is used to control read-only access using the "public" community string. ACL 30 is used to
control read-write access using the "private" community string.
NOTE
When snmp-server community is configured, all incoming SNMP packets are validated first by their
community strings and then by their bound ACLs.
Defining the console idle time
By default, a Brocade device does not time out serial console sessions. A serial session remains open
indefinitely until you close it. You can however define how many minutes a serial management session
can remain idle before it is timed out.
NOTE
You must enable AAA support for console commands, AAA authentication, and Exec authorization in
order to set the console idle time.
To configure the idle time for a serial console session, use the following command.
device(config)#console timeout 120
Syntax:[no] console timeout [ 0-240 ]
Possible values: 0 - 240 minutes
Default value: 0 minutes (no timeout)
NOTE
In RADIUS, the standard attribute Idle-Timeout is used to define the console session timeout value. The
attribute Idle-Timeout value is specified in seconds. Within the switch, it is truncated to the nearest
minute, because the switch configuration is defined in minutes.
Remote access restrictions
By default, a Brocade device does not control remote management access based on the IP address of
the managing device. You can restrict remote management access to a single IP address for the
following access methods:
• Telnet access
• SSH access
• SNMP access
In addition, you can restrict all access methods to the same IP address using a single command.
The following examples show the CLI commands for restricting remote access. You can specify only
one IP address with each command. However, you can enter each command ten times to specify up to
ten IP addresses.
To allow SSH access to the Brocade device only to the host with IP address 10.157.22.39, enter the
following command.
device(config)#ip ssh client 10.157.22.39
Syntax: [no] ip ssh client { ip-addr | ipv6-addr }
Restricting SNMP access to a specific IP address
To allow SNMP access only to the host with IP address 10.157.22.14, enter the following command.
device(config)#snmp-client 10.157.22.14
Syntax: [no] snmp-client { ip-addr | ipv6-addr }
Restricting all remote management access to a specific IP address
To allow Telnet and SNMP management access to the Brocade device only to the host with IP
address 10.157.22.69, enter three separate commands (one for each access type) or enter the
following command.
device(config)#all-client 10.157.22.69
Syntax: [no] all-client { ip-addr | ipv6-addr }
Restricting access to the device based on IP orMAC address
You can restrict remote management access to the Brocade device, using Telnet, SSH, HTTP, and
HTTPS, based on the connecting client IP or MAC address.
Restricting Telnet connection
You can restrict Telnet connection to a device based on the client IP address or MAC address.
To allow Telnet access to the Brocade device only to the host with IP address 10.157.22.39 and MAC
address 0000.000f.e9a0, enter the following command.
Syntax:[no] ip ssh client { ip-addr | ipv6-addrmac-addr }
To allow SSH access to the Brocade device to a host with any IP address and MAC address
0000.000f.e9a0, enter the following command.
device(config)#ip ssh client any 0000.000f.e9a0
Syntax: [no] ip ssh client any mac-addr
Defining the Telnet idle time
You can define how many minutes a Telnet session can remain idle before it is timed out. An idle Telnet
session is a session that is still sending TCP ACKs in response to keepalive messages from the device,
but is not being used to send data.
To configure the idle time for a Telnet session, use the following command.
device(config)#telnet timeout 120
Syntax:[no] telnet timeoutminutes
For minutes enter a value from 0 - 240. The default value is 0 minutes (no timeout).
Specifying the maximum number of login attemptsfor Telnet access
If you are connecting to the Brocade device using Telnet, the device prompts you for a username and
password. By default, you have up to 4 chances to enter a correct username and password. If you do
not enter a correct username or password after 4 attempts, the Brocade device disconnects the Telnet
session.
You can specify the number of attempts a Telnet user has to enter a correct username and password
before the device disconnects the Telnet session. For example, to allow a Telnet user up to 5 chances
to enter a correct username and password, enter the following command.
device(config)#telnet login-retries 5
Syntax:[no] telnetlogin-retriesnumber
You can specify from 0 - 5 attempts. The default is 4 attempts.
Changing the login timeout period for Telnet sessions
NOTE
You need to configure telnet with the enable telnet authentication local command to enable only a
certain number of telnet login attempts.
Changing the login timeout period for Telnet sessions
By default, the login timeout period for a Telnet session is 2 minutes. To change the login timeout
period, use the following command.
device(config)#telnet login-timeout 5
Syntax:[no] telnet login-timeoutminutes
For minutes , enter a value from 1 to 10. The default timeout period is 2 minutes.
Restricting remote access to the device tospecific VLAN IDs
You can restrict management access to a Brocade device to ports within a specific port-based VLAN.
VLAN-based access control applies to the following access methods:
• Telnet access
• SNMP access
• TFTP access
By default, access is allowed for all the methods listed above on all ports. Once you configure security
for a given access method based on VLAN ID, access to the device using that method is restricted to
only the ports within the specified VLAN.
VLAN-based access control works in conjunction with other access control methods. For example,
suppose you configure an ACL to permit Telnet access only to specific client IP addresses, and you
also configure VLAN-based access control for Telnet access. In this case, the only Telnet clients that
can access the device are clients that have one of the IP addresses permitted by the ACL and are
connected to a port that is in a permitted VLAN. Clients who have a permitted IP address but are
connected to a port in a VLAN that is not permitted still cannot access the device through Telnet.
Restricting Telnet access to a specific VLAN
To allow Telnet access only to clients in a specific VLAN, enter a command such as the following.
device(config)#telnet server enable vlan 10
The command in this example configures the device to allow Telnet management access only to
clients connected to ports within port-based VLAN 10. Clients connected to ports that are not in VLAN
10 are denied management access.
Syntax:[no] telnet server enablevlanvlan-id
Restricting SNMP access to a specific VLAN
To allow SNMP access only to clients in a specific VLAN, enter a command such as the following.
The command in this example configures the device to allow SNMP access only to clients connected to
ports within port-based VLAN 40. Clients connected to ports that are not in VLAN 40 are denied access.
Syntax:[no] snmp-server enablevlanvlan-id
Restricting TFTP access to a specific VLAN
To allow TFTP access only to clients in a specific VLAN, enter a command such as the following.
device(config)#tftp client enable vlan 40
The command in this example configures the device to allow TFTP access only to clients connected to
ports within port-based VLAN 40. Clients connected to ports that are not in VLAN 40 are denied access.
Syntax:[no] tftp client enablevlanvlan-id
Designated VLAN for Telnet management sessionsto a Layer 2 Switch
All Brocade FastIron devices support the creation of management VLANs. By default, the management
IP address you configure on a Layer 2 Switch applies globally to all the ports on the device. This is true
even if you divide the device ports into multiple port-based VLANs.
If you want to restrict the IP management address to a specific port-based VLAN, you can make that
VLAN the designated management VLAN for the device. When you configure a VLAN to be the
designated management VLAN, the management IP address you configure on the device is associated
only with the ports in the designated VLAN. To establish a Telnet management session with the device,
a user must access the device through one of the ports in the designated VLAN.
You also can configure up to five default gateways for the designated VLAN, and associate a metric
with each one. The software uses the gateway with the lowest metric. The other gateways reside in the
configuration but are not used. To use one of the other gateways, modify the configuration so that the
gateway you want to use has the lowest metric.
If more than one gateway has the lowest metric, the gateway that appears first in the running-config is
used.
NOTE
If you have already configured a default gateway globally and you do not configure a gateway in the
VLAN, the software uses the globally configured gateway and gives the gateway a metric value of 1.
To configure a designated management VLAN, enter commands such as the following.
device(config)#vlan 10 by port
device(config-vlan-10)#untag ethernet 1/1 to 1/4
device(config-vlan-10)#management-vlan
device(config-vlan-10)#default-gateway 10.10.10.1 1
device(config-vlan-10)#default-gateway 10.20.20.1 2
These commands configure port-based VLAN 10 to consist of ports 1/1 - 1/4 and to be the designated
management VLAN. The last two commands configure default gateways for the VLAN. Since the
10.10.10.1 gateway has a lower metric, the software uses this gateway. The other gateway remains in
the configuration but is not used. You can use the other one by changing the metrics so that the
10.20.20.1 gateway has the lower metric.
Syntax:[no] default-gatewayip-addrmetric
The ip-addr parameters specify the IP address of the gateway router.
The metric parameter specifies the metric (cost) of the gateway. You can specify a value from 1 - 5.
There is no default. The software uses the gateway with the lowest metric.
Device management security
By default, all management access is disabled. Each of the following management access methods
must be specifically enabled as required in your installation:
• SSHv2
• SNMP
The commands for granting access to each of these management interfaces is described in the
following.
Allowing SSHv2 access to the Brocade device
To allow SSHv2 access to the Brocade device, you must generate a Crypto Key as shown in the
following command.
device(config)#crypto key generate
Syntax:crypto key [ generate | zeroize ]
The generate parameter generates a dsa key pair.
The zeroize parameter deletes the currently operative dsa key pair.
In addition, you must use AAA authentication to create a password to allow SSHv2 access. For
example the following command configures AAA authentication to use TACACS+ for authentication as
the default or local if TACACS+ is not available.
device(config)#aaa authentication login default tacacs+ local
Allowing SNMP access to the Brocade device
To allow SNMP access to the Brocade device, enter the following command.
device(config)#snmp-server
Syntax: [no] snmp server
Disabling specific access methods
You can specifically disable the following access methods:
• Telnet access
• SNMP access
• TFTP
NOTE
If you disable Telnet access, you will not be able to access the CLI except through a serial connection
to the management module. If you disable SNMP access, you will not be able to use an SNMP-based
management applications.
You can use a Telnet client to access the CLI on the device over the network. If you do not plan to use
the CLI over the network and want to disable Telnet access to prevent others from establishing CLI
sessions with the device, enter the following command.
device(config)#no telnet server
To re-enable Telnet operation, enter the following command.
device(config)#telnet server
Syntax: [no] telnet server
Disabling SNMP access
To disable SNMP management of the device.
device(config)#no snmp-server
To later re-enable SNMP management of the device.
device(config)#snmp-server
Syntax: [no] snmp-server
Disabling TFTP access
You can globally disable TFTP to block TFTP client access. By default, TFTP client access is enabled.
To disable TFTP client access, enter the following command at the Global CONFIG level of the CLI.
device(config)#tftp disable
When TFTP is disabled, users are prohibited from using the copy tftp command to copy files to the
system flash. If users enter this command while TFTP is disabled, the system will reject the command
and display an error message.
To re-enable TFTP client access once it is disabled, enter the following command.
device(config)#no tftp disable
Syntax: [no] tftp disable
Passwords used to secure access
Passwords can be used to secure the following access methods:
• Telnet access can be secured by setting a Telnet password. Refer to Setting a Telnet password on
page 32.
• Access to the Privileged EXEC and CONFIG levels of the CLI can be secured by setting passwords
for management privilege levels. Refer to Setting passwords for management privilege levels on
page 32.
This section also provides procedures for enhancing management privilege levels, recovering from a
lost password, and disabling password encryption.
You also can configure up to 16 user accounts consisting of a user name and password, and assign
each user account a management privilege level. Refer to Local user accounts on page 35.
Setting a Telnet password
By default, the device does not require a user name or password when you log in to the CLI using
Telnet. You can assign a password for Telnet access using one of the following methods.
Set the password "letmein" for Telnet access to the CLI using the following command at the global
CONFIG level.
device(config)#enable telnet password letmein
Syntax: [no] enable telnet password string
Suppressing Telnet connection rejection messages
By default, if a Brocade device denies Telnet management access to the device, the software sends a
message to the denied Telnet client. You can optionally suppress the rejection message. When you
enable the option, a denied Telnet client does not receive a message from the Brocade device.
Instead, the denied client simply does not gain access.
To suppress the connection rejection message, use the following CLI method.
To suppress the connection rejection message sent by the device to a denied Telnet client, enter the
following command at the global CONFIG level of the CLI.
device(config)#telnet server suppress-reject-message
Syntax: [no] telnet server suppress-reject-message
Setting passwords for management privilege levels
You can set one password for each of the following management privilege levels:
• Super User level - Allows complete read-and-write access to the system. This is generally for
system administrators and is the only management privilege level that allows you to configure
passwords.
• Port Configuration level - Allows read-and-write access for specific ports but not for global (systemwide) parameters.
• Read Only level - Allows access to the Privileged EXEC mode and User EXEC mode of the CLI but
only with read access.
You can assign a password to each management privilege level. You also can configure up to 16 user
accounts consisting of a user name and password, and assign each user account to one of the three
privilege levels. Refer to Local user accounts on page 35.
NOTE
You must use the CLI to assign a password for management privilege levels.
If you configure user accounts in addition to privilege level passwords, the device will validate a user
access attempt using one or both methods (local user account or privilege level password), depending
on the order you specify in the authentication-method lists. Refer to Authentication-method lists on page
75.
Follow the steps given below to set passwords for management privilege levels.
1. At the opening CLI prompt, enter the following command to change to the Privileged level of the
EXEC mode.
device> enable
device#
2. Access the CONFIG level of the CLI by entering the following command.
device#configure terminal
device(config)#
3. Enter the following command to set the Super User level password.
device(config)#enable super-user-password text
NOTE
You must set the Super User level password before you can set other types of passwords. The
Super User level password can be an alphanumeric string, but cannot begin with a number.
4. Enter the following commands to set the Port Configuration level and Read Only level passwords.
device(config)#enable port-config-password text
device(config)#enable read-only-password text
Syntax: enable super-user-password text
Syntax: enable port-config-password text
Syntax: enable read-only-password text
NOTE
If you forget your Super User level password, refer to Recovering from a lost password on page 34.
Augmenting management privilege levels
Each management privilege level provides access to specific areas of the CLI by default:
• Super User level provides access to all commands and displays.
• Port Configuration level gives access to:
‐The User EXEC and Privileged EXEC levels
‐The port-specific parts of the CONFIG level
‐All interface configuration levels
• Read Only level gives access to:
‐The User EXEC and Privileged EXEC levels
You can grant additional access to a privilege level on an individual command basis. To grant the
additional access, you specify the privilege level you are enhancing, the CLI level that contains the
command, and the individual command.
NOTE
This feature applies only to management privilege levels on the CLI.
Enhance the Port Configuration privilege level so users also can enter IP commands at the global
CONFIG level.
device(config)#privilege configure level 4 ip
In this command, configure specifies that the enhanced access is for a command at the global
CONFIG level of the CLI. The level 4 parameter indicates that the enhanced access is for
management privilege level 4 (Port Configuration). All users with Port Configuration privileges will
have the enhanced access. The ip parameter indicates that the enhanced access is for the IP
commands. Users who log in with valid Port Configuration level user names and passwords can enter
commands that begin with "ip" at the global CONFIG level.
The cli-level parameter specifies the CLI level and can be one of the following values:
• exec - EXEC level; for example, device> or device#
• configure - CONFIG level; for example, device(config)#
• interface - Interface level; for example, device(config-if-6)#
• loopback-interface - loopback interface level
• virtual-interface - Virtual-interface level; for example, device(config-vif-6)#
• dot1x - 802.1X configuration level
• ipv6-access-list - IPv6 access list configuration level
• rip-router - RIP router level; for example, device(config-rip-router)#
• ospf-router - OSPF router level; for example, device(config-ospf-router)#
• dvmrp-router - DVMRP router level; for example, device(config-dvmrp-router)#
• pim-router - PIM router level; for example, device(config-pim-router)#
• bgp-router - BGP4 router level; for example, device(config-bgp-router)#
• vrrp-router - VRRP configuration level
• gvrp - GVRP configuration level
• trunk - trunk configuration level
• port-vlan - Port-based VLAN level; for example, device(config-vlan)#
• protocol-vlan - Protocol-based VLAN level
The privilege-level indicates the number of the management privilege level you are augmenting. You
can specify one of the following:
• 0 - Super User level (full read-write access)
• 4 - Port Configuration level
• 5 - Read Only level
The command -string parameter specifies the command you are allowing users with the specified
privilege level to enter. To display a list of the commands at a CLI level, enter "?" at that level's
command prompt.
Recovering from a lost password
Recovery from a lost password requires direct access to the serial port and a system reset.
NOTE
You can perform this procedure only from the CLI.
Follow the steps given below to recover from a lost password.
1. Start a CLI session over the serial interface to the device.
2. Reboot the device.
3. At the initial boot prompt at system startup, enter b to enter the boot monitor mode.
4. Enter no password at the prompt. (You cannot abbreviate this command.) This command will cause
the device to bypass the system password check.
5. Enter boot system flash primary at the prompt. On ICX 6430 and ICX 6450 devices, enter
boot_primary.
6. After the console prompt reappears, assign a new password.
Displaying the SNMP community string
If you want to display the SNMP community string, enter the following commands.
device(config)#enable password-display
device#show snmp server
The enable password-display command enables display of the community string in the output of the
show snmp server command. Display of the string is still encrypted in the startup-config file and
running-config. When the enable password-display command is configured, the user password and
snmp community string are encrypted in the show run command output. Enter the command at the
global CONFIG level of the CLI.
Specifying a minimum password length
By default, the Brocade device imposes no minimum length on the Line (Telnet), Enable, or Local
passwords. You can configure the device to require that Line, Enable, and Local passwords be at least
a specified length.
For example, to specify that the Line, Enable, and Local passwords be at least 8 characters, enter the
following command.
You can define up to 32 local user accounts on a Brocade device. User accounts regulate who can
access the management functions in the CLI using the following methods:
• Telnet access
• SNMP access
• SSH access
Local user accounts provide greater flexibility for controlling management access to Brocade devices
than do management privilege level passwords and SNMP community strings of SNMP versions 1 and
2. You can continue to use the privilege level passwords and the SNMP community strings as additional
means of access authentication. Alternatively, you can choose not to use local user accounts and
instead continue to use only the privilege level passwords and SNMP community strings. Local user
accounts are backward-compatible with configuration files that contain privilege level passwords. Refer
to Setting passwords for management privilege levels on page 32.
If you configure local user accounts, you also need to configure an authentication-method list for
Telnet access and SNMP access. Refer to Authentication-method lists on page 75.
For each local user account, you specify a user name. You also can specify the following parameters:
• A password
NOTE
If you use AAA authentication for SNMP access and set the password same as the username,
providing the password during authentication is optional. You can provide just the correct username
for successful authentication.
• A management privilege level, which can be one of the following:
‐Super User level (default) - Allows complete read-and-write access to the system. This is
generally for system administrators and is the only privilege level that allows you to
configure passwords.
‐Port Configuration level - Allows read-and-write access for specific ports but not for global
parameters.
‐Read Only level - Allows access to the Privileged EXEC mode and User EXEC mode with
read access only.
• You can set additional username and password rules. Refer to Enhancements to username and
password on page 36.
Enhancements to username and password
This section describes the enhancements to the username and password features introduced in earlier
releases.
The following rules are enabled by default:
• Users are required to accept the message of the day.
• Users are locked out (disabled) if they fail to login after three attempts. This feature is automatically
enabled. Use the disable-on-login-failure command to change the number of login attempts (up to
10) before users are locked out.
The following rules are disabled by default:
• Enhanced user password combination requirements
• User password masking
• Quarterly updates of user passwords
• You can configure the system to store up to 15 previously configured passwords for each user.
• You can use the disable-on-login-failure command to change the number of login attempts (up to
10) before users are locked out.
• A password can now be set to expire.
Enabling enhanced user password combination requirements
When strict password enforcement is enabled on the Brocade device, you must enter a minimum of
eight characters containing the following combinations when you create an enable and a user
password:
Password minimum and combination requirements are strictly enforced.
Use the enable strict-password-enforcement command to enable the password security feature.
device(config)#enable strict-password-enforcement
Syntax:[no] enable strict-password-enforcement
This feature is disabled by default.
The following security upgrades apply to the enable strict-password-enforcement command:
• Passwords must not share four or more concurrent characters with any other password configured
on the router. If the user tries to create a password with four or more concurrent characters, the
following error message will be returned.
Error - The substring str within the password has been used earlier, please choose a
different password.
For example, the previous password was Ma!i4aYa&, the user cannot use any of the following as his or
her new password:
• ‐Ma!imai$D because "Mail" were used consecutively in the previous password
‐&3B9aYa& because "aYa&" were used consecutively in the previous password
‐i4aYEv#8 because "i4aY" were used consecutively in the previous password
• If the user tries to configure a password that was previously used, the Local User Account
configuration will not be allowed and the following message will be displayed.
This password was used earlier for same or different user, please choose a different
password.
Enabling user password masking
By default, when you use the CLI to create a user password, the password displays on the console as
you type it. For enhanced security, you can configure the Brocade device to mask the password
characters entered at the CLI. When password masking is enabled, the CLI displays asterisks (*) on the
console instead of the actual password characters entered.
The following shows the default CLI behavior when configuring a username and password.
device(config)#username kelly password summertime
The following shows the CLI behavior when configuring a username and password when passwordmasking is enabled.
device(config)#username kelly password
Enter Password: ********
NOTE
When password masking is enabled, press the [Enter] key before entering the password.
Syntax:usernamenamepassword [Enter]
For [Enter], press the Enter key. Enter the password when prompted.
If strict-password-enforcement is enabled, enter a password which contains the required character
combination. Refer to Enabling enhanced user password combination requirements on page 36.
To enable password masking, enter the following command.
device(config)#enable user password-masking
Syntax: [no] enable user password-masking
Enabling user password aging
For enhanced security, password aging enforces quarterly updates of all user passwords. After 180
days, the CLI will automatically prompt users to change their passwords when they attempt to sign on.
When password aging is enabled, the software records the system time that each user password was
configured or last changed. The time displays in the output of the show running configuration
command, indicated by set-time time .
device#show run
Current configuration:
....
username waldo password .....
username raveen set-time 2086038248
....
The password aging feature uses the NTP server clock to record the set-time. If the network does not
have an NTP server, then set-time will appear as set-time 0 in the output of the show runningconfiguration command.
A username set-time configuration is removed when:
• The username and password is deleted from the configuration
• The username password expires
When a username set-time configuration is removed, it no longer appears in the show runningconfiguration output.
Note that if a username does not have an assigned password, the username will not have a set-time
configuration.
Password aging is disabled by default. To enable it, enter the following command at the global
CONFIG level of the CLI.
device(config)#enable user password-aging
Syntax: [no] enable user password-aging
Configuring password history
By default, the Brocade device stores the last five user passwords for each user. When changing a
user password, the user cannot use any of the five previously configured passwords.
For security purposes, you can configure the Brocade device to store up to 15 passwords for each
user, so that users do not use the same password multiple times. If a user attempts to use a password
that is stored, the system will prompt the user to choose a different password.
To configure enhanced password history, enter a command such as the following at the global
CONFIG level of the CLI.
The CLI provides up to three login attempts. If a user fails to login after three attempts, that user is
locked out (disabled). If desired, you can increase or decrease the number of login attempts before the
user is disabled. To do so, enter a command such as the following at the global CONFIG level of the
CLI.
device(config)#enable user disable-on-login-failure 7
Syntax:enable userdisable-on-login-failure1-10
To re-enable a user that has been locked out, do one of the following:
• Reboot the Brocade device to re-enable all disabled users.
• Enable the user by entering the following command.
device(config)#username sandy enable
device(config)#user sandy enable
device#show user
Username Password Encrypt Priv Status Expire Time
==============================================================================
sandy $1$Gz...uX/$wQ44fVGtsqbKWkQknzAZ6. enabled 0 enabled 90 days
Syntax: username name enable
Setting passwords to expire
You can set a user password to expire. Once a password expires, the administrator must assign a new
password to the user. To configure a user password to expire, enter the following.
device(config)#username sandy expires 20
Syntax:usernamenameexpiresdays
Enter 1 - 365 for number of days. The default is 90 days.
device(config)#username sandy expires 20
device#show user
Username Password Encrypt Priv Status Expire Time
================================================================================
sandy $1$Gz...uX/$wQ44fVGtsqbKWkQknzAZ6. enabled 0 enabled 20 days
Requirement to accept the message of the day
If a message of the day (MOTD) is configured, a user will be required to press the Enter key before he
or she can login. MOTD is configured using the banner motd command.
There are no new CLI commands for this feature.
NOTE
This requirement is disabled by default, unless configured. Users are not required to press Enter after
the MOTD banner is displayed. Refer to "Requiring users to press the Enter key after the message of
the day banner" section in the FastIron Ethernet Switch Administration Guide .
You can create accounts for local users with or without passwords. Accounts with passwords can have
encrypted or unencrypted passwords.
You can assign privilege levels to local user accounts, but on a new device, you must create a local
user account that has a Super User privilege before you can create accounts with other privilege
levels.
NOTE
You must grant Super User level privilege to at least one account before you add accounts with other
privilege levels. You need the Super User account to make further administrative changes.
Local user accounts with no passwords
To create a user account without a password, enter the following command at the global CONFIG
level of the CLI.
If you want to use unencrypted passwords for local user accounts, enter a command such as the
following at the global CONFIG level of the CLI.
device(config)#username wonka password willy
If password masking is enabled, press the [Enter] key before entering the password.
device(config)#username wonka password
Enter Password: *******
The above commands add a local user account with the user name "wonka" and the password. This
account has the Super User privilege level; this user has full access to all configuration and display
features.
This command adds a user account for user name "waldo", password "whereis", with the Read Only
privilege level. Waldo can look for information but cannot make configuration changes.
You can enter up to 48 characters for user-string .
The privilege privilege-level parameter specifies the privilege level for the account. You can specify
one of the following:
• 0 - Super User level (full read-write access)
• 4 - Port Configuration level
• 5 - Read Only level
The default privilege level is 0 . If you want to assign Super User level access to the account, you can
enter the command without privilege 0 , as shown in the command example above.
The password | nopassword parameter indicates whether the user must enter a password. If you
specify password , enter the string for the user's password. You can enter up to 48 characters for
password-string . If strict password enforcement is enabled on the device, you must enter a minimum
of eight characters containing the following combinations:
• At least two upper case characters
• At least two lower case characters
• At least two numeric characters
• At least two special characters
NOTE
You must be logged on with Super User access (privilege level 0) to add user accounts or configure
other access parameters.
To display user account information, enter the following command.
device#show users
Syntax:show users
To know the different methods to secure access to the device using the configured username and
password, see Authentication-method lists on page 75.
Changing a local user password
To change a local user password for an existing local user account, enter a command such as the
following at the global CONFIG level of the CLI.
NOTE
You must be logged on with Super User access (privilege level 0) to change user passwords.
device(config)#username wonka password willy
If password masking is enabled, enter the username, press the [Enter] key, then enter the password.
device(config)#username wonka password
Enter Password:
The above commands change wonka's user name and password.
The password-string parameter is the user password. The password can be up to 48 characters and
must differ from the current password and two previously configured passwords.
When a password is changed, a message such as the following is sent to the Syslog.
SYSLOG: <14>Jan 1 00:00:00 10.44.9.11 Security: Password has been changed for user
tester from console session.
The message includes the name of the user whose password was changed and during which session
type, such as Console, Telnet, SSH, Web, SNMP, or others, the password was changed.
You can use the security protocol Terminal Access Controller Access Control System (TACACS) or
TACACS+ to authenticate the following kinds of access to the Brocade device:
• Telnet access
• SSH access
• Console access
• Access to the Privileged EXEC level and CONFIG levels of the CLI
The TACACS and TACACS+ protocols define how authentication, authorization, and accounting
information is sent between a Brocade device and an authentication database on a TACACS/TACACS
+ server. TACACS/TACACS+ services are maintained in a database, typically on a UNIX workstation
or PC with a TACACS/TACACS+ server running.
How TACACS+ differs from TACACS
TACACS is a simple UDP-based access control protocol originally developed by BBN for MILNET.
TACACS+ is an enhancement to TACACS and uses TCP to ensure reliable delivery.
TACACS+ is an enhancement to the TACACS security protocol. TACACS+ improves on TACACS by
separating the functions of authentication, authorization, and accounting (AAA) and by encrypting all
traffic between the Brocade device and the TACACS+ server. TACACS+ allows for arbitrary length
and content authentication exchanges, which allow any authentication mechanism to be utilized with
the Brocade device. TACACS+ is extensible to provide for site customization and future development
features. The protocol allows the Brocade device to request very precise access control and allows the
TACACS+ server to respond to each component of that request.
NOTE
TACACS+ provides for authentication, authorization, and accounting, but an implementation or
configuration is not required to employ all three.
When you configure a Brocade device to use a TACACS/TACACS+ server for authentication , the
device prompts users who are trying to access the CLI for a user name and password, then verifies
the password with the TACACS/TACACS+ server.
If you are using TACACS+, Brocade recommends that you also configure authorization , in which the
Brocade device consults a TACACS+ server to determine which management privilege level (and
which associated set of commands) an authenticated user is allowed to use. You can also optionally
configure accounting , which causes the Brocade device to log information on the TACACS+ server
when specified events occur on the device.
NOTE
By default, a user logging into the device from Telnet or SSH would first enter the User EXEC level.
The user can enter the enable command to get to the Privileged EXEC level. A user that is
successfully authenticated can be automatically placed at the Privileged EXEC level after login. Refer
to Entering privileged EXEC mode after a Telnet or SSH login on page 52.
Configuring TACACS/TACACS+ for devices in a Brocade traditional stack
Configuring TACACS/TACACS+ for devices in a Brocade traditional stack
Becausedevices operating in a Brocade traditional stack topology present multiple console ports, you
must take additional steps to secure these ports when configuring TACACS/TACACS+.
The following is a sample AAA console configuration using TACACS+.
• all - logs out all console port on stack units that are not the Active Controller
• unit - logs out the console port on a specified unit
Once AAA console is enabled, you should log out any open console ports on your traditional stack
using the kill console command:
device(config)#kill console all
In case a user forgets to log out or a console is left unattended, you can also configure the console
timeout (in minutes) on all stack units (including the Active Controller).
device(config)#stack unit 3
device(config-unit-3)#console timeout 5
device(config-unit-3)#exit
device(config)#stack unit 4
device(config-unit-4)#console timeout 5
Use the show who and the show telnet commands to confirm the status of console sessions.
stack9#show who
Console connections (by unit number):
1 established
you are connecting to this session
4 seconds in idle
2 established
1 hours 3 minutes 12 seconds in idle
3 established
1 hours 3 minutes 9 seconds in idle
4 established
1 hours 3 minutes 3 seconds in idle
Telnet connections (inbound):
1 closed
2 closed
3 closed
4 closed
5 closed
Telnet connection (outbound):
6 closed
SSH connections:
1 closed
2 closed
3 closed
4 closed
5 closed
stack9#
stack9#show telnet
Console connections (by unit number):
1 established
Brocade devices support two kinds of TACACS+ authorization:
• Exec authorization determines a user privilege level when they are authenticated
• Command authorization consults a TACACS+ server to get authorization for commands entered by
the user
When TACACS+ exec authorization takes place, the following events occur.
1. A user logs into the Brocade device using Telnet or SSH
2. The user is authenticated.
3. The Brocade device consults the TACACS+ server to determine the privilege level of the user.
4. The TACACS+ server sends back a response containing an A-V (Attribute-Value) pair with the
privilege level of the user.
5. The user is granted the specified privilege level.
When TACACS+ command authorization takes place, the following events occur.
TACACS+ accounting
TACACS+ accounting works as follows.
1. One of the following events occur on the Brocade device:
• ‐A user logs into the management interface using Telnet or SSH
‐A user enters a command for which accounting has been configured
‐A system event occurs, such as a reboot or reloading of the configuration file
2. The Brocade device checks the configuration to see if the event is one for which TACACS+
accounting is required.
3. If the event requires TACACS+ accounting, the Brocade device sends a TACACS+ Accounting Start
packet to the TACACS+ accounting server, containing information about the event.
4. The TACACS+ accounting server acknowledges the Accounting Start packet.
5. The TACACS+ accounting server records information about the event.
6. When the event is concluded, the Brocade device sends an Accounting Stop packet to the TACACS+
accounting server.
7. The TACACS+ accounting server acknowledges the Accounting Stop packet.
AAA operations for TACACS/TACACS+
The following table lists the sequence of authentication, authorization, and accounting operations that
take place when a user gains access to a Brocade device that has TACACS/TACACS+ security
configured.
User action
Applicable AAA operations
User attempts to gain access to the
Privileged EXEC and CONFIG levels of the
CLI
AAA security for commands pasted into the running-config
AAA security for commands pasted into the running-config
If AAA security is enabled on the device, commands pasted into the running-config are subject to the
same AAA operations as if they were entered manually.
When you paste commands into the running-config, and AAA command authorization or accounting, or
both, are configured on the device, AAA operations are performed on the pasted commands. The AAA
operations are performed before the commands are actually added to the running-config. The server
performing the AAA operations should be reachable when you paste the commands into the runningconfig file. If the device determines that a pasted command is invalid, AAA operations are halted on the
remaining commands. The remaining commands may not be executed if command authorization is
configured.
TACACS/TACACS+ configuration considerations
• You must deploy at least one TACACS/TACACS+ server in your network.
• Brocade devices support authentication using up to eight TACACS/TACACS+ servers. The device
tries to use the servers in the order you add them to the device configuration.
• You can select only one primary authentication method for each type of access to a device (CLI
through Telnet, CLI Privileged EXEC and CONFIG levels). For example, you can select TACACS+
as the primary authentication method for Telnet CLI access, but you cannot also select RADIUS
authentication as a primary method for the same type of access. However, you can configure backup
authentication methods for each access type.
• You can configure the Brocade device to authenticate using a TACACS or TACACS+ server, not
both.
Configuring TACACS
Follow the procedure given below for TACACS configurations.
1. Identify TACACS servers. Refer to Identifying the TACACS/TACACS+ servers on page 48.
2. Set optional parameters. Refer to Setting optional TACACS and TACACS+ parameters on page
49.
3. Configure authentication-method lists. Refer to Configuring authentication-method lists forTACACS
and TACACS+ on page 50.
Configuring TACACS+
Follow the procedure given below for TACACS+ configurations.
1. Identify TACACS+ servers. Refer to Identifying the TACACS/TACACS+ servers on page 48.
2. Set optional parameters. Refer to Setting optional TACACS and TACACS+ parameters on page
49.
3. Configure authentication-method lists. Refer to Configuring authentication-method lists forTACACS
and TACACS+ on page 50.
4. Optionally configure TACACS+ authorization. Refer to Configuring TACACS+ authorization on page
53.
5. Optionally configure TACACS+ accounting. Refer to TACACS+ accounting configuration on page
The ip-addr | ipv6-addr | hostname parameter specifies the IP address or host name of the server. You
can enter up to eight tacacs-server host commands to specify up to eight different servers.
NOTE
To specify the server's host name instead of its IP address, you must first identify a DNS server using
the ip dns server-address ip-addr command at the global CONFIG level.
If you add multiple TACACS/TACACS+ authentication servers to the Brocade device, the device tries
to reach them in the order you add them. For example, if you add three servers in the following order,
the software tries the servers in the same order.
1. 10.94.6.161
2. 10.94.6.191
3. 10.94.6.122
You can remove a TACACS/TACACS+ server by entering no followed by the tacacs-server
command. For example, to remove 10.94.6.161, enter the following command.
device(config)#no tacacs-server host 10.94.6.161
NOTE
If you erase a tacacs-server command (by entering "no" followed by the command), make sure you
also erase the aaa commands that specify TACACS/TACACS+ as an authentication method. (Refer
to Configuring authentication-method lists forTACACS and TACACS+ on page 50.) Otherwise,
when you exit from the CONFIG mode or from a Telnet session, the system continues to believe it
is TACACS/TACACS+ enabled and you will not be able to access the system.
Specifying different servers for individual AAA functions
The auth-port parameter specifies the UDP (for TACACS) or TCP (for TACACS+) port number of
the authentication port on the server. The default port number is 49.
Specifying different servers for individual AAA functions
In a TACACS+ configuration, you can designate a server to handle a specific AAA task. For example,
you can designate one TACACS+ server to handle authorization and another TACACS+ server to
handle accounting. You can set the TACACS+ key for each server.
To specify different TACACS+ servers for authentication, authorization, and accounting, enter the
command such as following.
The default parameter causes the server to be used for all AAA functions.
After authentication takes place, the server that performed the authentication is used for authorization
and accounting. If the authenticating server cannot perform the requested function, then the next server
in the configured list of servers is tried; this process repeats until a server that can perform the
requested function is found, or every server in the configured list has been tried.
Setting optional TACACS and TACACS+ parameters
You can set the following optional parameters in a TACACS and TACACS+ configuration:
• TACACS+ key - This parameter specifies the value that the Brocade device sends to the TACACS+
server when trying to authenticate user access.
• Retransmit interval - This parameter specifies how many times the Brocade device will resend an
authentication request when the TACACS/TACACS+ server does not respond. The retransmit value
can be from 1 - 5 times. The default is 3 times.
• Dead time - This parameter specifies how long the Brocade device waits for the primary
authentication server to reply before deciding the server is dead and trying to authenticate using the
next server. The dead-time value can be from 1 - 5 seconds. The default is 3 seconds.
• Timeout - This parameter specifies how many seconds the Brocade device waits for a response from
a TACACS/TACACS+ server before either retrying the authentication request, or determining that the
TACACS/TACACS+ servers are unavailable and moving on to the next authentication method in the
authentication-method list. The timeout can be from 1 - 15 seconds. The default is 3 seconds.
Setting the TACACS+ key
The key parameter in the tacacs-server command is used to encrypt TACACS+ packets before they
are sent over the network. The value for the key parameter on the Brocade device should match the
one configured on the TACACS+ server. The key can be from 1 - 32 characters in length and cannot
include any space characters.
NOTE
The tacacs-server key command applies only to TACACS+ servers, not to TACACS servers. If you are
configuring TACACS, do not configure a key on the TACACS server and do not enter a key on the
Brocade device.
Encryption of the TACACS+ keys is done by default. The 0 parameter disables encryption. The 1
parameter is not required; it is provided for backwards compatibility.
Setting the retransmission limit
The retransmit parameter specifies how many times the Brocade device will resend an authentication
request when the TACACS/TACACS+ server does not respond. The retransmit limit can be from 1 - 5
times. The default is 3 times.
To set the TACACS and TACACS+ retransmit limit, enter a command such as the following.
device(config)#tacacs-server retransmit 5
Syntax: tacacs-server retransmit number
Setting the timeout parameter
The timeout parameter specifies how many seconds the Brocade device waits for a response from
the TACACS/TACACS+ server before either retrying the authentication request, or determining that
the TACACS/TACACS+ server is unavailable and moving on to the next authentication method in the
authentication-method list. The timeout can be from 1 - 15 seconds. The default is 3 seconds.
device(config)#tacacs-server timeout 5
Syntax: tacacs-server timeout number
Configuring authentication-method lists forTACACS and TACACS+
You can use TACACS/TACACS+ to authenticate Telnet/SSH access and access to Privileged EXEC
level and CONFIG levels of the CLI. When configuring TACACS/TACACS+ authentication, you create
authentication-method lists specifically for these access methods, specifying TACACS/TACACS+ as
the primary authentication method.
Within the authentication-method list, TACACS/TACACS+ is specified as the primary authentication
method and up to six backup authentication methods are specified as alternates. If TACACS/TACACS
+ authentication fails due to an error, the device tries the backup authentication methods in the order
they appear in the list.
When you configure authentication-method lists for TACACS/TACACS+ authentication, you must create
a separate authentication-method list for Telnet/SSH CLI access, and for access to the Privileged EXEC
level and CONFIG levels of the CLI.
To create an authentication method list that specifies TACACS/TACACS+ as the primary authentication
method for securing Telnet/SSH access to the CLI.
device(config)#enable telnet authentication
device(config)#aaa authentication login default tacacs local
The commands above cause TACACS/TACACS+ to be the primary authentication method for securing
Telnet/SSH access to the CLI. If TACACS/TACACS+ authentication fails due to an error with the server,
authentication is performed using local user accounts instead.
To create an authentication-method list that specifies TACACS/TACACS+ as the primary authentication
method for securing access to Privileged EXEC level and CONFIG levels of the CLI.
device(config)#aaa authentication enable default tacacs local none
The command above causes TACACS/TACACS+ to be the primary authentication method for securing
access to Privileged EXEC level and CONFIG levels of the CLI. If TACACS/TACACS+ authentication
fails due to an error with the server, local authentication is used instead. If local authentication fails, no
authentication is used; the device automatically permits access.
The web-server | enable | login parameter specifies the type of access this authentication-method list
controls. You can configure one authentication-method list for each type of access.
The method1 parameter specifies the primary authentication method. The remaining optional method
parameters specify additional methods to try if an error occurs with the primary method. A method can
be one of the values listed in the Method Parameter column in the following table.
Authentication method values TABLE 3
Method parameter Description
lineAuthenticate using the password you configured for Telnet access. The Telnet password is
configured using the enable telnet password... command. Refer to Setting a Telnet
password on page 32.
enableAuthenticate using the password you configured for the Super User privilege level. This
password is configured using the enable super-user-password... command. Refer to Setting
passwords for management privilege levels on page 32.
localAuthenticate using a local user name and password you configured on the device. Local user
names and passwords are configured using the username... command. Refer to Local user
account configuration on page 40.
tacacsAuthenticate using the database on a TACACS server. You also must identify the server to
the device using the tacacs-server command.
tacacs+Authenticate using the database on a TACACS+ server. You also must identify the server to
the device using the tacacs-server command.
radiusAuthenticate using the database on a RADIUS server. You also must identify the server to the
Entering privileged EXEC mode after a Telnet or SSH login
Authentication method values (Continued)TABLE 3
Method parameter Description
noneDo not use any authentication method. The device automatically permits access.
NOTE
For examples of how to define authentication-method lists for types of authentication other than
TACACS/TACACS+, refer to Authentication-method lists on page 75.
Entering privileged EXEC mode after a Telnet or SSH login
By default, a user enters User EXEC mode after a successful login through Telnet or SSH. Optionally,
you can configure the device so that a user enters Privileged EXEC mode after a Telnet or SSH login.
To do this, use the following command.
The user privilege level is based on the privilege level granted during login.
Configuring enable authentication to prompt for password only
If Enable authentication is configured on the device, when a user attempts to gain Super User access
to the Privileged EXEC and CONFIG levels of the CLI, by default he or she is prompted for a
username and password. You can configure the Brocade device to prompt only for a password. The
device uses the username entered at login, if one is available. If no username was entered at login,
the device prompts for both username and password.
To configure the Brocade device to prompt only for a password when a user attempts to gain Super
User access to the Privileged EXEC and CONFIG levels of the CLI.
Telnet and SSH prompts when the TACACS+ Server is unavailable
When TACACS+ is the first method in the authentication method list, the device displays the login
prompt received from the TACACS+ server. If a user attempts to login through Telnet or SSH, but
none of the configured TACACS+ servers are available, the following takes place:
• If the next method in the authentication method list is "enable", the login prompt is skipped, and the
user is prompted for the Enable password (that is, the password configured with the enable super-user-password command).
• If the next method in the authentication method list is "line", the login prompt is skipped, and the
user is prompted for the Line password (that is, the password configured with the enable telnetpassword command).
Brocade devices support TACACS+ authorization for controlling access to management functions in the
CLI. Two kinds of TACACS+ authorization are supported:
• Exec authorization determines a user privilege level when they are authenticated
• Command authorization consults a TACACS+ server to get authorization for commands entered by
the user
Configuring exec authorization
When TACACS+ exec authorization is performed, the Brocade device consults a TACACS+ server to
determine the privilege level of the authenticated user. To configure TACACS+ exec authorization on
the Brocade device, enter the following command.
If you specify none , or omit the aaa authorization exec command from the device configuration, no
exec authorization is performed.
A user privilege level is obtained from the TACACS+ server in the "foundry-privlvl" A-V pair. If the aaaauthorization exec default tacacs+ command exists in the configuration, the device assigns the user
the privilege level specified by this A-V pair. If the command does not exist in the configuration, then the
value in the "foundry-privlvl" A-V pair is ignored, and the user is granted Super User access.
NOTE
If the aaa authorization exec default tacacs+ command exists in the configuration, following
successful authentication the device assigns the user the privilege level specified by the "foundryprivlvl" A-V pair received from the TACACS+ server. If the aaa authorization exec default tacacs+
command does not exist in the configuration, then the value in the "foundry-privlvl" A-V pair is ignored,
and the user is granted Super User access.Also note that in order for the aaa authorization execdefault tacacs+ command to work, either theaaa authentication enable default tacacs+ command,
or the aaa authentication login privilege-mode command must also exist in the configuration.
Configuring an Attribute-Value pair on the TACACS+ server
During TACACS+ exec authorization, the Brocade device expects the TACACS+ server to send a
response containing an A-V (Attribute-Value) pair that specifies the privilege level of the user. When the
Brocade device receives the response, it extracts an A-V pair configured for the Exec service and uses
it to determine the user privilege level.
To set a user privilege level, you can configure the "foundry-privlvl" A-V pair for the Exec service on the
TACACS+ server.
user=bob {
default service = permit
member admin
#Global password
global = cleartext "cat"
service = exec {
foundry-privlvl = 0
}
}
In this example, the A-V pair foundry-privlvl = 0 grants the user full read-write access. The value
in the foundry-privlvl A-V pair is an integer that indicates the privilege level of the user. Possible values
are 0 for super-user level, 4 for port-config level, or 5 for read-only level. If a value other than 0, 4, or 5
is specified in the foundry-privlvl A-V pair, the default privilege level of 5 (read-only) is used. The
foundry-privlvl A-V pair can also be embedded in the group configuration for the user. See your
TACACS+ documentation for the configuration syntax relevant to your server.
If the foundry-privlvl A-V pair is not present, the Brocade device extracts the last A-V pair configured
for the Exec service that has a numeric value. The Brocade device uses this A-V pair to determine the
user privilege level.
user=bob {
default service = permit
member admin
#Global password
global = cleartext "cat"
service = exec {
privlvl = 15
}
}
The attribute name in the A-V pair is not significant; the Brocade device uses the last one that has a
numeric value. However, the Brocade device interprets the value for a non-"foundry-privlvl" A-V pair
differently than it does for a "foundry-privlvl" A-V pair. The following table lists how the Brocade device
associates a value from a non-"foundry-privlvl" A-V pair with a Brocade privilege level.
Brocade equivalents for non-"foundry-privlvl" A-V pair values TABLE 4
Value for non-"foundry-privlvl" A-V pairBrocade privilege level
150 (super-user)
From 14 - 14 (port-config)
Any other number or 05 (read-only)
In the example above, the A-V pair configured for the Exec service is privlvl = 15 . The Brocade
device uses the value in this A-V pair to set the user privilege level to 0 (super-user), granting the user
full read-write access.
In a configuration that has both a "foundry-privlvl" A-V pair and a non-"foundry-privlvl" A-V pair for the
Exec service, the non-"foundry-privlvl" A-V pair is ignored.
user=bob {
default service = permit
member admin
#Global password
global = cleartext "cat"
service = exec {
foundry-privlvl = 4
privlvl = 15
}
}
In this example, the user would be granted a privilege level of 4 (port-config level). The privlvl = 15
A-V pair is ignored by the Brocade device.
If the TACACS+ server has no A-V pair configured for the Exec service, the default privilege level of 5
(read-only) is used.
When TACACS+ command authorization is enabled, the Brocade device consults a TACACS+ server
to get authorization for commands entered by the user.
You enable TACACS+ command authorization by specifying a privilege level whose commands require
authorization. For example, to configure the Brocade device to perform authorization for the commands
available at the Super User privilege level (that is, all commands on the device), enter the following
command.
The privilege-level parameter can be one of the following:
• 0 - Authorization is performed for commands available at the Super User level (all commands)
• 4 - Authorization is performed for commands available at the Port Configuration level (port-config and
read-only commands)
• 5 - Authorization is performed for commands available at the Read Only level (read-only commands)
NOTE
TACACS+ command authorization can be performed only for commands entered from Telnet or SSH
sessions, or from the console.
TACACS+ command authorization is not performed for the following commands:
• At all levels: exit , logout , end , and quit .
• At the Privileged EXEC level: enable or enable text , where text is the password configured for the
Super User privilege level.
If configured, command accounting is performed for these commands.
AAA support for console commands
AAA support for commands entered at the console includes the following:
• Login prompt that uses AAA authentication, using authentication-method Lists
• Exec Authorization
• Exec Accounting
• Command authorization
• Command accounting
• System Accounting
To enable AAA support for commands entered at the console, enter the following command.
device(config)#enable aaa console
Syntax: [no] enable aaa console
TACACS+ accounting configuration
Brocade devices support TACACS+ accounting for recording information about user activity and system
events. When you configure TACACS+ accounting on a Brocade device, information is sent to a
TACACS+ accounting server when specified events occur, such as when a user logs into the device or
the system is rebooted.
Configuring TACACS+ accounting for Telnet/SSH (Shell) access
Configuring TACACS+ accounting for Telnet/SSH (Shell) access
To send an Accounting Start packet to the TACACS+ accounting server when an authenticated user
establishes a Telnet or SSH session on the Brocade device, and an Accounting Stop packet when the
user logs out.
You can configure TACACS+ accounting for CLI commands by specifying a privilege level whose
commands require accounting. For example, to configure the Brocade device to perform TACACS+
accounting for the commands available at the Super User privilege level (that is; all commands on the
device), enter the following command.
An Accounting Start packet is sent to the TACACS+ accounting server when a user enters a
command, and an Accounting Stop packet is sent when the service provided by the command is
completed.
NOTE
If authorization is enabled, and the command requires authorization, then authorization is performed
before accounting takes place. If authorization fails for the command, no accounting takes place.
The privilege-level parameter can be one of the following:
• 0 - Records commands available at the Super User level (all commands)
• 4 - Records commands available at the Port Configuration level (port-config and read-only
commands)
• 5 - Records commands available at the Read Only level (read-only commands)
Configuring TACACS+ accounting for system events
You can configure TACACS+ accounting to record when system events occur on the Brocade device.
System events include rebooting and when changes to the active configuration are made.
The following command causes an Accounting Start packet to be sent to the TACACS+ accounting
server when a system event occurs, and a Accounting Stop packet to be sent when the system event
is completed.
device(config)#aaa accounting system default start-stop tacacs+
Configuring an interface as the source for allTACACS and TACACS+
packets
You can designate the lowest-numbered IP address configured an Ethernet port, loopback interface,
or virtual interface as the source IP address for all TACACS/TACACS+ packets from the Layer 3
Displaying TACACS/TACACS+ statistics andconfiguration information
Switch. For configuration details, see "Specifying a single source interface for specified packet types"
section in the FastIron Ethernet Switch Layer 3 Routing Configuration Guide .
Displaying TACACS/TACACS+ statistics andconfiguration information
The show aaa command displays information about all TACACS+ and RADIUS servers identified on
the device.
You can use a Remote Authentication Dial In User Service (RADIUS) server to secure the following
types of access to the Brocade Layer 2 Switch or Layer 3 Switch:
• Telnet access
• SSH access
• Access to the Privileged EXEC level and CONFIG levels of the CLI
RADIUS authentication, authorization, and accounting
When RADIUS authentication is implemented, the Brocade device consults a RADIUS server to verify
user names and passwords. You can optionally configure RADIUS authorization , in which the
Brocade device consults a list of commands supplied by the RADIUS server to determine whether a
user can issue a command he or she has entered, as well as accounting , which causes the Brocade
device to log information on a RADIUS accounting server when specified events occur on the device.
RADIUS authentication
When RADIUS authentication takes place, the following events occur.
1. A user attempts to gain access to the Brocade device by doing one of the following:
• ‐Logging into the device using Telnet or SSH
‐Entering the Privileged EXEC level or CONFIG level of the CLI
2. The user is prompted for a username and password.
3. The user enters a username and password.
4. The Brocade device sends a RADIUS Access-Request packet containing the username and
password to the RADIUS server.
5. The RADIUS server validates the Brocade device using a shared secret (the RADIUS key).
6. The RADIUS server looks up the username in its database.
7. If the username is found in the database, the RADIUS server validates the password.
8. If the password is valid, the RADIUS server sends an Access-Accept packet to the Brocade device,
authenticating the user. Within the Access-Accept packet are three Brocade vendor-specific
attributes that indicate:
• ‐The privilege level of the user
‐A list of commands
‐Whether the user is allowed or denied usage of the commands in the list
The last two attributes are used with RADIUS authorization, if configured.
9. The user is authenticated, and the information supplied in the Access-Accept packet for the user is
stored on the Brocade device. The user is granted the specified privilege level. If you configure
RADIUS authorization, the user is allowed or denied usage of the commands in the list.
RADIUS authorization
When RADIUS authorization takes place, the following events occur.
1. A user previously authenticated by a RADIUS server enters a command on the Brocade device.
2. The Brocade device looks at its configuration to see if the command is at a privilege level that
requires RADIUS command authorization.
3. If the command belongs to a privilege level that requires authorization, the Brocade device looks at
the list of commands delivered to it in the RADIUS Access-Accept packet when the user was
authenticated. (Along with the command list, an attribute was sent that specifies whether the user is
permitted or denied usage of the commands in the list.)
NOTE
After RADIUS authentication takes place, the command list resides on the Brocade device. The
RADIUS server is not consulted again once the user has been authenticated. This means that any
changes made to the user command list on the RADIUS server are not reflected until the next time
the user is authenticated by the RADIUS server, and the new command list is sent to the Brocade
device.
4. If the command list indicates that the user is authorized to use the command, the command is
executed.
RADIUS accounting
RADIUS accounting works as follows.
1. One of the following events occur on the Brocade device:
• ‐A user logs into the management interface using Telnet or SSH
‐A user enters a command for which accounting has been configured
‐A system event occurs, such as a reboot or reloading of the configuration file
2. The Brocade device checks its configuration to see if the event is one for which RADIUS accounting
is required.
3. If the event requires RADIUS accounting, the Brocade device sends a RADIUS Accounting Start
packet to the RADIUS accounting server, containing information about the event.
4. The RADIUS accounting server acknowledges the Accounting Start packet.
5. The RADIUS accounting server records information about the event.
6. When the event is concluded, the Brocade device sends an Accounting Stop packet to the RADIUS
accounting server.
7. The RADIUS accounting server acknowledges the Accounting Stop packet.
AAA operations for RADIUS
The following table lists the sequence of authentication, authorization, and accounting operations that
take place when a user gains access to a Brocade device that has RADIUS security configured.
User action
User attempts to gain access to the
Privileged EXEC and CONFIG levels of the
CLI
User logs in using Telnet/SSHLogin authentication:
AAA security for commands pasted Into the running-config
If AAA security is enabled on the device, commands pasted into the running-config are subject to the
same AAA operations as if they were entered manually.
When you paste commands into the running-config, and AAA command authorization or accounting,
or both, are configured on the device, AAA operations are performed on the pasted commands. The
AAA operations are performed before the commands are actually added to the running-config. The
server performing the AAA operations should be reachable when you paste the commands into the
running-config file. If the device determines that a pasted command is invalid, AAA operations are
halted on the remaining commands. The remaining commands may not be issued if command
authorization is configured.
NOTE
Since RADIUS command authorization relies on a list of commands received from the RADIUS server
when authentication is performed, it is important that you use RADIUS authentication when you also
use RADIUS command authorization.
RADIUS configuration considerations
• You must deploy at least one RADIUS server in your network.
• Brocade devices support authentication using up to eight RADIUS servers, including those used for
802.1X authentication and for management. The device tries to use the servers in the order you add
them to the device configuration. If one RADIUS server times out (does not respond), the Brocade
device tries the next one in the list. Servers are tried in the same sequence each time there is a
request.
• You can optionally configure a RADIUS server as a port server , indicating that the server will be
used only to authenticate users on ports to which it is mapped, as opposed to globally authenticating
users on all ports of the device. In earlier releases, all configured RADIUS servers are "global"
servers and apply to users on all ports of the device. Refer to RADIUS server per port on page 64.
• You can map up to eight RADIUS servers to each port on the Brocade device. The port will
authenticate users using only the RADIUS servers to which it is mapped. If there are no RADIUS
servers mapped to a port, it will use the "global" servers for authentication. In earlier releases, all
RADIUS servers are "global" servers and cannot be bound to individual ports. Refer to RADIUS
server to individual ports mapping on page 65.
• You can select only one primary authentication method for each type of access to a device (CLI
through Telnet, CLI Privileged EXEC and CONFIG levels). For example, you can select RADIUS as
the primary authentication method for Telnet CLI access, but you cannot also select TACACS+
authentication as the primary method for the same type of access. However, you can configure
backup authentication methods for each access type.
Configuring RADIUS
Follow the procedure given below to configure a Brocade device for RADIUS.
1. Configure Brocade vendor-specific attributes on the RADIUS server. Refer to Brocade-specific
attributes on the RADIUS server on page 62.
2. Identify the RADIUS server to the Brocade device. Refer to Identifying the RADIUS server to the
Brocade device on page 64.
3. Optionally specify different servers for individual AAA functions. Refer to Specifying different servers
for individual AAA functions on page 64.
4. Optionally configure the RADIUS server as a "port only" server. Refer to RADIUS server per port on
page 64.
5. Optionally bind the RADIUS servers to ports on the Brocade device. Refer to RADIUS server to
individual ports mapping on page 65.
6. Set RADIUS parameters. Refer to RADIUS parameters on page 66.
7. Configure authentication-method lists. Refer to Setting authentication-method lists for RADIUS on
page 67.
8. Optionally configure RADIUS authorization. Refer to RADIUS authorization on page 69.
9. Optionally configure RADIUS accounting. Refer to RADIUS accounting on page 71.
Brocade-specific attributes on the RADIUS server
NOTE
For all Brocade devices, RADIUS Challenge is supported for 802.1x authentication but not for login
authentication.
During the RADIUS authentication process, if a user supplies a valid username and password, the
RADIUS server sends an Access-Accept packet to the Brocade device, authenticating the user. Within
the Access-Accept packet are three Brocade vendor-specific attributes that indicate:
• The privilege level of the user
• A list of commands
• Whether the user is allowed or denied usage of the commands in the list
You must add these three Brocade vendor-specific attributes to your RADIUS server configuration,
and configure the attributes in the individual or group profiles of the users that will access the Brocade
device.
Brocade Vendor-ID is 1991, with Vendor-Type 1. The following table describes the Brocade vendorspecific attributes.
Brocade vendor-specific attributes for RADIUS TABLE 6
Attribute nameAttribute ID Data type Description
foundry-privilegelevel
foundry-commandstring
1integerSpecifies the privilege level for the user. This attribute can be set
to one of the following:
• 0 - Super User level - Allows complete read-and-write
access to the system. This is generally for system
administrators and is the only management privilege level
that allows you to configure passwords.
• 4 - Port Configuration level - Allows read-and-write access
for specific ports but not for global (system-wide) parameters.
• 5 - Read Only level - Allows access to the Privileged EXEC
mode and User EXEC mode of the CLI but only with read
access.
2stringSpecifies a list of CLI commands that are permitted or denied to
the user when RADIUS authorization is configured.
The commands are delimited by semi-colons (;). You can specify
an asterisk (*) as a wildcard at the end of a command string.
For example, the following command list specifies all show and
debug ip commands, as well as the write terminal command:
The hostip-addr | ipv6-addr | server-name parameter is either an IP address or an ASCII text string.
The auth-port parameter is the Authentication port number. The default is 1645.
The acct-port parameter is the Accounting port number. The default is 1646.
Specifying different servers for individual AAA functions
In a RADIUS configuration, you can designate a server to handle a specific AAA task. For example,
you can designate one RADIUS server to handle authorization and another RADIUS server to handle
accounting. You can specify individual servers for authentication and accounting, but not for
authorization. You can set the RADIUS key for each server.
To specify different RADIUS servers for authentication, authorization, and accounting, enter
commands such as the following.
The default parameter causes the server to be used for all AAA functions.
After authentication takes place, the server that performed the authentication is used for authorization
and accounting. If the authenticating server cannot perform the requested function, then the next
server in the configured list of servers is tried; this process repeats until a server that can perform the
requested function is found, or every server in the configured list has been tried.
RADIUS server per port
You can optionally configure a RADIUS server per port, indicating that it will be used only to
authenticate users on ports to which it is mapped. A RADIUS server that is not explicitly configured as
a RADIUS server per port is a global server , and can be used to authenticate users on ports to which
no RADIUS servers are mapped.
• RADIUS servers 10.10.10.103 and 10.10.10.104 will be used only to authenticate users on ports to
which the servers are mapped. To map a RADIUS server to a port, refer to RADIUS server to
individual ports mapping on page 65.
• RADIUS servers 10.10.10.105 and 10.10.10.106 will be used to authenticate users on ports to which
no RADIUS servers are mapped. For example, port e 9, to which no RADIUS servers are mapped,
will send a RADIUS request to the first configured RADIUS server, 10.10.10.105. If the request fails,
it will go to the second configured RADIUS server, 10.10.10.106. It will not send requests to
10.10.10.103 or 10.10.10.104, since these servers are configured as port servers.
The auth-portnumber parameter is the Authentication port number; it is an optional parameter. The
default is 1645.
The acct-portnumber parameter is the Accounting port number; it is an optional parameter. The default
is 1646.
The default keystringdot1x parameter indicates that this RADIUS server supports the 802.1X
standard. A RADIUS server that supports the 802.1X standard can also be used to authenticate
non-802.1X authentication requests.
The port-only parameter is optional and specifies that the server will be used only to authenticate users
on ports to which it is mapped.
RADIUS server to individual ports mapping
You can map up to eight RADIUS servers to each port on the Brocade device. The port will authenticate
users using only the RADIUS servers to which the port is mapped. If there are no RADIUS servers
mapped to a port, it will use the "global" servers for authentication.
As in previous releases, a port goes through the list of servers in the order in which it was mapped or
configured, until a server that can perform the requested function is found, or until every server in the
list has been tried.
• This feature works with 802.1X and multi-device port authentication only.
• You can map a RADIUS server to a physical port only. You cannot map a RADIUS server to a VE.
RADIUS server-to-ports configuration example and command syntax
To map a RADIUS server to a port, enter commands such as the following.
device(config)#int e 3
device(config-if-e1000-3)#dot1x port-control auto
device(config-if-e1000-3)#use-radius-server 10.10.10.103
device(config-if-e1000-3)#use-radius-server 10.10.10.110
With the above configuration, port e 3 would send a RADIUS request to 10.10.10.103 first, since it is
the first server mapped to the port. If it fails, it will go to 10.10.10.110.
Syntax:use-radius-serverip-addr
The hostip-addr is an IPv4 address.
RADIUS parameters
You can set the following parameters in a RADIUS configuration:
• RADIUS key - This parameter specifies the value that the Brocade device sends to the RADIUS
server when trying to authenticate user access.
• Retransmit interval - This parameter specifies how many times the Brocade device will resend an
authentication request when the RADIUS server does not respond. The retransmit value can be
from 1 - 5 times. The default is 3 times.
• Timeout - This parameter specifies how many seconds the Brocade device waits for a response
from a RADIUS server before either retrying the authentication request, or determining that the
RADIUS servers are unavailable and moving on to the next authentication method in the
authentication-method list. The timeout can be from 1 - 15 seconds. The default is 3 seconds.
Setting the RADIUS key
The key parameter in the radius-server command is used to encrypt RADIUS packets before they
are sent over the network. The value for the key parameter on the Brocade device should match the
one configured on the RADIUS server. The key can be from 1 - 32 characters in length and cannot
include any space characters.
To specify a RADIUS server key, enter a command such as the following.
device(config)#radius-server key mirabeau
Syntax:radius-server key [ 0 ] string
When you display the configuration of the Brocade device, the RADIUS key is encrypted.
Brocade(config)#radius-server key abc
Brocade(config)#write terminal
...
Brocade(config)#sh run | in radius
radius-server key abc
Encryption of the RADIUS keys is done by default and the default value is 2
( SIMPLE_ENCRYPTION_BASE64). The 0 parameter disables encryption. The 1 parameter is not
required; it is provided for backwards compatibility.
Setting the retransmission limit
The retransmit parameter specifies the maximum number of retransmission attempts. When an
authentication request times out, the Brocade software will retransmit the request up to the maximum
number of retransmissions configured. The default retransmit value is 3 retries. The range of retransmit
values is from 1 - 5.
To set the RADIUS retransmit limit, enter a command such as the following.
device(config)#radius-server retransmit 5
Syntax: tacacs-server retransmit number
Setting the timeout parameter
The timeout parameter specifies how many seconds the Brocade device waits for a response from the
RADIUS server before either retrying the authentication request, or determining that the RADIUS server
is unavailable and moving on to the next authentication method in the authentication-method list. The
timeout can be from 1 - 15 seconds. The default is 3 seconds.
device(config)#radius-server timeout 5
Syntax: radius-server timeout number
Setting RADIUS over IPv6
Brocade devices support the ability to send RADIUS packets over an IPv6 network.
To enable the Brocade device to send RADIUS packets over IPv6, enter a command such as the
following at the Global CONFIG level of the CLI.
The ipv6-host address is the IPv6 address of the RADIUS server. When you enter the IPv6 host
address, you do not need to specify the prefix length. A prefix length of 128 is implied.
Setting authentication-method lists for RADIUS
You can use RADIUS to authenticate Telnet/SSH access and access to Privileged EXEC level and
CONFIG levels of the CLI. When configuring RADIUS authentication, you create authentication-method
lists specifically for these access methods, specifying RADIUS as the primary authentication method.
Within the authentication-method list, RADIUS is specified as the primary authentication method and up
to six backup authentication methods are specified as alternates. If RADIUS authentication fails due to
an error, the device tries the backup authentication methods in the order they appear in the list.
When you configure authentication-method lists for RADIUS, you must create a separate
authentication-method list for Telnet or SSH CLI access and for CLI access to the Privileged EXEC
level and CONFIG levels of the CLI.
To create an authentication-method list that specifies RADIUS as the primary authentication method
for securing Telnet access to the CLI.
device(config)#enable telnet authentication
device(config)#aaa authentication login default radius local
The commands above cause RADIUS to be the primary authentication method for securing Telnet
access to the CLI. If RADIUS authentication fails due to an error with the server, local authentication is
used instead.
To create an authentication-method list that specifies RADIUS as the primary authentication method
for securing access to Privileged EXEC level and CONFIG levels of the CLI.
device(config)#aaa authentication enable default radius local none
The command above causes RADIUS to be the primary authentication method for securing access to
Privileged EXEC level and CONFIG levels of the CLI. If RADIUS authentication fails due to an error
with the server, local authentication is used instead. If local authentication fails, no authentication is
used; the device automatically permits access.
The aaa authentication | enable | login parameter specifies the type of access this authenticationmethod list controls. You can configure one authentication-method list for each type of access.
The method1 parameter specifies the primary authentication method. The remaining optional method
parameters specify additional methods to try if an error occurs with the primary method. A method can
be one of the values listed in the Method Parameter column in the following table.
Authentication method values TABLE 7
Method parameter Description
lineAuthenticate using the password you configured for Telnet access. The Telnet password is
configured using the enable telnet password... command. Refer to Setting a Telnet
password on page 32.
enableAuthenticate using the password you configured for the Super User privilege level. This
password is configured using the enable super-user-password... command. Refer to
Setting passwords for management privilege levels on page 32.
localAuthenticate using a local user name and password you configured on the device. Local
user names and passwords are configured using the username... command. Refer to Local
user account configuration on page 40.
tacacsAuthenticate using the database on a TACACS server. You also must identify the server to
the device using the tacacs-server command.
tacacs+Authenticate using the database on a TACACS+ server. You also must identify the server to
the device using the tacacs-server command.
radiusAuthenticate using the database on a RADIUS server. You also must identify the server to
Entering privileged EXEC mode after a Telnet or SSH login
Authentication method values (Continued)TABLE 7
Method parameter Description
noneDo not use any authentication method. The device automatically permits access.
NOTE
For examples of how to define authentication-method lists for types of authentication other than
RADIUS, refer to Authentication-method lists on page 75.
Entering privileged EXEC mode after a Telnet or SSH login
By default, a user enters User EXEC mode after a successful login through Telnet or SSH. Optionally,
you can configure the device so that a user enters Privileged EXEC mode after a Telnet or SSH login.
To do this, use the following command.
The user privilege level is based on the privilege level granted during login.
Configuring enable authentication to prompt for password only
If Enable authentication is configured on the device, when a user attempts to gain Super User access to
the Privileged EXEC and CONFIG levels of the CLI, by default he or she is prompted for a username
and password. You can configure the Brocade device to prompt only for a password. The device uses
the username entered at login, if one is available. If no username was entered at login, the device
prompts for both username and password.
To configure the Brocade device to prompt only for a password when a user attempts to gain Super
User access to the Privileged EXEC and CONFIG levels of the CLI.
Brocade devices support RADIUS authorization for controlling access to management functions in the
CLI. Two kinds of RADIUS authorization are supported:
• Exec authorization determines a user privilege level when they are authenticated
• Command authorization consults a RADIUS server to get authorization for commands entered by the
user
Configuring exec authorization
When RADIUS exec authorization is performed, the Brocade device consults a RADIUS server to
determine the privilege level of the authenticated user. To configure RADIUS exec authorization on the
Brocade device, enter the following command.
If you specify none , or omit the aaa authorization exec command from the device configuration, no
exec authorization is performed.
NOTE
If the aaa authorization exec default radius command exists in the configuration, following
successful authentication the device assigns the user the privilege level specified by the foundryprivilege-level attribute received from the RADIUS server. If the aaa authorization exec defaultradius command does not exist in the configuration, then the value in the foundry-privilege-level
attribute is ignored, and the user is granted Super User access.Also note that in order for the aaa
authorization exec default radius command to work, either theaaa authentication enable default
radius command, or the aaa authentication login privilege-mode command must also exist in the
configuration.
Configuring command authorization
When RADIUS command authorization is enabled, the Brocade device consults the list of commands
supplied by the RADIUS server during authentication to determine whether a user can issue a
command he or she has entered.
You enable RADIUS command authorization by specifying a privilege level whose commands require
authorization. For example, to configure the Brocade device to perform authorization for the
commands available at the Super User privilege level (that is; all commands on the device), enter the
following command.
The privilege-level parameter can be one of the following:
• 0 - Authorization is performed (that is, the Brocade device looks at the command list) for commands
available at the Super User level (all commands)
• 4 - Authorization is performed for commands available at the Port Configuration level (port-config
and read-only commands)
• 5 - Authorization is performed for commands available at the Read Only level (read-only
commands)
NOTE
RADIUS command authorization can be performed only for commands entered from Telnet or SSH
sessions, or from the console.
NOTE
Since RADIUS command authorization relies on the command list supplied by the RADIUS server
during authentication, you cannot perform RADIUS authorization without RADIUS authentication.
Command authorization and accounting for console commands
Command authorization and accounting for console commands
The Brocade device supports command authorization and command accounting for CLI commands
entered at the console. To configure the device to perform command authorization and command
accounting for console commands, enter the following.
device(config)#enable aaa console
Syntax: [no] enable aaa console
CAUTION
If you have previously configured the device to perform command authorization using a RADIUS
server, entering the enable aaa console command may prevent the execution of any subsequent
commands entered on the console. This happens because RADIUS command authorization
requires a list of allowable commands from the RADIUS server. This list is obtained during
RADIUS authentication. For console sessions, RADIUS authentication is performed only if you
have configured Enable authentication and specified RADIUS as the authentication method (for
example, with the aaa authentication enable default radius command). If RADIUS authentication
is never performed, the list of allowable commands is never obtained from the RADIUS server.
Consequently, there would be no allowable commands on the console.
RADIUS accounting
Brocade devices support RADIUS accounting for recording information about user activity and system
events. When you configure RADIUS accounting on a Brocade device, information is sent to a RADIUS
accounting server when specified events occur, such as when a user logs into the device or the system
is rebooted.
Configuring RADIUS accounting for Telnet/SSH (Shell) access
To send an Accounting Start packet to the RADIUS accounting server when an authenticated user
establishes a Telnet or SSH session on the Brocade device, and an Accounting Stop packet when the
user logs out.
You can configure RADIUS accounting for CLI commands by specifying a privilege level whose
commands require accounting. For example, to configure the Brocade device to perform RADIUS
accounting for the commands available at the Super User privilege level (that is; all commands on the
device), enter the following command.
An Accounting Start packet is sent to the RADIUS accounting server when a user enters a command,
and an Accounting Stop packet is sent when the service provided by the command is completed.
If authorization is enabled, and the command requires authorization, then authorization is performed
before accounting takes place. If authorization fails for the command, no accounting takes place.
The privilege-level parameter can be one of the following:
• 0 - Records commands available at the Super User level (all commands)
• 4 - Records commands available at the Port Configuration level (port-config and read-only
commands)
• 5 - Records commands available at the Read Only level (read-only commands)
Configuring RADIUS accounting for system events
You can configure RADIUS accounting to record when system events occur on the Brocade device.
System events include rebooting and when changes to the active configuration are made.
The following command causes an Accounting Start packet to be sent to the RADIUS accounting
server when a system event occurs, and a Accounting Stop packet to be sent when the system event
is completed.
device(config)#aaa accounting system default start-stop radius
Configuring an interface as the source for allRADIUS packets
You can designate the lowest-numbered IP address configured an Ethernet port, loopback interface,
or virtual interface as the source IP address for all RADIUS packets from the Layer 3 Switch. For
configuration details, see "Specifying a single source interface for specified packet types" section in
the FastIron Ethernet Switch Layer 3 Routing Configuration Guide .
Displaying RADIUS configuration information
The show aaa command displays information about all TACACS/TACACS+ and RADIUS servers
identified on the device.
Radius keyThe setting configured with the radius-server key command. At the Super User privilege level,
the actual text of the key is displayed. At the other privilege levels, a string of periods (....) is
displayed instead of the text.
Radius retries The setting configured with the radius-server retransmit command.
Radius timeout The setting configured with the radius-server timeout command.
Radius Server For each RADIUS server, the IP address, and the following statistics are displayed:
Auth Port RADIUS authentication port number (default 1645)
Acct Port RADIUS accounting port number (default 1646)
• opens - Number of times the port was opened for communication with the server
• closes - Number of times the port was closed normally
• timeouts - Number of times port was closed due to a timeout
• errors - Number of times an error occurred while opening the port
• packets in - Number of packets received from the server
• packets out - Number of packets sent to the server
connectionThe current connection status. This can be "no connection" or "connection active".
SSL security
The Brocade device supports Secure Sockets Layer / Transport Level Security (SSL 3.0 / TLS 1.0).
When enabled, the SSL protocol uses digital certificates and public-private key pairs to establish a
secure connection to the Brocade device. Digital certificates serve to prove the identity of a connecting
client, and public-private key pairs provide a means to encrypt data sent between the device and the
client.
Configuring SSL consists of the following tasks:
1. Importing an RSA certificate and private key file from a client (optional)
2. Generating a certificate
Specifying a port for SSL communication
By default, SSL protocol exchanges occur on TCP port 443. You can optionally change the port number
used for SSL communication.
For example, the following command causes the device to use TCP port 334 for
SSL communication.
The default key size for Brocade-issued and imported digital certificates is 1024 bits. If desired, you
can change the default key size to a value of 512, 2048, or 4096 bits. To do so, enter a command
such as the following at the Global CONFIG level of the CLI.
Brocade(config)#ip ssl cert-key-size 512
Syntax: ip ssl cert-key-size <512/ 1024/ 2048/ 4096>
NOTE
The SSL server certificate key size applies only to digital certificates issued by
Brocade and does not apply to imported certificates.
Support for SSL digital certificates larger than 2048 bits
Brocade devices have the ability to store and retrieve SSL digital certificates that are up to 4000 bits in
size.
Support for SSL certificates larger than 2048 bits is automatically enabled. You do not need to perform
any configuration procedures to enable it.
Importing digital certificates and RSA private key files
To allow a client to communicate with other Brocade device using an SSL connection, you configure a
set of digital certificates and RSA public-private key pairs on the device. A digital certificate is used for
identifying the connecting client to the server. It contains information about the issuing Certificate
Authority, as well as a public key. You can either import digital certificates and private keys from a
server, or you can allow the Brocade device to create them.
If you want to allow the Brocade device to create the digital certificates, refer to the next section,
Generating an SSL certificate on page 75. If you choose to import an RSA certificate and private key
file from a client, you can use TFTP to transfer the files.
For example, to import a digital certificate using TFTP, enter a command such
as the following:
If the certificate does not automatically generate, enter the following command to
generate it.
Brocade(config)#crypto-ssl certificate generate
Syntax:[no] crypto-ssl certificate generate
If you did not already import a digital certificate from a client, the device can
create a default certificate. To do this, enter the following command.
To delete the SSL certificate, enter the following command.
Brocade(config)#crypto-ssl certificate zeroize
Syntax: [no] crypto-ssl certificate zeroize
Authentication-method lists
To implement one or more authentication methods for securing access to the device, you configure
authentication-method lists that set the order in which the authentication methods are consulted.
In an authentication-method list, you specify the access method (Telnet, SNMP, and so on) and the
order in which the device tries one or more of the following authentication methods:
• Local Telnet login password
• Local password for the Super User privilege level
• Local user accounts configured on the device
• Database on a TACACS or TACACS+ server
• Database on a RADIUS server
• No authentication
NOTE
The TACACS/TACACS+, RADIUS, and Telnet login password authentication methods are not
supported for SNMP access.
NOTE
To authenticate Telnet access to the CLI, you also must enable the authentication by entering the
enable telnet authentication command at the global CONFIG level of the CLI.
NOTE
You do not need an authentication-method list to secure access based on ACLs or a list of IP
addresses. Refer to ACL usage to restrict remote access on page 23 or Remote access restrictions on
page 25.
Configuration considerations for authentication-method lists
In an authentication-method list for a particular access method, you can specify up to seven
authentication methods. If the first authentication method is successful, the software grants access
and stops the authentication process. If the access is rejected by the first authentication method, the
software denies access and stops checking.
However, if an error occurs with an authentication method, the software tries the next method on the
list, and so on. For example, if the first authentication method is the RADIUS server, but the link to the
server is down, the software will try the next authentication method in the list.
NOTE
If an authentication method is working properly and the password (and user name, if applicable) is not
known to that method, this is not an error. The authentication attempt stops, and the user is denied
access.
The software will continue this process until either the authentication method is passed or the software
reaches the end of the method list. If the Super User level password is not rejected after all the access
methods in the list have been tried, access is granted.
Configuration considerations for authentication-method lists
• For CLI access, you must configure authentication-method lists if you want the device to
authenticate access using local user accounts or a RADIUS server. Otherwise, the device will
authenticate using only the locally based password for the Super User privilege level.
Examples of authentication-method lists
The following examples show how to configure authentication-method lists. In these examples, the
primary authentication method for each is "local". The device will authenticate access attempts using
the locally configured usernames and passwords.
The command syntax for each of the following examples is provided in the Command Syntax section.
Example 1
To configure an authentication-method list for SNMP, enter a command such as the following.
device(config)#aaa authentication snmp-server default local
This command allows certain incoming SNMP SET operations to be authenticated using the locally
configured usernames and passwords. When this command is enabled, community string validation is
not performed for incoming SNMP V1 and V2c packets. This command takes effect as long as the first
varbind for SNMP packets is set to one of the following:
Certain SNMP objects need additional validation. These objects include but are not limited to:
snAgReload , snAgWriteNVRAM , snAgConfigFromNVRAM , snAgImgLoad , snAgCfgLoad and
snAgGblTelnetPassword . For more information, see snAgGblPassword in the IronWare MIB
Reference Guide>.
If AAA is set up to check both the username and password, the string contains the username, followed
by a space then the password. If AAA is set up to authenticate with the current Enable or Line
password, the string contains the password only.
Note that the above configuration can be overridden by the command no snmp-server pw-check ,
which disables password checking for SNMP SET requests.
Example 2
To configure an authentication-method list for the Privileged EXEC and CONFIG levels of the CLI, enter
the following command.
device(config)#aaa authentication enable default local
This command configures the device to use the local user accounts to authenticate attempts to access
the Privileged EXEC and CONFIG levels of the CLI.
Example 3
To configure the device to consult a RADIUS server first to authenticate attempts to access the
Privileged EXEC and CONFIG levels of the CLI, then consult the local user accounts if the RADIUS
server is unavailable, enter the following command.
device(config)#aaa authentication enable default radius local
Command Syntax
The following is the command syntax for the preceding examples.
The snmp-server | web-server | enable | login parameter specifies the type of access this
authentication-method list controls. You can configure one authentication-method list for each type of
access.
NOTE
Web management is not supported in Release 8.0.00a and later releases. If web management is
enabled, you must configure the no web-management command to disable it.
NOTE
TACACS/TACACS+ and RADIUS are supported only with the enable and login parameters.
The method1 parameter specifies the primary authentication method. The remaining optional method
parameters specify additional methods to try if an error occurs with the primary method. A method can
be one of the values listed in the Method Parameter column in the following table.
Authentication method values TABLE 9
Method parameter Description
lineAuthenticate using the password you configured for Telnet access. The Telnet password is
configured using the enable telnet password... command. Refer to Setting a Telnet
password on page 32.
enableAuthenticate using the password you configured for the Super User privilege level. This
password is configured using the enable super-user-password... command. Refer to Setting
passwords for management privilege levels on page 32.
localAuthenticate using a local user name and password you configured on the device. Local user
tacacsAuthenticate using the database on a TACACS server. You also must identify the server to
tacacs+Authenticate using the database on a TACACS+ server. You also must identify the server to
radiusAuthenticate using the database on a RADIUS server. You also must identify the server to the
noneDo not use any authentication method. The device automatically permits access.
Authentication method values (Continued)TABLE 9
names and passwords are configured using the username... command. Refer to Local user
account configuration on page 40.
the device using the tacacs-server command.
the device using the tacacs-server command.
device using the radius-server command. Refer to RADIUS security on page 58.
TCP Flags - edge port security
NOTE
This feature is not supported on FastIron X Series devices.
The edge port security feature works in combination with IP ACL rules, and supports all 6 TCP flags
present in the offset 13 of the TCP header:
• +|- urg = Urgent
• +|- ack = Acknowledge
• +|- psh = Push
• +|- rst = Reset
• +|- syn = Synchronize
• +|- fin = Finish
TCP flags can be combined with other ACL functions (such as dscp-marking and traffic policies),
giving you greater flexibility when designing ACLs.
The TCP flags feature offers two options, match-all and match-any:
• Match-any - Indicates that incoming TCP traffic must be matched against any of the TCP flags
configured as part of the match-any ACL rule. In CAM hardware, the number of ACL rules will
match the number of configured flags.
• Match-all - Indicates that incoming TCP traffic must be matched against all of the TCP flags
configured as part of the match-all ACL rule. In CAM hardware, there will be only one ACL rule for
all configured flags.
Using TCP Flags in combination with other ACL features
Using TCP Flags in combination with other ACL features
The TCP Flags feature has the added capability of being combined with other ACL features.
device(config-ext-nACL)#permit tcp any any match-all +urg +ack +syn -rst trafficpolicy test
This command configures the ACL to match incoming traffic with the TCP Flags urg, ack, and syn and
also to apply the traffic policy (rate, limit, etc.) to the matched traffic.
device(config-ext-nACL)#permit tcp any any match-all +urg +ack +syn -rst tos normal
This command configures the ACL to match incoming traffic with the flags urg, ack, and syn, and also
sets the tos bit to normal when the traffic exits the device.
NOTE
TCP Flags combines the functionality of older features such as TCP Syn Attack and TCP Establish.
Avoid configuring these older features on a port where you have configured TCP Flags. TCP Flags can
perform all of the functions of TCP Syn Attack and TCP Establish, and more. However, if TCP Syn
Attack is configured on a port along with TCP Flags, TCP Syn Attack will take precedence.
NOTE
If an ACL clause with match-any exists, and the system runs out of CAM, if the total number of TCP
rules to TCP Flags will not fit within 1021 entries (the maximum rules allowed per device), then none of
the TCP Flag rules will be programmed into the CAM hardware.
NOTE
If a range option and match-any TCP-flags are combined in the same ACL, the total number of rules will
be calculated as: Total number of rules in CAM hardware = (number of rules for range)* (number of
rules for match-any TCP-flags).
Boot image download over SCP08.0.0108.0.0108.0.0108.0.0108.0.0108.0.0108.0.10
ICX 7750
SSH version 2 overview
Secure Shell (SSH) is a mechanism for allowing secure remote access to management functions on a
Brocade device. SSH provides a function similar to Telnet. Users can log into and configure the device
using a publicly or commercially available SSH client program, just as they can with Telnet. However,
unlike Telnet, which provides no security, SSH provides a secure, encrypted connection to the device.
The Brocade SSH2 implementation is compatible with all versions of the SSH2 protocol (2.1, 2.2, and
so on). At the beginning of an SSH session, the Brocade device negotiates the version of SSH2 to be
used. The highest version of SSH2 supported by both the Brocade device and the client is the version
that is used for the session. Once the SSH2 version is negotiated, the encryption algorithm with the
highest security ranking is selected to be used for the session.
Brocade devices also support Secure Copy (SCP) for securely transferring files between a Brocade
device and SCP-enabled remote hosts.
NOTE
The SSH feature includes software that is copyright Allegro Software Development Corporation.
SSH2 is supported in the Layer 2 and Layer 3 codes.
SSH2 is a substantial revision of Secure Shell, comprising the following hybrid protocols and
definitions:
• SSH Transport Layer Protocol
• SSH Authentication Protocol
• SSH Connection Protocol
• SECSH Public Key File Format
• SSH Fingerprint Format
• SSH Protocol Assigned Numbers
• SSH Transport Layer Encryption Modes
• SCP/SSH URI Format
Tested SSH2 clients
The following SSH clients have been tested with SSH2:
• SSH Secure Shell 3.2.3
• Van Dyke SecureCRT 5.2.2
• F-Secure SSH Client 5.3 and 6.0
• PuTTY 0.62
NOTE
SSH session may drop when using PuTTY on Windows system and left idle for more than 45 minutes.
• OpenSSH 4.3p2
• Brocade FastIron SSH Client
NOTE
Supported SSH client public key sizes are 1024 or 2048 bits for DSA keys and RSA keys.
SSH2 supported features
SSH2 (Secure Shell version 2 protocol) provides an SSH server and an SSH client. The SSH server
allows secure remote access management functions on a Brocade device. SSH provides a function
that is similar to Telnet, but unlike Telnet, SSH provides a secure, encrypted connection.
Brocade SSH2 support includes the following:
• Key exchange methods are diffie-hellman-group1-sha1.
• The supported public key algorithms are ssh-dss and ssh-rsa .
• Encryption is provided with 3des-cbc , aes128-cbc , aes192-cbc or aes256-cbc . AES encryption
has been adopted by the U.S. Government as an encryption standard.
• Data integrity is ensured with hmac-sha1.
• Supported authentication methods are Password , interactive, and Key authentication.
• Five inbound SSH connection at one time are supported.
• Five outbound SSH is supported.
SSH2 unsupported features
The following are not supported with SSH2:
• Compression
• TCP/IP port forwarding, X11 forwarding, and secure file transfer
• SSH version 1
SSH2 authentication types
SSH2 unsupported features
The Brocade implementation of SSH2 supports the following types of user authentication:
• DSA challenge-response authentication , where a collection of public keys are stored on the device.
Only clients with a private key that corresponds to one of the stored public keys can gain access to
the device using SSH.
• RSA challenge-response authentication , where a collection of public keys are stored on the device.
Only clients with a private key that corresponds to one of the stored public keys can gain access to
the device using SSH.
• Password authentication , where users attempting to gain access to the device using an SSH client
are authenticated with passwords stored on the device or on a TACACS or TACACS+ server or a
RADIUS server.
• Interactive-authentication
• Keyboard-interactive authentication
Configuring SSH2
You can configure the device to use any combination of these authentication types. The SSH server
and client negotiate which type to use.
To configure SSH2, follow these steps:
1. Generate a host Digital Signature Algorithm (DSA) or Ron Rivest, Adi Shamir and Leonard Adleman
Algorithm (RSA), and private key pair for the device.
See the section Enabling and disabling SSH by generating and deleting host keys on page 84.
2. Configure DSA or RSA challenge-response authentication.
See the section Configuring DSA or RSA challenge-response authentication on page 86.
3. Set optional parameters.
See the section Optional SSH parameters on page 88.
Enabling and disabling SSH by generating and deleting host keys
Enabling and disabling SSH by generating and deleting host keys
To enable SSH, you generate a DSA or RSA host key on the device. The SSH server on the Brocade
device uses this host DSA or RSA key, along with a dynamically generated server DSA or RSA key
pair, to negotiate a session key and encryption method with the client trying to connect to it.
While the SSH listener exists at all times, sessions can not be started from clients until a host key is
generated. After a host key is generated, clients can start sessions.
To disable SSH, you delete all of the host keys from the device.
When a host key is generated, it is saved to the flash memory of all management modules. When a
host key is is deleted, it is deleted from the flash memory of all management modules.
The time to initially generate SSH keys varies depending on the configuration, and can be from a
under a minute to several minutes.
SSHv2 RSA host key format is different between FastIron 07.x.xx, 08.0.00 and 08.0.00a software
versions .
• When you upgrade from FastIron 07.x.xx, 08.0.00 to 08.0.00a software version , if RSA key is
present in FastIron 07.x.xx or 08.0.00 software version, same size will be regenerated in FastIron
08.0.00a software version. Old SSHv2 host key is retained unless they are cleared by the cryptokey zeroize command.
• When you downgrade the FastIron software from version 08.0.00a to 08.0.00 or 07.x.xx, consider
the following scenarios:
‐SSHv2 RSA host key created in FastIron 07.x.xx or 08.0.00 software version and retained
in FastIron 08.0.00a-- In this case, booting up with FastIron 07.x.xx or 08.0.00 software
versions reads the old format SSHv2 RSA host keys and enables the SSHv2 RSA server
on the switch.
‐SSHv2 RSA host key created in FastIron 08.0.00a--In this case, booting up with FastIron
07.x.xx or 08.0.00 software versions does not read the new format SSHv2 RSA host keys
and SSHv2 server is not enabled on the switch.
SSH host keys created with DSA method is interoperable between FastIron 07.x.xx, 08.0.00 and
08.0.00a software versions.
Generating and deleting a DSA key pair
To generate a DSA key pair, enter the following command.
device(config)#crypto key generate dsa
To delete the DSA host key pair, enter the following command.
device(config)#crypto key zeroize dsa
Syntax:crypto key { generate | zeroize } dsa
The generate keyword places a host key pair in the flash memory and enables SSH on the device, if it
is not already enabled.
The zeroize keyword deletes the host key pair from the flash memory. This disables SSH if no other
server host keys exist on the device.
The dsa keyword specifies a DSA host key pair. This keyword is optional. If you do not enter it, the
command crypto key generate generates a DSA key pair by default, and the command crypto keyzeroize works as described in Deleting DSA and RSA key pairs on page 85.
The generate keyword places an RSA host key pair in the flash memory and enables SSH on the
device, if it is not already enabled.
The optional [modulus modulus-size ] parameter specifies the modulus size of the RSA key pair, in
bits. The valid values for modulus-size are 1024 or 2048. The default value is 1024.
The zeroize keyword deletes the RSA host key pair from the flash memory. This disables SSH if no
other authentication keys exist on the device.
The rsa keyword specifies an RSA host key pair.
NOTE
OnICX 6430 and ICX 6450 devices, the crypto key generate command can take up to 16 minutes to
complete.
Deleting DSA and RSA key pairs
To delete DSA and RSA key pairs from the flash memory, enter the following command:
device(config)#crypto key zeroize
Syntax:crypto keyzeroize
The zeroize keyword deletes the host key pair from the flash memory. This disables SSH.
Providing the public key to clients
The host DSA or RSA key pair is stored in the system-config file of the Brocade device. Only the public
key is readable. Some SSH client programs add the public key to the known hosts file automatically. In
other cases, you must manually create a known hosts file and place the public key of the Brocade
device in it.
If you are using SSH to connect to a Brocade device from a UNIX system, you may need to add the
public key on the Brocade device to a “known hosts” file on the client UNIX system; for example,
$HOME/.ssh/known_hosts. The following is an example of an entry in a known hosts file.
Configuring DSA or RSA challenge-response authentication
Configuring DSA or RSA challenge-response authentication
With DSA or RSA challenge-response authentication, a collection of clients’ public keys are stored on
the Brocade device. Clients are authenticated using these stored public keys. Only clients that have a
private key that corresponds to one of the stored public keys can gain access to the device using SSH.
When DSA or RSA challenge-response authentication is enabled, the following events occur when a
client attempts to gain access to the device using SSH:
1. The client sends its public key to the Brocade device.
2. The Brocade device compares the client public key to those stored in memory.
3. If there is a match, the Brocade device uses the public key to encrypt a random sequence of bytes.
4. The Brocade device sends these encrypted bytes to the client.
5. The client uses its private key to decrypt the bytes.
6. The client sends the decrypted bytes back to the Brocade device.
7. The Brocade device compares the decrypted bytes to the original bytes it sent to the client. If the
two sets of bytes match, it means that the client private key corresponds to an authorized public
key, and the client is authenticated.
Setting up DSA or RSA challenge-response authentication consists of the following steps.
Importing authorized public keys into the Brocade device
SSH clients that support DSA or RSA authentication normally provide a utility to generate a DSA or
RSA key pair. The private key is usually stored in a password-protected file on the local host; the
public key is stored in another file and is not protected. You must import the client public key for each
client into the Brocade device.
Collect one public key of each key type (DSA and/or RSA) from each client to be granted access to
the Brocade device and place all of these keys into one file. This public key file may contain up to 16
keys. The following is an example of a public key file containing one public key:
Each key in the public key file must begin and end with the first and last lines in this example. If your
client does not include these lines in the public key, you must manually add them.
Import the authorized public keys into the Brocade device active configuration by loading this public
key file from a TFTP server.
To load a public key file called pkeys.txt from a TFTP server, enter a command such as the following:
Enabling DSA or RSA challenge-response authentication
The tftp-server-ip-addr variable is the IP address of the tftp server that contains the public key file that
you want to import into the Brocade device.
The filename variable is the name of the public key file that you want to import into the Brocade device.
The remove parameter deletes the public keys from the device.
To display the currently loaded public keys, enter the following command.
device#show ip client-pub-key
---- BEGIN SSH2 PUBLIC KEY ---Comment: DSA Public Key
AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/
z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om
1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5cv
wHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9v
GfJ0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA
vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB
AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS
n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5
sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV
---- END SSH2 PUBLIC KEY ----
Syntax:show ip client-pub-key [ beginexpression | excludeexpression | includeexpression ]
To clear the public keys from the buffers, enter the following command.
device#clear public-key
Syntax: clear public-key
Enabling DSA or RSA challenge-response authentication
DSA and RSA challenge-response authentication is enabled by default. You can disable or re-enable it
manually.
To enable DSA and RSA challenge-response authentication.
device(config)#ip ssh password-authentication yes
To disable DSA and RSA challenge-response authentication.
You can adjust the following SSH settings on the Brocade device:
• The number of SSH authentication retries
• The user authentication method the Brocade device uses for SSH connections
• Whether the Brocade device allows users to log in without supplying a password
• The port number for SSH connections
• The SSH login timeout value
• A specific interface to be used as the source for all SSH traffic from the device
• The maximum idle time for SSH sessions
Setting the number of SSH authentication retries
By default, the Brocade device attempts to negotiate a connection with the connecting host three
times. The number of authentication retries can be changed to between 1 - 5.
NOTE
The ip ssh authentication-retries command is not applicable on Brocade devices which acts as an
SSH client. When the Brocade device acts as an SSH client and when you try to establish an SSH
connection with wrong credentials, the session is not be established. The connection is terminated.
The device does not check the SSH authentication retry configuration set using the ip sshauthentication-retries command. The command is applicable only to SSH clients like PUTTY, Secure
CRT, and so on.
For example, the following command changes the number of authentication retries to 5.
device(config)#ip ssh authentication-retries 5
Syntax: ip ssh interactive--authentication-retries number
Deactivating user authentication
After the SSH server on the Brocade device negotiates a session key and encryption method with the
connecting client, user authentication takes place. The Brocade implementation of SSH supports DSA
or RSA challenge-response authentication and password authentication.
With DSA or RSA challenge-response authentication, a collection of clients’ public keys are stored on
the Brocade device. Clients are authenticated using these stored public keys. Only clients that have a
private key that corresponds to one of the stored public keys can gain access to the device using SSH.
With password authentication, users are prompted for a password when they attempt to log into the
device (provided empty password logins are not allowed). If there is no user account that matches the
user name and password supplied by the user, the user is not granted access.
You can deactivate one or both user authentication methods for SSH. Note that deactivating both
authentication methods essentially disables the SSH server entirely.
To disable DSA or RSA challenge-response authentication, enter the following command.
To deactivate password authentication, enter the following command.
device(config)#ip ssh password-authentication no
Syntax:ip ssh password--authentication { no | yes }
The default is yes .
Enabling empty password logins
By default, empty password logins are not allowed. This means that users with an SSH client are
always prompted for a password when they log into the device. To gain access to the device, each user
must have a user name and password. Without a user name and password, a user is not granted
access.
If you enable empty password logins, users are not prompted for a password when they log in. Any user
with an SSH client can log in without being prompted for a password.
To enable empty password logins, enter the following command.
device(config)#ip ssh permit-empty-passwd yes
Syntax: ip ssh permit-empty-passwd { no | yes }
Setting the SSH port number
By default, SSH traffic occurs on TCP port 22. You can change this port number. For example, the
following command changes the SSH port number to 2200.
device(config)#ip ssh port 2200
Note that if you change the default SSH port number, you must configure SSH clients to connect to the
new port. Also, you should be careful not to assign SSH to a port that is used by another service. If you
change the SSH port number, Brocade recommends that you change it to a port number greater than
1024.
Syntax:ip ssh portnumber
Setting the SSH login timeout value
When the SSH server attempts to negotiate a session key and encryption method with a connecting
client, it waits a maximum of 120 seconds for a response from the client. If there is no response from
the client after 120 seconds, the SSH server disconnects. You can change this timeout value to
between 1 - 120 seconds. For example, to change the timeout value to 60 seconds, enter the following
command.
Designating an interface as the source for all SSH packets
Designating an interface as the source for all SSH packets
You can designate a loopback interface, virtual interface, or Ethernet port as the source for all SSH
packets from the device. For details, see "Specifying a single source interface for specified packet
types" section in the FastIron Ethernet Switch Layer 3 Routing Configuration Guide .
Configuring the maximum idle time for SSH sessions
By default, SSH sessions do not time out. Optionally, you can set the amount of time an SSH session
can be inactive before the Brocade device closes it. For example, to set the maximum idle time for
SSH sessions to 30 minutes, enter the following command.
device(config)#ip ssh idle-time 30
Syntax:ip ssh idle-timeminutes
If an established SSH session has no activity for the specified number of minutes, the Brocade device
closes it. An idle time of 0 minutes (the default value) means that SSH sessions never time out. The
maximum idle time for SSH sessions is 240 minutes.
Filtering SSH access using ACLs
You can permit or deny SSH access to the Brocade device using ACLs. To use ACLs, first create the
ACLs you want to use. You can specify a numbered standard IPv4 ACL, a named standard IPv4 ACL
The show who command also displays information about SSH connections:
device#show who
Console connections:
Established
you are connecting to this session
2 minutes 56 seconds in idle
SSH server status: Enabled
SSH connections (inbound):
1. established, client ip address 10.2.2.1, server hostkey DSA
1 minutes 15 seconds in idle
2. established, client ip address 10.2.2.2, server hostkey RSA
2 minutes 25 seconds in idle
SSH connection (outbound):
3. established, server ip address 10.37.77.15, server hostkey RSA
7 seconds in idle
Syntax: show who { begin expression | exclude expression | include expression }
Secure copy with SSH2
Displaying additional SSH connection information
Secure Copy (SCP) uses security built into SSH to transfer image and configuration files to and from
the device. SCP automatically uses the authentication methods, encryption algorithm, and data
compression level configured for SSH. For example, if password authentication is enabled for SSH, the
user is prompted for a user name and password before SCP allows a file to be transferred. No
additional configuration is required for SCP on top of SSH.
You can use SCP to copy files on the Brocade device, including the startup configuration and running
configuration files, to or from an SCP-enabled remote host.
Enabling and disabling SCP
SCP is enabled by default and can be disabled. To disable SCP, enter the following command.
device(config)#ip ssh scp disable
Syntax: ip ssh [ scp ] { disable | enable }
NOTE
If you disable SSH, SCP is also disabled.
Secure copy configuration notes
• When using SCP, enter the scp commands on the SCP-enabled client, rather than the console on
the Brocade device.
• Certain SCP client options, including -p and -r, are ignored by the SCP server on the Brocade device.
If an option is ignored, the client is notified.
• An SCP AES copy of the running or start configuration file from the Brocade device to Linux WS 4 or
5 may fail if the configuration size is less than 700 bytes. To work around this issue, use PuTTY to
copy the file.
• SCP does not support running config overwite except acl configuration.
Copying the running config file to an SCP-enabled client
To copy the running configuration file on the Brocade device to a file called c:\cfg\fdryrun.cfg on the
SCP-enabled client, enter the following command.
Copying the startup config file to an SCP-enabled client
To copy the startup configuration file on the Brocade device to a file called c:\cfg\brcdestart.cfg on the
SCP-enabled client, enter the following command.
After the copy operation is completed at the host, you do not get the command prompt back because
the switch is synchronizing the image to flash. To ensure that you have successfully copied the file,
issue the show flash command. If the copy operation is not complete, the show flash command output
will show the partition (primary or secondary) as EMPTY.
NOTE
The Brocade device supports only one SCP copy session at a time.
Copying a Software Image file from flash memory
The scp command syntax differs between device series. Use the command syntax in the appropriate
section.
To copy a software image file from the primary flash on these devices to an SCP-enabled client, enter a
command such as the following.
The ip-address variable is the IP address of the server from which the digital certificate file is
downloaded.
The certificate-filename variable is the file name of the digital certificate that you are importing to the
device.
The scp command can be used when TFTP access is unavailable or not permitted and the command
has an equivalent functionality to the ip ssl certificate-data-file tftp .
To import an RSA private key from a client using SCP, enter a command such as the following one:
C:\> scp keyfile user@10.168.9.210:sslPrivKey
Syntax:scpkey-filenameuser@ip-addresssslPrivKey
The ip-address variable is the IP address of the server that contains the private key file.
The key-filename variable is the file name of the private key that you want to import into the device.
The scp command can be used when TFTP access is unavailable or not permitted and the command
has an equivalent functionality to the ip ssl private-key-file tftp command.
Importing a DSA or RSA public key
To import a DSA or RSA public key from a client using SCP, enter a command
such as the following one:
C:\> scp pkeys.txt user@10.168.1.234:sshPubKey
Syntax:scpkey-filenameuser@ip-address:sshPubKey
The ip-address variable is the IP address of the server that contains the public
key file.
The key-filename variable is the name of the DSA or RSA public key file that
you want to import into the device.
The scp command can be used when TFTP access is unavailable or not
permitted and the command has an equivalent function to the ip ssh pub-key-file tftp command. For more information on the ip ssh pub-key-file tftp
command, refer to Importing authorized public keys into the Brocade device on
page 86.
Copying license files
To copy the license files from a client using SCP, enter commands such as the following:
SSH2 client allows you to connect from a Brocade device to an SSH2 server, including another
Brocade device that is configured as an SSH2 server. You can start an outbound SSH2 client session
while you are connected to the device by any connection method (SSH2, Telnet, console). Brocade
devices support one outbound SSH2 client session at a time.
The supported SSH2 client features are as follows:
• Encryption algorithms, in the order of preference:
• The client session can be established through either in-band or out-of-band management ports.
• The client session can be established through IPv4 or IPv6 protocol access.
• The client session can be established to a server listening on a non-default SSH port.
Enabling SSH2 client
To use SSH2 client, you must first enable SSH2 server on the device. See SSH2 authentication types
on page 83.
When SSH2 server is enabled, you can use SSH client to connect to an SSH server using password
authentication.
Configuring SSH2 client public key authentication
To use SSH client for public key authentication, you must generate SSH client authentication keys and
export the public key to the SSH servers to which you want to connect.
The following sections describe how to configure SSH client public key authentication:
• Generating and deleting a client DSA key pair on page 97
• Generating and deleting a client RSA key pair on page 98
• Exporting client public keys on page 98
Generating and deleting a client DSA key pair
To generate a client DSA key pair, enter the following command.
device(config)#crypto key client generate dsa
To delete the DSA host key pair, enter the following command.
The generate keyword places an RSA host key pair in the flash memory.
The zeroize keyword deletes the RSA host key pair from the flash memory.
The optional [modulus modulus-size ] parameter specifies the modulus size of the RSA key pair, in
bits. The valid values for modulus-size are 1024 or 2048. It is used only with the generate parameter.
The default value is 1024.
The rsa keyword specifies an RSA host key pair.
Exporting client public keys
Client public keys are stored in the following files in flash memory:
• A DSA key is stored in the file $$sshdsapub.key .
• An RSA key is stored in the file $$sshrsapub.key .
To copy key files to a TFTP server, you can use the copy flash tftp command.
You must copy the public key to the SSH server. If the SSH server is a brocade device, see the
section Importing authorized public keys into the Brocade device on page 86.
Using SSH2 client
To start an SSH2 client connection to an SSH2 server using password authentication, enter a
command such as the following:
device# ssh 10.10.10.2
To start an SSH2 client connection to an SSH2 server using public key authentication, enter a
command such as the following:
The ipv4Addr , ipv6Addr , and host-name variables identify an SSH2 server. You identify the server to
connect to by entering its IPv4 or IPv6 address or its hostname.
The optional [public-key [dsa | rsa]] parameter specifies the type of public key authentication to use
for the connection, either DSA or RSA. If you do not enter this parameter, the default authentication
type is password.
The optional portportnum parameter specifies that the SSH2 connection will use a non-default SSH2
port, where portnum is the port number. The default port number is 22.