What To Do: Users Still Wants Telnet

Posted on in Categories CentOS, fedora linux, GNU/Open source, High performance computing, Howto, Linux, package management, RedHat/Fedora Linux, Security, Ubuntu Linux, UNIX last updated August 26, 2008

TELNET ( TELecommunication NETwork ) is a network protocol used on the Internet or local area network (LAN) connections. It was developed in late 60s with RFC 15. Telnet is pretty old for login into remote system and it has serious security problem. Most admins will recommend using Open SSH (secure shell) for all remote activities. But you may find users who are still demanding telnet over ssh as they are comfortable with Telnet. Some users got scripts written in 90s and they don’t want to change it. So what do you do when users demands telnet?

The problem with telnet

Telnet sends everything in clear text format including username and password. You can use tcpdump or snoop to see all information.

Secure telnet

You can install Kerberos enabled telnetd. Discussion related to Kerberos and secure telnet is beyond the scope of this blog post but I do recommend Kerberos Infrastructure HOWTO for further information. Following packages under Debian will install secure telnet including Kerberos server:
# apt-get install krb5-telnetd krb5-clients
CentOS / RHEL / Red Hat / Fedora Linux user need to install package called krb5-workstation:
# yum install krb5-workstation
You need to configure Kerberos server and Kerberos enabled telnet / ftp. Please see the man pages for further information.

Bottom line: migrate users to ssh

I highly recommend migrating your users to SSH and discarding telnet, ftp and all r* services. First, you need to educate users about telnet and insecure protocols. Once user(s) made aware of the problem, help them to migrate to SSH:

  • Disable telnet and force to use them ssh based tools
  • Explain basic ssh syntax
  • Explains password less login
  • Explain how to use ssh in scripts
  • Explain how to use sftp instead of ftp client
  • Explain how to use scp instead of rcp client

Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin and a trainer for the Linux operating system/Unix shell scripting. He has worked with global clients and in various industries, including IT, education, defense and space research, and the nonprofit sector. Follow him on Twitter, Facebook, Google+.

11 comment

  1. At a certain establishment, it’s not only telnet, but rsh, rcp, and the lot, which are SOP. Much more use of rsh than telnet as it’s “more convenient” with passwordless authentication based on trusted hosts.

    As ssh + ssh-agent offers passwordless authentication, the primary objection to switching from rsh is mostly mooted. Note that users on legacy MS Windows systems are going to have to work through some cruft to get a key agent up, but these aren’t likely to be your power users anyway (most of our ssh/rsh activity is ‘nix-to-‘nix, and in fact I don’t believe we’ve got an rsh client for Windows, but use PuTTY instead).

    There are two specific advantages of ssh over rsh which will go a long way to convincing at least more technical users to buy into ssh:

    – rsh requires two low-numbered (1-1024) ports for each outbound connection. This limits the number of remote hosts which may be accessed by all users at any one time to something less than 512 (as other ports are almost certainly already in use for other services). In a large farm environment and/or with many users it is pretty easy to exhaust this resource.

    – ssh returns the exit value of the last-run process in a list of commans. So that if you run “ssh remotehost ‘uptime; true'” you’ll see $? equal to 0. “ssh remotehost ‘uptime; false'” will return 1. This is very useful in running scripts, particularly to many hosts.

    On the downside, you may want to set the option “-o ‘StrictHostKeyChecking no” to avoid having to validate (or override) several hundred host keys on first access. If your site uses poor host key management practices (e.g.: frequently regenerates hostkeys), you may want to clear out your ~/.ssh/known_hosts file periodically (which really isn’t a good idea, but may be a pragmatic necessity). If anyone reading this has a good host key management system, I’d be interested in hearing it.

    – Karsten M. Self

  2. You didn’t mention that setting up Kerberos is a major undertaking and likely requires at least one or two independent servers and affects your entire infrastructure…

    You also didn’t mention the use of SOCKS and SOCKS clients (like telnet, for instance).

    I would hypothesize that setting up SOCKS is a lot simpler than setting up Kerberos.

  3. Why would you even try to accommodate a user that wanted to run such an out dated and un-secure application like telnet? It’s the job of IT admins to SECURE their operations, not bow down to the whim of ever mis-informed or completely out-of-date user. Say “no!” and move on.

  4. Skippy: In practice you are absolutely correct. In reality…that’s another matter. It is the job of IT people to try to secure their networks, but when it’s taken out of their hands by others (read: boss) for various reasons (read: $$$) then there isn’t much we can do.

  5. I don’t like to be critical, but I must say that this article is very MS like. “What to do when you need X. Install X.” WTF? Why do your users need telnet. Anyone who needs to use telnet should be smart enough to learn to use ssh.

  6. I would have to agree with VonSkippy and Winter. If users wants telnet, it is the responsibility of system administrator to put the foot down and say NO. Also, it is very important to educate both users and boss about the problem with telnet.

    Typically, in an organization, once you raise your concern on a security issue to the top management, most of the times, they’ll support you, as they’ll be held accountable, if some breach happens because of that particular security issue you have brought to their attention.

  7. How about telling the user and the approving manager about the incidents who have happened due to insecure telnet?

    If they still require it and email you back, then I would go ahead and do it.

  8. What I’d probably do is set up a nice little demonstration for the person demanding telnet and show them how everything they do can be read by anyone. Maybe even have them login and change their password and then read them back their new password. But of course, if you could do and get away with that would depend on where you work.

    It seems to me that while the more technical of us understand the need of things like encryption, that’s not something the less technical users see. They can’t see their data being transferred in the clear, so why would anyone else? After all, if they can’t see it, it must be secure. Hence, a nice little demonstration might be in order to show them what’s actually going on and how horribly insecure telnet really is.

  9. I don’t see resistance to ssh for user’s home or work computers, the problem arises when users travel and want to run from computers they can’t install software on. We have had mostly good luck with the Mindterm ssh client, which runs (as a Java applet) on a web page. There is more information here:


    but evenso, there are some browsers with Java not available. We haven’t yet found anything in Javascript, which would be even more widely available.

    I would also note that using kerberized telnet, or rsh with agents won’t protect plaintext passwords in the datastream, as when the user logs into another machine during a telnet session.

Leave a Comment