| |
| ▲ | mikkupikku 3 hours ago | parent | next [-] | | Hosted roguelikes have been using ssh for at least 15 years. It's probably time for MUD folks to consider this. | | | |
| ▲ | RupertSalt 9 hours ago | parent | prev [-] | | If MUDs and other games were indeed using port 23/tcp for player access, they were not only incorrect but rather dangerous. Since 23/tcp is a well-known IANA-registered port for the Telnet service, it is an RFC violation to use it for a service that is not telnetd/remote logins via TELNET protocol. Any port below 1024 signifies that it is a "privileged port". This is an archaic distinction that developed in high-trust R&E networks, but it did signify that the listener on the port had administrative/root access to spawn a service there, so it was kind of a signal that you could "trust" the remote server with your login credentials. The privileged ports were also priority, because if the unprivileged ones were "first come, first served" for unprivileged users, the administrator would have the ability to enforce the uniqueness of "privileged ports", and disable or kill any process that shouldn't be using one. A MUD Wizard who finds their port in-use (bound) on start is on their own. Typically there were no MUDs running with, or needing, root privileges. They were run under user accounts, or specific unprivileged role accounts. They had no need of a privileged port, and many were clandestine or unauthorized, and forced to use a higher port number. That's why the 4-digit ports became so popular. Anyway, the custom has already developed of blocking port 23 to protect users from unwittingly opening a management or login interface. Most shrewd admins would choose a port that isn't routinely blocked and filtered... and port-scanned. If your favorite MUD runs on port 23 today, such as nethack or something, then I am glad for this change, which will force the administrator to select a unique port that does not imply privilege, TELNET protocol, or shell login credentials. It is totally RFC-compliant to select an unassigned port above 1023, and MUD conventions have popularized several numbers that are still recognizable to players today. | | |
| ▲ | Kim_Bruning 8 hours ago | parent | next [-] | | They're remote terminal applications? Remote interactive text sessions. Over TELetype NETworking? You're saying that connecting my tty (emulator), to a remote host is not the purpose of telnet? <backs away slowly> Though ... I suppose by now a switch to port 22 could make sense. | | |
| ▲ | RupertSalt 8 hours ago | parent [-] | | 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=23.
I would say that by the letter of the law, and by longstanding convention, that port 23/tcp is given to telnetd type login servers. A server listening on port 23 is expected to accept login credentials and furnish a shell or some management interface that affects the host itself. That someone would log in as a terminal user and perform computing tasks.A MUD game could never be confused with managing the server where it runs, or a user/admin login to access that operating system. A MUD game has a specific purpose of recreation/leisure/communication. Again, let us not conflate port 23 with telnetd with the TELNET protocol. These are all completely separate and distinct. Except that port 23/tcp implies TELNET protocol and also implies a telnetd-type server. It is sort of a one-way chain of requirement. telnetd could be run on any port (inadvisable) while TELNET protocol could be implemented by any other service (often preferable). A MUD server is perfectly entitled to use TELNET protocol! In my server-hacking days, I often considered it a mistake and error not to support TELNET protocol! If I had known how to implement it, I would've added it to TinyMUCK myself! Honestly, it was not a priority because there was no known client supporting TELNET, either. Of course, protocol support needs to be on both ends to be effective. Without demand or capability from clients, it didn't really make sense for server programmers to add it in. But we were perfectly content to stay on port 2283, port 4201, or port 6250, as our players and Wizards had established the games to run there, especially in those days we wished to escape notice by admins. The TELNET protocol can run on any port and support any "network virtual terminal" service. But the "telnet port" on 23 is special, unique, and as of last month, really inadvisable for everyone. | | |
| ▲ | FEELmyAGI an hour ago | parent | next [-] | | > 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 character name. The database is stored as directories and files, with occasional symlinks. Any programming or scripting language which is capable of manipulating Mooix's data files can be used to write custom commands, in a similar idea to, say, CGI. Libraries have been created to aid in this for several languages, including Perl, C, Ruby, and bash. When a character is enabled as a programmer, they basically get the amount of power normally associated with a shell account. They can create and execute files, evaluate perl scripts, and can access a simplified version of a standard UNIX shell, among other benefits. Facilities are provided to edit Mooix scripts or programs (using your favorite editor) from within the MUD, then set them up to be executed when a user types a certain command. []https://everything2.com/title/Mooix | |
| ▲ | metroholografix 35 minutes ago | parent | prev | next [-] | | The vast majority of MUDs don't even implement the full TELNET protocol, just a small subset. In typical MUD fashion, fundamental TELNET parts like option negotiation were either hacked together -badly- or altogether ignored. For the longest time in the 90s TELNET AYT would crash tons of custom implementations. | |
| ▲ | simlevesque 7 hours ago | parent | prev | next [-] | | I don't understand how playing a MUD doesn't fit the definition of "remote user access to service hosts". | |
| ▲ | kps 6 hours ago | parent | prev | next [-] | | > by longstanding convention, that port 23/tcp is given to telnetd type login servers First thing I ever telnetted to was Melvyl, University of California's library catalogue, around 1985. This was “remote user access” (I was a remote user) to “service hosts” (running the catalogue) providing “remote terminal access”. It was not a login. | | |
| ▲ | RupertSalt 5 hours ago | parent [-] | | I remember using MELVYL too, and you're completely right about that. I would suggest that MELVYL on port 23/tcp was also unnecessarily impinging on the IETF standards. MELVYL could have easily established its own well-known port with the IANA and not conflicted with the TELNET login port. Before the WWW, there were a multiplicity of search services and indexes. Remember Archie, WAIS, and Gopher? Apparently, WAIS was assigned port 210/tcp, but Archie apparently used TELNET on 23/tcp as well. I think some of the pioneering Internet services were perceived as not requiring a dedicated port. If MELVYL was the only service running on the mainframe and it wasn't running a Unix telnetd, then why not usurp 23/tcp? The admins there probably perceived it as a virtual "octopus cable" connecting remote "terminal labs", and for sure they had alternate methods of access for OS servicing and configuration purposes. In the beginning of MELVYL they were undecided about which protocol would prevail, and TCP/IP was competing with others, so port numbers may have been afterthoughts for the architects. The most important thing may have been the principle of not surprising users or confusing them with parameters. "telnetting to a host" was way easier without trying to specify that they needed a port number. Just ask any Unix admin where MUD users try to bang on their telnetd port trying to play the game... |
| |
| ▲ | da_chicken 7 hours ago | parent | prev | next [-] | | Boy, wait until I tell you what happened with http! | | |
| ▲ | RupertSalt 7 hours ago | parent [-] | | Exactly the same thing? Are you taunting me with some kind of ignorance? Again, you've introduced ambiguity and we can't tell if you are referring to a protocol, or a port. https has the special property of working on any port and didn't need to switch to 443. You could run https servers on port 80. Both of them are considered "privileged". Plenty of http and https servers alike on unprivileged ports too. Ports 80 and 443 were more about exclusivity and well-known assignments, than trust. The unique thing about HTTP the protocol is that it came to be implemented by practically everything, as in REST and web apps. It's an Internet lingua franca. TELNET protocol was severely neglected, which is why I was surprised that MUDs kept it alive! To sibling: A MUD character is not a user. A user is a user who logs into user accounts, e.g. shells. You could read it as "a host providing a service" to someone, I suppose, but again, in longstanding practice, 23/tcp was reserved to telnetd and other management/shell logins, not some kind of generic "interactive NVT anything goes" service. "Remote terminal access" was understood universally as like a console, or tty, that would invariably present a shell login, not Zork or Colossal Cave! |
| |
| ▲ | Kim_Bruning 6 hours ago | parent | prev [-] | | You mean something like this? mudplayer:x:1001:1001:MUD Player:/home/mudplayer:/usr/games/adventure
| | |
| ▲ | RupertSalt 6 hours ago | parent [-] | | [flagged] | | |
| ▲ | zenethian 5 hours ago | parent | next [-] | | Their replies are only obtuse because you fail to see that you’re being made fun of for having such a ridiculous pedantic position about this. “Terminal” does not mean shell when you read the Telnet RFC. It means TTY. A human to machine interface. MUDs implement the Telnet protocol and provide a remote TTY. What’s running on the terminal is absolutely irrelevant. | | |
| ▲ | RupertSalt 5 hours ago | parent [-] | | It is not pedantic and many respondents are simply obstinately conflating the tcp port with the protocol and with the server software. You have done the same thing. Did you not read my statement where I said it is perfectly fine and even preferable for MUDs to implement TELNET? Where did I ever oppose the implementation of TELNET protocol? Yes, when the TELNET protocol is in use, the applications are irrelevant to the underlying substrate of an NVT. But when port 23 is in use, everything changes. That is my point. And there seems to be a brigade of mudders who are butthurt about losing their pet TCP port in this. They cannot mock me because they are wrong. Their wizards chose poorly decades ago. <backs away slowly> <realizes HN is not a MUD> <stops emoting like you're a monster uWu> | | |
| ▲ | zenethian 5 hours ago | parent [-] | | Can you show the exact line in the RFC or IANA port reservations that says it has to implement a shell login interface with the Telnet protocol if it’s on port 23? Because I can’t find it. Nothing says that anywhere. | | |
| ▲ | RupertSalt 4 hours ago | parent [-] | | I literally already did. And it is not merely the RFC which specifies it. The RFC defines the protocol and really leaves it open-ended for any sort of implementation. What defines port 23/tcp is the longstanding usage and the original understanding of a "remote terminal" or NVT. In 1983 when the IETF described the NVT, it was simply understood that a terminal, or "canonical console", was a method to access a timesharing system and log in as a user. If you went to a "terminal lab" or you sat down at a desk with a "terminal" or "teletype" or any of its predecessors, you were preparing to log in and do some programming or data processing. There were literally no terminal labs where you would sit down and begin playing Centipede, Asteroids, or PONG. Those were completely different concepts of "consoles" and "cabinets" and the IETF did not stutter when they defined an NVT. Every Unix implementation, every router and network device, practically anything with an Internet connection implemented a "shell" login on port 23 or it did not. There were plenty of systems with /usr/games and a plethora of leisure-time activities, but surprisingly they did not default to using port 23/tcp. It has been long-standing tradition, and convention, that the TELNETD service operating on 23/tcp is what a user expects to find when they connect. MUD admins and wizards who put their servers on 23/tcp necessarily needed another way to log in and manage their server. I am surprised that they were so easily able to usurp telnetd if this was the status quo. Was sshd already established for them or something? Did they just resort to rlogin instead? I'm genuinely clueless and curious how it was so easy to usurp 23/tcp and use it for MUDs. Because my community often ran them clandestinely, and we always ran them unprivileged, so there would literally be no way for the server to start on port <1024 -- it never ever had root access! If your MUD ran on port 23, that's dangerous because at some point, somewhere, some time, it enjoyed root access, and hopefully dropped that UID 0 immediately after the bind()! | | |
| ▲ | ylow 3 hours ago | parent [-] | | Just for you I will switch my FTP server to run on Port 23. | | |
|
|
|
| |
| ▲ | 5 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | Kim_Bruning 5 hours ago | parent | prev [-] | | > Your MUD wizards made a bad, bad choice long ago when they picked port 23. I'm confused. I refer you to my previous answer. Which does not specify a port, nor does it need to. :x: can be a PAM database? It's ... how I'd do it. You get a lot for free. |
|
|
|
| |
| ▲ | ordu 5 hours ago | parent | prev | next [-] | | > Any port below 1024 signifies that it is a "privileged port". This is an archaic distinction that developed in high-trust R&E networks, but it did signify that the listener on the port had administrative/root access to spawn a service there, so it was kind of a signal that you could "trust" the remote server with your login credentials. If something is running on a privileged port is not enough to trust it. Firstly you need to trust to a host, you need to know where are you connecting to. If you connect to a random host with a privileged port and pass it your credentials you are doing stupid things. This thing with privileged ports is protecting you from users who could run arbitrary code on a server. From them and not from anyone else. So for MUD there is a lot of reasons to run on 23 port, it is a signal for users of MUD that they are connecting to a process hat was started by the owner of the machine having the root. > If your favorite MUD runs on port 23 today, such as nethack or something, then I am glad for this change, which will force the administrator to select a unique port that does not imply privilege, TELNET protocol, or shell login credentials. It is totally RFC-compliant to select an unassigned port above 1023, and MUD conventions have popularized several numbers that are still recognizable to players today. If I was running a MUD, I would find some way to get around. I could use 22 for example, though it could cause me problems with logging in with ssh. But it is not an issue really, there are 1k privileged ports, I could choose one from them. | | |
| ▲ | RupertSalt 5 hours ago | parent [-] | | You have contradicted yourself within your comment. Either a "privileged port" can be trusted or it cannot. As I implied in my previous comment, "privileged ports" are no longer a signal of trust on Internet hosts. Literally anyone could have administrator access to a host. The MUD could be running on a Raspberry Pi in a guy's basement. A telnetd server could be on port 23 of a personal router. You could telnet into a print server, a washing machine, or a microwave oven. In a world where devices are cheap, personal, and accessible, anyone could be an administrator of anything. You say "privileged ports ... protect you from users who could run arbitrary code" which makes no sense, man! Unprivileged users can always run arbitrary code unless they can't! Administrators must be able to run arbitrary code! Why should you be protected from that? If someone cannot run arbitrary code then chances are that they cannot bind a "privileged port" so is that what you meant? Again, why does a MUD need a privileged port? Why? No reason. The vast majority of "privileged ports" are occupied and assigned. You do not want to use them. You have no reason to use unassigned, privileged ports for a MUD. It is not a question of "trust" or "arbitrary code" or authenticated users -- it's just a dumb game with no effects on the OS or host system, man! It's a virtual system! I am afraid that MUD gaming has messed with people's minds more than social media. I myself was psychologically damaged by it. I urge you to seek help, before anyone else posts incoherent comments in this thread today. |
| |
| ▲ | unethical_ban 5 hours ago | parent | prev | next [-] | | Yes, and sftp and scp should not operate on port 22 because that isn't proper, interactive SSH! | |
| ▲ | sophacles 4 hours ago | parent | prev [-] | | > it is an RFC violation I hate to break it to you, but RFC violations power the internet. Also, RFCs are non-binding and the IANA port numbers are just strongly suggested. |
|
|
