Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

371–380 of 414 posts

Re: The Day the Telnet Died

#371
post #357

I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along. What I'd like to know is how the arguments get inter…

You passed '-f root' to login (a single long string). telnetd is likely passing '-f' 'root' to login (two arguments instead of one, whether this is because it creates two, or it uses the shell (which then reparses) I don't know). But '-f' is a valid option to login (man login): login [-p] [-h host] [-H] [-f username|username] ... -f Used to skip a login authentication. This option is usually used by the getty(8) auto…

I was reading https://www.offsec.com/blog/cve-2026-24061/, which implies that precisely that single long string passes through getenv("USER") in the attack. The mystery is how that single long string in telnetd becomes two separate arguments for login. execv or posix_spawn certainly won't do that. So either there's a version of /usr/bin/login that parses arguments in some very sus way, or there's a shell involved somehow.

Re: The Day the Telnet Died

#372
post #339

Earlier quoted context omitted.

I'm saying that 90% of these setups look like this (or do the equivalent thing manually): ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168... They have ssh, but no proper key management

Well, sure. You can turn off host key checking in ssh! But that isn't responsive to a point that (1) host key validation exists in ssh and (2) host key validation is on by default in ssh.

Their original comment was referring to people ignoring the warning banner and connecting anyway when the host changes. Not that it doesn't exist.

Re: The Day the Telnet Died

#373
post #345

Earlier quoted context omitted.

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

So you’re just changing which volunteers you depend on? That’s really productive of you. Thank you for your service.

[flagged]

Re: The Day the Telnet Died

#374
post #257

Earlier quoted context omitted.

That link goes to a page full of random garbage. No commits there to be seen. Apparently the owners of that website don't like my choice of user agent, and have decided to punish me accordingly.

Same here. It says please wait while verifying.

I just checked, and it's confirmed: I am definitely using a web browser. It seems my browser and this site have a different definition of web standards, however.

So exhausting to be surrounded by people with a paranoid, irrational fear of robots, who don't give a shit who they harm in their zeal to lash out and strike the evil bots.

Re: The Day the Telnet Died

#375

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.

This simply isn't happening, and we have the data to prove it: https://www.terracenetworks.com/blog/2026-02-11-telnet-routi...

Re: The Day the Telnet Died

#376
post #341

Earlier quoted context omitted.

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.

telnet hasn’t shipped with macOS since 10.12 Sierra, ten years ago. Debian also isn’t shipping telnet in the base install since Debian 11.

Thanks, sounds like a recent development. I don't use macOS, but on other peoples macOS computer it was always there, even when they are not developers. But it could very well be that these computers are ten years old.

I mean technically MS Windows 10 is ten years old, but the big upgrade wave to 10 only happened like 4 years ago, which is quite recently. Maybe that is similar to macOS users, I don't know that.

Re: The Day the Telnet Died

#377

Earlier quoted context omitted.

I would never ever install your distro for this reason alone. Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt. Removing the telnet client was, in part, a recognition that its complementary server was deprecated and unsafe. If everyone was transitioned to ssh and nc, [and custom MUD clients], why keep telnet around? Any software like this represents tech d…

> I would never ever install your distro for this reason alone. And you are? Completely mystified as to why you'd think I would care. I built this distro for me and my people, not you. That's the whole point. We're getting off this ride. > Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt. Not a subscriber to this religion. There is nothing about new softwa…

Well this is weird.

You talk about me, my, mine, my network, my computer. But you're promoting a "distro". That means you're distributing software. It's not yours anymore.

Attackers on a network will use techniques to "pivot". Once a "foothold" is established then they scan for other places to attack. They will indeed get inside "your" computer, or router, and then compromise your telnetd.

It comes back to the liberty of swinging your arms vs. the proximity to my nose. If your distro is connected to a network, then you're responsible and accountable for security issues that result. There are thousands of distro kiddies sending out their favorite flavor of Linux, but how many audited it like Theo de Raadt?

You don't seem to understand the CVE under discussion. It doesn't even affect telnet(1). Practically nobody runs telnetd(8) anymore since the introduction of encryption, ssh, and the like. MUD players use MUD clients. Network admins use nc(1). The reason "telnet" was deprecated is: it's just not really useful anymore without its complementary service. telnet(1) isn't inherently dangerous, it's just superfluous, and distros pretty much evaluated that it wasn't worth hanging on to.

As for "traceroute", I'm not sure it's "useless or dangerous", but it can be misleading and definitely superfluous. It is widely misinterpreted by novices trying to prove something about their WAN connectivity. It misrepresents network topology and doesn't work real good with modern equipment or protocols. It was a judicious decision to bundle it with network debugging tools, because not everyone needs to debug networks. Especially the ones who believe that they can.

I would say that any network debugging tool available is also useful to your attackers with a foothold. A "living off the land" attack will leverage your telnet client, will run traceroutes on your network, and they will use all the software cruft that you didn't uninstall! I am pretty sure there are distros that simply don't come with development environments, C compilers, or various interpreters anymore, and it is for this reason: they are not inherently insecure or vulnerable, but "living off the land" will weaponize them every time.

However, I must concede that your temperament and tone is well-suited to being a distro administrator. You remind me of Linus Torvalds vs. Andrew Tanenbaum, or Theo de Raadt vs. FreeBSD. Perhaps Scott Adams vs. the world. Carry on, good sir.

Re: The Day the Telnet Died

#378

Earlier quoted context omitted.

No. MUDs should never have adopted port 23 or port 22 or any pre-assigned ports. There is no "well-known port assignment" from IANA for MUD-type games or servers. The end of RFC854, the very last paragraph, states: https://datatracker.ietf.org/doc/html/rfc854 Port Assignment When used for remote user access to service hosts (i.e., remote terminal access) this protocol is assigned server port 23 (27 octal). That is L=…

> A MUD game could never be confused with managing the server where it runs What do you think of [], highlights: It is extremely tightly integrated with the system. Connections are handled by telnetd, and the interface is basically considered a shell by the system. MUD characters are treated as actual users by the system, with a UNIX username consisting of "m-" followed by the first 5 characters of their selected cha…

Well that's unique!

It is a horse of a different color when user logins are handled by telnetd itself. I would imagine that access could also be provided by ssh. I know of no MUD that supports MFA, public/private keys, and host certificates!

At any rate, as of January 2026, Mooix users are gonna have a tough time connecting on port 23/tcp. I won't say they've been wrong for using it until now, but they may find themselves forced to switch to ssh, or at least a 4-digit port number. And patch that GNU telnetd ASAP, man.

EDIT: Sad to say, please do not visit the website cited in this linked article. It is, how you say, squatted by purveyors of smut. It may be the case that Mooix is abandonware.

Re: The Day the Telnet Died

#379

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.

This simply isn't happening, and we have the data to prove it: https://www.terracenetworks.com/blog/2026-02-11-telnet-routi...

> The sky is not falling.

Great analysis, thank you!

New thread: Reports of Telnet's Death Have Been Greatly Exaggerated https://news.ycombinator.com/item?id=46980355

Re: The Day the Telnet Died

#380

Earlier quoted context omitted.

> I would never ever install your distro for this reason alone. And you are? Completely mystified as to why you'd think I would care. I built this distro for me and my people, not you. That's the whole point. We're getting off this ride. > Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt. Not a subscriber to this religion. There is nothing about new softwa…

Well this is weird. You talk about me, my, mine, my network, my computer. But you're promoting a "distro". That means you're distributing software. It's not yours anymore. Attackers on a network will use techniques to "pivot". Once a "foothold" is established then they scan for other places to attack. They will indeed get inside "your" computer, or router, and then compromise your telnetd. It comes back to the libert…

[flagged]
Post reply on HN