5 ms·

Stop using Telnet to test ports

34 points by rascul 4y ago

inferiorhuman 4y ago
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.
IronWolve 4y ago
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.
- fyver 4y ago
  Neither is telnet.
  - themoonisachees 4y ago
    Telnet is installed by default in most distros.
    - tmtvl 4y ago
      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.
      - HankB99 4y ago
        Telnet is not in the default Debian or Raspbian installs either.
    - jghn 4y ago
      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.
hitsurume 4y ago
I hate this clickbait title, especially since its trying to discredit valuable and useful tools.
- commandlinefan 4y ago
  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.
talonx 4y ago
"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.
- Suzuran 4y ago
  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.
- phone8675309 4y ago
  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.
  - talonx 4y ago
    In principle, yes. But if I am testing for open ports, does encryption really matter?
  - account42 4y ago
    You forgot to encrypt your comment.
galleywest200 4y ago
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.
egorfine 4y ago
Title: Stop using Telnet Text: For example: $ telnet raspberrypi 8086 [...] This works perfectly fine.
prepend 4y ago
> nc -z -v -w 5 raspberrypi 22 Vs > 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.
- everforward 4y ago
  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.
- phone8675309 4y ago
  You could just make a shell alias or wrapper script that would simplify the whole thing
  - prepend 4y ago
    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.
- arp242 4y ago
  You can just use "nc raspberrypi 22" as well; don't really need those flags.
bdavbdav 4y ago
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".
- AnIdiotOnTheNet 4y ago
  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.
- reisse 4y ago
  > 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.
  - bdavbdav 4y ago
    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).
_zoltan_ 4y ago
No, I will keep using telnet, thank you.
ihatepython 4y ago
Actually I have already replaced Telnet with systemd
mindcrime 4y ago
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-tcp-port-is-open-from-a-shell-script https://stackoverflow.com/questions/4922943/test-if-remote-t...
nightshift1 4y ago
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-ports/td-p/2690228 https://community.cisco.com/t5/switching/telnet-tcp-udp-port...
doubled112 4y ago
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.
commandersaki 4y ago
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".

34 points by rascul 4y ago

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.

IronWolve 4y ago

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.

fyver 4y ago
Neither is telnet.
- themoonisachees 4y ago
  Telnet is installed by default in most distros.
  - tmtvl 4y ago
    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.
    - HankB99 4y ago
      Telnet is not in the default Debian or Raspbian installs either.
  - jghn 4y ago
    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.

hitsurume 4y ago

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

commandlinefan 4y ago
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.

talonx 4y ago

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

Suzuran 4y ago
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.
phone8675309 4y ago
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.
- talonx 4y ago
  In principle, yes. But if I am testing for open ports, does encryption really matter?
- account42 4y ago
  You forgot to encrypt your comment.

galleywest200 4y ago

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.

egorfine 4y ago

Title: Stop using Telnet Text: For example: $ telnet raspberrypi 8086 [...] This works perfectly fine.

prepend 4y ago

> nc -z -v -w 5 raspberrypi 22 Vs > 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.

everforward 4y ago
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.
phone8675309 4y ago
You could just make a shell alias or wrapper script that would simplify the whole thing
- prepend 4y ago
  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.
arp242 4y ago
You can just use "nc raspberrypi 22" as well; don't really need those flags.

bdavbdav 4y ago

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

AnIdiotOnTheNet 4y ago
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.
reisse 4y ago
> 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.
- bdavbdav 4y ago
  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).

_zoltan_ 4y ago

No, I will keep using telnet, thank you.

ihatepython 4y ago

Actually I have already replaced Telnet with systemd

mindcrime 4y ago

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-tcp-port-is-open-from-a-shell-script https://stackoverflow.com/questions/4922943/test-if-remote-t...

nightshift1 4y ago

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-ports/td-p/2690228 https://community.cisco.com/t5/switching/telnet-tcp-udp-port...

doubled112 4y ago

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.

commandersaki 4y ago

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