301–310 of 414 posts
Never mind telnetd. Tier 1 transit providers doing port filtering is EXTREMELY alarming. They have partitioned the Internet, and in a way that automatic routing (BGP) can't get around.
Isn't this one of the remaining, "legit" uses of the Telnet protocol on TCP/23 port over the public Internet?
Earlier quoted context omitted.
Two wrongs don't make a right. Apple still includes uucp for some unknown reason. The saving disk space argument makes no sense because telnet was one of the smaller binaries in /usr/bin. Telnet continues to be widely used for select use cases and being told we're naughty by not including it feels punitive and just adds extra steps. What are you supposed to do, trash a $1m piece of industrial equipment because Apple…
Ubuntu and derivates removing telnet from the default install, along with other basic tools like traceroute etc, was one of the driving factors toward me creating my own distro. I'm sick of basic stuff being omitted because somebody just decided it's not needed anymore.
Earlier quoted context omitted.
netcat, socat and openssl s_client are all available for general manual connection testing. As are many other tools. But the ones above are basically far better direct telnet alternatives.
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?
Earlier quoted context omitted.
Most people don't care about FCC rules. I'm breaking a tonne of FCC rules right now.
In general, this is pretty true in practice. Just dont mess with: GPS, Airline radio, cell phones, broadcast infra, emergency services If you're blowing double the power for ISM, nobody cares. Your PEP using a yagi is 4x what is legal? Unless you piss off a ham, nobody cares. And even if you are a ham, and are using 150KHz bandwidth with low power in, say 50MHz (regulation says 40KHz max), again, nobody cares. And al…
So much gatekeeping.
Incidentally, I have it Word From On High within Ofcom here in the UK that you literally cannot pay them to take an interest in what happens on the amateur bands.
There's "breaking the law" and there's "being a bit rude", the latter of which might be things like "hey let's do fastscan TV on 70cm and use about half the allocation!" You do have to watch with 70cm in the UK though because amateur radio is a secondary user, with primary users being the armed forces. But it's 10MHz wide and there's space for everyone to play.
Putting the 70cm packet BBS channel 5kHz above where all the car alarm keyfobs work was a bit silly though.
As regards microwave stuff, I've got some scrap 26GHz stuff at work that can apparently be tuned to 24GHz by swapping the cavity tuning screw for one of the slightly longer ODU outer cover screws, and tweaking a setting in the EEPROM in Factory Never Touch This Shit mode. Want to bet they had radio amateurs working for them?
Earlier quoted context omitted.
Changes like these lend even more credibility to the approach of putting everything on port 443 over TLS, and distinguishing protocols based on hostname / HTTP path.
If everything was on port 443 why would we even need ports. The ports are there for a reason, it is idiotic to serve everything over http as you would need a mechanism to distinguish the different flows of traffic anyhow.
We can either have a standard and accept that bad actors will use it against us, or we can accept the chaos that results from abandoning it.
Earlier quoted context omitted.
> 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 the…
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.
The point is that a "private" cert is not a "cert" as commonly understood. The important part to a certification authority is the AUTHORITY part, not the data format. Either there is a trusted third party that will promise you are who you say you are, or there is not. With SSH, there is not, nor can there be as it is commonly deployed.
So applications that want that have used other protocols and other schemes, very productively.
Earlier quoted context omitted.
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? Though ... I suppose by now a switch to port 22 could make sense.
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=…
mudplayer:x:1001:1001:MUD Player:/home/mudplayer:/usr/games/adventure