Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

351–360 of 414 posts

Re: The Day the Telnet Died

#351
post #349

Earlier quoted context omitted.

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 timeshar…

Just for you I will switch my FTP server to run on Port 23.

Data or Control channel?

TCP or UDP or SCTP?

The world's your oyster, man

Re: The Day the Telnet Died

#352
post #202

Earlier quoted context omitted.

MUDs were my introduction to telnet- I grew up a university kid and had access to Wesleyan's minicomputer EAGLE.WESLEYAN.EDU running OpenVMS. I used it to telnet to CMU's TinyMUD and later other TinyMUDs around the country. I recall OpenVMS's telnet had a problem with newlines/carriage returns so all the text was staircased, so I ended up learning C and writing a MUD client. I still habitually use telnet today even i…

For a few weeks I ran a MUD over AX.25 for a couple of my friends. Because on their own, MUDs aren't nerdy enough, amateur radio isn't nerdy enough, and indeed packet radio isn't nerdy enough. Eventually we decided we'd had our fun and now I needed to the TNC for something else.

Ah, my grandfather was a ham (N4MDB) and he always tried to get me interested in it, but I had to tell him I preferred the internet (this was late 80's, so few people actually had internet). Later when I read Stevens networking books I learned there was a whole Hawaii-based packet radio (ALOHAnet) , and the UC campuses had intercampus microwave networking for a while as well. I actually still remember him telling me about bouncing radio waves off the atmosphere which seemed like magic to me at the time.

Re: The Day the Telnet Died

#353

Earlier quoted context omitted.

I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?

Because for a long time, on most computers, the telnet client was the closest thing to an "open a tcp socket to this ip/port and connect the i/o from it to stdin/stdout" application you can get without installing something or coding it up yourself. These days we have netcat/socat and others, but they're not reliably installed, while telnet used to be generally available because telnetting to another machine was more…

In corporate environments, netcat was often banned as it was seen as a "hacking" tool. Having it installed would sometimes get the attention of the security folks, depending how tightly they controlled things.

Re: The Day the Telnet Died

#354

Earlier quoted context omitted.

Lots of text games - MUDs - still play over telnet using dedicated MUD clients that implement their own telnet stack. Outright blocking the port has an outsized side efffe on them, this is simply not right.

Hosted roguelikes have been using ssh for at least 15 years. It's probably time for MUD folks to consider this.

[dead]

Re: The Day the Telnet Died

#355
I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along.

What I'd like to know is how the arguments get interpreted like that in the first place. If I try giving that kind of argument /usr/bin/login directly, its argument parser chides me:

  $ login '-f root'
  login: illegal option --  
What's telnetd doing differently? Is it invoking login via a shell?

Re: The Day the Telnet Died

#357

I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along. What I'd like to know is how the arguments get inter…

You passed '-f root' to login (a single long string). telnetd is likely passing '-f' 'root' to login (two arguments instead of one, whether this is because it creates two, or it uses the shell (which then reparses) I don't know).

But '-f' is a valid option to login (man login):

login [-p] [-h host] [-H] [-f username|username]

...

-f Used to skip a login authentication. This option is usually used by the getty(8) autologin feature.

Re: The Day the Telnet Died

#358
post #38

Earlier quoted context omitted.

it was just ai written thats why.. unexpectedly so from greynoise.

Well, I mean, the first part is a song by Don McLean called American Pie. You might know that, unsure that everyone will pick it out though. One of the most famous play choices at karaoke bars these days too. I think because the song is a long story, of sorts? But it's a terribly long song and I will leave to take a smoke break anytime it gets chosen. You're going to be there for a good 10 minutes before it concludes…

I was at a bar a few months back, drinking some brewskis with my broskis, and there was a guy with a guitar playing some songs. He started singing (bye bye miss) American Pie. Somewhere around the 4th verse he got stuck in a loop and sang that verse 3 or 4 times before he gave up.

Re: The Day the Telnet Died

#359
post #335

Earlier quoted context omitted.

I run a PDP-10 during the colder parts of the year. It's for historical preservation reasons. There are others doing the same thing. We still offer telnet access because that's how it worked back then. I guess we aren't going to be doing that anymore.

If you can get it on IPv6, maybe via a gateway, port 23 filtering doesn't seem to be applied to IPv6 yet! (I assume because the v6 address space is too large to mass scan?)

If I am rewriting the network stack or making other substantial changes, that defeats the purpose of historical preservation.
Post reply on HN