can't ssh to 2811

[olhcc]

I can't seem to SSH into our 2811 box. It's running SPSERVICES feature pack. I zeroized rsa key, regenerated RSA key, got the debug message that SSH v2.0 ENABLED, and then reconfigured:

line vty 0 4

login local

transport input ssh

session-timeout 10

Shouldn't that be all there is to it? (There are no ACLs blocking my host from that of Fast0/0.)

[Jon Marshall]

When you say you can't log in are you not even getting a prompt ?

Jon

[olhcc]

Yes, using PuTTY, I just get a "Connection Timed Out." I can ping the box and even ran an NMap against it, so I know I have IP connectivity.

All logging on the 2811 box is set to debug, yet nothing is showing up there to indicate any kind of failure. I can log into the console, so I know that my credentials are good.

[Jon Marshall]

You are using a username/password for ssh access yes ?

Have a quick look at this doc to make sure you haven't missed anything.

http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186a00800949e2.shtml

One other thing when you connect with Putty client you are selecting SSH instead of telnet. I only ask because i keep making the same mistake all the time :-)

Jon

[ralphcarter]

Do these commands in order.

# ip ssh version 2

# ip domain-name xxx.xxx

# crypto key generate rsa mod 1024

I saw that if you change the version after crypto, it doesnt work.

[glen.grant]

Follow Ralph Carters instructions and it should work . Do the domain name , create the SSH key with the crypto command and add your ssh transport commands under the vty sessions. If you are not using a AAA setup (tacacs) then you must also have the local username and password for authentication .

[Richard Burts]

Ben

I believe that these are good suggestions (though in reading this thread it sounds like you may have done these already). Give them a try and see if they help.

If they do not then log in on the console, run debug ip ssh, and attempt to ssh to the router. The debug output may show us what the problem is.

HTH

Rick

[olhcc]

I followed this exact order, received this in the log:

Jun 5 09:21:21: %SSH-5-ENABLED: SSH 2.0 has been enabled

...but still get a connection timeout. I did do the debug ip ssh command, but nothing showed up in the log or on the console (logging set to debug) when I try to connect from my workstation. I have tried using PuTTY as well as TeraTerm with the same results, so I know it is not my SSH client.

I have no idea what the problem is. I have another router, a 2801, and it has the exact same SSH config and I can get into the box no problem. I've set up dozens of routers to accept SSH and it's easy to do. I'm thinking it might be time to make this TAC's problem...

PS- I did an NMAP to the box and this is what I saw:

Interesting ports on (10.8.x.x):

Port State Service

22/tcp filtered ssh

Why is it filtered when it should be open? There are no firewalls between me and it and no ACLs on the VTY line. Any other ideas?

[Jon Marshall]

When a port is filtered in Nmap it means that the packet has been silently dropped so it could be

1) As you say a firewall/acl is blocking the packet and not sending any response back.

2) There is something wrong with the service ie. it receives the SYN packet but does not send a SYN-ACK back or if it does that gets blocked/dropped/lost somewhere.

You are also correct in that you should be seeing it as "open".

Is there any chance you could try and ssh from the subnet the router is attached to ?

Jon

[Richard Burts]

Ben

At the risk of pointing out the obvious, if you had debug running for ssh, attempted an ssh connection, and there was no debug output that points to the conclusion that the ssh packet did not get to the router. Which would support the theory that there is a firewall or something filtering the SSH attempts.

HTH

Rick

[josejames]

Can you send a partial config with user credentials, interfaces, ip inspect, nat

If your natting then try and create a ip nat inside blah blah 22

You could also confirm the ssh is functioning correctly by ssh -l %username% %ip address%

[olhcc]

I'd prefer not to post any part of the config here.

I am connected to the same L3 switch as the router, but we are on different VLANs. I have double- and triple-checked the ACLs and route tables in the switch, and nothing is filtering SSH to the router or blackholing me. Simply, the router is filtering port 22, so something in the router is misconfigured or malfunctioning.

I'll be opening a TAC case today. I'll make sure to post the results. Thanks everyone for their input so far.

[olhcc]

Just an update:

I do have a TAC case open. In doing so, they had me do "debug ip tcp". When I try to connect, the following is logged:

Jun 10 10:58:18: tcp0: I LISTEN 10.8.x.x:8322 10.8.x.x:22 seq 4275081987

OPTS 8 SYN WIN 65535

Jun 10 10:58:18: TCP0: bad seg from 10.8.x.x -- IDB not up: port 22 seq 4275081987 ack 0 rcvnxt 0 rcvwnd 4128 len 0

I have asked what "IDB not up" points to. I did try and connect from the same VLAN, and it did connect without a problem. I am routed correctly to the router through the switch in between, and there are no ACLs blocking. Could this be an ARP issue?

Also, I applied ACL 23 to vty 0 4. Now, in the log, I see:

Jun 10 11:04:00: %SEC-6-IPACCESSLOGNP: list 23 permitted 0 10.8.x.x -> 0.0.0.0

, 6

Why is it showing the destination address as 0.0.0.0? Perhaps this is relevant, perhaps not.

[Richard Burts]

Ben

I think that it does not matter.

If you applied access list 23 that is a standard access list and the source address matters but the destination address does not matter (is not checked). Also assuming that you applied the access-class as inbound (rather than outbound) then the logic is concerned with where the request came from and does not matter which destination address was used.

The IDB not up sounds more interesting and more significant.

Are you by any chance doing address translation on this router? I wonder if there is translation if it could be interferring with the ssh attempt?

HTH

Rick

[olhcc]

Thanks Rick, I just wanted to eliminate the ACL23 as another possible cause of the problem.

Yes, the IDB is more interesting, and is all we have to go on at this point. In searching for IDB, all I came across was Interface Descriptor Block:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_tech_note09186a0080094322.shtml

To answer your question, there is no NATing taking place at all on this router. It is currently serving as a gateway for a 400-phone VoIP system, so there is very little config on the box pertaining to NAT and ACLs.