Hello, On Wed, Jul 08, 2026 at 12:36:36AM +0200, Christian Groessler wrote: > In "trusted local networks" one could use telnet and forget about ssh > overhead...
I don't really follow the logic. telnet is not designed for file transfer but for interactive login. The trivial overhead of encryption and initial key exchange won't be at all noticeable in an interactive terminal session so why would you ever use antiquated and poorly-maintained software like telnet? ssh is right there and works fine. Even when it comes to bulk data transfer, SSH is not really slowed down that much by encryption and key exchange. I have no problem doing 500MB/s from an nvme, through SSH over the local network to another nvme. The bottleneck isn't the CPU unless we are talking very weak systems. The bottleneck is down to the fact that SSH isn't a dedicated file transfer tool and just uses a single TCP stream with conservative window scaling. This still works quite well on reliable, low latency links. TCP really falls apart on high latency links with even a tiny amount of loss, but local networks aren't usually like that. But even if you DID find encryption overhead to be an issue, you wouldn't try to shove massive amounts of data though telnet, you would just us something like nc! It's packaged in Debian and installing it on both ends is far more sane than running telnetd on one end and telnet client on the other! There is almost no scenario in which running telnetd makes sense, even on an isolated network where every host is on your desk, except perhaps nostalgia. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting "I am the permanent milk monitor of all hobbies!" — Simon Quinlank
