I have 6 devices that i rsync to a central location to back them up. Ive been using ssh as the -e option. Problem is i use public key with passphrases, meaning to backup all six i need to go to each device and run the backup script. Since i typically backup /etc, /home, and /root this means entering sudo and the ssh passphrase 3x for each device.

I would much prefer a script that runs on back storage device that can pull the data from each device without having to use ssh (encryption is not necessary since all traffic is either local or going through a vpn connection).

I could then put this script in root’s crontab or make it a systemd service running as root.

But i dont know how i can remote sync without ssh

    • Nibodhika@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      10 months ago

      I love this answer because it’s exactly what he’s asking, but absolutely what he shouldn’t do hahahaha.

      Anyone wondering, go to a computer and type nc -lp PORT > file (Replacing PORT with the port you want to use), now go to a different computer and type nc IP PORT < FILE (Replacing IP and Port with the IP from the first machine and the PORT you ran on the command there, and FILE with a file you want to copy). Congratulations, you just copied a file from one machine to another without using SSH.

      • SolidGrue@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        10 months ago

        You can pipe tar through it too.

        Receiver: nc -lp 12345 | tar xf -
        Sender: tar cf - . | nc 192.168.0.123 12345

        Also dd if you’re moricated to image over the network.

        I mean, he asked…

        • SolidGrue@lemmy.world
          link
          fedilink
          English
          arrow-up
          4
          ·
          edit-2
          10 months ago

          Sends in the clear, no error checking, the nc command is promiscuous while its bound to the port. No crypto or compression to slow you down. Just a raw pipe of bytes

          Its a bad idea, part of the forbidden codex known only to old, irreverent graybeards who know better but don’t care anymore. There are better ways that are both more reliable and better practice.

          You might want to look into using passwordless SSH keys within your script (see ssh -i) which isn’t the most secure.practice on multiuser systems, but is Okayish in Devops and backups. Add other factors like aggressive allowed hosts settings on the receiver, and rotate the keys regularly.