SSH-Access Denied when password is entered

[kuesteral]

I can ssh to the routers 10.1.3.1 int but not to the 10.1.3.x dhcp clients. Before the internet access and nat stuff was added to this config ssh worked.

The problem is when performing ssh to a 10.1.3.x unit from a 10.1.1.x unit. They get a login and can enter the username and password but get Access Denied when the password is entered. If the router is taken out of the equation ssh works fine so we know the config below is the problem.

Current configuration : 3607 bytes
!
! Last configuration change at 02:49:56 Chicago Sun Jun 17 2012 by xxxxxxxxx
!
version 12.3
no service timestamps debug uptime
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxx
enable password xxxxxxxxx
!
username xxxxxxx password 0 xxxxxxxx
clock timezone Chicago -6
clock summer-time Chicago date Apr 6 2003 2:00 Oct 26 2003 2:00
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
aaa new-model
!
!
aaa session-id common
ip subnet-zero
!
!
ip dhcp excluded-address 10.1.3.0 10.1.3.29
ip dhcp excluded-address 10.1.3.60 10.1.3.255
!
ip dhcp pool tvmbox
   network 10.1.3.0 255.255.255.0
   default-router 10.1.3.1
   dns-server x.x.x.x x.x.x.x

!
ip cef
ip audit po max-events 100
ip dhcp-server 10.1.3.1
no ftp-server write-enable
!
!
!
!
!
!
!
interface Ethernet0
ip address 10.1.1.190 255.255.255.0
ip nat outside
full-duplex
!
interface FastEthernet0
ip address 10.1.3.1 255.255.255.0
ip nat inside
speed auto
full-duplex
!
interface Serial0
no ip address
shutdown
!
ip nat inside source list 101 interface Ethernet0 overload
ip nat inside source static tcp 10.1.1.190 22 interface FastEthernet0 22
ip nat inside source static tcp 10.1.1.190 22 10.1.3.30 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.31 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.32 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.33 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.34 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.35 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.36 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.37 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.38 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.39 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.40 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.41 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.42 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.43 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.44 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.45 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.46 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.47 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.48 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.49 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.50 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.51 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.52 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.53 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.54 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.55 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.56 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.57 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.58 22 extendable
ip nat inside source static tcp 10.1.1.190 22 10.1.3.59 22 extendable
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.2
no ip http server
ip http secure-server
!
!
access-list 101 permit ip 10.1.3.0 0.0.0.255 any
!
!
line con 0
line aux 0
line vty 0 4
password xxxxxxxxx
!
end

Router#

[handoko wiyanto]

from this config, there is NAT configuration enabled. may i know why you need nat here?

[kuesteral]

We needed nat to allow the 10.1.3.x dhcp clients to have internet access.

[handoko wiyanto]

by using private ip nat to private ip?

[kuesteral]

Let me restate the nat config as I messed that up.

We have nat on the interfaces to allow internet access for the 10.1.3.x clients. (This stopped ssh from working.)

We added static nat routes to get ssh to work for these same clients. except we have the issue of the password being denied. (This allowed ssh to get through but the password is getting access denied.)

Something else to note is the unix boxes we are trying to ssh to through the router have ssh ver. 2 on them while the router has ver. 1.5. Is this my problem? And if so is there a workaround?

[handoko wiyanto]

interesting what you have here,

so youre saying that the internet connection for network

10.1.3.0/24 is working normal?

how about if the network in

10.1.3.0/24

try to ssh to the other way? can the password sent trough? for example the unix devices, ssh your pc or other pc that sit on the same network. if those unix devices can ssh to the other way (internet or your network) means youre only facing one way SSH problem.

based on that, i would ask you to go trough the nat config again. as far as i know, in normal circumstances, if you need to SSH to a pc/server from outside interface to inside interface, you need to define static NAT for all the pc behind it. for example if you want to have 20 client ssh-able, then you need to do 20 static nat.

by the way. when you take out this router, what device are you using? and what things that you configured there?

regards,

[Richard Burts]

Al

I am confident that the version of SSH running on the router is not the issue that prevents SSH to the 10.1.3 clients. The version of SSH is significant on the host that is the source and on the host that is the destination. But the version of SSH running on the router has no impact on SSH that is being forwarded through the router.

My guess is that the problem involves the multiple static nat translations configured for the hosts in the 10.1.3 subnet. As a test I suggest tht you remove the static nat translations for all hosts execpt one. Then try SSH from that host. Give this a try and let us know how it works.

HTH

Rick

[kuesteral]

To Rick,

Took out all but one static entry, same problem.

To handoko,

When the Cisco 1721 is taken out of the equation the router/gateway that connections go thorugh is an RVS4000 with little or no configuration done to it. This is the unit that provides internet access and routing on the 10.1.1.x. network.

One user also noted that when he tries to use Cygwin it actually reports back the following error message:

Protocol major versions differ: 2 vs. 1

Al

[handoko wiyanto]

hi Al,

based on the fact that you find, i can see that you  have doubts about this ssh protocol diffrences. do a show version, and  post the ios version + feature set that you use. from that we can find  is there any ios that support ssh v2 for that 1721 router. if we find  the ios, then you may want to proceed with the ios upgrade

in the mean time, we can once again go trough you config.

regards,

[kuesteral]

handoko-

The 1721 router is on 12.3 main ver. and it only has ssh ver1.5. There are newer versions of IOS that show ssh ver 2 but we don't have the ability to download them.

The RVS 4000 is for 10.1.1.x internet access, the 1721 only serves machines we are setting up on the shop floor.

Rick-

Removed the static routes as you suggested except one and tried it, didn't work.

I have someone from another division of the company here looking at the issue and I will post back what I find out. I appreciate the replies thus far.

[handoko wiyanto]

hi Al,

ive been reading the other way to do nat using route map. but i think we can talk about that later.

anyway, do your rvs4000 also support ssh v2?

and how about you paste some debug ip ssh result here.

regards,

[Richard Burts]

Al

I hope that the person from another division finds something to explain what is going on. In the mean time I have re-read the thread and would like some clarification about your environment. Are you doing the SSH from some device outside that comes through the Ethernet 0 10.1.1.190 interface? Is the SSH attempt destination address specifying the 10.1.3.x address? Or is the SSH attempt using destination address of 10.1.1.190 and using the router to translate and forward to the SSH destination?

I am wondering if the SSH attempt is getting SSH on the router instead of on the intended inside device. That would explain the error message about Protocol major versions differ: 2 vs. 1

One way to check this would be to run debug for SSH on the router and see if the router is processing the SSH request locally instead of forwarding as you intend. Or an easier way to test would be to try the SSH and login using a user name and password that are valid on the router.

HTH

Rick

[handoko wiyanto]

hi Rick,

glad to have you here with us.

as per my understanding, al cant do ssh from network 10.1.1.0/24 network to 10.1.3.0/24.

but al not yet clarify whether network 10.1.3.0/24 can ssh one of the device in network 10.1.1.0/24

regards,

[kuesteral]

Hi guys,

The network mask of clients in the 10.1.1.x side change their mask to /16 in order to access the 10.1.3.x just for clarification.

We do not ever ssh from 10.1.3.x to 10.1.1.x but I uunderstand your wanting to test that and we may test that eventually but I do not generally access the 10.1.3.x clients that is handled by someone else.

There is not outside access involved with this ssh scenario, all internal inside the bldg through the 1721. They ssh to the 10.1.3.x units directly not 10.1.1.190. The only outside piece is the 10.1.3.x clients ability to get to the 'net to pull updates.

Again, the ssh worked before we introduced internet access for 10.1.3.x on the 1721. So I have trouble believing there is anything wrong with ssh per se. No time until later in the week to work on this.

Thanks guys, i'll follow up.

[kuesteral]

OK, follow up as promised. Things just got delayed here.

We have this working now and it turned out to be the gateway router (RVS4000) at 10.1.1.2. We added a route for 10.1.3.0 255.255.255.0 10.1.1.190 to it. The Cisco 1721 config had the nat stuff removed and nothing added, no access-list, etc. The access-list shown in the config above was removed also.

So I was banging my head against the wall trying to configure the 1721 when all the while the gateway router simply needed that route added.

Thanks for your replies and I hope this info might help someone else in the future.

Al