Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

Post reply on HN
Print view View original

171–180 of 414 posts

Re: The Day the Telnet Died

#171

Post by EE84M3i »

mmh0000 wrote: post #134
AnonHP wrote: post #128

So Telnet as a client is not dead though, right? A long time ago, I used to use the Telnet client to talk to SMTP servers (on port 25) and send spoofed emails to friends for fun. With port blocking widening in scope, I’ve long believed that we would one day have every service and protocol listening on port 443. Since all other ports are being knocked off in the name of security, we’ll end up having one port that make…

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?

Re: The Day the Telnet Died

#174

Post by RupertSalt »

p_ing wrote: post #172
epcoa wrote: post #136

Earlier quoted context omitted.

telnet has never been in POSIX though.

It's a joke and a poke that macOS isn't certified UNIX as shipped.

https://www.opengroup.org//openbrand/register/

To actually pass the certification test suite on a real system, Apple sometimes needs to apply special configurations (e.g., disabling System Integrity Protection (SIP), using case-sensitive filesystem, enabling certain legacy services, etc.).

telnet(1) is not required by POSIX (nor is nc or ssh required!)

Ironically, telnet(1) did not begin as a "Unix" utility but an ARPANET protocol suite program. It was available cross-platform. It is unclear whether all editions of Unix included a client, but BSD for sure was the point where telnet and TCP/IP became essential integrations for the systems.

Re: The Day the Telnet Died

#175

Post by acters »

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.

So basically the same as censorship because that is the exact same thing blocking ports does.

Re: The Day the Telnet Died

#176

Post by varenc »

Since Tier 1 transit providers have now blocked telnet (port 23), this means the death of watching ASCII Star Wars with `telnet towel.blinkenlights.nl`

However, if you still long for nostalgia, I was able to access it over IPv6 using a VPN based in the Netherlands:

    telnet 2001:7b8:666:ffff::1:42
I'm sure the port 23 telnet blocking will be coming to IPv6 soon though.

Re: The Day the Telnet Died

#177

Post by acters »

mmh0000 wrote: post #134
AnonHP wrote: post #128

So Telnet as a client is not dead though, right? A long time ago, I used to use the Telnet client to talk to SMTP servers (on port 25) and send spoofed emails to friends for fun. With port blocking widening in scope, I’ve long believed that we would one day have every service and protocol listening on port 443. Since all other ports are being knocked off in the name of security, we’ll end up having one port that make…

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.

Re: The Day the Telnet Died

#180

Post by jmb99 »

its_magic wrote: post #139
tokyobreakfast wrote: post #121

Earlier quoted context omitted.

Two wrongs don't make a right. Apple still includes uucp for some unknown reason. The saving disk space argument makes no sense because telnet was one of the smaller binaries in /usr/bin. Telnet continues to be widely used for select use cases and being told we're naughty by not including it feels punitive and just adds extra steps. What are you supposed to do, trash a $1m piece of industrial equipment because Apple…

Ubuntu and derivates removing telnet from the default install, along with other basic tools like traceroute etc, was one of the driving factors toward me creating my own distro. I'm sick of basic stuff being omitted because somebody just decided it's not needed anymore.

How on god’s green earth is `sudo apt install telnet` sufficiently challenging to be a driving factor to creating your own distro??
Post reply on HN