Ok, everyone knows how insecure telnet is. At least everyone who has been alive and involved with computers since the dawn of the 21st century. Its weaknesses are well known, and it has been consigned to near oblivion as a result. I know this, you know this, we all know this. And we all use ssh with key pairs when we need to initiate remote sessions over an internet connection as a result. Case closed.

But telnet remains around. It's available in Arch repositories, for example, and in Void's too. Probably all major Debian derivatives include it too (it's in the repositories for Ubuntu 14.04--the only Debian variant to which I have access at the moment). So it's still being used. I believe I've used it within the last 5 years for some sort of openwrt router administration tasks, for example. So there is a very limited range of scenarios in which telnet remains an appropriate tool: based on recent personal experience, one such use scenario is within the confines of a private LAN.

Which gets me thinking. I regularly need to access consoles on machines on my local LAN, and I'm not sure the added bother of using ssh authentication and private keys is justified for such a scenario. So I've begun considering whether telnet might not be a viable option for initiating remote shell sessions within this sheltered environment. It could be less complex than using ssh for that, since I could script some way of sending credentials. Heck, I could even make new accounts with new credentials and limited privileges on those machines, and use su to access a more privileged account once logged in there.

So, what are the hazards in such a scenario? Log-in credentials appearing in bash history is one. That could be a problem if someone were to gain physical access to a machine located in my domicile. Ok. I suppose another possible hazard would be someone penetrating my firewall and getting onto my LAN and snooping traffic there--another means by which credentials could be pilfered and other traffic captured. Or, someone local might defeat my wifi network's WPA encryption and similarly snoop traffic and pilfer telnet credentials and traffic. Those are the possible hazards I can think of.

What are some others? What other good reasons should I take into consideration for not running telnet on my private LAN in order to establish shell sessions between my local hosts? Input will be appreciated.

We run in on a lan that has no outside access on some older QNX systems. It was easier to isolate the lan then to try to redo everything.

Is telnet less than secure on a home lan? Well, maybe. The question may be how well the lan is secure by some UTM device or firewall. If you have left your lan vulnerable and most do then telnet is much more easily attacked. There are ways to minimize risk and that is all you really can do in every situation. Your risk level is the question here.

There are a few. Telnet console access from virtual host to guest is one, I also use the telnet protocol to for BBS access over internet, lthough that COULD be piped over SSH or an SSL tunnel. Also, maintaining ancient legacy servers that do nto support newer protocols.

I use the telnet CLIENT often, but use of telnet SERVER is pretty rare. There are some special cases where security just does not matter much.

I often use telnet to communicate with my virtual machines, if you don't care about the security then go ahead.

I wouldn't want to miss telnet if I have to test a connection. Telnetting to port 80, 25, 443, 587, 110 or 3389 shows me if there is "something" on the other side and if it is responding.

I do hope any further communication fails because of security, but to see there is a server alive on the other side is darned useful. It is better than a port scan, because a port scan shows a listening port, but it does not show if there is a responding server behind.

jlinkels

x3270 - been a while since I needed it, but was certainly this century.

You had me at EHLO ?

2 members found this post helpful.