Telnet from HP-UX to red hat connects but no login prompt

[Snipor]

Guys/Gals,

I'm having a strange issue. I have looked online all day and just can't seem to find an answer. I have a red hat server with telnet capabilities. I am able to connect to it through telnet using the many other linux machines setting around and also 2 of the 3 hp-ux boxes I support. The problem I am having is with one of the hp-ux boxes. It connects as I verified in the linux server logs but all I get is:

Trying...
Connected to test2.
Escape character is '^]'.
Local flow control on


A login never comes up and it just hangs there. From what I can tell my /etc/hosts files are setup correctly on both machines. I am not using hosts.allow or hosts.deny. Again, all other computers are able to connect via telnet with no issues except for this one. They are all on the same ip network.

Yes I'm not a fan of telnet but unfortunately the company I work for doesn't upgrade very often and we are still currently using telnet in some places (I am working on weeding this out).

Any suggestions? Thanks in advance.



Knowledge is Power......

 

[Snipor]

I also meant to mention that when it connects to the server and hangs, the server shows it connected in /var/log/secure. On top of that it can telnet to other boxes without any problems.

 

[Snipor]

I am able to connect with rlogin by the way. So weird.

 

[Annihilannic]

Have you double-checked network settings between the hosts to make sure netmasks are identical, etc. and no funny routes are configured?

Next thing I'd try is to tcpdump the connection from the Red Hat side, both from a working and the broken HP box, then compare them and try and see where it goes wrong...

Annihilannic.

 

[Edcrosbys]

Does this happen from all hosts telneting to this server (when logging in as same user)?

My bet is that you are using (or have enabled) reverse lookup for hosts.deny or some sillyness and there is an issue of lookup. Try to put the ip and hostname in /etc/hosts on the telnetd server to see if it resolves the issue.

If that doesn't fix it, I would run telnetd in debug mode (I believe it's available on redhat). This should provide you more info about what it's doing.

In the event it doesn't work, it's always a great excuse to implement ssh!

 

[Snipor]

I've checked routes nothing out of the ordinary. SSH is enabled on the red hat machine but the client is a very old K570 unix box that does not have SSH installed and we are unable to get ssh for it. Also, we have another K570 with identical O/S and settings (except for ip address, but same netmask and so forth) and it can connect fine. In fact all other computers can connect to this machine via telnet if they wish.

I enabled debug mode on telnet and here is what I am getting. On the client machine that is not working I get:

Trying...
Connected to host.
Escape character is '^]'.
td: send do AUTHENTICATION
Local flow control on
td: recv do SUPPRESS GO AHEAD
td: send will SUPPRESS GO AHEAD
td: recv will TERMINAL TYPE
td: send do TERMINAL TYPE
td: recv will TSPEED
td: send do TSPEED
td: recv will LFLOW
td: send do LFLOW
td: recv will NAWS
td: send do NAWS
td: recv suboption NAWS 0 80 (80) 0 24 (24)

It sits right there. The server as I mentioned before does show it connected in /var/log/secure.

Now the other unix box that is working okay, this is the debug I get:

Trying...
Connected to host.
Escape character is '^]'.
td: send do AUTHENTICATION
Local flow control on
td: recv do SUPPRESS GO AHEAD
td: send will SUPPRESS GO AHEAD
td: recv will TERMINAL TYPE
td: send do TERMINAL TYPE
td: recv will TSPEED
td: send do TSPEED
td: recv will LFLOW
td: send do LFLOW
td: recv will NAWS
td: send do NAWS
td: recv wont AUTHENTICATION
td: send will ENCRYPT
td: send do ENCRYPT
td: send do XDISPLOC
td: send do NEW-ENVIRON
td: send do OLD-ENVIRON
td: recv suboption NAWS 0 80 (80) 0 24 (24)
Telnet TERMINAL-SPEED option ON
td: recv dont ENCRYPT
td: recv wont ENCRYPT
td: recv wont XDISPLOC
td: recv wont NEW-ENVIRON
td: recv wont OLD-ENVIRON
td: recv suboption TERMINAL-SPEED IS 9600,9600
td: recv suboption TERMINAL-TYPE IS "XTERM"
td: send do ECHO
td: send will STATUS
td: recv wont ECHO
td: recv dont STATUS
td: send will ECHO

host.domain.net (Linux release 2.6.9-78.0.8.ELsmp #1 SMP Wed Nov 5 07:10:44 EST 2008) (2)

login: td: recv do ECHO


So as you can see the faulty client isn't getting the "recv won't AUTHENTICATION" and so forth. I changed the name of the computer and domain for security purpopes.

Any ideas?

 

[Edcrosbys]

Did you check the reverse lookup of the host that isn't working from the telnetd server?

I would try another telnet client (ncftp, or netcat) from that client. I would also check telnet client patch versions (if they are similar). Can the Bad client telnet to other servers?

Here's my last snippet about troubleshooting telnet (or other inetd/xinetd daemons):

replace the in.telnetd line in your /etc/inetd.conf file with something like:
telnet		stream	tcp	nowait	telnetd.telnetd	/usr/sbin/tcpd	/root/bin/trace.telnetd

"/root/bin/trace.telnetd" is a shell script that looks like:
#!/bin/sh
exec strace -o /tmp/telnetd.trace /usr/sbin/in.telnetd
## End trace.telnetd ##

Then you need to make trace.telnetd executable and restart inet
kill -HUP $(cat /var/run/inetd.pid)

 

[Snipor]

Correct if I'm wrong but that script is for debugging telnet connection issues to a UNIX server. However, I'm trying to connect from the UNIX box to a Red Hat Server. I was able to enable debugging on the Red Hat Server and I posted the differences above. I've tested both rlogin and ftp and I am able to connect to the Red Hat Server using those protocols from the Unix client. Also, the UNIX client is able to connect to other machines without any issues using telnet.

 

[Snipor]

Also wanted to mention thanks for the ideas. I will look into seeing if there are differences in patch levels.

 

[Snipor]

Apparently NAWS stands for Negotiate About Window Size and is nothing more then a way for the client to tell server the window size. For some reason though, after sending this information it never receives a response. It just sits on it as can bee seen here:

Connected to host.
Escape character is '^]'.
SENT do SUPPRESS GO AHEAD
SENT will TERMINAL TYPE (don't reply)
SENT will TERMSPEED (don't reply)
SENT will LFLOW (don't reply)
SENT will NAWS (don't reply)
RCVD do 37 (reply)
SENT ??? 37 (don't reply)
RCVD will SUPPRESS GO AHEAD (don't reply)
RCVD do TERMINAL TYPE (don't reply)
RCVD do TERMSPEED (don't reply)
RCVD do LFLOW (don't reply)
Local flow control on
RCVD do NAWS (don't reply)
Sent suboption NAWS 0 80 (80) 0 24 (24)

As you can see we are indeed connected. But the client is waiting for something.

 

[Snipor]

We still haven't found a solution for this. I noticed looking at the debug I posted above that the NAWS is okay, it's just never getting the Telnet TERMINAL-SPEED option ON part. Any clues why this might happen?

 

[Snipor]

I managed to install OpenSSH on HP-UX 11i (B.11.00) and it works fine.

 

[Snipor]

For documentation purposes here is the link I created in HP's forums documenting how I installed OpenSSH on older version os HP UX like what I have. HP doesn't supply their version of OpenSSH (SecureShell) for any Unix operating system below HP-UX 11iv1 so this documentation was needed.

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1310616