Re: ssh issue that I don't understand

scp for transfer or rsync may be...

On mer., 2026-07-08 at 00:24 +0000, Andy Smith wrote:
> 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