Telnet isn't the problem | Hacker News Reader

Telnet isn't the problem

chasechristian.com

5 pointsmadsushi8 comments

Point by point. 1. Gentoo ships without telnet, and I call this good. And RedHat is probably the most respected OS around. I sure do have a problem with Ubuntu including telnet; kudos to MS for leading the way.

2. So get rid of FTP too, you'll get no argument from me on that point. HTTP is harder to do without, but at least it doesn't send passwords in the clear. Is the argument here meant to be "parts of the internet are still insecure, so there's no point trying to be secure"?

3. Irrelevant

4. Rarely. Telnet is not designed as a network testing tool, and there are better tools available for that use case. More to the point, anyone competent to use telnet knows where to find it. A tool that requires the user to be aware of the risks should not be in the default install.

1. While RedHat is respected, Ubuntu is very widely deployed as well and is the most common distro that I run into (in my own limited experience).

2. My point for 2 is that not all traffic needs to be encrypted. If there's no confidential or private data, why waste the CPU cycles?

3. I disagree. Having telnet available by default does not open any new attack vectors.

4. Telnet may not be designed for it, but that's how it's widely used. SMTP and port troubleshooting have been done with telnet for years, and quite successfully. I think there needs to be a balance between availability and protecting the user, and on a server OS, that line should probably lean towards availability since an advanced user is assumed. By your reasoning, the 'del' command shouldn't be available by default because an unassuming user might delete an important file.

2. Telnet is, fundamentally, a remote login protocol; it's been bodged into doing other things, but that's its primary purpose, and it should be obvious why that needs encryption.

And you're seriously worried about wasting cycles on encryption? Did I accidentally step through a timewarp to 1970?

3. Telnet being available opens the attack vector of "user uses telnet to log into a remote system, transmitting credentials in the clear". That's a big enough vulnerability that the fact it doesn't introduce any other ones is really beside the point.

4. Telnet isn't just a program that can be used to do something unfortunate. It's a program that does something unfortunate by default, if you try to use it in the obvious way for the purpose for which it is designed. It's a gun that comes with the barrel pointing out the bottom of the handle.

And I really don't see any decent use cases for it. There are better tools for network testing, and better tools for remote login. It's time for it to die.

Name one better tool that I can explain how to use over the phone to a non-savvy user running Windows.

I disagree that telnet is fundamentally a remote login protocol. In fact, telnet has no login parameters built-in at all, like SSH does. Telnet is simply a TCP communication program, any login functions are part of the remote telnet daemon and have nothing to do with the local telnet client. Telnet is a networking tool first and foremost, and the login portion is what has been added on.

I have to agree with this. The main use I have for telnet is checking that I can get access to an outside host:port from a locked down box I can't install anything on that is behind a firewall.

For example: "Hey, program N is having trouble connecting to XX.XX.XX.XX:YYYY, what's going on?" A ping and a quick check of "telnet XX.XX.XX.XX:YYYY" is very valuable when seeing if it's a firewall issue or something to check in the application.

Is there a replacement application I could use in the default install of windows to do the same thing? I really just need to verify I can get a TCP connection established to an outside address and port.

Right like I'm going to fire up an ssh session to an external lox and then run nmap to check for an open port on a remote server? Oh wait, I'll need putty. oh wait, I can't get out because my firewall has issues, ports are messy. Hmm should I find a way to get putty and different net connection to where I want? No instead now, I'm taking another 5 minutes to get telnet installed on the server. I guess the arguement that it will be more productive in the long term to get ssh going is valid but I prefer the simplicity and speed of running up telnet.

And for that matter if your answer is powershell then go ahead and type up this script in notepad and save it as a ps1, then configure powershell to run code while I telnet

:: powershell script try { $tcp=new-object System.Net.Sockets.TcpClient $tcp.connect("localhost",25) $tcp.close() } catch { "Exception occured" }

Reply on news.ycombinator.com