[lug] telnetd problem

[D. Stimits]

Chris Wade wrote:
> 
> So here's what happens:
> 
> I vpn in to work, get into a shell there and telnet back to my home
> machine's IP port 113.  Works ok, I get the 'Connected to...' message, type,
> get an error and am kicked out.  So that's fine... Then I try it from the
> laptop using SecureCRT and I get a flashing cursor, no introductory message,
> but I type and get an error and am kicked out.  So I guess that's normal,
> then I try it from dos (cmd) and get nothing but a cursor, doesn't show my
> keystrokes, I hit any key and return and I'm out.  So I suppose it's working
> from all three, just with varying degrees of communication.

It might not be an error, but since the identd daemon should be sending:
Escape character is '^]'.

A proper termination to a session would be something similar to:
0 , 0 : ERROR : UNKNOWN-ERROR

...I suspect that it is not working right. If this latter error message
does not show up on termination of the port 113 connection, then it was
xinetd or inetd that terminated the session, and not identd (which would
cause identd to fail). Even if it does not work right, it doesn't
guarantee auth port is necessary. You can test by temporarily
deactivating port 113 on the home box that has the sshd daemon. Assuming
you are using RH, run as root first a status check:
/etc/rc.d/init.d/identd status

Assuming it is running, then stop it temporarily:
/etc/rc.d/init.d/identd stop

Try your successful version again. If it fails to allow you in, you
found the problem. If it still works, there may be a flaw in my argument
which this does not test: It is assuming that it is necessary to run
identd from the sshd machine. My assumption is that your source machine
trying to connect to the linux machine can be made to fail or not fail
based on location, not on machine (auth requests can originate from
either end, without identd on the requesting machine...only identd
enabled machines will *respond* to auth requests...it is a two-way
street). If your client machine is not the same one during test of both
locations (and vpn might matter here, the vpn host port 113 could
respond differently than the other machine), then we can't guarantee
that the client end responds to identd requests. So also try the
reverse, though I'm not certain it will be any more than a subjective
clue: from the linux box, telnet to port 113 of the connecting sources,
see if things work or fail as before.

Before I confuse you with "maybe" suggestions, go ahead and give it a
try. I've wanted to turn on auth port in my Win 2k machine, but I've
never been able to figure out how to enable it. And the MS site doesn't
give the information. I suppose auth port requires one to pay for a
third party package on win.

D. Stimits, stimits at idcomm.com

> 
> Chris
> 
> > -----Original Message-----
> > From: D. Stimits [mailto:stimits at idcomm.com]
> > Sent: Sunday, October 14, 2001 8:39 PM
> > To: lug at lug.boulder.co.us
> > Subject: Re: [lug] telnetd problem
> >
> >
> > Chris Wade wrote:
> > >
> > > I use SecureCRT at work to telnet from Win2000 to my Linux
> > machine at home.
> > > I've got a cable modem at home with a hub going off to the
> > linux machine and
> > > two windows laptops, all with separate IP addresses.  So
> > picture Cable
> > > Modem, Hub, then the three branching off from there... I
> > would like to have
> > > the laptops plus one macintosh going through the hub to the
> > linux box to the
> > > cable modem, but that's another issue.
> > >
> > > When I try to telnet now from my laptop to the linux box,
> > using its IP, I
> > > get 'telnetd: getnameinfo' and connection aborted, while at
> > work it works
> > > fine.  Any obvious reasons why this would be so?
> > >
> > > Thanks,
> > >
> > > Chris
> > > _______________________________________________
> > > Web Page:  http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> > Minor possibility, I'm not familiar with what the errors would show up
> > as, but maybe it is an auth issue? From the location that works, is it
> > possible to telnet to port 113 of the target machine for cases that
> > work, but not able to do so from the location that fails? E.G.,
> > telnet 1.2.3.4 113
> > (if it allows connect, just type garbage and hit enter,
> > you've verified
> > auth is open)
> >
> > There's a good chance it has nothing to do with auth, but sometimes
> > things are set to require it.
> >
> > D. Stimits, stimits at idcomm.com
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug