Can telnet in from one account, not another

I have a strange problem. Slackware 2.0.30 kernel. From some accounts I have on this machine, I can telnet into itself fine, others connect, then immediately disconnect, as if a wrapper denied entrance. But why should it care if I am telnetting in from the account 'test' or the account 'mud'. test can get in, mud cannot. The reason this concerns me is that I have software that telnets into the machine automatically and runs a linux program automatically. The softwear, when telnetting in, is denied access, instantly drops connection. When I run telnet manually, and go in, it works. Using my program to telnet into my account at work, it works... seems it's being picky and denying whoever if feels like. I added ALL: ALL to hosts.allow... didnt do anything. Any ideas? Any hints?
LVL 2
edskeeAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

unicorntechCommented:
Remove the file /etc/hosts.deny. Do a kill - HUP (pid of inetd) and then try again. Also do a tail -f /var/adm/syslog and messages and see why the service was denied. This should then enable to track down the problem
0
edskeeAuthor Commented:
Tried that, didnt help. It's still disconnecting. syslog doesnt show anything, this is what messages shows:
Feb  6 07:44:39 ebonmists in.telnetd[776]: connect from mud@192.168.1.1

That's it. Disconnects. Connection closed by forigen host. Why would it care about the login name you are logged in under when accpeting a telnet request? This is really pissing me off. Might I have a bad copy of a tcp wrapper? Should I nuke the wrapper and just go with in.telnetd? What does the wrapper do besides denying access to someone I tell it to deny access to? I don't currently need to deny anyone, so it should be safe to lose the wrapper, right?
0
edskeeAuthor Commented:
Ok, I found the problem. I had a bad/old/bugged/whatever version of in.telnetd. I copied a copy from work overtop of it, restarted inetd, and it works fine now. Dont know what the problem was, nor do i care to know. It works, I'm happy. Unicorntech... re-answer it with something so we can close the question. Thanks for your help.
0
n0thingCommented:
In your scripts, program. If using csh do a "set TERM=vt100",
or Bourne Shell "set TERM vt100 export TERM". Or do it manually
on the command line and retry telnet to see if it still denies
you. My approach seems strange but try it. :))

Regards,
Minh Lai
0
alexbikCommented:
I know that you've already solved the problem, but take a look
at the shell that's installed for that account. Is it in /etc/shells? Some programs can be picky about that.

Alex

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.