Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I am having difficulties telnetting into my Redhat Linux server from other machines. After hanging up on "connecting to 188.8.131.52..." for a few seconds, it completes the error message by adding "could not open connection to the host on port 23: Connection failed".
Telnetting outwards from the Linux server (e.g; to a Solaris server) works fine. Yet still, telnetting from the Linux server to itself (127.0.0.1) is not working properly. It returns with the login prompt, but on authentication it returns with a "password incorrect" message although I am certain I put in the right password.
Location: Somewhere inside 9.9 million sq. km. Canada
Distribution: Slackware 14.1, 14.2
Do you have the telnet daemon running? Do a command 'ps aux' and look through the output for telnetd.
Next I would highly recommend you install and configure Openssh. It should be available as a rpm for redhat. Telnet is totally not secure, and few if anyone uses it anymore. SSH is secure, can be set up with keys for login. If you look in the Tutorial section under Networking on this board, you will find tutorials on how to set this up.
My personal preference is to install Webmin, also available through rpsms, a web based tool to configure and manage a server. It allows you to connect to a server using a standard web browser through port 10000. On the server you open your browser, and type https://localhost:10000 to connect to webmin. You can set up users, or configure as root. It provides a graphical interface, and much easier way of configuring, starting and stopping various servers. I use it to configure ssh, samba, printers and network settings on my machines. For a noob, this can help save a lot of frustration.
It sounds like you have more than one obstacle in the way, here.
The TCP connection is probably being blocked by iptables. If you post your output from 'iptables -L -n', here, we can probably identify the rule(s) that are blocking telnet traffic. Also, the telnetd daemon is probably misconfigured for your situation. If you post the contents of the telnet service config file, possibly in /etc/xinetd.d/telnet, someone here may be able to identify the changes required.
Finally, it is considered good practice these days to not use telnet. All of the functionality of telnet, and more, is provided by ssh, and is much more secure. Same goes for ftp (use sftp or scp). If the machine in question is internet-accessible, please consider disabling the telnetd and ftpd daemons. A vulnerable Linux host is a hazard to everyone that uses the net.
No attachements here. This is not e-mail. Just cut and paste into the edit window. Use the 'advanced' button, which makes it possible to paste things in a 'code' box for easier viewing of plain formatted text, like this:
flags = REUSE
socket_type = stream
wait = no
user = root
log_on_failure += USERID
server = /usr/kerberos/sbin/telnetd
disable = no
I suggest disabling the kerberos encrypted version, and enabling the plain telnet version, at least to test the connectivity. If your telnet client is not kerberos enabled, maybe it is why you can't log in.
To camorri: The telnet daemon is not run directly like many other network services. It is under an umbrella daemon, xinetd. When a request for a connection on a port known to xinetd is received, xinetd dispatches the function it understands to be responsible for serving connections on that port. For port 23, the standard telnet port, it dispatches the telnet server, or else the krb-telnet server, depending on what is set up in the xinet.d directory. That is why there is no process showing up in the output of ps -aux.
I geuss it might be worthwhile explaining some details about how to enable/disable services launched by xinetd. You must first edit the appropriate file(s) in /etc/xinetd.d/. Then, find the PID of the xinetd daemon, with ps -e | grep xinetd.
Finally, restart the xinetd daemon, with kill -1 PID_of_xinetd
Thanks to both of you, SSH was already installed on the server and I have it working now, after downloading the SSH-client for the Windows platform--putty.exe. Regarding the webmin also, I have some success---It is running fine locally, but does not connect from a remote host.
I would still like to find out why the telnet is not working as a learning point on IP configuration, if not for any other purpose. PLease see the out put from the iptables -L -n command below:
This is a diagnostic, only. If it allows telnet to operate, then it is an exercise left for the reader to correctly modify the firewall script (possibly in /etc/init.d/iptables + /etc/sysconfig/iptables-config) to permanently add the rule. Look for the rules that open up ports 80 & 22, and add another for port 23.
In any case you should probably remove the diagnostic with