cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
188521
Views
46
Helpful
17
Replies

Getting SSH error 'connection refused'

sonikbaby
Level 1
Level 1

Hello,

I need some help on this issue. On some routers and switches I am getting connection refused when trying to SSH to them. Telnet works fine ofcourse. I am  thinking it maybe the 'crypto key generate rsa' command is missing? But some of the routers that are having the issue have that command issued.  Here is the configuration (I removed encrypted passwords)  What could it be?


ALAM-RTR1-2811#show run
Building configuration...

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname ALAM-RTR1-2811
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 warnings
no logging console
enable secret 5
!
aaa new-model
!
!
aaa authentication login default group radius local-case
aaa accounting exec default start-stop group radius
aaa accounting network default start-stop group radius
!
aaa session-id common
!
resource policy
!
memory-size iomem 10
clock timezone MDT -7
clock summer-time mdt recurring
ip subnet-zero
!
!
ip cef
!
!
no ip domain lookup
ip domain name parametrix.com
ip ssh rsa keypair-name ALAM-RTR1-2811
ip ssh version 2
!
modemcap entry usrmodem1:MSC=&FS0=1&C1&D3&H1&R2&B1
!
!
username routeradmin secret 5
!
!
!
interface Loopback1
ip address 172.30.127.254 255.255.255.255
no ip redirects
no ip unreachables
no ip proxy-arp
!
interface FastEthernet0/0
description Uplink to Quest MPLS
no ip address
duplex full
speed 100
!
interface FastEthernet0/0.705
description Quest qmoe
encapsulation dot1Q 705
ip address 192.168.252.65 255.255.255.192
no snmp trap link-status
!
interface FastEthernet0/0.706
description Quest MPLS
encapsulation dot1Q 706
ip address X.x.X.x 255.255.255.252
no snmp trap link-status
!
interface FastEthernet0/1
description Uplink to internal network
ip address 172.30.0.1 255.255.252.0
duplex full
speed 100
!
ip classless
ip route 0.0.0.0 0.0.0.0 63.234.101.209
ip route x.x.x.x 255.255.255.252 x.x.x.x.
ip route 172.21.0.0 255.255.128.0 192.168.252.66
ip route 172.22.0.0 255.255.128.0 x.x.x.x.x
ip route 172.30.0.0 255.255.128.0 172.30.0.30
!
ip http server
no ip http secure-server
!
snmp-server community XXXXXX RW 1
snmp-server community XXXXXX RO 1
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps envmon
snmp-server enable traps config
radius-server host 172.24.10.44 auth-port xxxx acct-port xxxx key 7
!
control-plane
!
banner exec ^CCC
Welcome to the Parametrix Albuquerque Router
^C
banner login ^CCC Welcome to the Albuquerque Router .  Please login.
^C
banner motd ^CCC
        >>>>>>>>>> WARNING <<<<<<<<<<
Unauthorized access to this system is a violation of the Federal Electronics
Communications Privacy  Act of 1986, and may result in fines of $250,000
and/or imprisonment (Title 18, USC).
^C
!
line con 0
exec-timeout 30 0
password 7 XXXXXXXXXXXXX
logging synchronous
line aux 0
password 7 XXXXXXXXXXXXX
logging synchronous
modem InOut
modem autoconfigure type usrmodem1
transport input all
autoselect during-login
autoselect ppp
flowcontrol hardware
line vty 0 4
exec-timeout 30 0
password 7 XXXXXXXXXXXXXXX
transport input telnet ssh
transport output all
!
scheduler allocate 20000 1000
ntp clock-period 17180099
ntp master 2
ntp server 140.142.16.34
!
end

17 Replies 17

Hello everyone,

I know this is an old topic but just had the same problem and tested everything posted on the internet without success. I also know my case might be a little different since I'm using all virtual devices. Anyways, wanted to share what did the trick for me.

I verified the device configurations and looked like everything was correct.

SSH v2 configured, RSA Key generated (2048) - this key value is important cause some devices do not seem to support 4096, i had the transport input and accept commands as well as the propper aaa configuration commands and no ACL configured on my device.

IP connectivity was also ok.

"show ssh" command showed multiple sessions being used and then checked my virtual lines using "show line" to display that all of them were occupied. Seems depending on your configuration (exec timeout 0 0 or such) and how and what are you connecting from, the lines  will / might not clear after timeout or simply wont time out.

Just clear your lines (clear line vty [X]) and that would do it for you.

Cheers!

This was absolutely helpful to me!  It was my entire problem all along, but did not see it.  Long story short, I started losing SSH access to my Core switch over a year ago.  I set up a work around (PC connected to it via console that I could remote in to), so has always been a lower priority since I have had access through my work around.  I searched and searched and read so many things about SSH not working on my 9400 switch, and everything was telling me to check the configuration - whether it be SSH, line vty, crypto, etc.  

Finally, after about a year and a half of not being able to SSH to my core switch, I found your comment here saying that there might be sessions still connected that never dropped.  Sure enough, after running "show ssh" I found 15 SSH sessions that never dropped (vty 0 4 and vty 5 15).  I went through and did "clear line vty [X]" one by one to remove all 15.  Thank you so much!

Review Cisco Networking for a $25 gift card