Hacker News Reader

Comment by abalashov | Hacker News Reader

Am I the only one who still thinks that telnet is a basic utility that should be installed on every system? It's a lot easier and more explicit to verify that a TCP listener is working using telnet than netcat and the like.

I know I'm living in a different and hitherto unimaginable universe when I paste modern cloud-devops sysadmin types the output of a hung telnet connection attempt to port 22, as implicit evidence that it's blocked by a firewall or whatnot, e.g.

    $ telnet 172.30.110.9 22
    Trying 172.30.110.9...
    ^C

and they say, "But it's SSH, so you can't use Telnet!"

... bro. I know it's a DeVry Cloud DevOps certificate, but...

View on HN

It is on every system, kinda (well curl usually is):

~ $ curl -v telnet://1.1.1.1:443

* Trying 1.1.1.1:443...

* Connected to 1.1.1.1 (1.1.1.1) port 443

~ $ curl -v telnet://1.1.1.1:22

* Trying 1.1.1.1:22...

^C ~ $

I didn't know curl could do that. Something new every day... thanks!

Having said that, in the world of my customers' systems, neither telnet nor curl can be presumed, it seems.

Me either until a few years ago. My mind was well blown!

Introduces more ambiguity in terms of replies, but you could also just use curl straight up:

~ $ curl -v 1.1.1.1:53

* Trying 1.1.1.1:53...

* Connected to 1.1.1.1 (1.1.1.1) port 53

* using HTTP/1.x

> GET / HTTP/1.1

> Host: 1.1.1.1:53

> User-Agent: curl/8.13.0

> Accept: / >

* Request completely sent off

* Empty reply from server

* shutting down connection #0

curl: (52) Empty reply from server

~ $ curl -v 1.1.1.1:22

* Trying 1.1.1.1:22...

Curl is not installed by default on Debian or Ubuntu. And if you need to apt install you might as well just apt telnet.

Your secops team might disagree

I dont really see how that is any different from netcat with -v option.

I will grant that it's a matter of taste and the prejudices of being O.G., but the subtle visual difference between:

   $ nc -v 172.30.110.9 22
   [literally nothing]

and:

   $ telnet 172.30.110.9 22
   Trying 172.30.110.9...

... has always struck me as significant, and pedagogically relevant.

I don't know. I still use telnet for things, but I can use nc in a pinch. I would be more inclined to wish for expect.

What I don't get is all the SSL kids never mention s_client, as in "...use s_client instead". Granted, most of the time ssl will work for, you know SSH (port 22). Are you really going to negotiate the cypher by hand, mate? I get it, how many of them can identify what "\x16\x03\x01" is?

How do you even test TCP listeners with telnet? Like how do you do an HTTPS handshake by hand. It doesn't seem practical in the modern world.

Not intended for such advanced situations, only ones where knowing that you're listening on 443 (or whatever) is enough.

You don't do a HTTPS handshake by hand. That's what openssl s_client is for.

https://docs.openssl.org/1.0.2/man1/s_client/

Or maybe socat, I don't use it but I'm pretty sure I've seen people use it.

You are proving my point that telnet is not useful in modern times.

Only if you're a web economy weenie and think HTTP[S] is the measure of utility of most TCP interactions. ;)

I can't remember the last time I used telnet to test whether a web server was live. I don't think web servers figure very prominently in the work I do, though not zero, for sure. However, I doubt I'm the only one in that boat.

Okay let's say you want to ping a Minecraft server and see how many users are online. That's not possible either with telnet.

The concept of protocols made up of printable characters delimited by new lines is antiquated.

But that's not what I want to do. I just want to know if the listening socket is bound.

Alright, let's say you try doing that but it fails for some reason. Where did the failure occur? Were you able to open a TCP connection but you received garbage data that your minecraft-ping command didn't understand? Were you able to open a TCP connection but you received no reply to your ping? Did you fail to open a TCP connection (no SYNACK in response to your SYN)?

All of those problems have different root causes and therefore have different solutions. Telnet helps you figure out where in the stack the failure is occurring.

Did you seriously just say "hitherto unimaginable"?

I did. In the century I come from, Telnet would never be confused for SSH.

Lol, these sorts of comments spark memories, one being at a telecom where our team basically was the incoming ticket Ops team for just about all other internal teams, we would often get tickets with the heading "Putty is down."

Always makes me chuckle whenever I remember that..

https://youtu.be/mpNn1nht0_8?t=219

Reply on news.ycombinator.com