# Newbie Question: How to get telnetd working?

## abreuma

I'm a complete Linux/Gentoo newbie.  Just got Gentoo installed on a AlphaStation.  I already have sshd working and I know that "good".  I also know that telnet is "bad" but I'd like to get it working as a learning exercise.

I did

# emerge netkid-telnetd

and things seemed to go well.  When I try to

# telnet 127.0.0.1

-or-

# telnet <my local LAN address>

I get a "connection refused" message.

So I decided I had forgot the "rc-update" step like I had done to finish the sshd installation.  I haven't found an rc-update command that actually works with the telnetd stuff.  So I know it's me that's confused.

What did my emerge of netkit-telnetd do?

How is this daemon supposed to get started?

Is there a configuration file edit step?

----------

## j-m

You need to explicitly enable this in /etc/xinetd.d and start xinetd after. I strongly suggest against using telnet at all, SSH is much better and safer. If you absolutely need telnetd, then configure you firewall to only allow trusted IP addresses to connect. 

Note that this does not prevent password sniffing, so telnet is a very bad idea,  think twice.   :Shocked: 

----------

## nightblade

 *j-m wrote:*   

> telnet is a very bad idea,  think twice.  

 

True... but the original poster clearly stated that it is only "a learning exercise"  :Wink: 

----------

## bcmm

Telnet can be useful (and, I think, safe) behind a NAT firewall (port 23 not forward), on a network of Windows XP machines. XP comes with a telnet client (based on BSD's telnet I think?) but you need to install extra software for SSH.

What is xinitd and how do you start it? Is it sufficient to edit /etc/xinetd.d/telnetd and change "disable = yes" to "disable = no"?

Is telnet safe in the environment I described above?

----------

## jonnevers

the only real use for telnet anymore is for reverse engineering network protocols: telnet some.server.tld:25

that will initiate a terminal connection to a mail server and you can manually enter commands...

there really is no use learning anything from telnet, password sniffing is trivial using the daemon as it uses cleartext passwords. sure inside a NAT is fine, depending; it is not fine if you have an open Wifi access point for instance. (or any Wifi AP really...)

if you on winxp, using telnet instead of SSH is still not acceptable. if you are connecting to a SSH enabled host from a windows box, use PuTTY. PuTTY is a great SSH client for windows! it dosen't require an install either, it is just a barebones .exe to download.

----------

## bcmm

Ok, but maybe I might not want to download it either. And anyway, the XP boxes are here, behind the firewall.

Compatibility with stupid operating systems is a perfectly good reason to use telnet in a secure environment.

The other use is reading POP3 mail when there is no mail client installed...

----------

## j-m

 *bcmm wrote:*   

> 
> 
> Compatibility with stupid operating systems is a perfectly good reason to use telnet in a secure environment.
> 
> The other use is reading POP3 mail when there is no mail client installed...

 

Ad 1/ LAN is NOT a secure environment. Would you like to have your root password sniffed?   :Rolling Eyes: 

Ad 2/ For this one you need telnet client, not telnet server (daemon).

----------

## bcmm

1) Why is small LAN not secure (given that I try to stop the XP users from installing junk)?

2) You are right about the client/server point, I was following up jonnevers comment about protocol reverse-engineering.

----------

## jonnevers

 *bcmm wrote:*   

> Ok, but maybe I might not want to download it either. And anyway, the XP boxes are here, behind the firewall.
> 
> 

 

once you've used PuTTY you won't even bother to make the above theoretical situation anymore. one would be well advised to avoid telnet, it is obsolete tech that needs to be phased out ASAP. 

on a side note, i use PuTTY for the telnet sessions I do need to make, to legacy servers outside of my realm of influence. so get PuTTY, use it for all your terminal needs.

----------

## abreuma

I appreciate all the responses.  When I said I was a Linux newbie I should have also added that I'm not a unix person either.  Just picking up those skills now, or trying to.

 *j-m wrote:*   

> You need to explicitly enable this in /etc/xinetd.d and start xinetd after. 

 

Back to my education and what the emerge command did.  I sort of understand what rc-update was doing and how it configures my system to start some piece of new software when it boots.  But I'm not sure how to "start xinetd" if it's not via rc-update?  That's where I need the education.

Once I get telnet working I'll turn it off.  There's enough concern is this single thread to convince me that ssh is the way to go.

----------

## nightblade

 *abreuma wrote:*   

>  But I'm not sure how to "start xinetd" if it's not via rc-update?  That's where I need the education.
> 
> 

 

Check the /etc/xinetd.d/telnetd file. You will have to set:

```

disable = no

```

and then restart xinetd:

```

/etc/init.d/xinetd restart

```

Of course, check that you don't have any iptables rule that blocks connections to your telnet port.

----------

## abreuma

```

/etc/init.d/xinetd restart

```

And that's where things get confusing.  When I look in the init.d directory there is nothing that looks like 'xinetd' in there.  I suspect that's why I couldn't rc-update it either.  Does his my emerge went wrong somewhere?  Remember that this is an Alpha I'm working with.

----------

## j-m

 *abreuma wrote:*   

> 
> 
> ```
> 
> /etc/init.d/xinetd restart
> ...

 

Oooops, maybe it will work much better if you emerge xinetd...  :Very Happy: 

----------

## abreuma

 *j-m wrote:*   

> Oooops, maybe it will work much better if you emerge xinetd... 

 

Ok, so I did this:

# emerge netkit-telnetd

and got something, but it doesn't appear to be a telnetd daemon I guess.  So now I need to

# emerge xinetd

to get what I really need, right?

If that's the case I guess I need more education on how to choose the correct packages.    :Sad: 

----------

## enternaL

The "d" in "telnetd" and "xinetd" stand for daemon, aka server/service, so yes, those are the two packages you need.

----------

## Valhlalla

Everytime you use telnet instead of ssh it makes the baby Jesus cry.

----------

## nobspangle

because xinetd is not a dependency of telnetd you have to install it manually. Xinetd is an updated version of inetd which is a daemon used on unix systems to start other services. The advantage of this is that you don't need to have a load of pointless services taking up resources when you hardly use them. Xinetd listens to the ports for you and when you try to access one it starts that service.

After you have emerge xinetd you will be able to add it to your default runlevel with rc-update and start it with the init.d script. As well as changin the xinetd.d/telnetd file, you also need to edit xinetd.conf and change the line "only from = localhost"

And for all those people who say telnet isn't useful, I have a few boxes where I can access ssh from the net. On those boxes I have password login disabled, having telnet installed means I can login when I am on the same LAN without having to dig out the private key. Also telnet is handy for those situations when you update glibc and ssh stops working until it is restarted.

----------

## nightblade

 *nobspangle wrote:*   

> 
> 
> And for all those people who say telnet isn't useful, I have a few boxes where I can access ssh from the net. On those boxes I have password login disabled, having telnet installed means I can login when I am on the same LAN without having to dig out the private key. Also telnet is handy for those situations when you update glibc and ssh stops working until it is restarted.

 

Not to mention the possibility of using telnet on channels which are already protected by an encryption layer (eg: VPN) without adding further encrypt/decrypt overhead

----------

## BitJam

Telnetd may have its uses despite generally being a security nightmare.   But so might a tactical nuclear device have its uses, or a 50 mm machine gun.

The original poster said he was a newbie to Linux/Unix.   The posts saying that telnetd has its uses, although true, are very misleading.  It would be far better to just tell him it totally sucks, its a huge security risk and never ever use it.

By the time he has enough knowlege and experience to use telnetd safely, he can figure out for himself the few cases where it is useful.  In the meantime, it is best to let him know that using telnet or telnetd is like having unprotected sex in a whorehouse with a person whose gender you least prefer.

----------

## cirne

At work I have a firewall that is very restrictive in its outgoing connection policy; I can't connect outwards over SSH protocol (or any encrypted protocol, really, except for some HTTPS sites).  Occasionally I need to connect to my home server to find a file or look up some information, so I use telnet with single-use passwords.  Enabling telnetd does have its uses, occasionally.

----------

## j-m

 *cirne wrote:*   

> At work I have a firewall that is very restrictive in its outgoing connection policy; I can't connect outwards over SSH protocol (or any encrypted protocol, really, except for some HTTPS sites).  Occasionally I need to connect to my home server to find a file or look up some information, so I use telnet with single-use passwords.  Enabling telnetd does have its uses, occasionally.

 

The fact that your administrator is an idiot does not justify using totally unsecured protocols in general. A newbie definitely won´t be able to use OTPs at all, probably he does not even know what does it mean. I totally agree with BitJam.

----------

## BitJam

 *j-m wrote:*   

>  *cirne wrote:*   At work I have a firewall that is very restrictive in its outgoing connection policy; I can't connect outwards over SSH protocol (or any encrypted protocol, really, except for some HTTPS sites).  Occasionally I need to connect to my home server to find a file or look up some information, so I use telnet with single-use passwords.  Enabling telnetd does have its uses, occasionally. 
> 
> The fact that your administrator is an idiot does not justify using totally unsecured protocols in general. A newbie definitely won´t be able to use OTPs at all, probably he does not even know what does it mean. I totally agree with BitJam.

 

Also, wouldn't it be easier to run sshd configured to listen on port 23 instead of having to deal with one-time passwords?

----------

## j-m

 *BitJam wrote:*   

> 
> 
> Also, wouldn't it be easier to run sshd configured to listen on port 23 instead of having to deal with one-time passwords?

 

Hmm, I suppose that there is probably some application-level firewall that is filtering encypted protocols. Which either proves the fact that the administrator is an idiot who creates insecurity instead of security or the fact the all the content of the packets is being logged somewhere and those which cannot be decrypted are undesirable - and in such case using telnet seems as an incredibly dumb idea.  :Shocked: 

----------

## cirne

 *j-m wrote:*   

>  *BitJam wrote:*   
> 
> Also, wouldn't it be easier to run sshd configured to listen on port 23 instead of having to deal with one-time passwords? 
> 
> Hmm, I suppose that there is probably some application-level firewall that is filtering encypted protocols. Which either proves the fact that the administrator is an idiot who creates insecurity instead of security or the fact the all the content of the packets is being logged somewhere and those which cannot be decrypted are undesirable - and in such case using telnet seems as an incredibly dumb idea. 

 

It's the SSH protocol that's being filtered, not just the port.  Not even SSH on port 443 works.  In this case, I'm assuming it is indeed that they don't want encrypted data going outside the firewall, especially since protection of the sensitive data within the firewall is their primary motivator.

That being said, I don't really care that my packets are being logged-- I don't connect to an outside computer to try and hide things from my employer, and I don't transmit any private or sensitive data over the link, so I don't really care that much about someone viewing the connection.  But without the telnet/OTP combination I wouldn't be able to access my computer at all.

Other than that, I agree of course that using telnet access is definitely the least preferable of methods.

----------

