33
submitted 9 months ago by neosheo@discuss.tchncs.de to c/linux@lemmy.ml

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

top 37 comments
sorted by: hot top controversial new old
[-] matcha_addict@lemy.lol 21 points 9 months ago

From my understanding, the issue is you can't run them as background script because it is promoting you for the passphrase of the ssh key?

The easiest way to solve this is to use a ssh key that has no passphrase. Yes it's possible and it won't prompt you for it. Whenever you create a key, it asks you to enter a passphrase. If you hit enter without entering anything, there's no passphrase.

But if you just don't want ssh at all, you can use rsync daemon. Someone else mentioned it here. It's not as hard as they said, especially if you're in a local network where you're fine without encryption.

[-] hangukdise@lemmy.ml 4 points 9 months ago

rsync with open SSH certificates is secure without prompting for any password at all

[-] mozz@mbin.grits.dev 13 points 9 months ago* (last edited 9 months ago)

Use a restricted account with an un-passphrased key is probably by far the easiest way. You could also use rsyncd, but you'll have to fool with a whole bunch of stuff. The work involved will probably be a superset of just doing a restricted account for the rsync process to use for rsync-over-ssh.

Edit: I had totally missed that the issue was passphrase of the key, not password

[-] Bitrot@lemmy.sdf.org 3 points 9 months ago

They are already using ssh keys...

[-] mozz@mbin.grits.dev 4 points 9 months ago

Oops. I totally missed that. I revised my comment to reflect it.

[-] Oisteink@feddit.nl 3 points 9 months ago

And they have to use locked keys? In a setup where they don’t need encryption?

[-] Deckweiss@lemmy.world 9 points 9 months ago

Take a look at borgbackup if you want to overhault your backing up in general. It has some neat advantages.

[-] lemmyvore@feddit.nl 2 points 9 months ago* (last edited 9 months ago)

This. Rsync is not backup. Use an app that was actually designed for remote backup.

That being said, they'd probably have the same problem with borg and password-protected keys. 🙂

[-] bjoern_tantau@swg-empire.de 9 points 9 months ago

You can use rrsync to set up a key without any permissions besides rsyncing to one location.

https://www.man7.org/linux/man-pages/man1/rrsync.1.html

[-] Ramin_HAL9001@lemmy.ml 8 points 9 months ago* (last edited 9 months ago)

I am also going to recommend the same solution as @matcha_addict@lemy.lol in this comment: https://lemmy.ml/comment/7998407

You can create a key pair that is specifically just for this kind of backup transaction.

To limit its affects, create a user and group on each of the devices that are highly restricted.

This is actually the most secure solution that doesn’t require an interactive password prompt. The passwordless key only serves this one purpose and has small attack surface.

Basically, you can tell SSH to allow root login on certain devices by setting up a root key pair. You configure SSH on the target device such that when it logs in, the login must run a script or a single command instead of running a shell, this limits what attackers can do if they somehow steal your private keys. You can also keep these private keys in your SSH agent so you only have to enter their passwords once, this will allow you to run remote commands without a password.

I would recommend also exploring the possibility of setting up an Rsync Daemon on each remote device, it keeps an Rsync process running on a remote device and listens for connections from Rsync clients. https://linuxconfig.org/how-to-setup-the-rsync-daemon-on-linux

On an unrelated topic: you might also want to look into using Btrfs and making and transferring snapshots to other devices.

[-] drwho@beehaw.org 3 points 9 months ago

There's a somewhat more secure way to go about it.

A backup script on the host in question runs periodically as root and makes a local copy of the files owned by the backup user. The central host then makes a backup of the not-root-owned files on the host in question. It adds two extra steps but you don't have to set up SSH access for the root account.

[-] neosheo@discuss.tchncs.de 2 points 9 months ago

I have decided to use rrsync to do this.

Im using btrfs on the back drive but using ext4 on the remote devices. Wont the snapshots, if sent to a remote device be the same size as the original data?

[-] Ramin_HAL9001@lemmy.ml 1 points 9 months ago

I guess the Btrfs snapshopt approach is not possible for your setup since the devices you want to backup are not Btrfs and cannot create snapshots.

Yes, the snapshots will be the size of the whole partition, I had not thought about that problem. I do not know if it is possible to create incremental snapshots with Btrfs.

[-] BaalInvoker@lemmy.eco.br 7 points 9 months ago
[-] neosheo@discuss.tchncs.de 3 points 9 months ago

I use it too but i like rsync better for backups

[-] blashork@hexbear.net 7 points 9 months ago

tbh why not jsut set them up with an ssh key that doesn't have an associated passphrase? Besides that, if you don't care about encrypting like you say, then you could replace all calls to ssh with telnet.

At least that's my immediate thoughts.

[-] neosheo@discuss.tchncs.de 3 points 9 months ago

Because i don't like have passphraseless keys on my devices, i may just be being paranoid.

[-] matcha_addict@lemy.lol 8 points 9 months ago

You can create a key pair that is specifically just for this kind of backup transaction.

To limit its affects, create a user and group on each of the devices that are highly restricted.

This is actually the most secure solution that doesn't require an interactive password prompt. The passwordless key only serves this one purpose and has small attack surface.

[-] lemmyvore@feddit.nl 3 points 9 months ago

Look into ssh agent. It's a program that runs in the background and "caches" ssh keys after you unlock them once.

[-] neosheo@discuss.tchncs.de 2 points 9 months ago

I have tried but it doesn't really work in the script. You load the key into the agent but it still asks for the passphrase

[-] ElderWendigo@sh.itjust.works 1 points 9 months ago

As long as you restrict the user of those keys access to an interactive shell and limit access to only the directories rsync needs for backup, it's more like giving the pool boy keys to the pool rather than allowing access to the whole house.

[-] neosheo@discuss.tchncs.de 1 points 9 months ago

Well i gave it readonly access to / because i am trying to sync /etc /home and /root. Is there a way to give access to multiple locations?

[-] taladar@sh.itjust.works 0 points 9 months ago

It is still many times more secure than using something unencrypted.

If you are truly paranoid you could also use something like borg in append only mode though and put that into a chroot with just the necessary tools on the server side.

[-] neosheo@discuss.tchncs.de 2 points 9 months ago

Yeah, i think im gonna look into rrsync and try to set up a user with a password-less key

[-] IsoKiero@sopuli.xyz 4 points 9 months ago

You can run rsyncd as a service on host you wish to back up and connect to that from your central point directly without ssh. Traffic is unencrypted and I wouldn't trust on that over public network, but you can bind rsyncd to localhost and open a single ssh tunnel for each host (or even write a small script to keep tunnels open automatically) and then just run rsync over that. That's how I backup my things, just with backuppc in the mix (I've got scripts to open/close ssh tunnels at backuppc configuration). VPN tunnels are also an option to encrypt traffic, but depending on your use case that might be a bit overkill.

Or if you're not tied to rsync you could use something like BorgBackup or other tools which manage the whole jazz for you out of the box.

[-] Nibodhika@lemmy.world 2 points 9 months ago

You can create a second SSH key without passphrase, add that to the authorised keys, and specify to use that key instead, for example using an SSH config file.

Now this is a bit of a security flaw because anyone with access to the key can use it, so you can use rrsync to make sure that key only has access to rsync, so worst case scenario it can destroy your backup, but that's expected since you want write access to your backup without inputting a password.

[-] neosheo@discuss.tchncs.de 1 points 9 months ago

Yeah this is what im leaning towards

[-] knfrmity@lemmygrad.ml 2 points 9 months ago

You could rsync with directories shared on the local network, like a samba share or similar. It's a bit slower than ssh but for regular incremental backups you probably won't notice any difference, especially when it's supposed to run in the background on a schedule.

Alternatively use a non-password protected ssh key, as already suggested.

You can also write rsync commands or at least a shell script that copies all of your desired directories with one command rather than one per file.

[-] TGhost@lemmy.dbzer0.com 1 points 9 months ago

Ansible is the way for you I guess

[-] NegativeLookBehind@kbin.social 5 points 9 months ago* (last edited 9 months ago)

That’s just SSH with extra steps

(But I agree)

Or just remove the pass phrase from the key…

[-] neosheo@discuss.tchncs.de 2 points 9 months ago

I've tried it before but i want a situation where i dont need to use the ssh agent. I think i'm gonna go with using rrsync

[-] solidgrue@lemmy.world 1 points 9 months ago
[-] Nibodhika@lemmy.world 4 points 9 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 3 points 9 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....

[-] matcha_addict@lemy.lol 1 points 9 months ago

What're the downsides? I'm sure it's very insecure. Is it faster?

[-] solidgrue@lemmy.world 4 points 9 months ago* (last edited 9 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.

this post was submitted on 04 Feb 2024
33 points (92.3% liked)

Linux

48040 readers
817 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS