ameblo.over-update.download

Crypto key generate rsa. cryptokeygeneratersa,page2 Cisco IOS Security Command Reference: Commands A to C, Cisco IOS XE Release 3SE (Catalyst 3850 Switches). HOW TO CONFIGURE SSH VERSION 2 ON CISCO ROUTER. Crypto key generate rsa usage-keys label sshkey modulus 768. Configures SSH control variables on the Router.

• Crypto Key Generate Rsa Ip Ssh Version 2
• Git Generate Ssh Key
• Ssh Version 2 Generate Crypto Key In Pdf
• Generate Ssh Key Linux

Contents

Introduction

Secure Shell (SSH) is a protocol which provides a secure remote access connection to network devices. Communication between the client and server is encrypted in both SSH version 1 and SSH version 2. Implement SSH version 2 when possible because it uses a more enhanced security encryption algorithm.

This document discusses how to configure and debug SSH on Cisco routers or switches that run a version of Cisco IOS^® Software that supports SSH. This document contains more information on specific versions and software images.

Prerequisites

Requirements

The Cisco IOS image used must be a k9(crypto) image in order to support SSH. For example c3750e-universalk9-tar.122-35.SE5.tar is a k9 (crypto) image.

Components Used

The information in this document is based on Cisco IOS 3600 Software (C3640-IK9S-M), Release 12.2(2)T1.

SSH was introduced into these Cisco IOS platforms and images:

• SSH Version 1.0 (SSH v1) server was introduced in some Cisco IOS platforms and images that start in Cisco IOS Software Release 12.0.5.S.

• SSH client was introduced in some Cisco IOS platforms and images starting in Cisco IOS Software Release 12.1.3.T.

• SSH terminal-line access (also known as reverse-Telnet) was introduced in some Cisco IOS platforms and images starting in Cisco IOS Software Release 12.2.2.T.

• SSH Version 2.0 (SSH v2) support was introduced in some Cisco IOS platforms and images starting in Cisco IOS Software Release 12.1(19)E.

• Refer to How to Configure SSH on Catalyst Switches Running CatOS for more information on SSH support in the switches.

Refer to the Software Advisor (registered customers only) for a complete list of feature sets supported in different Cisco IOS Software releases and on different platforms.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are in a live network, make sure that you understand the potential impact of any command before you use it.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

SSH v1 vs. SSH v2

Use the Cisco Software Advisor (registered customers only) in order to help you find the version of code with appropriate support for either SSH v1 or SSH v2.

Network Diagram

Test Authentication

Authentication Test without SSH

First test the authentication without SSH to make sure that authentication works with the router Carter before you add SSH. Authentication can be with a local username and password or with an authentication, authorization, and accounting (AAA) server that runs TACACS+ or RADIUS. (Authentication through the line password is not possible with SSH.) This example shows local authentication, which lets you Telnet into the router with username 'cisco' and password 'cisco.'

Authentication Test with SSH

In order to test authentication with SSH, you have to add to the previous statements in order to enable SSH on Carter and test SSH from the PC and UNIX stations.

At this point, the show crypto key mypubkey rsa command must show the generated key. After you add the SSH configuration, test your ability to access the router from the PC and UNIX station. If this does not work, see the debug section of this document.

Optional Configuration Settings

Prevent Non-SSH Connections

If you want to prevent non-SSH connections, add the transport input ssh command under the lines to limit the router to SSH connections only. Straight (non-SSH) Telnets are refused.

Test to make sure that non-SSH users cannot Telnet to the router Carter.

Set Up an IOS Router or Switch as SSH Client

There are four steps required to enable SSH support on a Cisco IOS router:

1. Configure the hostname command.

2. Configure the DNS domain.

3. Generate the SSH key to be used.

4. Enable SSH transport support for the virtual type terminal (vtys).

If you want to have one device act as an SSH client to the other, you can add SSH to a second device called Reed. These devices are then in a client-server arrangement, where Carter acts as the server, and Reed acts as the client. The Cisco IOS SSH client configuration on Reed is the same as required for the SSH server configuration on Carter.

Issue this command to SSH from the Cisco IOS SSH client (Reed) to the Cisco IOS SSH server (Carter) in order to test this:

• SSH v1:

• SSH v2:

Setup an IOS Router as an SSH server that performs RSA based User Authentication

Complete these steps in order to configure the SSH server to perform RSA based authentication.

1. Specify the Host name.

2. Define a default domain name.

3. Generate RSA key pairs.

4. Configure SSH-RSA keys for user and server authentication.

5. Configure the SSH username.

6. Specify the RSA public key of the remote peer.

7. Specify the SSH key type and version. (optional)

8. Exit the current mode and return to privileged EXEC mode.

   Note: Refer to Secure Shell Version 2 Support for more information.

Add SSH Terminal-Line Access

If you need outbound SSH terminal-line authentication, you can configure and test SSH for outbound reverse Telnets through Carter, which acts as a comm server to Philly.

If Philly is attached to Carter's port 2, then you can configure SSH to Philly through Carter from Reed with the help of this command:

• SSH v1:

• SSH v2:

You can use this command from Solaris:

Restrict SSH access to a subnet

You need to limit SSH connectivity to a specific subnetwork where all other SSH attempts from IPs outside the subnetwork should be dropped.

You can use these steps to accomplish the same:

1. Define an access-list that permits the traffic from that specific subnetwork.

2. Restrict access to the VTY line interface with an access-class.

This is an example configuration. In this example only SSH access to the 10.10.10.0 255.255.255.0 subnet is permitted, any other is denied access.

Note: The same procedure to lock down the SSH access is also applicable on switch platforms.

Configure the SSH Version

Configure SSH v1:

Configure SSH v2:

Configure SSH v1 and v2:

Note: You receive this error message when you use SSHv1:

Note: Cisco bug ID CSCsu51740 (registered customers only) is filed for this issue. Workaround is to configure SSHv2.

Variations on banner Command Output

The banner command output varies between the Telnet and different versions of SSH connections. This table illustrates how different banner command options work with various types of connections.

Unable to Display the Login Banner

SSH version 2 supports the login banner. The login banner is displayed if the SSH client sends the username when it initiates the SSH session with the Cisco router. For example, when the Secure Shell ssh client is used, the login banner is displayed. When the PuTTY ssh client is used, the login banner is not displayed. This is because Secure Shell sends the username by default and PuTTY does not send the username by default.

The Secure Shell client needs the username to initiate the connection to the SSH enabled device. The Connect button is not enabled if you do not enter the host name and username. This screenshot shows that the login banner is displayed when Secure Shell connects to the router. Then, the login banner password prompt displays.

The PuTTY client does not require the username to initiate the SSH connection to the router. This screenshot shows that the PuTTY client connects to the router and prompts for the username and password. It does not display the login banner.

This screen shot shows that the login banner is displayed when PuTTY is configured to send the username to the router.

debug and show Commands

Before you issue the debug commands described and illustrated here, refer to Important Information on Debug Commands. Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

• debug ip ssh—Displays debug messages for SSH.

• show ssh—Displays the status of SSH server connections.

• show ip ssh—Displays the version and configuration data for SSH.

  • Version 1 Connection and no Version 2

  • Version 2 Connection and no Version 1

  • Version 1 and Version 2 Connections

Sample Debug Output

Router Debug

Note: Some of this good debug output is wrapped to multiple lines because of spatial considerations.

Server Debug

Note: This output was captured on a Solaris machine.

What can go Wrong

Crypto Key Generate Rsa Ip Ssh Version 2

These sections have sample debug output from several incorrect configurations.

Git Generate Ssh Key

SSH From an SSH Client Not Compiled with Data Encryption Standard (DES)

Solaris Debug

Router Debug

Bad Password

Router Debug

SSH Client Sends Unsupported (Blowfish) Cipher

Router Debug

Geting the '%SSH-3-PRIVATEKEY: Unable to retrieve RSA private key for' Error

If you receive this error message, it may be caused due to any change in the domain name or host name. In order to resolve this, try these workarounds.

• Zeroize the RSA keys and re-generate the keys.

• If the previous workaround does not work, try these steps:

  1. Zeroize all RSA keys.

  2. Reload the device.

  3. Create new labeled keys for SSH.

Ssh Version 2 Generate Crypto Key In Pdf

Cisco bug ID CSCsa83601 (registered customers only) has been filed to address this behaviour.

Troubleshooting Tips

• If your SSH configuration commands are rejected as illegal commands, you have not successfully generated a RSA key pair for your router. Make sure you have specified a host name and domain. Then use the crypto key generate rsa command to generate an RSA key pair and enable the SSH server.

• When you configure the RSA key pair, you might encounter these error messages:

  1. No hostname specified

     You must configure a host name for the router using the hostname global configuration command.

  2. No domain specified

     You must configure a host domain for the router using the ip domain-name global configuration command.

• The number of allowable SSH connections is limited to the maximum number of vtys configured for the router. Each SSH connection uses a vty resource.

• SSH uses either local security or the security protocol that is configured through AAA on your router for user authentication. When you configure AAA, you must ensure that the console is not running under AAA by applying a keyword in the global configuration mode to disable AAA on the console.

• No SSH server connections running.

  This output suggests that the SSH server is disabled or not enabled properly. If you have already configured SSH, it is recommended that you reconfigure the SSH server in the device. Complete these steps in order to reconfigure SSH server on the device.

  1. Delete the RSA key pair. After the RSA key pair is deleted, the SSH server is automatically disabled.

     Note: It is important to generate a key-pair with at least 768 as bit size when you enable SSH v2.

     Caution: This command cannot be undone after you save your configuration, and after RSA keys have been deleted, you cannot use certificates or the CA or participate in certificate exchanges with other IP Security (IPSec) peers unless you reconfigure CA interoperability by regenerating RSA keys, getting the CA's certificate, and requesting your own certificate again.Refer to crypto key zeroize rsa - Cisco IOS Security Command Reference, Release 12.3 for more information on this command.

  2. Reconfigure the hostname and domain name of the device.

  3. Generate an RSA key pair for your router, which automatically enables SSH.

     Refer to crypto key generate rsa - Cisco IOS Security Command Reference, Release 12.3 for more information on the usage of this command.

     Note: You can receive the SSH2 0: Unexpected mesg type received error message due to a packet received that is not understandable by the router. Increase the key length while you generate rsa keys for ssh in order to resolve this issue.

  4. Configure SSH server. In order to enable and configure a Cisco router/switch for SSH server, you can configure SSH parameters. If you do not configure SSH parameters, the default values are used.

     ip ssh {[timeout seconds] [authentication-retries integer]}

     Refer to ip ssh - Cisco IOS Security Command Reference, Release 12.3 for more information on the usage of this command.

Related Information

Generate Ssh Key Linux

1. Assign a local login (operator) and enable (manager) password.

   At a minimum, HP recommends that you always assign at least a manager password to the switch. Otherwise, under some circumstances, anyone with Telnet, web, or serial port access could modify the switch configuration.

   To configure local passwords:

   You can configure both the operator and manager password with one command.

   Syntax:

   Configuring local passwords

2. Generate the switch public and private key pair.

   A public and private host key pair must be generated on the switch. The switch uses this key pair along with a dynamically generated session key pair to negotiate an encryption method and session with an SSH client trying to connect to the switch.

   The host key pair is stored in the switch flash memory, and only the public key in this pair is readable. The public key should be added to a 'known hosts' file (for example, $HOME/.ssh/known_hosts on UNIX systems) on the SSH clients which should have access to the switch. Some SSH client applications automatically add the switch public key to a 'known hosts' file. Other SSH applications require you to manually create a known hosts file and place the switch public key in the file. See the documentation for your SSH client application for more details.

   (The session key pair mentioned above is not visible on the switch. It is a temporary, internally generated pair used for a particular switch/client session, and then discarded.)

   NOTE: When generating a host key pair on the switch, the switch places the key pair in flash memory and not in the running-config file. Also, the switch maintains the key pair across reboots, including power cycles. Consider this key pair to be 'permanent' and avoid re-generating the key pair without a compelling reason. Otherwise, you must re-introduce the switch public key on all management stations you have set up for SSH access to the switch using the earlier pair. Removing (zeroing) the switch public/private key pair renders the switch unable to engage in SSH operation and automatically disables IP SSH on the switch. To verify whether SSH is enabled, execute show ip ssh. However, any active SSH sessions will continue to run, unless explicitly terminated with the CLI kill command. To generate or erase the switch public/private host key pair:

   Because the host key pair is stored in flash instead of the running-config file, it is not necessary to use write memory to save the key pair. Erasing the key pair automatically disables SSH.

   Syntax:

   crypto key generate <autorun-key[rsa] cert[rsa] <keysize> [ssh][dsa rsa]bits <keysize>>

   Installs authentication files for ssh or https server, or for autorun.

   Install RSA key for autorun. See 'Configuring Autorun on the Switch' in the Management and Configuration Guide for more information.

   Install RSA key for https certificate.

   Microsoft office 2010 keygen. What’s even better is that Microsoft keeps updating these products with new versions that keep on coming with added and improved features.Microsoft Office 2010 product key has been one of the most popular and widely used Office versions from Microsoft. Documents, presentations, spreadsheets – you name it, everything has been made simpler and much easier. The release of Microsoft Office 2010 had everyone in awe of the powerful tools and features it had to make everything related to professional life much more convenient.

   Use your SSL enabled browser to access the switch using the switch IP address or DNS name (if allowed by your browser). See the documentation provided with the browser application for more information.

   Install host key for ssh server. Specify the key type as DSA or RSA.

   Specify the key size (in bits).

   zeroize <ssh cert autorun[rsa]>

   Erases the switch public/private key pair and disables SSH operation.

   Displays switch public key. Displays the version 1 and version 2 views of the key.

   See SSH client public-key authentication for information about public keys saved in a configuration file.

   Displays hashes of the switch public key in phonetic format, see “Displaying the Public Key:”.

   Microsoft Office 2013 Crack With Product Key Generator Updated Version. Microsoft Office 2013 Product Key Generator removes toolbars and allows you to move to a tab in a document as in E-Reader. Videos are better supported You can search, add and display directly in Word. Oct 25, 2019  Microsoft Office Professional Plus 2013 Product Key + Crack Upgraded Microsoft Office Professional Plus 2013 Product Key is an office suite of desktop programs, services, and servers for the Microsoft Windows as well as Mac OS X operating systems, created by Microsoft. The brand new Microsoft Office has updated versions of Word, Excel, PowerPoint, Outlook, and OneNote as well as. Product key generator microsoft office professional plus 2013 keygen.

   Displays fingerprints of the switch public key in hexadecimal format, see “Displaying the Public Key:”.

   Example:

   To generate and display a new key:

   Example of generating a public/private host key pair for the switch

   To compare the switch key to the key stored in your client's known-hosts file, note that the formatting and comments need not match.

   NOTE: 'Zeroizing' the switch key automatically disables SSH (sets ip ssh to no). Thus, if you zeroize the key and then generate a new key, you must also re-enable SSH with the ip ssh command before the switch can resume SSH operation.

   Configuring key lengths:

   The crypto key generate ssh command allows you to specify the type and length of the generated host key. The size of the host key is platform-dependent as different switches have different amounts of processing power. The size is represented by the <keysize> parameter and has the values shown in . The default value is used if keysize is not specified.

   RSA/DSA values for various HP networking switches

   Platform	Maximum RSA Key Size (in bits)	DSA Key Size (in bits)
   5400/3500/6200/8200/2900	1024, 2048, 3072 Default: 2048	1024
   4200/2900/2810/2610/2510	1024, 2048 Default: 2048	1024
   5300/2800/3400/2600	896	512

3. Provide the switch public key to clients.

   When an SSH client contacts the switch for the first time, the client will challenge the connection unless you have already copied the key into the client's 'known host' file. Copying the switch key in this way reduces the chance that an unauthorized device can pose as the switch to learn your access passwords. The most secure way to acquire the switch public key for distribution to clients is to use a direct, serial connection between the switch and a management device (laptop, PC, or UNIX workstation), as described below.

   The public key generated by the switch consists of three parts, separated by one blank space each:

   A public key generated by the switch

   With a direct serial connection from a management station to the switch:

   1. Use a terminal application such as HyperTerminal to display the switch public key with the show crypto host public-key command, see Example of generating a public/private host key pair for the switch.

   2. Bring up the SSH client's 'known host' file in a text editor such as Notepad as straight ASCII text, and copy the switch public key into the file.

   3. Ensure that there are no changes or breaks in the text string. A public key must be an unbroken ASCII string. Line breaks are not allowed (changes in the line breaks will corrupt the Key.) For example, if you are using Windows® Notepad, ensure that Word Wrap (in the Edit menu) is disabled, and that the key text appears on a single line.

      Example of a correctly formatted public key

   4. Add any data required by your SSH client application. For example, before saving the key to an SSH client's 'known hosts' file you may have to insert the switch IP address:

      Example of a switch public key edited to include the switch’s IP address

      For more on this topic, see the documentation provided with your SSH client application.

   Displaying the Public Key:

   The switch provides three options for displaying its public key. This is helpful if you need to visually verify that the public key the switch is using for authenticating itself to a client matches the copy of this key in the client's 'known hosts' file:

   • Non-encoded ASCII numeric string:

     Requires a client ability to display the keys in the 'known hosts' file in the ASCII format. This method is tedious and error-prone due to the length of the keys. See Example of a correctly formatted public key.

   • Phonetic hash:

     Outputs the key as a relatively short series of alphabetic character groups. Requires a client ability to convert the key to this format.

   • Hexadecimal hash:

     Outputs the key as a relatively short series of hexadecimal numbers. Requires a parallel client ability.

   For example, on the switch, generate the phonetic and hexadecimal versions of the switch public key as follows:

   Visual phonetic and hexadecimal conversions of the switch public key

   The two commands shown in Visual phonetic and hexadecimal conversions of the switch public key convert the displayed format of the switch (host) public key for easier visual comparison of the switch public key to a copy of the key in a client's 'known host' file. The switch has only one RSA host key. The 'babble' and 'fingerprint' options produce two hashes for the key--one that corresponds to the challenge hash you will see if connecting with a v1 client, and the other corresponding to the hash you will see if connecting with a v2 client. These hashes do not correspond to different keys, but differ only because of the way v1 and v2 clients compute the hash of the same RSA key. The switch always uses an ASCII version of its public key, without babble or fingerprint conversion, for file storage and default display format.

4. Enable SSH on the switch and anticipate SSH client contact behavior.

   The ip ssh command enables or disables SSH on the switch, and modifies parameters the switch uses for transactions with clients. After you enable SSH, the switch can authenticate itself to SSH clients.

   NOTE: Before enabling SSH on the switch you must generate the switch public/private key pair. If not yet done, see Generate the switch public and private key pair. When configured for SSH, the switch uses its host public key to authenticate itself to SSH clients.For SSH clients to authenticate themselves to the switch, configure SSH on the switch for client public-key authentication at the login (operator) level. To enhance security also configure local, TACACS+, or RADIUS authentication at the enable (manager) level. See Step 5.

   SSH client contact behavior:

   At the first contact between the switch and an SSH client, if the switch public key has not been copied into the client, then the client's first connection to the switch will question the connection and, for security reasons, provide the option of accepting or refusing. If it is safe to assume that an unauthorized device is not using the switch IP address in an attempt to gain access to the client's data or network, the connection can be accepted. (As a more secure alternative, the client can be directly connected to the switch serial port to download the switch public key into the client.)

   NOTE:When an SSH client connects to the switch for the first time, it is possible for a 'man-in-the-middle' attack; that is, for an unauthorized device to pose undetected as the switch, and learn the usernames and passwords controlling access to the switch. This possibility can be removed by directly connecting the management station to the switch serial port, using a show command to display the switch public key, and copying the key from the display into a file. This requires a knowledge of where the client stores public keys, plus the knowledge of what key editing and file format might be required by the client application. However, if the first contact attempt between a client and the switch does not pose a security problem, this is unnecessary.

   Enabling SSH on the switch:

   1. Generate a public/private key pair if you have not already done so. See Generate the switch public and private key pair.

   2. Execute the ip ssh command.

   Disabling SSH on the switch:

   Perform either of the following:

   • Execute no ip ssh.

   • Zeroize the switch existing key pair, see “To generate or erase the switch public/private host key pair:” for more details.

     Syntax:

     Enables or disables SSH on the switch.

     [cipher <cipher-type>]

     Specify a cipher type to use for connection.

     Valid types are:

     • aes128-cbc

     • 3des-cbc

     • aes192-cbc

     • aes256-cbc

     • aes128-ctr

     • aes192-ctr

     • aes256-ctr

     Default: All cipher types are available.

     Use the no form of the command to disable a cipher type.

     Enable/disable secure file transfer capability. SCP and SFTP secure file transfer will not function unless SSH is also enabled.

     [ip-version <4 6 4or6>]

     Select the IP mode to run in. The mode 'ip-version 4' only accepts connections from IPv4 clients. The mode 'ip-version 6' only accepts connections from IPv6 clients. The mode 'ip-version 4or6' accepts connections from both IPv4 and IPv6 clients.

     Default: ip-version 4 or 6

     Allows configuration of the set of MACs that can be selected. Valid types are:

     • hmac-md5

     • hmac-sha1

     • hmac-sha1-96

     • hmac-md5-96

     Default: All MAC types are available.

     Use the no form of the command to disable a MAC type.

     The TCP port number for SSH connections.

     Default: 22.

     Sets the maximum length of time (in seconds) allowed for initial protocol negotiation and authentication.

     Default: 120 seconds

     NOTE:HP recommends using the default TCP port number (22). However, you can use ip ssh port to specify any TCP port for SSH connections except those reserved for other purposes. Examples of reserved port numbers reserved IP ports are 23 (Telnet) and 80 (http). Some other reserved TCP ports on the switch are 49, 80, 1506, and 1513.

     Enabling IP SSH and displaying the SSH configuration

     CAUTION:Protect your private key file from access by anyone other than yourself. If someone can access your private key file, they can penetrate SSH security on the switch by appearing to be you. SSH does not protect the switch from unauthorized access via the WebAgent, Telnet, SNMP, or the serial port. While WebAgent and Telnet access can be restricted by the use of passwords local to the switch, if you are unsure of the security this provides, you may want to disable web-based and/or Telnet access (no web-management and no Telnet). If you need to increase SNMP security, use SNMP version 3 only. To increase the security of your web interface see the section on SSL. For an additional security measure, see the authorized IP managers feature in the Management and Configuration Guide for your switch. To protect against unauthorized access to the serial port (and the Clear button, which removes local password protection), keep physical access to the switch restricted to authorized personnel.

5. Configure the switch for SSH authentication.

   Note that all methods in this section result in authentication of the switch public key by an SSH client. However only Option B below results in the switch also authenticating the client's public key. Also, for a more detailed discussion of the topics in this section, see SSH client public-key authentication notes.

   NOTE:HP recommends that you always assign a manager-level (enable) password to the switch. Without this level of protection, any user with Telnet, web, or serial port access to the switch can change the switch configuration. If you configure only an operator password, entering the operator password through telnet, web, ssh or serial port access enables full manager privileges. See Assign a local login (operator) and enable (manager) password.

   Option A: Configuring SSH access for password-only SSH authentication:

   When configured with this option, the switch uses its public key to authenticate itself to a client, but uses only passwords for client authentication.

   Syntax:

   aaa authentication ssh login <local tacacs radius [peap-mschapv2>][<local none>]

   Configures a password method for the primary and secondary login (operator) access. If you do not specify an optional secondary method, it defaults to none. If the primary method is local, the secondary method must be none.

   aaa authentication ssh enable <local tacacs radius>[<local none>]

   Configures a password method for the primary and secondary enable (manager) access. If you do not specify an optional secondary method, it defaults to none. If the primary method is local, the secondary method must be none.

   Option B: Configuring the switch for client Public-Key SSH authentication

   If configured with this option, the switch uses its public key to authenticate itself to a client, but the client must also provide a client public key for the switch to authenticate. This option requires the additional step of copying a client public-key file from a TFTP or SFTP server into the switch. This means that before you can use this option, you must:

   1. Create a key pair on an SSH client.

   2. Copy the client's public key into a public-key file (which can contain up to 10 client public keys.)

   3. Copy the public-key file into a TFTP or SFTP server accessible to the switch and download the file to the switch.

   For more on these topics, see SSH client public-key authentication notes.

   With steps a-c complete and SSH properly configured on the switch, if an SSH client contacts the switch, login authentication automatically occurs first, using the switch and client public keys. After the client gains login access, the switch controls client access to the manager level by requiring the passwords configured earlier by the aaa authentication ssh enable command.

   Syntax:

   Copies a public-key file into the switch.

   Configures the switch to authenticate a client public key at the login level with an optional secondary password method.

   Default: none

   Syntax:

   aaa authentication ssh enable <local tacacs radius> <local none>

   Configures a password method for the primary and secondary enable (manager) access. If you do not specify an optional secondary method, it defaults to none.

   If the primary access method is local, you can only specify none for a secondary access method.

   NOTE: The configuration of SSH clients' public keys is stored in flash memory on the switch. You also can save SSH client public-key configurations to a configuration file by entering the following commands: include-credentials write memory For more information about saving security credentials to a configuration file, see Saving security credentials in a config file.

   Example:

   Assume you have a client public-key file named Client-Keys.pub (on a TFTP server at 10.33.18.117) ready for downloading to the switch. For SSH access to the switch allow only clients having a private key that matches a public key found in Client-Keys.pub. For manager-level (enable) access for successful SSH clients use TACACS+ for primary password authentication and local for secondary password authentication, with a manager username of '1eader' and a password of 'm0ns00n'. To set up this operation, configure the switch in a manner similar to the following:

   Configuring for SSH access requiring a client public-key match and manager passwords

   SSH configuration and client public-key listing from figure shows how to check the results of the above commands.

   SSH configuration and client public-key listing from figure

6. Use an SSH client to access the switch.

   Test the SSH configuration on the switch to ensure that you have the level of SSH operation needed for the switch. If you have problems, see 'RADIUS-related problems' in the Management and Configuration Guide for your switch.