Stop using Telnet to test ports | Hacker News Reader

Stop using Telnet to test ports

redhat.com

34 pointsrascul31 comments

> nc -z -v -w 5 raspberrypi 22

> telnet raspberrypi 22

No, I will keep using telnet over netcat. I’m not remembering and looking up those switches over and over.

If I’m automating port checks, I’m probably using neither. But if I want to check if something is listening then I can remember the telnet command and will use that.

That was my first thought. Both the bash and expect scripts seem more complicated than the equivalent Python.

expect requires me to know a fairly niche DSL, and the bash version requires me to remember a bunch of arcane info like the ability to make TCP connections by echoing into /dev.

I would push back on an MR with either of the first two. The bash+nc one I could live with, though.

You could just make a shell alias or wrapper script that would simplify the whole thing

Yes, certainly. But, for me, the reason I’m telnetting to ports is because I just want to check as a one off. If I check so frequently that I need an alias, I’ll use something else. So if I want a quick hack, I just need a quick hack.

Not sure why nc is that much better for me to tell if something is listening on a port.

You can just use "nc raspberrypi 22" as well; don't really need those flags.

I hate this clickbait title, especially since its trying to discredit valuable and useful tools.

Yeah, the third paragraph says (of telnet):

> This works perfectly fine, assuming you're testing only one service and one port

... which is what I'm doing about 99% of the time.

I usually don't use telnet just because it's usually (annoyingly) not installed any more, so I have to stop and try to remember how to do the same thing with nc.

"Stop using telnet" sounds like it's advocating to stop using telnet because of something that's wrong with it. The article actually is about writing scripts to do more complex things on top of telnet and other utilities.

While the content in the article is useful the title is misleading.

There IS something wrong with it - It's not the software the author likes, which makes not hating it a personal attack against the author.

Anything that is unencrypted by default has something wrong with it.

No machine I deploy has the telnet command present because I don't want to give my users free footguns.

In principle, yes. But if I am testing for open ports, does encryption really matter?

You forgot to encrypt your comment.

I've realised I feel like a total fish out of water when I've gone back to Windows this week (work...) and haven't got invaluable tools like netcat/netstat to test whether things are actually doing / listening to what I think they should be. Telnet seems to be the only obvious (semi-)OOTB option there.

What do people who end up doing haxxy dev work in windows do in these kind of situations (testing if ports are listening / open in Docker containers / WSL, listing out listening ports). It seems the tooling is often "Use this tool (telnet) in a hacky way", or "Download this horrible GUI".

Windows does have netstat, PowerShell has Test-NetConnection for testing port connectivity, and while I use puTTY I believe you can install telnet as an optional feature.

> What do people who end up doing haxxy dev work in windows do in these kind of situations

Windows has ping and tracert installed and working without administrative priviliges by default. Truly extraordinary feat many Linux distros are still not able to achieve.

And in my experience 99.9% network issues are debugged with the trio of ping/tracert/telnet.

I think CAP_NET_RAW is there for just about all linux distros now.

Yeah telnet just about does it, unfortunately not for UDP ports though, and still lacking a built in way to see what port is being held without grabbing procexp. It still feels like if you've got WSL sat there, thats still a much more capable place to mess about with this stuff (and this is coming from someone who spent the first half of their career building out Windows Server deployments).

I'm not going to stop using telnet to check ports when I just need to do a one-off, ad-hoc test directly from the command line. Too much muscle memory acquired around typing "telnet $host $port". But I DO use nc instead when writing scripts that need to test ports.

I borrowed the nc approach from one of the answers on this SO thread, which has some moderately interesting stuff in it:

https://stackoverflow.com/questions/4922943/test-if-remote-t...

No. I'm not writing a script to test an open port. netcat is prob the best alternative, but its also not installed by default.

Neither is telnet.

Telnet is installed by default in most distros.

Well it ain't in OpenSUSE Tumbleweed, Arch, or Gentoo. Though I don't know which software is installed out of the box in Fedora, Debian, the many Debian derivatives, and all of the smaller distros out there; so you may still be right.

Telnet is not in the default Debian or Raspbian installs either.

This is getting to be less and less true. `telnet MACHINE PORT` was my go to quick connectivity test for a couple of decades. And increasingly that's being replaced to me having to think about the right non-telnet way to do it.

I just use netcat, but that set off the security alarms at work once. SecOps messaged me and after they realized I was legitimate and not nefarious I never heard back.

I've been using "curl -v telnet://host:port" for some time now because it's more likely to be installed than telnet. Surprised it wasn't mentioned.

Stop using telnet… proceeds to show a script that uses telnet a the first 'solution'. Perhaps how to script health checks would be a better title.

This article just seems silly. As many have mentioned nobody is using telnet to check multiple ports (outside of a handful). If you need to "automate" checking ports, nmap has always been the tool. The choice between telnet and netcat has just been personally preference or availability.

I also hate the title of this article, really sick of seeing "Stop using X".

The title is correct but not for the same reasons as those mentionned in the article.

telnet was not made for UDP

Use netcat instead if you are not sure which one it is.

https://community.cisco.com/t5/switching/telnet-tcp-udp-port...

Title: Stop using Telnet

Text: For example: $ telnet raspberrypi 8086 [...] This works perfectly fine.

No, I will keep using telnet, thank you.

Actually I have already replaced Telnet with systemd

Reply on news.ycombinator.com