181–190 of 414 posts
Earlier quoted context omitted.
What do you think proper architecture would be, given that ssh needs a capability to let root logins? I suppose it could be via a proper PAM module, which is widely supported. Too bad the first PAM RFC was published about the same time the first be version of ssh was released.
Does ssh need to allow root logins? Sshing as a regular user and then sudo to root works 95% of the time…
Earlier quoted context omitted.
> Breaching the daemon only allows for the attacker to get access to the login Yes, but potentially any login. See the problem? If you compromise the gatekeeper, you are now the keymaster. Or whatever :)
I'll admit it is still problematic. But at least there is only 1 gatekeeper instead of 2.
https://i.imgur.com/tZoTWu6.png
Still seeing a sizable number of open ports but it's on the decline.
The design of telnet and ssh where you have a daemon running as root is bad security that as shown here is a liability, a ticking time bomb ready to give attackers root.
Earlier quoted context omitted.
Telnet is used in legacy, IoT, embedded, and low-level industrial hardware. It's also intentionally enabled on devices where automation was written for telnet and it wasn't easy to switch to ssh. If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around…
> 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…
Earlier quoted context omitted.
What stood out as AI written? It felt like a well-written article by an SME to me.
Not the original commenter, but I noticed it too. I guess it's hard since AI is trained on human content, so presumably humans write like this too, but a few that stood out to me: > Five entire countries vanished from GreyNoise telnet data: Zimbabwe, Ukraine, Canada, Poland, and Egypt. Not reduced — zero. > An attacker sends -f root as the username value, and login(1) obediently skips authentication, handing over a r…
GGP has a good eye.
Am I the only one who finds this suspicious ? About Telnetd “…The vulnerable code was introduced in a 2015 commit and sat undiscovered for nearly 11 years.”
Is there proof or evidence that it was never exploited in all of 10 years and remained as a latent zero-day?
The only saving grace I would propose, is that since telnetd has been aggressively deprecated once ssh became popular, and encryption became ubiquitous, and remote exploits became commonplace, and Starbucks WiFi was routinely surveilled, that telnetd simply wasn't running anywhere, anymore.
We have commenters saying that embedded systems and IoT used telnet servers. But were they running an actual GNU telnetd or just a management interface that answered on port 23/tcp? Commenters are citing statistics of "open port 23", but that means nothing in terms of this CVE, if it ain't GNU telnetd. Cisco has literally always used port 23 for management. Other routers and network devices use port 23 without telnetd.
How popular was GNU telnetd to be running on a system and exposed to the Internet? This article pertains to all the port-scanners running everywhere, so surely someone with a Shodan account can make a survey and tell us: who was still exposing GNU telnetd in 2026?
https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...
One of the changes is:
- getterminaltype (char *user_name, size_t len)
+ getterminaltype (char *uname, size_t len)
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?