06-04-2008 01:08 PM - edited 03-05-2019 11:26 PM
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.)
06-04-2008 01:10 PM
When you say you can't log in are you not even getting a prompt ?
Jon
06-04-2008 01:28 PM
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.
06-04-2008 01:52 PM
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
06-04-2008 02:25 PM
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.
06-04-2008 03:35 PM
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 .
06-04-2008 06:04 PM
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
06-05-2008 07:34 AM
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?
06-05-2008 09:06 AM
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
06-05-2008 11:54 AM
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
06-05-2008 01:05 PM
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%
06-06-2008 05:43 AM
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.
06-10-2008 08:06 AM
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.
06-10-2008 08:41 AM
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
06-10-2008 09:41 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide