edskee
asked on
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?
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
ASKER
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?
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?
ASKER
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.
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.