problem with remote login

[hanwucisco]

we use putty to login catalyst 3550. one of the switches recently doesnt let me login. this is the info given by putty:

"connection refused"

the user on the switch work fine.

what is the possible problem?

[Joe Clarke]

What protocol are you using to connect to the switch (i.e. telnet or SSH)? It may be that the protocol you are using is not configured on the switch, or there is an access-class list preventing you from connecting. Regardless of protocol, it could be that all vty lines are occupied. Try getting to the switch's console, and configuring more vty lines (if possible).

[hanwucisco]

thnaks,

we use SSH. it worked before. and now I can ping it.

When you say VTY is occupied, what is the possible reason? since I have tried many times. it is unlikely it is occupied by someone else for so long.

I worried about the RSA Key.

[Joe Clarke]

Connection refused means there is no listener on 22/tcp or that all the VTY lines are occupied. By occupied, I mean that there is a user logged into each available terminal line. If you get on the switch, run:

show line

Each VTY line with an asterisk ('*') beside it is occupied. You can clear those lines using the command:

clear line

You can also try to configure more lines using line vty 0-15. However, if all 15 lines are occupied, you will have to clear the lines before more users can log in.

[hanwucisco]

hi, Joe:

Please refer to the config below, we have many vty, and only 3 people can login, I am the only one that use the switch, how come they can be occupied?

as for tcp/22 how can i know there is no listener there?

tahnks,

H.w.

line vty 0 4

access-class 1 in

exec-timeout 3 0

password 7 xxxxxxxxxxxxxx

transport input ssh

line vty 5 15

access-class 1 in

exec-timeout 3 0

password 7 xxxxxxxxxxxxxx

transport input ssh

[Joe Clarke]

You have an access-class applied to these lines. What does access-list 1 look like? Is the host from which you are SSH'ing in that access-list?

[hanwucisco]

Joe:

Yes, the ACL let my computer in.

I always think about RSA, how do you think?

H.W.

[Joe Clarke]

A key problem would not result in a "connection refused" message. However, you could get a sniffer trace of the traffic to confirm what is going on during the TCP handshake. Typically, connection refused is seen when the client sends a SYN and the server responds with an RST.

If you've confirmed there are available VTY lines, and the access-list allows your client, and you are, in fact, seeing the RST, then you can enable debug ip ssh client on the switch (on the console), and see what's happening on the switch side. That will tell you if your TCP SYN is making it to the switch or not.

[hanwucisco]

thanks,

How do you do the sniff you said? please speak a little bit more,

thanks,

Han,

[Joe Clarke]

You can use wireshark (http://www.wireshark.org) on the client machine to capture a sniffer trace. Set your filter to:

host x.x.x.x and tcp port 22

Where x.x.x.x is the IP address of the switch.

[hanwucisco]

Joe:

thanks, I'll try that.

before doing it, I'd like to tell you why i am always thinking about RSA.

We have many cisco siwtches that are configured in same way. everytime, when i depoly a new switch, I have to execute the RSA command--crypto key generate rsa modulus

XXXX

if I forget, the syptom is the same as this, but this one, I did. it is just all of sudden, the problem happened again.

does this give you some thought?

thanks,

Han,

[Joe Clarke]

If the problem is happening sporadically, I suspect terminal lines are being exhausted. But without a debug from the switch and a sniffer trace, I cannot say for sure.

[hanwucisco]

Joe:

Sorry for the late reply. I've done the traffic sniffing. this is the result.

I change the configuration a little. 96.41 is my computer.

thnaks,

H

[Joe Clarke]

The TCP handshake is completing, but the client (your PC) appears to be dropping the connection after the switch sends the first data packet. This packet is usually the SSH header. Perhaps the switch is configured for SSH protocol version 2 only, and your client can only do protocol version 1. That is, the header is:

SSH-2.0-Cisco-1.25

But your client is expecting:

SSH-1.5-Cisco-1.25

or:

SSH-1.99-Cisco-1.25

In any event, your client acks this packet with a FIN in frame 6. Maybe there's some additional debugging you can do on your client.

[hanwucisco]

thanks, it is solved with your advice.