Why use ssh with local connections?

[catweazel]

viewtopic.php?f=47&t=274914

In the thread above, the OP appears to be using rsync with ssh to sync two locally attached drives, though I concede that isn't necessarily true. A little later in the thread, another poster uses ssh to sync between two machines on the same LAN.

In the first case, I rather think that using ssh is completely pointless. In the second case, it would also seem to be completely pointless if the destination machine on the local network also serves files and the LAN is sitting behind a NAT. I would have thought that using ssh would only be of benefit when communicating with remote machines.

Is there a method to this madness that I'm not seeing?

[HaveaMint]

viewtopic.php?f=47&t=274914

using rsync with ssh to sync two locally attached drives

I had to read this a few times before I finally wrapped my head around it (it's late) I haven't a clue why ssh is used for two drives on the same machine. I think that's how I'm reading it. I use ssh on two PC's but not on the same PC. Plus I'm lazy and use grsync.

[catweazel]

viewtopic.php?f=47&t=274914

using rsync with ssh to sync two locally attached drives

I had to read this a few times before I finally wrapped my head around it (it's late) I haven't a clue why ssh is used for two drives on the same machine. I think that's how I'm reading it. I use ssh on two PC's but not on the same PC. Plus I'm lazy and use grsync.

You read it the same as I did but, without asking and disrupting the thread, there's no way to know if the OP, for example, has set up an NFS connection on one of those mount points.

[HaveaMint]

Plus when you said "in the thread above " I went back to here and looked above viewforum.php?f=61&sid=7ca0011fc334c78d2d743894f3d4ac2b like I said it's late.

[catweazel]

Plus when you said "in the thread above " I went back to here and looked above viewforum.php?f=61&sid=7ca0011fc334c78d2d743894f3d4ac2b like I said it's late.

lol

[smurphos]

another poster uses ssh to sync between two machines on the same LAN.

i use rsync via ssh and sftp to mount shared drives on my LAN. Reason being is I find it way more simple to set up and maintain that p**sing around with that sorry mess called samba.

[catweazel]

another poster uses ssh to sync between two machines on the same LAN.

i use rsync via ssh and sftp to mount shared drives on my LAN. Reason being is I find it way more simple to set up and maintain that p**sing around with that sorry mess called samba.

I use NFS, it's much simpler to install and get running.

[smurphos]

I use NFS, it's much simpler to install and get running.

Another perfectly good option.

I went with SFTP to make it easier for Android and ChromeOS devices to access the shared drive as-well. Last time I checked there wasn't a good NFS client for Android, but my favoured Android File Manager and Sync client both support SFTP.

[catweazel]

I use NFS, it's much simpler to install and get running.

Another perfectly good option.

I went with SFTP to make it easier for Android and ChromeOS devices to access the shared drive as-well. Last time I checked there wasn't a good NFS client for Android, but my favoured Android File Manager and Sync client both support SFTP.

Ah. I just use KDE Connect.

[smurphos]

Ah. I just use KDE Connect.

Horses for Courses eh...

[catweazel]

Ah. I just use KDE Connect.

Horses for Courses eh...

lol - indeed.

[rene]

In the thread above, the OP appears to be using rsync with ssh to sync two locally attached drives, though I concede that isn't necessarily true.

Indeed it is not; he specifies --rsh=ssh but only when either source or destination is remote does rsync in fact use the configured remote-shell transport. With local sources and destinations -- and that is very much including on network-mounted drives such as NFS-mounted ones: once mounted they're to rsync simply local -- no remote-shell transport is involved; as far as it itself is concerned, rsync uses simple copies.

Once one or both of source or destination is legitimately non-local, using ssh does make some sense even on a private LAN. Foregoing its daemon mode, rsync needs a remote-shell and while that could for example be plain rsh instead of ssh, any remote-shell implementation other than ssh has by now fallen from grace. That is, although the s(ecure) part of ssh may be pointless on a private LAN, the sh(ell) part is not.

Given a personal disdain for "secuwity" as a substitute for having a clue, I stuck with rsh/rlogin for the longest time on my local LAN but stopped doing so one or two distributions ago when I needed ssh anyway for actual remote remote-shell, and installing rsh needed specific scrounging around to find out which BSD-like package the distribution-of-the-day had relegated it to -- or IIRC in fact since on one of the used distributions that seldomly used package started bombing out

I see that on a standard Mint install rsh in fact is ssh unless you install e.g. rsh-client which confuses things a bit, but also note you do not in fact need the "--rsh=ssh" parameter anyway since ssh is the default remote-shell transport on Debian/Ubuntu/Mint. Specifying that option does nothing magical; not even anything "secuwe".

[EDIT] Cleaned up some grammar only.

[catweazel]

In the thread above, the OP appears to be using rsync with ssh to sync two locally attached drives, though I concede that isn't necessarily true.

Indeed it is not; he specifies --rsh=ssh but only when either source or destination is remote does rsync in fact use the configured remote-shell transport. With local sources and destinations -- and that is very much including on network-mounted drives such as NFS-mounted ones: once mounted they're to rsync simply local -- no remote-shell transport is involved; as far as it itself is concerned, rsync uses simple copies.

Once one or both of source or destination is legitimately non-local, using ssh does make some sense even on a private LAN. Foregoing its daemon mode, rsync needs a remote-shell and while that could be for example plain rsh instead of ssh, any remote-shell implementation other than ssh has by now fallen out of grace. That is, although the s(ecure) part of ssh may be pointless on a private LAN, the sh(ell) part is not.

Given a personal disdain for "secuwity" as a substitute for having a clue, I stuck with rsh/rlogin for the longest time on my local LAN but stopped doing so one or two distributions ago when I needed ssh anyway for actual remote remote-shell and installing rsh needed specific scrounging around to find out which BSD-like package the specific distribution-of-the-day had relegated it to -- or IIRC in fact since on one of the used distributions that seldomly used package started bombing out

I see that on a standard Mint install rsh in fact IS ssh unless you install e.g. rsh-client which confuses things a bit, but also note you do not in fact need the "--rsh=ssh" parameter anyway since ssh is the default remote-shell transport on Debian/Ubuntu/Mint. Specifying that option does nothing magical; not even anything "secuwe".

Many thanks, rene, for clearing that up. Your reply was comprehensive, and appreciated.

[Portreve]

Well, catweazel, back when I still had a dedicated fileserver set up, I used ssh because that's the only way I had to get onto the box. I used Cinnamon's own built-in network drive capabilities for that. I've heard of NFS but honestly I don't know anything about it.

[sgtor]

There are at least two reasons I can think of to use SSH on a LAN.
The first one is a user who knows it's more secure and has read it's best to use it for security and not understanding that being behind a NAT is most likely going to be secure enough.

The second one would be someone or some company or organization who wants or needs to be on the paranoid end of the security scale thus they always employ every layer of security available to them.

If you think it's not possible for a hacker to find a way breach a NAT firewall and set up a sniffer to capture plain text passwords going over telnet on a LAN then I'm sorry to say it's possible.

On the other end of SSH security you have the Linux/Ebury rootkit that spreads from machine to machine on every SSH connection. Thankfully it's easy enough to check for ebury but of course that doesn't apply for zero day changes.