In college, wow 23 years ago now, my school still had a Telnet interface for students to apply for spots in the classes they wanted for the following semester
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
During my time at RIT, 2005-2010, you could apply for classes via a web interface, but if you wanted to actually get the good spots, you'd use the telnet interface.
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.
I got to experience the old VAX-based system for a few years, before it was migrated to Oracle Peoplesoft in 2011 (?) - which created as many problems as it solved.
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.
My school assigned classes automatically, but you could dial into a serial terminal to try to change classes. Obviously all of the good classes filled up fast so I wrote an Expect script that polled each class I wanted every 15 minutes and signed up if there was room. I managed to get into every class I wanted in my Senior year despite one semester getting an initial class schedule that was blank save for one class due the school's RNG hating on me.
Fellow RIT (‘08) alum. Same experience. I felt a bit advantaged being a computer-oriented chemistry major.
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.
That is amusing, similar experience at my university in Australia, the systems got busy when it was time to submit assignments, but the one Alpha server for some reason was always quiet. Something about it scared people off?
Czech Republic, same era, but a home grown registration system (never used anywhere outside the country). The experience was exactly the same. :-D The web interface was something new and fancy at that time, but servers couldn't handle the load. Those who didn't fear Telnet got a snappy interface and could register for classes that were in high demand.
Heh-he. In the olden days of 1990, our school's computer-based registration system used DTMF/'Touch-Tone'. When the new registration season started, lots of people learned to love their redial button. So many people would be trying to call that the local phone system around the school lost the dial tone, though not service.
Enjoy your time there -- a lot of people complain about it but I truly loved RIT. I hope they've maintained some of the feel of the campus among all the development which has happened... I can't believe that the Riverknoll apartments are apparently still in use!
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 end up back on campus now and then, despite having graduated and moved away ten years ago - it's definitely just as interesting to see what's changed as what _hasn't_ changed.
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.
Seconding this; during my B2B support days, this was essential, especially, since as security got a bit crazy, not all systems had telnet installed anymore and you weren't always in a position to install it.
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.
I'm actually a little surprised that worked; one of the major differences between HTTP/1.0 and HTTP/1.1 is that all HTTP/1.1 requests MUST include a Host HTTP header, so technically a HTTP/1.1 request without such a header is malformed.
Web servers have always had to be written for the web clients that existed, not how they should have existed.
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.
I'm dating myself, but my school had touch-tone service for the same thing. My trusty war-dialing script and I didn't fail to enroll into any class I wanted either. Ahh, the good ol' days.
To second the discussion everyone has about utilizing netcat instead I also want to point out that there is a tool on pretty much every linux machine ever that can perform netcat for SSL: `openssl s_client`. Ive used it on multiple occasions for toying with the HTTPS protocol and all of the features that only enable themselves when using a secure connection. It does just what netcat does, but initiates a secure SSL tunnel first.
The s_client binary does not implement all of the terminal controls in real telnet.
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.
**WARNING:** `openssl s_client` is designed only as a diagnostic tool and is NOT suitable if you care even slightly about security. By default it continues on verification failures so you get absolutely zero security.
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".
It's actually any line starting with R, like Referrer: yahoo.com. Also any line starting with Q, like Quiet, will disconnect, because you obviously meant Quit.
> "For the purposes of logging into a remote server, you should never, and probably have never considered it."
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.
No, it isn't, because a secure channel isn't the only thing SSH does to secure remote access. Consider that large fleet operators tend to use certificate authentication with SSH, and then work out how to replace that cleanly with telnet or rsh.
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.
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.
Well I used telnet before ssh was even a thing. It wasn't that weird back then and most internet systems were multi user where the common man didn't have root permissions. Thus so sniffing rights.
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.
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)
The hub was built to emulate the behavior of 10base2 and 10base5.
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.
10baseT would imply a hub, but 10base2 is “thinnet” (because the cable was thinner than the previous standard) where a coax cable runs between all devices on the segment, with no central device connecting them together.
Incidentally, it was the same signal that ran on 10base5 with the vampire taps.
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.
in the mid-90s i was invited to fix several schools' networks, a couple were novell and i forget what the others were (edit: also appletalk, which was similar but used 2 pairs on "telephone jacks", including little phone jack resistors), and those BNC connectors (or were they TNC?) were connected to stiff wires so any movement of the very heavy PCs connected to them tended to shear solder joints. I even had to replace "thinnet" coax that rats had eaten through.
I bet if i open my parts cabinet i still have enough stuff to build a token ring 10base2 network right now.
The advice "never use telnet" is fine. Yes, technically there are ways to use telnet safely (e.g. over WireGuard or a LAN), but they are fragile and I think it's better not to mention them.
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.)
SSH is not overkill, it is the default. There are some narrow circumstances where you might have a good reason to use telnet in 2023, but they are edge cases related to legacy hardware and possibly occasionally the desire for easy on-path interception. It is very unlikely that you have a good reason to not just use SSH. Even if you care nothing about the security advantages, SSH has more consistent and better-defined behavior around 8-bit data, and offers far more features.
telnetd probably doesn't have too many eyeballs, so I wouldn't be too confident about it really. Whatever eyeballs are focused on telnetd are less likely to be ones who take security as a major concern.
Yes, but note this is only the scp protocol. The /bin/scp tool uses the sftp protocol by default now, and you can just continue using it without problems (if you ssh is new enough; check the manpage).
I don't understand that article. Those issues look easy to patch up? The first one has been. The second one seem like a case of not allowing the server to execute text sent by the client in the filename?
The original scp used rcp (as a protocol, or very close to it) inside of ssh.
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 .
"with the expectation of getting a file called boring-spreadsheet.ods in the current working directory. If the remote server were to give a response like "here is the .bashrc file you asked for", though, scp would happily overwrite that file instead."
No they aren’t, because there can be multiple users on the same host that can do something else that briefly changes the routing table and suddenly your destination that would go over wireguard goes over something else.
Ssh gives you process to process security, which is far far better than host to host.
I think a lot of this type of affection for telnet is misplaced. The fact that telnet functions acceptably as an arbitrary TCP client is an unintentional side effect of the design, not its purpose. netcat is not only a more feature complete tool for simple network connections and diagnosis, it gives clearer and more helpful output on the state of the connection when used with the verbose flag.
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.
Part of it to be fair comes to telnet being ubiquitous. I've used any number of aix / hp-ux / solaris / Linux / windows / whatever systems over the decades, with limited or high privileges, and telnet was the one command that worked on all and could within 3 seconds and no fancy docs or knowledge and additional tools tell me the basics of what I needed to know. Are there better tools? Ab so freaking lutely. But telnet is there :-)
Twenty years ago, sure. Yet I every time I have the urge to use telnet on a modern system, I have to install it. You may as well install netcat if it is available (and if it is suitable to the task).
I had to point out that one may as well install better tooling more appropriate to the domain if one would have to install telnet, some years back. (-:
This is correct, telnet will send IAC codes (0x255) followed by two bytes. WILL, WONT, DO, DONT. If telnet encounters a IAC code, it will read the next two bytes or subcommand bytes hiding that from your output. Telnet should not be used for TCP debugging.
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.
Yes 0xFF, my brain short circuited. It’s a hairy protocol unless you scan byte by byte into a buffer, branching when you receive IAC codes. Because they can come mid-stream. Anytime. Anywhere in the buffer of packet data.
I use "telnet -8 -E" for our VAX (which runs on the Charon emulator).
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.
All this is true, but back in the early 90s... we just didn't have netcat, and telnet was on every single machine, and so that's what we used as a MUD client, for remote shell access, for system diagnosis to see if a port was open, for ad-hoc SMTP sessions, etc. My brain is still unfortunately wired to reach for it and I have never memorized the netcat flags in the same way.
It wasn't just for troubleshooting SMTP, it was also great for debugging HTTP when you were serving malformed headers causing your browser to explode. Is that technically the wrong solution? Okay, dad, but it was also my gaming platform at the time.
Telnet reminds me of the days when the internet was mysterious and exotic machines of all types existed.
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.
The original version of Android, on the T-Mobile G1 / HTC Dream, had a bug where all characters were sent to the command line as root. I restarted my friend's phone, typed `telnetd` and was able to telnet into the phone. A surprising number of options were available over telnetd. I made a few calls!
Fun facts, Telnet was actually the first Internet application and was also the very first killer application for the Internet.
"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].
Telnet support for PTT has already been deprecated for security reason so I am not sure PTT still count as a telnet-based BBS. Only ssh and websocket is supported nowadays.
Whether it counts depends from whether it's just "deprecated" or whether the users have actually stopped using it.
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).
It is deprecated is the sense that you can't even login using telnet. Try `luit -encoding big5 telnet ptt.cc`, and it will tell you to switch to websocket or ssh in Chinese.
It took me a while but is Ncat the same thing as netcat?
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.
Obviously it doesn't do the telnet protocol when run on port 23 (note the real telnet client disables the telnet handshake when port != 23, which is why it's useful as a generic TCP client anyway), but this basically keeps my muscle memory happy and it's clear from the output what's happening.
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.
There's a jpl service kicking around that's on telnet and is fun to play with. Nothing requiring a password - it's published material, essentially a website, but in command line form. Presumably the anon account permissions would take some care to set up, but once that's done it's a good interface, I think.
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.
Anyone else miss being able to just “talk” to people? It was the ultimate in distributed instant messaging. Instant down to the characters you were typing.
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.
I had an old device that spit out some odd format serial data I wanted to log recently. I pulled out an random ESP8266 on a tiny board from a drawer and quickly wrote some code to read a single pin for the Rx. I didn't have any memory onbaord to store anything, and figured it would be cool to just dump this data onto my network and use something else to check what the current value being reported was and log it on another machine.
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.
People insist on ssh being the secure option then go on to write confidential informations on Google Doc, then copy-paste it in Google Translate for translation and ChatGPT to get a summary, then mail everything using webmail.
Netcat is really a cleaner solution from this perspective.
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.
Socat doesn't support STARTTLS. If you want to debug SMTP submission "openssl s_client -starttls smtp -connect server:587" is awesome. Just take care not to use upper case "R" or "Q". Man, why did they implement rekeying and quit in such a bothersome way. Just use recipient and quit instead of RECIPIENT and QUIT.
Here is the script. This is like FTP/scp to an inbox. Remove the two leading spaces that HN needs in quoting code blocks.
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 "$@"
Telnet (the command) is still how I discover who the admin is for any given mail server. Random OSes don't come with nc.
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?
.
Microsoft Terminal still has some oddities that PuTTY does better, including REP of Supplementary Plane characters, but now the converse is also true. (-:
I would recommend windows terminal and the builtin windows openssh over putty these days if you must use windows.
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.
I'm not sure about others, but I use putty almost every day. It's a bit less than it used to be since Windows now has a decent ssh client and terminal.
Isn't this really what netcat is for? I've used telnet like this before I was really aware of netcat.. I even knew how to login to and use an irc server with telnet, PING/PONG included
I remember how I learned networking protocols basically over telnet in the 90s. You could send email by telnet'ing to some SMTP server, using the (HELO, MAIL FROM, RCPT TO commands). I of course debugged my HTTP cgi gateway using telnet and sending "GET / HTTP/1.1\nHost:somehost.com\n\n". I connected to IRC using telnet, joining channels and sending privmsgs (although answering PING requests from the server become annoying quickly). I learned that you can connect to FTPs using telnet, and on wrongly configured ones (FXP), you could use the FTP control channel to have the content of an arbitrary ASCII file be sent over a socket - just to use it to have the FTP server connect to an IRC server and send message to my online buddies.
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 wonder if you'll find it reassuring or chilling that tintin++ is still under active development and is arguably still the state of the art for mud scripting.
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.
I like discworld mud, it's loosely based on terry pratchett's books but has drifted a lot over the decades it's been active and is largely its own thing now.
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.
I wonder what it would take to take a MUD which speaks only telnet, and make it work behind a sshd proxy, with regular ssh password auth.
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.
Is there a tool that has incorporated everything mentioned in this article into a one-liner app/script and spits out all the server replies and a diagnosis guess?
Not intending to build it myself, just curious if it exists!
Telnet is usually removed from all contemporary development servers as a "security compromising tool". This renders problems much more hard to diagnose
If netcat is installed, just use that instead (it's also better for non-telnet protocols). If you don't even have netcat but you do have bash, you can use:
The next step could be to write a script which uses telnet and the other commands in the article to automatically pinpoint the connection problem, something like
I used to use telnet for this. Until,for compliance reasons, telnet was no longer allowed to be installed on many of the machines I work with. Now I use nc instead.
Neither telnet nor ssh handle problems like your laptop going to sleep or changing networks. These are stale and it in due time that we move to something better.
Mosh into a tmux session is dreamy. I can connect from my iPad to a remote server at home, carry it onto a bus and continue working, then carry to a coffee shop and finish what I was doing, all without ever having to reconnect.
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