Re: ssh issue that I don't understand
jean-christophe <[email protected]> Wed, 08 Jul 2026 07:27:16 +0200
| Newsgroups | gmane.linux.debian.user |
|---|---|
| Message-ID | <934761fc1ae781b8c4e51d12c3098081dbbb60f5.camel@blues-softwares.net> |
there are fusefs under linux if you like do a persistent link On mer., 2026-07-08 at 07:24 +0200, jean-christophe wrote: > 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