Still Love Telnet
bash-prompt.net
bash-prompt.net
It was quickly replaced by a web interface, which I promptly hacked to be able to take whatever classes I wanted with priority over everyone else, fun times
In case you are wondering, I let the admins know and they hired me to help them fix it
Still use Telnet on a regular basis to test connectivity to web servers or other services
Love connecting to port 80 and then typing:
HEAD / HTTP 1.0\n\n
It’s amazing to manually “talk” the protocol that browsers use to communicate with web servers
Specifically, you'd connect to a cluster of VMS machines (some VAXes, some Alphas) which had a text interface to the (reputedly) off-campus mainframe which did registration. I recall that "vaxa" was usually the most crowded because it was always listed first, but if you got on one of the Alpha systems it was more responsive.
Everyone insisted that you MUST use telnet, not ssh (although ssh was enabled) because having hundreds of students logged onto each VAX was enough load already without introducing cryptography. If I remember right, you could get a list of who was logged in which indicated if they came in via telnet or SSH, and people did get shamed for using SSH.
Interestingly, I'd never heard of the telnet interface to course registration before today. I did hear about the modem bank - and being the one with the old laptop (2006 vintage), got to use the modem with the campus's 5-digit dialing to get a session on it. This was, by far, more performant than trying to use the Web interface that everybody else was hitting, but interestingly it also didn't have the silly "we're closed from 6pm to 6am" stipulation.
I was always impressed at how fast the older professors could fly through the Student Information System. Force adding you to a class could literally take a few seconds - faster that it took that clunky web frontend to load a single page sometimes.
I recommend picking up a philosophy class with Dr Selinger if you've got a free elective hanging around.
PS the semester system is bullshit, quarters forever
I graduated right before the quarter-to-semester conversion happened, and heard more than my share of horror stories about lagging 10-week classes getting taught in 15, or worse, two 10-week classes smashed into a 20-week class, then taught in 15. Luckily, the writing was on the wall, so I ended up taking 32 course credits off-campus, and providing three years of pay stubs so that I could count part-time work as a co-op block, just so that I could graduate early.
Windows' best equivalent if it doesn't have telnet is from powershell:
Test-NetConnection -Computername [hostname or IP] -Port [some port number]
With the -Port flag, it will try to do a similar connection to a specific port.
Btw, had a classmate in college we called chungi (pronounced choon-ghee), we made some cool school projects together, including a videogame
Thanks for the nc recommendation
nc google.com 80
HEAD / HTTP/1.1
HTTP/1.1 200 OK
...
Sadly, a 100%-compliant web server (or client for that matter) would be greatly hobbled as to who it could communicate with on the real web. Although I do think the situation is far better now than it was 20 years ago.
A lot of times they are so much faster too
If you really want to use true telnet over TLS on the registered port of 992, then get a regular telnet client and telnet to a custom port on local host.
On that custom port, run stunnel in client mode. You can run this either in an inetd/socket activation setup, or in daemon mode that actively calls listen()
That stunnel should be configured to point at your telnet-ssl server (on port 992 if you want it accurately fingerprinted).
That telnet-ssl server should also be stunnel, and it should be configured to run telnetd in inetd mode.
That is the correct way to implement telnet-ssl. I would not trust any telnet client or server that was linked directly to a TLS library.
You must specify the options `-verify_return_error -verify_hostname <hostname>` to get even a semblance of security; however I don't know if they are sufficient, and the fact that they are not enabled by default is a massive red flag that tells you this tool was not designed to be secure.
As an alternative, I suggest using `gnutls-cli <host>[:<port>]` or `socat - SSL:<host>:<port>` (if they are installed; unfortunately they are not common). They pass the "Certificate" tests on https://badssl.com/ except for "pinning-test".
I mean, I assume at least once since you know about it. But for me, I don’t think I’ve ever typed a singular capital R anywhere on purpose.
It’s like nc on steroids. TLS, Unix sockets, and just about anything else that involves a digital cable connecting two streams of data.
When in doubt, just add more forking and socat!
This is not true when the client and server have both implemented Wireguard.
With Wireguard in place, it is safe to return to legacy telnet, ftp, and rsh. The use of rcp still remains problematic, for the same reasons that scp is deprecated.
It is not best practice to return and rely on these legacy protocols, as they are bad habits and are vulnerable when Wireguard (or equivalent protections at a lower level in the network stack) are in place.
There is something to the idea of drafting off of WireGuard's security! We have a WireGuard mesh internally, and I would push back on deploying something like mTLS on top of it. But we still need something like SSH to manage (not just encrypt, but manage) access.
If you think otherwise, I will invite you to implement this for SimH:
https://gunkies.org/wiki/Installing_VMS_V1.0_on_SIMH
(Yes, I have set this up.)
I’ve got one too, and I ssh over Wireguard to various machines in the mesh. But I’ve been thinking recently that one big shared Wireguard internal VPN that lets every machine get access to all ports of one-another is really not ideal.
And in light of that; if my Wireguard setup was more strict, then perhaps I would not even need ssh. But on the other hand I would prefer to keep my defences deep. I sleep better knowing that even if I mess up something with the Wireguard setup and the listening ports and addresses for host logins at least everything still has ssh protecting it.
In those days we also still used 10base2 so there wasn't even a switch involved. Every system could see each other's traffic. X terminals didn't have xauth in the beginning so anyone could connect to your terminal and screen grab or pop up pictures (something I did regularly for practical jokes)
On the one hand it's kinda crazy not many bad things happened back then. On the other, not too much important stuff was online in those days. And only a handful knew how it worked.
But yeah telnet and rlogin (authentication simply by having the right IP!!) were the tool for the job for many years believe it or not.
/GrandpaMode
Well ... perhaps augmented by the fact that I was using a crimping tool yesterday. But that wasn't coaxial cable. (-:
You’re thinking of a hub (repeats all packets on all ports).
This is how I recorded Vonage VoIP calls 20 years ago from anyone using the same hub in the residence.
10base2 was a coaxial cable (RG-58) shared by all devices. Each would have a T-splitter and there would be a terminator plug at the end. Removing that would cause half the network to stop working. Before that there was also another standard with ticker cable (RG-213) called 10Base5 but that was before my time. 10Base2 was still the way the network worked everywhere in my college though.
It was expensive and messy. Technically it worked a bit like a hub but it was a very different topology. At least physically (electrically it wasn't too different from how a hub shares its signals)
10base5 was the original inch-thick coax, and adaptors actually drilled into the cable. I have found 10base5 taps in odd places over the decades of my career.
10base2 was coax cable that we recognize, and there were t-connectors that allowed two cables to link into a host's network adapter.
The ends of the cable were capped with resistors ("terminators") that would radiate network traffic into (a very small amount of) heat.
This model uses CSMA/CD (carrier sense mutiple access/collision detect) very literally. Any station could transmit at any time, up to a maximum of 1518 bytes, including the Ethernet frame header. Transmit collisions were detected as frame size overruns. If the cable were too long, the ends would see correct transmissions, but the middle would see collisions. This explains the 500 and 200 meter limits of 10base5 and 10base2.
An understanding of this original topology and its limits is informative in the reasoning for modern Ethernet.
At the lab I hung out in as an undergrad, someone found what was termed "the connector of evil." On one end it looked like a thinnet terminator and on the other it looked to be a thicknet terminator - but they didn't terminate, it was a pass through.
And we used it. Some of the machines had 10b5 connectors and some had 10b2. The ones that used 10bT were at the other end of the room where the hub was.
The fun part was tracking down the inevitable "that machine dropped off the net" because the standing wave wasn't quite right for the thicknet side (and made the thinnet side unhappy too).
So we set it up to do a ping -f of an IP on the subnet that was on the 10bT side and redirect it to /dev/audio. This way machines that were on the net had speakers that were chipping away while those that had fallen off were silent. And then we'd go about swapping lengths of coax to get the standing wave to establish again when everything was chirping away... until we had to add another machine.
I bet if i open my parts cabinet i still have enough stuff to build a token ring 10base2 network right now.
Take the version in your comment for example. You wrote "With Wireguard in place, it is safe to return to legacy telnet", but that on its own is misleading: it is easy to accidentally route the connection outside WireGuard and compromise the password.
You do note later that it's not best practice and can be vulnerable (aside: I assume "are in place" should be "are not in place"), but a reader might miss that part or underestimate the risk.
Also, "safe" is subjective: telnet allows all the users on the network to try to bruteforce passwords. (SSH also allows that by default, but not for the root account, and it lets you disable password authentication entirely in favour of public key authentication etc.)
I think it's fine to give broadly-applicable-but-technically-inaccurate advice ("never use telnet"), and trust that the experts who can safely ignore this advice will understand that the advice is a simplification. (To be hyper-correct, one should give the broadly-applicable advice but also state that there are exceptions.)
Franky, do what you want in your lab.
I would urge you or anyone else to assume there's already a compromised device on your home network.
For our VAX? Oh boy...
https://lwn.net/Articles/835962/
The author of PuTTY quietly set pscp to prefer the SFTP protocol for these reasons; OpenSSH stated their intention to do the same.
IIRC, wildcards are allowed, so the rcp server expands them.
If the rcp server is malicious, it might slip an /etc/passed into its output, writing over the client. Very bad if the client is root.
The original scp suffers the same problem. I'm not sure if this issue is entirely avoided if a fully-qualifed path is sent to the server (but I think so).
EDIT: I am incorrect. The rcp server has complete control over the filename sent.
"...So one might type a command like:
$ scp admin:boring-spreadsheet.ods .
Networking between two Wireguard hosts will never see TCP on the wire.
Bad habits are OK with this in place.
Ssh gives you process to process security, which is far far better than host to host.
The telnet client and protocol offer various gotchas that can appear as mysterious problems when you use them for troubleshooting instead of netcat. For example, telnet is not 8-bit clean because of the fact that it was designed specifically as a protocol to carry 7-bit ASCII. RFC 856 seeks to address this and netkit telnet can be told to behave in RFC 856 mode using the -8 option, but there can be variations between clients in this regard, and virtually no one uses the -8 flag anyway. netkit (Linux) telnet without the -8 option will behave oddly whenever non-ASCII characters are encountered, as they will be interpreted as control codes in the telnet protocol.
It is a bit ironic, in this regard, that people using telnet as a TCP client almost always seem to be using it to troubleshoot SMTP - another protocol which is, for historic reasons, not 8-bit clean without extra work!
And that kind of gets at the biggest problem: telnet is not an arbitrary TCP connection utility, it specifically implements the telnet protocol. The telnet protocol is very simple, but it is there, and common telnet clients will send unsolicited (by the user) bytes in various circumstances in order to perform the telnet protocol. This can break the state of other protocols when you use telnet as a TCP client.
If you want a tool for network diagnosis or arbitrary connections, it is netcat. Telnet for this purpose is just a workaround that is becoming quite obsolete as fewer distributions include telnet by default (removing its primary advantage over netcat, that it is "already there"). Even bash's odd built-in TCP functionality is a better choice than telnet in a lot of these situations, as it's simpler and won't try to conform to the telnet protocol.
My 100 Croatian lipa
echo test > /dev/tcp/<ip>/<port>
Anyway though I have actually had to write a from scratch parser/interface to a custom and mostly undocumented old telnet system including multiple subprotocol negotiations and it really is pretty shitty. Even using it for more or less its intended purpose sucks.
We have Multinet ssh, but not enough ram and sundry resources to support 300+ concurrent sessions.
I have a container with TinySSH, with /etc/passwd accounts for each of our VAXes. These accounts are set to "exec telnet -8 -E (vaxhost)."
We used to use the Reflections terminal emulator with an stunnel binary packaged with it. Reflections is now over $500 per seat in licensing, and Rocket is under $100.
Rocket terminal refuses to allow a self-signed cert, and instead of renewing certs every two years, we push a private key to all our VAX users with Rocket, that launch the telnet.
Without the -8 option, the line-drawing characters don't render properly.
There was quite a bit of trial and error in getting this right.
I miss those times and often wonder what the world would be like had the internet remained as obscure (relatively) as it was back in the early 90s when I discovered it.
Google dorks are a lost cost and low effort way of searching for weird machines.
https://www.exploit-db.com/google-hacking-database
This is an interesting site which has some commands you can look through.
Note I would probably not be logged in with Google while trying this, just so you don't get flagged for review.
"The first data exchange over this new network occurred between computers at UCLA and the Stanford Research Institute. On their first attempt to log into Stanford's computer by typing "log win," UCLA researchers crashed their computer when they typed the letter 'g.'" [1].
[1] ARPAnet: The World's First Internet:
https://www.thoughtco.com/arpanet-the-worlds-first-internet-...
Consider that the GNU version of "fgrep" was "deprecated" for just under 14 years. And yet people were very clearly still using it in 2022 (when the 2021 code change apparently hit Debian) and 2023 (when the change hit Chris Siebennmann).
Edit: ah, clarified by other page:
> Ncat is our modern reinvention of the venerable Netcat (nc) tool released by Hobbit in 1996. While Ncat is similar to Netcat in spirit, they don't share any source code.
#!/bin/sh
nc -v "$1" "${2:-23}"
% cat /package/admin/djbwares/command/mconnect
#!/bin/sh
# WARNING: This file was auto-generated. Do not edit!
exec /usr/local/bin/tcpclient -RHl0 -- "${1-0}" "${2-25}" /usr/local/bin/mconnect-io
%
* https://jdebp.uk/Softwares/djbwares/guide/commands/mconnect-...
* https://jdebp.uk/Softwares/djbwares/guide/commands/finger@.x...
* https://jdebp.uk/Softwares/djbwares/guide/commands/who@.xml
Telnet better supports interactive terminal applications by exchanging info like the TERM environment setting, screen size, translation codes, etc.
Netcat doesn’t do any of that, but is simpler and better suited for sending or receiving binary data. It also has features that telnet doesn’t, like listening for incoming TCP connections and sending and receiving on UDP ports.
It's pretty rare to use Telnet these days. The exception is when you have to connect to devices like automation equipment, test equipment, admin ports on LAN switches, etc. Those devices shouldn't be on the internet, so they're not as much of a concern.
IIRC, the Telnet interface is technically more fully-featured than the others, although that's probably simply because it would have come into existence first.
I remember starting to craft a response before a friend was completely done asking a question … and then that friend stopping short and starting the next question before I was done answering.
Better than throwing an old computer in the garbage.
People act like if you're not connecting through SSH that you'll magically set the internet on fire.
Not every connection needs to be secure. I don't care if hackers see me reading Radio France International.
I could have used any number of packages that would create a little host on the ESP8266, or something that sends out MQTT packages to another server, etc etc.
but you know what was quickest? Telnet server on port 23, open, blasting out the buffered serial data once every second. It just sits there and does this. And if I want the data I just point a dashboard to that IP at that port and out it flows. If the device loses power and reboots, it is back up in a fraction of a second.
Security? who cares. it's some random numbers on my internal home network.
Netcat, combined with the openssl utility, can do some amazing things with moving files over SMTP. I can post my favorite hand-rolled script if there is interest. I boiled it out of mpack down to the shell.
At that point, wouldn't it be easier to just use socat?
This uses OpenSSL to a) send a base64-encoded MD5 hash of each file in the headers, then b) base64-encode the file itself. There is also an OpenSSL "smime" applet, but I really don't know what it does.
The netcat is going to send this over cleartext; use OpenSSL s_client (or maybe "nc -ssl" if your netcat supports it) if cleartext is a problem.
This is written in dash, so it should run in most POSIX-compliant shells. Note that local variables are not POSIX-compliant; for a true POSIX shell, change the shell function to "mimer () ( ...body ...)" to force a subshell.
Shellcheck doesn't like printf formats done like this, but you can't please everybody.
This also works in Windows with ports of OpenSSL and busybox, btw.
$ cat mimer
#!/bin/dash
mimer () {
local f \
SMTP='smtp.yourco.com' \
BOUND="$(openssl rand -base64 21 | sed 's@[/+=]@_@g')" \
SFORMAT='helo %s
mail from:%s
rcpt to:%s
data
Mime-Version: 1.0
Subject: %s
Content-Type: multipart/mixed; boundary="%s"
This is a MIME encoded message.
' \
MFORMAT='%s
Content-Type: application/octet-stream; name="%s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="%s"
Content-MD5: %s
'
{
printf "$SFORMAT" "$HOSTNAME" "$2" "$1" "$3" "$BOUND"
shift 3
while [ -n "$1" ]
do f=${1##*/}
printf "$MFORMAT" "--$BOUND" "$f" "$f" \
"$(openssl dgst -md5 -binary < "$1" | openssl base64)"
# base64 < "$1"
openssl base64 -in "$1"
echo
shift
done
printf '%s--\n.\nquit\n' "--$BOUND"
} | sed -e 's/$/\r/' | nc "$SMTP" 25
}
[ -z "$4" ] && { echo mimer to from subject file1 '[file2]' ...; exit; }
mimer "$@"Curl has been around for ages, but not for the entire WWW age.
telnet mail.foo.com 25
Connected to mail.foo.com port 25.
EHLO mail.foo.com
250-mail.foo.com Hello [172.16.0.5]
MAIL FROM: <me@myemail>
250 2.1.0 Sender OK
RCPT TO: <root>, <admin>, <mail admin>, <postmaster>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Subject: looking for mail admin
Hello! I'm Blahblah, I really need to reach the mail admin. Who are you?? How can I reach you?
.* https://github.com/microsoft/terminal/issues/15390
PuTTY is used in thin disguise by all MobaXTerm users, of course.
Anecdotally, a lot of the more senior windows admins at my work are still using putty and they do not seem interested one bit in switching. So putty definitely has some die-hard fans.
And wardialing... Boy did I love wardialing.
Good times. I look back at it with my rose-tinted glasses of course, but I wonder how it is today, given that everything is now SSL/TLS secured and you can basically not tamper with anything anymore without a deep understanding of the protocol and writing code first.
I had to reverse engineer a telnet interface for work last year and I did nearly all of the exploratory work in tt++. Got me back into mudding after many years away though. Once I had mastered that tool, why not.
Achaea is still really popular and active but I didn't spend all that much time on it when I was getting back into muds. It's got some freemium aspects to its model that turned me off but I understand is really well-liked by its players so probably worth a try anyway.
I also hear good things about alter aeon and it seems to be really active. I've been meaning to check it out but haven't yet.
---
A quick look makes mudding look more popular than it really is. There are hundreds of unique operating muds, but probably fewer than a dozen that ever see more than 50 simultaneous players. You could pretty easily narrow it down based on that and choose a couple whose theme appeals to you most. But also if you get into it you're choosing a community as much as a game, so observe and feel out the culture a bit before you get too invested.
And IMO skip anything that allows concurrent multiplay. Those look more busy than they are; in reality it's going to be a handful of people who have known each other for years each multiplaying dozens of characters.
Somehow we would want sshd to authenticate users using their MUD user name and password, and connect locally to the MUD instance, passing the credentials somehow.
The right way to do it is via libssh, I suppose; but that's integrating the SSH into the server.
https://dataswamp.org/~solene/2018-10-11-tor-hidden-service....
Replace the SSH port with the MUD one.
Not intending to build it myself, just curious if it exists!
bash -c 'exec 3<>/dev/tcp/$host/$port; cat >&3 | cat <&3'
Few people have ever discovered these, but they amuse me anyway. And I like being able to play nethack from anywhere, on any machine.
whatstheproblemwith hostname portAlternately, you can do the same with tmux or screen.
(yes, it works with netcatting to port 23, as no Telnet IAC codes are being used, but for me it will forever be a telnet show).