Enable ssh and disabling telnet

[michaeltint]

Hi All,

We have several switches that has both telnet and ssh and some has just telnet enabled. For security reasons i been asked to disable telnet and enable ssh.

I will be applying below to all switches which has ssh+telnet enable.

config t
ip ssh time-out 90
ip ssh authentication-retries 3
line vty 0 4
transport input ssh
no transport input telnet

Please comment on above commands as it will be used for 2950 & 3750 switches and if this is the safe and good way to do this.

What happens when the ‘transport input ssh’ command is entered on the switch vty lines? And will this block cut off existing telnet connection immediately?

Thanks,


Michael

 

[madwok]

transport input ssh should block out telnet

There is also an acl/access-class for vty should you want to tighten it down more.

 

[vipergg]

Verify you have the correct IOS that supports SSH . Verify the crypto keys have been generated before turning off telnet . If you turn off telnet and the keys have not been generated you will have to correct it on the console port as telnet or ssh will not work at that point . the just add the transport input ssh command and this will shut off telnet for any future connections.

 

[michaeltint]

thanks all.

all went well.

yes - 'no transport input telnet' is not needed

and also existing telnet connection does not get cut off, however any new connection is blocked.

 

[jimfixit]

I found this post while trying to do a similar thing on my 3750s...

transport input ssh does indeed enable ssh to be used. It does not shut off telnet however. After issuing this command I can still use a DOS window and telnet x.x.x.x big as life...and get in!

I tried an ACL but that does not work well either because VTY does not support extended access list to block specific ports, I would have to just block or permit traffic from specific IP addresses...horrible if/when you have to access remotely over citrix, VPN client from timbuktu or whereever, you have no idea what your IP can/will be.

IOS 12.4 does support extended access list on vty but where, oh where is 12.4 for 3750's? According to Cisco it's not even in the line up.

I tried to shut telnet off by applying extended acl to ethernet port...that worked but of course that's slow. I'd have to apply an ACL to every stinking port on the switch, not knowing where a hacker may try to get in from.

Is there no way to just turn off the telnet server portion of the IOS...like just say "NO whatever-this-feature-is" like you turn off the http and https sever code?

Thank you in advance,

 

[drewdown]

jinfixit, I deny telnet/shh on my 3750's with an ACL on the VTY lines for a range of IP addresses that I don't want anyone attempting to telnet/ssh from.

Who are you trying to block access from? Also it works in my case (solely internal) because I know which addresses I want to block and I am restricting them from accessing my network devices on the VTY lines, no reason to specify a port because no one should be accessing them except for the IT department anyway.

In my case our VPN Client uses a virtual adapter so I know what IP address range I will have when using it. I also know that I have specific machines that I can telnet/ssh from if the need arises.

Here is a snipet from my config:

access-list 10 deny   172.23.28.0 0.0.0.255
access-list 10 deny   172.23.27.0 0.0.0.255
access-list 10 deny   172.23.22.0 0.0.0.255
access-list 10 permit any

line con 0
line vty 0 4
 access-class 10 in
 password 7 XXXXXXXXXXXXXXXXX
 login authentication ADMINS
 length 0
 transport input ssh
line vty 5 15
 password 7 XXXXXXXXXXXXXXXX
 login authentication ADMINS
 transport input ssh

 

[jimfixit]

Basically I want all telnet shut out. If SSH is working there is no need of telnet.

This network wasn't laid out well in terms of IP addressing but it is what it is. You have to play with the cards you are dealt in some cases. I did not inherrit flexible enough addressing to summarily allow or deny certain addresses or ranges of addresses. And getting approval to fix that is like pulling teeth because, OMG it requires some down time on certain servers.

It's maddening that cisco gear is so freakin' limited that I can't apply an extended access list to the line ports. All I need is to block port 23 into vty 0-15. Why is security always an after-thought with these guys?

*sigh* sorry for the rant. Everything I want to do on the 3750's isn't supported....I really miss my juniper days sometimes.

 

[drewdown]

I hear you man. I was in the same position when I started here, thankfully for me I was allowed to re-configure the network as I saw fit.

 

[unclerico]

It's maddening that cisco gear is so freakin' limited that I can't apply an extended access list to the line ports. All I need is to block port 23 into vty 0-15. Why is security always an after-thought with these guys?

why would you need to apply an extended access list to the vty lines?? if you apply transport input ssh then only ssh is allowed in so no need for an extended acl since it by default will allow only tcp/22 to connect. if you apply transport input telnet then only telnet is allowed, no extended acl needed. if you really want to create an extended acl, apply it inbound on your VLAN SVI/physical port.

Everything I want to do on the 3750's isn't supported....I really miss my juniper days sometimes.

like??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[jimfixit]

Okay there's several things here.

Fact, the "transport input ssh" did not prohibit telnet however it did allow ssh at the same time as telnet. After much nashing of teeth I found that the problem is a bug in revision 12.2(44)SE5. If I backrev to 12.2(25r) then the command works as documented.

12.2.44 also happens to have a bug that causes repeated issuances of Show Int gi x/x/x to display output drop figures that are incorrect. Messes up stats for baselining and troubleshooting. There is a 12.2(50)out, but that still has the erroneous output drop in it. We back reved to 12.2(25) to get around that issue.

Why would I want an ACL? I'd rather not. But since I was fighting the transport command's failure to work right, it would have been nice to issue an ACL as a work around. Why on the VTY port and not on the vlan? Who wants to inspect every single packet on the entire net for the occassional instance of telnet?

What else would be nice? PBR on the 3750 isn't fully supported. The multiple tracking option isn't available because you have to have 12.4 (minimum) and of course there isn't one for 3750. Some advanced features of PBR are available in 12.2.44 but of course I'm on a different version for the reasons stated above. I have PBR but only a bare minimum feature set and it leaves us vulnerable when certain devices elsewhere in the network go down.

SO I have choose which features I want to work most...and pick the OS that will supply, and do without the other fixes/features. It's just frustrating, that's all.

 

[VinceWhirlwind]

Juniper IOS has had its own share of bugs, too - just be thankful you aren't having to deal with Nortel switch IOS which is so often absolutely riddled with critical bugs not just annoying ones.
I kind of agree with Unclerico, though - there doesn't seem to be much point to applying an extended ACL when there is a command to do exactly what you want with "no transport input telnet".

 

[jimfixit]

agreed...if bugs don't prevent it from working, the transport command is a better choice. In my original post I only knew it didn't work (not why) and was searching for a work around out of necessity.

Part of this may be caused by the fact that so very often I embark on a project only to find that the versions of IOS that run on Cisco 3750s do not support the solution as designed. It's very hard sometimes to figure out from documentation what IOS's will and will not support the commands outlined. Even our SE, with his many CCIE's will often recommend a method that, after we study up on it and then try to implement, we find 3750's won't support because there's no current IOS for them.

Yeah, they all have their problems.

 

[unclerico]

are you aware of the software adviser on cisco.com??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[burtsbees]

access-list 10 permit (subnet)

line vty 0 15
ip access-class in

That will filter traffic. You must use a standard acl for ip filtering, so access-class on the vty lines cannot filter at layer 4.

What you have done as far as ssh---you need

ip domain-name bla
crypto key gen rsa

Those must happen before you can ssh in.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[unclerico]

burt, permitting traffic is how i would do it also as opposed to explicitly denying the traffic. i have all of my devices configured to accept ssh sessions from my management workstations only, everything else is denied implicitly.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[VinceWhirlwind]

Even our SE, with his many CCIE's will often recommend a method that, ..., we find 3750's won't support"

Gee, you're not changing my opinion of those paper qualifications....

I had one the other day - was handing a network over to a one of those kind of blokes who uses a prominent "I'M A CCNP" in his email sig - he connected up a Pix so he could remote-manage the new network...
CCNP_GENIUS:It's not connecting, you must have configured your end wrong
Me: Can you ping my interface from your Pix?
CCNP_GENIUS:Yes
Me: Can you ping beyond my interface from your Pix?
CCNP_GENIUS:No.
Me: Duh. Put a route on your Pix.

 

[burtsbees]

Uncle...

10 permit (subnet) is a permit statement...

what did you mean?

"access-list 10 permit (subnet)"

Step away from the boilermakers...

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[unclerico]

lol, burt, i was agreeing with you man

burt, permitting traffic is how i would do it also as opposed to explicitly denying the traffic

step away from the crack pipe lol

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[burtsbees]

Whoopsie...

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!