For port checking I use `curl -v telnet://host:port`

> room designated was meadows and you could find herbs which would replenish over time

I'm sure several MUDs did this, but, this sounds an awful lot like my home MUD of Achaea, which started in ~1997, still exists (healthily!), and has this exact system :)

Were your MUDs on port 23? <runs and hides>

For Tiny* servers, "raw telnet" was considered a ghetto experience. The worst part was that the asynchronous output would just stream in whether or not you were done typing, and you'd invariably lose track of what your input line looked like. So the primary task of a TinyMUD client was to separate them. Some used a "split screen", and some just kept refreshing the input line as new output was displayed.

None of our MUDs ever appeared on port 23 and none of our servers ever spoke "The TELNET Protocol" as found in RFC 854. Telnet was simply the bundled TCP client that you could use for anything.

The other cool features for a MUD client was using macros to perform repeated tasks or say interesting things, and /hilite and /gag were indispensable. /gag silenced/muted a player or a pattern-match of your choice, and so to play with "raw telnet" was to unblock all your /gagged players and let them get under your skin again. A fate truly worse than death (well you got paid "insurance" for dying, so many people enjoyed the experience.)

Also popular in Tiny* clients was cursor line-editing and a command history. One client developer was sort of a troll, and so when he forked "tinywar" it began to feature some automation that could permit a player to make a real nuisance of themselves. But he was also a great programmer, and not all tinywar users were trolls, so it got put to good use.

Ultimately, Explorer_Bob wrote TinyFugue, and Ken Keys "Hawkeye" took over development, pushing it into amazing heights on a level with MUSH programming, and TinyFugue basically became the gold standard client for Unix and was also ported to Win32, and ultimately abandoned in an extremely stable state. I went to school with Ken. Miss you, man!

The last time I used Telnet was back in the late 80s for mostly CS class pranking, to remotely launch 50+ Xeyes Xwindows widgets on my class mate's Sun Workstation screens through a timed bash script. Watching them freak out as dozens of eyeballs suddenly appeared, while acting all innocent.

The only time I use telnet is when I'm building something with the socket API and want to make sure I did the setup/connection handover correctly so I make a quick echo server and connect over telnet just to confirm its working.

Surprisingly measuring legitimate Telnet usage may be even harder than measuring attacks! Getting representative metrics of benign src-dst endpoint pairs while controlling neither approaches impossibility, especially since at global scale it’d be mixed with (I suspect) orders of magnitude more attack traffic. Best you could probably do is measure on a clean-ish ISP like a university network.

Greynoise and others have shell companies and spin up exposed infra specifically to pick up scanning activity.

They have them all over the world to get attackers scanning only certain regions etc.

I should also note - I’m extremely skeptical of the OPs claims or inference that the attackers have potentially fingerprinted greynoises sensors. To suggest this while some traffic increased from specific ASN’s seems unlikely that this was the case.

If it’s not clear - this was written by a competitor of theirs.

This is a very challenging problem, especially if you don’t want to be over-concentrated on specific threat actors (as we suspect has happened here).

Instead, they chose a classic, yet timeless pop-culture reference: Mark Twain in 1897.

http://isabevigodadead.com/ [That's right, kids. There is no HTTPS server.]

The biggest remaining production use of telnet is IBM mainframe and midrange systems. tn3270 which is a telnet extension implementing support for 3270 block mode terminal data streams is still in widespread use, and there is also tn5250 which does the same for 5250 terminals (used on IBM i / AS/400)

This use case is perfectly secure, because IBM mainframe/midrange telnet servers support telnet-over-TLS, and that’s what people run in production

For connecting to mainframes, SSH has no real advantage over TLS, and its major disadvantage is that there is no standardised way to transmit 3270/5250 data streams over it

But people looking for telnet traffic over the public Internet probably won’t even notice this, because they aren’t looking for telnet over TLS - which is difficult to distinguish from whatever else over TLS - and because almost all of it goes over VPNs not the public Internet

You can wrap any TCP protocol in TLS which means every TCP protocol supports encryption, Telnet included. The app (and server) simply need to wrap their connections in TLS, which is trivial in many programming ecosystems.

And IMO, X.509 (used in TLS) is virtually superior over SSH’s bespoke certificate format in every way. You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want).

The main downside is that X.509 is more complex.

I had a similar question. I use ssh usually these days. Telnet has one thing going for itself though: simplicity.

SSH without proper key management offers marginal benefits compared to telnet.

Probably because ssh ciphers change, telnet doesn’t, and you’re not really supposed to be internet exposing those interfaces anyway.

Why use ssh when wireguard is available?

Tangentially, I saw an ad the other day for software which purports to encrypt your keystrokes: https://www.keystrokelock.com/ I have no idea what that means.