The Day the Telnet Died • Hacker News Board

Re: The Day the Telnet Died

#191

Post by anonymousiam » Wed, Feb 11, 2026, 5:06 AM UTC

For about 15 years beginning in 2003 I had some VPSs with CrystalTech/NewTek. I noticed right away that they had blocked all port 23 traffic in/out of their edge.

I asked them about it and they said it was a security measure. Apparently they used telnet for managing their routers.

It turned out that they did not have very good security anyway.

https://krebsonsecurity.com/2018/02/domain-theft-strands-tho...

I switched to A2 hosting shortly after the above incident, but I dumped them when they did not keep up to date on their Ubuntu LTS OS options.

I've been running on AWS for the past eight years. It costs more, but it's been extraordinarily reliable.

A2 and AWS do not restrict port 23.

Re: The Day the Telnet Died

#192

Post by [deleted] » Wed, Feb 11, 2026, 5:11 AM UTC

swinglock wrote: post #190

EE84M3i wrote: post #171

Earlier quoted context omitted.

I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?

Because it's there.

[deleted]

Re: The Day the Telnet Died

#193

Post by chenmx » Wed, Feb 11, 2026, 5:20 AM UTC

[dead]

Re: The Day the Telnet Died

#194

Post by degamad » Wed, Feb 11, 2026, 5:30 AM UTC

EE84M3i wrote: post #171

mmh0000 wrote: post #134

Earlier quoted context omitted.

netcat, socat and openssl s_client are all available for general manual connection testing. As are many other tools. But the ones above are basically far better direct telnet alternatives.

I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?

Because for a long time, on most computers, the telnet client was the closest thing to an "open a tcp socket to this ip/port and connect the i/o from it to stdin/stdout" application you can get without installing something or coding it up yourself.

These days we have netcat/socat and others, but they're not reliably installed, while telnet used to be generally available because telnetting to another machine was more common.

These days, the answer would be to use a netcat variant. In the past, telnet was the best we could be confident would be there.

Re: The Day the Telnet Died

#195

Post by breve » Wed, Feb 11, 2026, 5:34 AM UTC

trebligdivad wrote: post #24

Why are people still using telnet across the internet in this century? Was this _all_ attack traffic? (OK, I know one ancient talker that uses it - but on a very non-standard port so a port 23 block wouldn't be relevant)

telnet lambda.moo.mud.org 8888

Re: The Day the Telnet Died

#196

Post by its_magic » Wed, Feb 11, 2026, 5:36 AM UTC

db48x wrote: post #170

its_magic wrote: post #150

Earlier quoted context omitted.

Maybe the lesson here is to stop letting the GNU folks do things, if this is what they do. This is only one example of craziness coming out of the GNU camp.

GNU doesn’t provide labor, only organizational tools like mailing lists and whatnot. The projects that GNU supports are still run by individual volunteers. If you want it done better then please volunteer so that you can be the one doing it better.

I am the one doing it better. GNU software is slowly being deprecated on my system, starting with glibc.

Re: The Day the Telnet Died

#197

Post by prerok » Wed, Feb 11, 2026, 5:36 AM UTC

chenmx wrote: post #193

[dead]

I think it would be better suited to use the terms we use for natural languages. A natural language is dead when the last person who learned it as first language dies and are extinct when there is noone that would speak it at all.

In these terms, telnet has been dead for a long while, but it's extinct now.

Re: The Day the Telnet Died

#198

Post by breve » Wed, Feb 11, 2026, 5:36 AM UTC

RupertSalt wrote: post #19

Twisol wrote: post #5

> Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call. Does this impact traffic for MUDs at all? I know several MUDs operate on nonstandard Telnet ports, but many still allow connection on port 23. Does this block end-to-end Telnet traffic, or does it only block attempts to access Telnet service…

Most MUDs do not use Telnet. MUDs use plaintext TCP protocols that are accessible to a wide range of clients. The Telnet protocol is well-defined and not completely plaintext. There are in-band signaling methods and negotiations. Telnet is defined to live on 23/tcp as an IANA well-known, privileged, reserved port. MUDs do none of this. You can usually connect to a MUD using a Telnet client, but most players hate the…

> MUDs do none of this.

MOOs do.

Re: The Day the Telnet Died

#199

Post by fragmede » Wed, Feb 11, 2026, 5:47 AM UTC

virgulino wrote: post #169

Never mind telnetd. Tier 1 transit providers doing port filtering is EXTREMELY alarming. They have partitioned the Internet, and in a way that automatic routing (BGP) can't get around.

not to mention, filtering on udp vs tcp, which makes using anything else impossible. Not that I have one, but it's just a bit in a field, why filter on it?

Re: The Day the Telnet Died

#200

Post by fragmede » Wed, Feb 11, 2026, 5:48 AM UTC

acters wrote: post #177

mmh0000 wrote: post #134

Earlier quoted context omitted.

netcat, socat and openssl s_client are all available for general manual connection testing. As are many other tools. But the ones above are basically far better direct telnet alternatives.

If it's alright to be pedantic, anyone with programming knowledge can do the same without these tools. What these offer is tried and tested secure code for client side needs, clear options and you don't need to hand roll code for.

who's hand rolling code anymore these days though?