Telnet "Connection closed by foreign host"
 

Hello, I acidentally posted this in the newbie forums and then saw there was a networking forum!

I'm having problems trying to get my linux machine to accept telnet connections from any other type of machine. Whenever I try to telnet from a solaris or linux machine to the linux host machine I get a, "Connection closed by foreign host" and it returns me back to the terminal. I can Telnet/rsh/rlogin from any of the linux machines into the solaris box but the reverse can not be achieved.

On the linux machine this problem is easily solved by just using SSH, however I am unable to use SSH on the Solaris as the SSH client is not installed. On the Linux host I have telnet set to enable in my /etc/xinit.d directory and I even do a /etc/init.d/xinitd restart. xinitd is running as I can pull it out of top using grep. Any ideas as to why telnet is refusing connections?

Have you checked you /etc/hosts.allow?

In etc/hosts.allow I have "ALL : ALL : ALLOW" on the linux machines. And both .rhosts and hosts.equiv have "+ +".

At this moment I've given up on all security I can achieve between these machines in order to get this networking thing to work. Once I can figure out how to get it to work, then I can start messing around and tweaking them the way I need them to work.

Are you trying to telnet in as root or as a user? I seem to remember there is an extra setting (somewhere) about allowing remote root.

And what about your /etc/hosts.deny ?
Are you running SELINUX?

rhosts and hosts.equiv are not relevant to telnet.

Hmmm... I have no idea if it is or not. The "linux" machines right now are running off customized Gentoo live cds with various programs to help back up partition images on other systems. But after doing some searching, I can assume that they are.

There was no /etc/hosts.deny file. I figure that since it did not exist I did not have to create it like I did for /etc/hosts.allow

I Just got home so I won't be able to do much more but get ideas until I get back tomorrow.

On the linux machine that cannot be connected to via telnet, run:

telnet localhost

add show what happens.

Trying to telnet into machine that can not be telnet into I get...

Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
Connection closed by foreign host.

sounds like maybe the telnet server is not running.
to check run netstat -an |grep 23
you should see something like...
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
...port 23 being the telnet port
if you don't see it make sure you have it installed. if installed check your logs for xinetd errors concerning telnet.

I ran -an | grep 23 and I see

tcp 0 0.0.0.0:23 0.0.0.0:* LISTEN

So did less /var/log/messages | grep telnet and I got

Jun 26 15:41:01 sysresccd xinetd[8673]: Reading included configuration file: /etc/xinetd.d/telnetd [file=/etc/xinetd.d/telnetd] [line=68]
Jun 26 15:43:53 sysresccd xinetd[8743]: Reading included configuration file: /etc/xinetd.d/telnetd [file=/etc/xinetd.d/telnetd] [line=68]
Jun 26 15:45:46 sysresccd xinetd[8743]: START: telnet pid=8774 from=127.0.0.1
Jun 26 15:45:46 sysresccd xinetd[8774]: FAIL: telnet address from=127.0.0.1
Jun 26 15:45:46 sysresccd xinetd[8743]: EXIT: telnet status=0 pid=8774 duation=0(sec)

check /var/log/secure for telnet/xinetd messages
check iptables -L for firewall rule preventing telnet

There is no /var/log/secure

I did a find / -name 'secure' 2>results

and there was no lines written to "results"

I ran iptables -L and I got this for output

Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

I have no idea what any of this means, but I'm reading the man page right now trying to understand it.

No, telnet is running. Telnet output the messages:
The disconnect happens after this, and is due to a security configuration somewhere dropping the connection.

See if you have an /var/log/authpriv.

Disable telnet via xinetd. Restart xinetd.

Then, start telnetd manually on the command line, using the -debug option, and various -D options for debugging. See man telnetd on the options available for your telnetd for -D. Then make your connection and see what happens.

I do not have /var/log/authpriv.

I'm trying to start in.telnetd -D report (just as an example, I've tried all the options and get the same following result)

in.telnetd: getpeername: Socket operation on non-socket

Am I forgetting a flag or is this not what I want to run?

Please show the output of :

telnetd --help

I'm not sure which options your telnet supports.

You are starting telnet as root, right ?

Yes I am starting telnet as root.

telnetd --help has nothing listed. Bash also says there is no telnetd command. zsh thinks I meant telnet and tried to correct it to that. Also when I look up the manual for telnetd, it brings up the manual for in.telnetd.

Use the telnet command, of course, that is correct for your system. The point is, I'm trying to understand your telnetd's command line options.

Please don't interpret the results for me. Instead, copy and paste the command and its output.

Run your telnetd program, whatever its name, with the --help option.

"No, telnet is running. Telnet output the messages:"
Mr C - you are right - I thought of that after my post - my apologies to all.
That's why I veered off to a security related issue.
-Jim

Alright well, after running a which telnetd I've found nothing so I'm back to using /usr/sbin/in.telnetd

in.telnetd has no --help. But in its man the options are

telnet --help brings up
Sorry if this is beginning to get frustrating. I'm beginning to move into unfamiliar areas so I'll be mostly if not wholly, clueless.

lets see how telnetd is started..
more /etc/xinetd.d/telnet

change disable to no

I did before, it was disabled in an earlier post in order to try to start telnetd manually through the console. Changing disable = no and restarted xinetd brings me back to the original problem.

check /etc/services and make sure port 23 specifies telnet.
start in.telnetd -D report
...and see what happens when telneting.
you might also try capturing traffic for review
on host running telnetd try - tcpdump port 23 - before telnet attempt.

lkm01801 - we've already verify that telnet was running and responding - the data is there in the previous threads.

What we are trying to do now is find out why the telnetd is *closing the connection* already made. This is an access control issue, not a telnet not started issue.

jhilton - with telnet DISABLED in xinetd, try the following on a command line:

/usr/sbin/in.telnetd -D netdata -debug 9999

Does this startup telnet to where you can connect to telnet on another session as:

telnet localhost 9999

btw. don't use which as the definitive answer to where your commands might be - it only looks in your directories specified in your PATH, so commands that live in directories you normally won't have in your PATH won't be search (eg: in.telnetd). Use locate instead

locate telnetd

jlm01801 - start in.telnetd -D report does nothing as far as I can tell. in.telnetd -D start brings me right back to the console but there was no output.

in /etc/services telnet is listed as port 23.

This is the TCP dump I got from telneting, with it continuing for about 8 or so lines.
Mr. C - I just disabled telnet through xinetd and restarted xinetd again.

Yes, /usr/sbin/in.telnetd -D netdata -debug 9999 does start telnetd and it prompted me to the login screen! I just tried to login and it booted me off for not incorrect passwords... as well as a timeout.

Thanks for the advice on locate. Its one reason that I started this topic in the newbie forums as I am a newbie.

Excellent - you're on your way to debugging. Ignore the timeouts and password requests. We don't need to actually log in yet, as we're debugging just the ability of a local vs. remote connection.

Now, keep that manually-started telnet running, and from one of your *remote* (Solaris) machines, attempt to telnet as you did locally:

telnet remote_ip_here 9999

You are trying to see what happens remotely vs. locally.

It took me into the login screen on the solaris machine upon telnet as it did when I tried to do it locally. with the same results of not trying to be able to login. It also timed out after I left it alone for awhile.

Are you saying "on the Solaris machine, when I ran the telnet to the remote linux machine at port 9999, you received no request for a password" (different that when you tried locally on the linux box?

All this confusion would be eliminated if you just showed exactly the commands you try and their output (copy / paste), and then add your commentary.

Oh woops sorry.

On the linux machine I did /usr/sbin/in.telnetd -D netdata -debug 9999

Then on the solaris machine I entered telnet *linux ip address* 9999

On the solaris machine was able to connect to the linux machine through telnet and I was prompted for a username and a password.

The Linux machine closed the connection after being idle for a short time.

And this outcome is different that when telnet was started by inetd, right ? Those attempts failed previous, by now at least you are getting to the password connection dialog, right?

Yes, previously when xinetd handled telnetd I was not getting the password, or even the login dialogue. Now with telnetd being ran from the command line I am getting the password and login prompts.

Good. This proves the issue is with an authentication or access-control layer such as SELINUX, tcpwrappers (hosts.allow,deny), or pam, or and IDS, or fail2ban, or ?

You're going to need to determine how each of these is configured, and which one is causing the connection to be closed summarily from the server end.

FYI: you are aware of the Freshports for Solaris, where you can download a binary SSH package for your Solaris systems, right ? This is probabably a better choice overall.

Alright, thank you for all your help Mr. C. I'll take a look into all your suggestions and try to narrow it down, however I'm beginning to think it might be PAM.

I'll let my boss know about Freshports for Solaris, but however due to the nature of the network and the situation I doubt this idea will make it very far.

My Solution
 

I know this is an old post and I'm aware of the rules for reviving dead posts, but this issue appears to still be open and I have some information that might help.

When I had my telnetd running through xinetd, I confirmed that it was running by looking at the results of netstat -a.

I would attempt to make a connection from the same machine by doing:

It immediately failed with the following:

I checked my /var/log/messages and found the following:

I noticed in my /etc/xinetd.conf file, the default setting for the only_from configuration was localhost. I changed it to read:

I then restarted xinetd, and the connection finally made it through to login. I hope this helps somebody.

if: netstat -an |grep 23 (ok=LISTEN)
check System/Administration/Server Settings/Services/On Demand Services
make sure On Demand Service, krb5-telnet selected and running
if not, check/save then restart xinetd service

connection closed by foreign host
 

Attachment 21292

please help me what worng with my configuration