What? Whaddya mean refused?
Yup, this is what I struggled with for the last couple of days and I wanted to save other people some brain damage, so here goes:
line vty 0 4
login local
logging synchronous
exec-timeout 5 0
transport input ssh
ip ssh version 2
crypto key generate rsa general-keys modulus 2048
So that's the basics for the config. No ACLs on the line (removed them for troubleshooting). So I did the usual increase logging level, debug ip ssh, yadda yadda. Ended up opening a case with Cisco. Here's the "Ah ha!" moment that I didn't even consider:
router#who
Line User Host(s) Idle Location
* 0 con 0 root idle 00:00:00
vty 450 idle 7w5d x.x.x.x
vty 451 idle 6w5d x.x.x.x
vty 452 idle 6w0d x.x.x.x
vty 453 idle 5w5d x.x.x.x
vty 454 idle 5w2d x.x.x.x
Yikes! These sessions never exited or were torn down. So to test I added line vty 5 and was able to login so now I had proof that I simply had all of my vty sessions tied up. Clearing them was a bit tricky as you'll see later. I took over managing this system a while back and the WAN is typically one place in your environment where very few changes are made. Apparently the ISP had been logging in because the IP addresses in x.x.x.x were not any of my public IPs and the vty lines did NOT have any session timeout or exec timeout (I added that). For this reason, I didn't even think to check if any sessions had been opened! So the part that was very strange, however, is the naming of the lines as '450', '451', '452', etc. Trying to clear those lines resulted in
% 450 is an illegal line number [OK]
I have always just seen them as single digit line numbers unless you have lines defined 10-15. Anybody else seen that? In any case, clearing the lines by the single digit 0, 1, 2, etc. still worked. Problem solved.
Hope that helps someone else.
