cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11205
Views
0
Helpful
3
Replies

How do you set up SSHv2 on stacked 3750x

klambert1218
Level 1
Level 1

I am having a bit of a problem getting SSHv2 to work on stacked 3750x switches. Here's the story. I replaced one 6506-E with a pair of stacked 3750x, and I basically just copied the configuration from the 6506-E to the 3750x. While copying:

ip ssh time-out 60

ip authentication-retries 2

ip ssh logging events

ip ssh version 2

no ip domain-lookup
ip domain-name trdm
login block-for 300 attempts 3 within 60
login on-failure log

login on-success log

to the new switch, I was informed that I had to generate rsa keys in order to enable ssh. So after the entire configuration was copied, I went back and ran

cry key gen rsa

and I chose 1024 bit modulus. It successfully created it, and I was able to verify that SSHv2 was enabled by issuing

sh ip ssh

which returned

SSHv Enabled - version 2.0

Authentication timeout: 60 secs; Authentication retries: 2

Now when I issue

sh cry key mypubkey rsa

I get


Key name: hostname

Storage Device: not specified

Usage: General Purpose Key

Key is not exportable.

Key Data:

     <omitted>


Key name: hostname.server

Temporary key

  Usage: Encryption Key

  Key is not exportable.

  Key Data:

    <omitted>

The config for my vty lines are:

lin con 0

exec-timeout 4 30

timeout login response 300

login

lin vty 0 4

access-class 101 in

exec-timeout 4 30

password 7 <omitted>

login local

transport input ssh

lin vty 5 15

access-class 101 in

exec-timeout 4 30

password 7 <omitted>

login local

transport input telnet ssh

The ACL is

access-list 101 permit tcp host <omitted> any eq 22

access-list 101 permit tcp host <omitted> any eq 22

access-list 101 permit tcp host <omitted> any eq 22

However, if I use telnet, it works without issue. Anyone have any suggestions?

1 Accepted Solution

Accepted Solutions

Collin Clark
VIP Alumni
VIP Alumni

You should be using a standard access list instead of an extended one. As Jennifer stated, try removing the access-class from the VTY's and see if it works. If so I would create a standard ACL and test it with that.

View solution in original post

3 Replies 3

Jennifer Halim
Cisco Employee
Cisco Employee

Does it work if you take the ACL 101 out from the vty line?

Also pls check that the SSH Client that you use is negotiating on SSH version 2 as well. Try use different SSH client to see if it works.

Collin Clark
VIP Alumni
VIP Alumni

You should be using a standard access list instead of an extended one. As Jennifer stated, try removing the access-class from the VTY's and see if it works. If so I would create a standard ACL and test it with that.

klambert1218
Level 1
Level 1

Okay, I have solved my problem on my own, but part of it could have been attributed to the ACL, so I'll award points for that. Essentially what it boils down to is:

1. I didn't have a username and password set up on the switch.

2. I was using an extended ACL on the vty lines.

Once I added the username and password in the global configuration and implemented the standard ACL on the vty lines, it worked without issue. Just one more lesson learned the hard way.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: