• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 251
  • Last Modified:

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?
0
edskee
Asked:
edskee
1 Solution
 
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

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now