Comments on: What To Do: Users Still Wants Telnet

By: Planet Malaysia

Planet Malaysia — Wed, 03 Sep 2008 03:40:25 +0000

I had the same issue. One of my customer using scanner login via telnet.

By: Rick

Rick — Mon, 01 Sep 2008 17:06:37 +0000

Couldn’t you enable IPsec for telnet connections? That would cover any issues on the LAN.

By: Daniel Feenberg

Daniel Feenberg — Sun, 31 Aug 2008 13:22:03 +0000

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:

http://www.appgate.com/index/products/mindterm/

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.

By: thegopher

thegopher — Sat, 30 Aug 2008 01:39:09 +0000

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.

By: Nagendra Pratap Singh

Nagendra Pratap Singh — Fri, 29 Aug 2008 06:52:32 +0000

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.

By: Ramesh @ The Geek Stuff

Ramesh @ The Geek Stuff — Fri, 29 Aug 2008 02:37:33 +0000

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.

By: Winter

Winter — Thu, 28 Aug 2008 00:49:45 +0000

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.

By: Tim

Tim — Wed, 27 Aug 2008 10:49:26 +0000

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.

By: VonSkippy

VonSkippy — Wed, 27 Aug 2008 03:25:08 +0000

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.

By: David

David — Tue, 26 Aug 2008 19:11:34 +0000

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.

By: Karsten M. Self

Karsten M. Self — Tue, 26 Aug 2008 16:23:17 +0000

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
http://linuxmafia.com/~karsten