Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dagrichards]

We are having intermittent "new telnet failed " errors trying to ssh to a HP9000.

I see in the logs on the HP that the users successfully login, but after about 30 seconds telnet pro comes back with  "new telnet failed ". Is there a regestry setting or some such I can use that will adjust up the timeout? I can get in with PuTTY when I can not with Telnet Pro .....

[jimn]

It's hard to tell what's going on, especially since it's intermittent. There are no timeout settings to set. It could be timing out, but I'd say it's more likely that for some reason Pro is not somehow missed the final packet(s) in order to complete the connection (as it appears the remote side got everything it needed to complete the connection).

Unfortunately, I don't know why it would happen, except as it's intermittent perhaps it's related to some kind of network congestion. 30 seconds should be more than enough time for the packets to reach their destination, if there're ever going to reach it.

I also don't know why Putty seems to always work, especially since Pro also uses Putty code for SSH connections. Unless you only try Putty after Pro fails and the problem is unlikely to happen twice in a row.

[dagrichards]

Users that experience this problem, are unable to log in pretty much ever.
So it does happen happen 2,3,4 time in a row.  It is restricted to users that use qicklink from Trizetto which fires off a menu shell.

If I get a couple of failures I then will try PuTTY, after that Telnet Pro _does_ work ..


Really no way to set a timeout?  PuTTY certainly waits longer, derived code or no.

[jimn]

If you are using a version older than about 5.1.16, you could update to the current version, as there was an upgrade to the SSH code at around that time.

[dagrichards]

This does not look like dropped packets to me, here is a dump of a failed login.
I tried again right afterwards and got in both dumps looked the same.

below the dump there is a snip from syslog.log

the version we are running is 5.1.25, is there anuthing more recent than that?

tcpdump: listening on em0, link-type EN10MB
13:55:37.009067 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: S 607750731:607750731(0) win 16384 <mss 1460,nop,nop,sackOK>
13:55:37.009911 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: S 3988621873:3988621873(0) ack 607750732 win 32768 <mss 1460,nop,nop,sackOK> (DF)
13:55:37.010427 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: . ack 1 win 17520
13:55:37.018406 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: P 1:21(20) ack 1 win 32768 (DF)
13:55:37.018796 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: P 1:43(42) ack 21 win 17500
13:55:37.054758 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: P 21:629(608) ack 43 win 32768 (DF)
13:55:37.210302 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: P 43:531(488) ack 629 win 16892
13:55:37.286365 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: . ack 531 win 32768 (DF)
13:55:37.286630 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: P 531:547(16) ack 629 win 16892
13:55:37.328464 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: P 629:909(280) ack 547 win 32768 (DF)
13:55:37.452028 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: P 547:819(272) ack 909 win 16612
Jun 22 13:55:38 fw0 isakmpd[23967]: transport_send_messages: giving up on message 0x3c069300, exchange carplink
Jun 22 13:55:38 fw0 isakmpd[23967]: transport_send_messages: either this message did not reach the other peer
Jun 22 13:55:38 fw0 isakmpd[23967]: transport_send_messages: or this is an attempted IKE scan
13:55:37.526343 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: . ack 819 win 32768 (DF)
13:55:37.568440 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: P 909:1501(592) ack 819 win 32768 (DF)
13:55:37.712620 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: P 819:835(16) ack 1501 win 17520
13:55:37.786430 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: . ack 835 win 32768 (DF)
13:55:37.786821 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: P 835:887(52) ack 1501 win 17520
13:55:37.787930 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: P 1501:1553(52) ack 887 win 32768 (DF)
13:55:38.005936 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: . ack 1553 win 17468
13:56:00.422319 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: P 887:955(68) ack 1553 win 17468
13:56:00.457522 rimer.ccchsd.gov.ssh > 172.16.4.230.64252: P 1553:1637(84) ack 955 win 32768 (DF)
13:56:00.646180 172.16.4.230.64252 > rimer.ccchsd.gov.ssh: . ack 1637 win 17384




Jun 22 13:57:37 rimer sshd[3305]: fatal: Timeout before authentication for 172.16.4.230
Jun 22 13:57:56 rimer sshd[3314]: Accepted keyboard-interactive/pam for cshelby from 172.16.4.230 port 64540 ssh2

[Bob]

Check to make sure your server is doing SSH version 2 first. We do NOT implement SSH verison 1 because of security issues in the V1 protocol.

In your sshd config file (usually /etc/ssh/sshd_config or /etc/sshd_config) check the protocol line, add this if there isn't one or uncomment or change it to the following if there is one (and restart sshd).

Protocol 2,1

Report back please.

[dagrichards]

Thanks for the reply but...
My ssh server is configured only for ssh2
And since the logs on all the "Telnet Failed" errors show a successfull PAM auth, this could not have been the error anyway.

A work around that I have found is to save the username and passwd in the user profile,
this of course makes the client not very secure, but does at least leave the transport encrypted.  What would be very nice is if we could use rsa keys and passwords, without a need for caching the auth info in the client.  

This issue is most definitely a client issue, perhaps even a bug. Take a look at the dumps I sent that show the traffic.  If you require more data let me know.

[Bob]

It only happens with the clients running an app automatically from the login? Interesting. What terminal type are you using?

[dagrichards]

The common thread seemed to be users running a menu from qicklink/trizetto/rims ( a vendor J. River seems to be familiar with ). However when I removed the .profile  that was calling the menu the problem persisted ... go figure.

We are using vt220 7bit, with a custom keymap that remaps F5.

[Bob]

Hmmm, I assume that you could follow the authorization dialog in the ascii part of your dump?
Is there any difference between the machines that work and the ones that do not?
You might want to turn up the sshd debugging level so you get more interesting stuff in the logs. I'm thinking that the timeout message may be after the fact of another problem and not really indicate the real trouble.

When Jim is back on Monday I'll discuss this more with him.