

Telnet isn't the problem - madsushi
http://chasechristian.com/155/tech/telnet-isnt-the-problem/

======
lmm
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.

~~~
madsushi
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.

~~~
lmm
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.

~~~
madsushi
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.

------
howeyc
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.

------
TanningTour12
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.

~~~
TanningTour12
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" }

