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)
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)
To watch Star Wars in ASCII.
telnet towel.blinkenlights.nl https://www.youtube.com/watch?v=Mhcf6tc2jeQ
(Remember hearing about this a long time ago (from some searching I think it was in 1999 via Slashdot) and verified some instance of it still exists/works.)
It might be the telnet filtering in action. The host responds to ping but I get nothing back on TCP/23, not even a reset.
It's still working over IPv6
~~IIRC the blinkenlights telnet movies have been offline for a few years already.~~
I connected a few times today to the IPv4 one. Have had no problems myself.
Telnet is used in legacy, IoT, embedded, and low-level industrial hardware. It's also intentionally enabled on devices where automation was written for telnet and it wasn't easy to switch to ssh.
If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around the host keys constantly changing. Without host key verification, there's kinda no point to the rest.
Even assuming the host keys were verified, the popular ssh conventions are to use either long-lived static keys (and almost nobody puts a password on theirs), or a password. Very few people use SSH with 2FA, and almost no-one uses ephemeral keys (OIDC) or certificates (which many people screw up).
So in terms of how people actually use it, SSH is one of the least secure transport methods. You'd be much more secure by using telnet over an HTTPS websocket with OAuth for login.
How do you automate, for example, "HTTPS over websocket with OAuth", without providing some kind of hard-coded, static or otherwise persistent authentication credentials to the calling system in some form (either certificate based auth, OAuth credentials, etc.)?
The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Though all your comments about SSH (especially host verification) holds true.
Just honestly trying to understand the possible solution space to the IoT problem and automated (non-human) authorization.
The manufacturer should at least supply certificates, and it could be up to you to ignore or use. It's not much but it's something.
> Very few people use SSH with 2FA.
PCI DSS, HIPAA, and ISO 27001 each either highly recommend or enforce this.
I wouldn't use a jumphost without it.
> Nobody verifies host keys,
The known_hosts file is verification of host keys. It's not verification of a host cert, which is a different thing. Most sshd instances are running on ad hoc hardware without the ability to associate them with someone a cert authority would be willing to authenticate.
Basically people running services that need cert-based authentication are already using TLS (or if they're using sshd they've locked it down appropriately). SSH is for your workstation and your RPi and whatnot.
SSH certs aren't TLS certs. Totally different format. All SSH CAs are private, you run your own CA to issue certs to devices you want to allow to connect to your server.
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.
> IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.
I know from bitter experience that IPsec is a “now you have two problems” kind of solution, but the Authentication Header is a thing and is supported by most (all?) implementations. Ham radio operators probably don’t have much use for the actual features of telnet compared to plain netcat, do they? (It’s mostly terminal feature negotiation and such.)
TIL that IPsec can be used without encryption. That should work pretty well.
Telnet is mostly used for auth and straightforward terminal/BBS access in my experience. There are some other alternatives like HamSSH but I don’t think it’s that common.
What I meant in my remark about Telnet is that, if you just want is a bidirectional byte pipe to e.g. run a terminal over, then you just need TCP or anything else providing the same abstraction, like TLS-over-TCP or TCP-over-IPsec; whether you then choose to run a getty on that terminal is not for the network to care. (I don’t believe you can get netcat to drive a PTY, so you’ll need e.g. socat. And of course if you want cryptographic authentication then you don’t need or want a getty.)
Telnet, on the other hand, is quite a bit fancier than that and has a fairly involved feature negotiation mechanism for terminal connections that is not entirely in line with the prevalent DEC tradition. As admittedly one of the funkiest examples of what you can do with it, there is for instance a mode[1] where the client is asked to emulate a terminal of the IBM 3270 lineage. (To a practicioner of the aforementioned DEC tradition, those feel like the marsupials of terminals: everything is functionally there, but primitive and derived are occasionally flipped and some features are oddly weak or misdesigned due to a lack of competition.) So if you do actually use Telnet the protocol, by all means, I’ll be delighted to learn what you do with it (partly why I asked in the first place). But if you just need a pipe, then TCP is enough, and netcat or socat make fine ad-hoc clients.
[1] https://tools.ietf.org/html/rfc6270
One? All the talkers still use it and all the MUDs/MOOs etc. far out number the talkers.
N.U.T.S. 3.3.3 4eva! There was a NUTS 4, but about a decade too late.
As I understand it, greynoise is monitoring scanner traffic, so yes this would all be scans or attacks
Probably one of the reasons this bug survived so long is that it isn't used much for priveleged access any more, but so you can play a moo or play you an ASCII movie, as people below you are replying.
Aardwolf works well from my work laptop. And I don’t care if someone sees what I’m doing
Do you care if they steal your account though and drop all your inventory?
The problem is the auth is plain text too and you're open to having your credentials stolen.
TBH, I don’t care if someone drop all my inventory and delete my account. If I would care about it then I would obviously not use telnet.
nethack.alt.org still maintains a telnet server!
I've always used ssh to connect to it. And it's true that their port 23 is still open at last check. If you cannot reach port 23, and you irrationally hate ssh, you may use 14321 as an alternate.
https://www.alt.org/nethack/
I run a DikuMUD that users connect to using Telnet
I really should update it to allow more secure options
> that users connect to using Telnet
Not anymore ;)
Seriously though: did you notice any spikes up or down?
If you'd run it on a non-standard port, anyone can still connect with netcat, socat, etc etc.
Ah, not really. We are on a non-standard port (9000). I just meant some folks use the telnet client to connect, and we do negotiate some telnet options. I use tintin++ these days but I think most of our players are still using decades old zMUD versions to connect!
I always preferred gmud, but zmud has all the bells and whistles. All I needed was ANSI color, aliases, triggers, and command history.
How can I get access?
Or with telnet (the client)