Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

241–250 of 414 posts

Re: The Day the Telnet Died

#241

Earlier quoted context omitted.

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…

You don't even need netcat or socat for that, probing /dev/tcp/ / from the shell is enough.

That's some gnu bash shenanigans. There is no /dev/tcp in unix

Lots of shops didn't have gnu installed: telnet was what we had.

Re: The Day the Telnet Died

#242
post #197
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.

Even that's argued within linguistics. There are languages which survive for generations as secondary languages (especially trade languages as Swahili or Chinook Jargon appear to have been originally). Also some like Latin, Hebrew and Sanskrit which survive for centuries but not as native languages.

Re: The Day the Telnet Died

#243

Earlier quoted context omitted.

Because it's there.

It hasn't for the most part of the last 2 decades.

The telnet client comes with MS Windows, Linux and macOS. The only platforms were you need to install some extra component are Android and iOS.

Re: The Day the Telnet Died

#244

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)

Hams use it over packet radio sometimes since encryption is forbidden on the amateur bands. IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.

You can use ssh with the None cipher, thus disabling encryption entirely while still using the rest of the protocol.

Re: The Day the Telnet Died

#245

What an amazing bug. I probably spent my first 10 years on the internet just using telnet. They were wild times. You could log ethernet traffic and see passwords. Towards the end of those we started to have a few more single-user machines, but the vast majority were old school many many user machines, where "root" was thought to be tightly restricted (of course, even then, in practice it wasn't if you were in the kno…

Never used telnet to log in to something but it is a cool debugging tool, so used it for that. E.g. can this container even send traffic to that container at all.

Re: The Day the Telnet Died

#246
post #215

Earlier quoted context omitted.

?

because it reads like claude output? and also the pattern: > The most interesting thing here isn't the CVE… This is what mature security… > The most interesting finding isn't that hyperbolic growth… This is Kuhnian paradigm… both comments in the last 24h

Whatever the AI, the point is valid and I had a similar train of thought reading TFA. This comment section took a different turn but hey, what can be used for good can be abused for bad. Gee whizz!

Re: The Day the Telnet Died

#247
post #235

Earlier quoted context omitted.

There's no UNIX requirement for telnet. Ubuntu does not include it by default (starting 16.04?). Most most distros don't.

Netcat works as a telnet client. GAWK can do that too with a dumb loop. So can con(1) under 9front.

Using netcat results in showing Unicode replacement symbols, instead of answering to telnet options. I doubt it implements telnet at all, because this is just not its job.

Re: The Day the Telnet Died

#248
post #61

It's nice to not see C being blamed for once! ... Just good old lack of reasoning (which is most C's codebase downfall, agreeably).

Argument injection can happen in any programming language where you can concatenate strings and call something with the result.

Re: The Day the Telnet Died

#249

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.

Port 23 has been filtered by most providers for decades.

This is why everything converges on using TLS over 443 or a high port number. I don't see this as a huge deal, and especially not one deserving all caps rants about censorship. Save those for things like FOSTA/SESTA.

Re: The Day the Telnet Died

#250
post #177

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.

You can program without tools? I want to see that. Do you still have switches to alter RAM content, or do you use the butterfly method?
Post reply on HN