Toon posts:

[rsync] Remote server lokaal backuppen (root || ssh)

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Haha ik word gek, probeer heel simpel mijn remote server lokaal te backuppen met rsync maar dit blijkt nog lastiger te zijn om het goed te doen dan ik had ingeschat.

Wil liever geen directe root access naar mijn server hebben, dus geef je een user ssh toegang met rsa key. Die user heeft op remote natuurlijk geen toegang tot alle files en directories. Ook op te lossen, geef sudo rechten. Dan heb je het probleem van password prompt. Vooruit, gooien we een NOPASSWD exception voor user en rsync command in /etc/sudoers en draaien rsync met --rsync-path="sudo /usr/bin/rsync".

Zouden we er toch bijna moeten zijn. Oh wacht ik wil wel group en owner id's behouden, dus -a flag voor rsync graag. Maar dat werkt alleen als we lokaal als root draaien. Zucht fijn, sudo rsync die handel dan maar. Ja maar ho eens even, dan gaat rsync lopen ssh'en als root naar de remote en dat mag lekker niet! Gloeiende gloeiende!

Ok rustig, dit is ook vast op te lossen. The -e flag to the rescue. Rsync die bende met -e "sudo -u user ssh"
en handige harry heb het voor me kaar. Maar nee, dan moet je natuurlijk je key passphrase opgeven dus dan is het zooitje weer niet in een cronjob te draaien! Aarrrgh 8)7 :( |:(

Ik zie door de ssh-bomen het rsync-bos niet meer.

Nu zie ik nog twee oplossingen, of mijn lokale root user key access geven tot de remote, of lokale user een passphraseless rsa key geven. Beiden zijn volgens mij niet echt hoe het zou moeten :'(

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik waardeer de hulp, maar dat is basis kennis en werkt allemaal naar behoren. Dat was dus ook niet het probleem wat ik beschreef

Acties:
  • 0 Henk 'm!

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 01-10 08:15

deadinspace

The what goes where now?

Verwijderd schreef op donderdag 09 oktober 2014 @ 02:45:
Haha ik word gek, probeer heel simpel mijn remote server lokaal te backuppen met rsync maar dit blijkt nog lastiger te zijn om het goed te doen dan ik had ingeschat.

Wil liever geen directe root access naar mijn server hebben, dus geef je een user ssh toegang met rsa key. Die user heeft op remote natuurlijk geen toegang tot alle files en directories. Ook op te lossen, geef sudo rechten. Dan heb je het probleem van password prompt. Vooruit, gooien we een NOPASSWD exception voor user en rsync command in /etc/sudoers en draaien rsync met --rsync-path="sudo /usr/bin/rsync".
Ik vind zulke constructies eigenlijk slechter dan als root laten ssh-en. Sudo is sowieso meh, en hoe ingewikkelder je het maakt, hoe meer problemen het op kan leveren (ook maar niet alleen qua veiligheid).

Als je af wil dwingen dat alleen rsync aangeroepen kan worden (wat een goed idee is), dan kun je daar ssh forced commands voor gebruiken. Wel even uitzoeken wat rsync precies uit wil voeren.
Zouden we er toch bijna moeten zijn. Oh wacht ik wil wel group en owner id's behouden, dus -a flag voor rsync graag. Maar dat werkt alleen als we lokaal als root draaien. Zucht fijn, sudo rsync die handel dan maar. Ja maar ho eens even, dan gaat rsync lopen ssh'en als root naar de remote en dat mag lekker niet! Gloeiende gloeiende!

Ok rustig, dit is ook vast op te lossen. The -e flag to the rescue. Rsync die bende met -e "sudo -u user ssh"
en handige harry heb het voor me kaar.
Ehm...
rsync user@host:path/ dst/
? :P
Maar nee, dan moet je natuurlijk je key passphrase opgeven dus dan is het zooitje weer niet in een cronjob te draaien! Aarrrgh 8)7 :( |:(

Ik zie door de ssh-bomen het rsync-bos niet meer.

Nu zie ik nog twee oplossingen, of mijn lokale root user key access geven tot de remote, of lokale user een passphraseless rsa key geven. Beiden zijn volgens mij niet echt hoe het zou moeten :'(
Ja, om geautomatiseerd te ssh'en heb je wel een unencrypted private key nodig ja ;)

Maar met bovenstaande constructie kun je afdwingen dat met die specifieke key alleen backups gemaakt kunnen worden, dus met die key kan iemand niet het systeem binnendringen. Wel informatie uitlezen die het makkelijk maakt binnen te dringen, maar die informatie staat ook al in de (unencrypted) backup. Als een aanvaller bij de private key kan dan kan hij ook bij de backups dus dat maakt dan ook weinig meer uit.

[ Voor 6% gewijzigd door deadinspace op 10-10-2014 13:36 ]


Acties:
  • 0 Henk 'm!

  • BtM909
  • Registratie: Juni 2000
  • Niet online

BtM909

Watch out Guys...

Reacties zijn afgesplitst uit De Devschuur Coffee Corner - Iteratie 7

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.


Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Laatst online: 01-10 21:30

Hero of Time

Moderator LNX

There is only one Legend

Verwijderd schreef op donderdag 09 oktober 2014 @ 02:45:
Nu zie ik nog twee oplossingen, of mijn lokale root user key access geven tot de remote, of lokale user een passphraseless rsa key geven. Beiden zijn volgens mij niet echt hoe het zou moeten :'(
Maar dat is juist wel hoe het geïmplementeerd wordt. Om dingen te scripten over SSH zonder dat je wachtwoorden nodig hebt (passphrase is gewoon een ander woord voor wachtwoord) moet je dat op die manier doen.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • Kees
  • Registratie: Juni 1999
  • Laatst online: 10:44

Kees

Serveradmin / BOFH / DoC
Verwijderd schreef op donderdag 09 oktober 2014 @ 02:45:

Nu zie ik nog twee oplossingen, of mijn lokale root user key access geven tot de remote, of lokale user een passphraseless rsa key geven. Beiden zijn volgens mij niet echt hoe het zou moeten :'(
Of iets als:
sudo /usr/bin/rsync -a --delete --delete-excluded --size-only --stats --include=/remote/dir --include=/remote-dir-twee --exclude=/remote/dir-twee/drie/* --rsh="ssh -i /path/to/id_rsa" --rsync-path="sudo rsync" user@remote.server:/ /locale/path/voor/backup

En tja, dan moet die /path/to/id_rsa file wel passphraseless zijn als je dat in een cron wil zetten maar daar is niet echt aan te ontkomen, als je er wel een passphrase opzet zul je die toch op een of andere manier moeten geven en dus in plaintext/reverse encrypted ergens in je script moeten hebben of het handmatig elke keer uitvoeren. Dan is een passless phrase wel zo handig. Je geeft de user op de remote server al passwordless sudo rsync rechten; dus basically heeft die al volledige root toegang (zo lastig is het niet om een extra file in /etc/sudoers.d/ te zetten die je een passwordless rootshell geeft als je eenmaal toegang tot die user hebt).

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan


Acties:
  • 0 Henk 'm!

  • begintmeta
  • Registratie: November 2001
  • Niet online

begintmeta

Moderator General Chat
Is het überhaupt wel echt nodig om (root) toegang te hebben tot alle files en directories?

[ Voor 11% gewijzigd door begintmeta op 10-10-2014 12:18 ]


Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Laatst online: 01-10 21:30

Hero of Time

Moderator LNX

There is only one Legend

begintmeta schreef op vrijdag 10 oktober 2014 @ 12:17:
Is het überhaupt wel echt nodig om (root) toegang te hebben tot alle files en directories?
Wel als het 600 of 640 van andere gebruikers/groepen is dan de gebruiker die rsync draait. Denk aan een /var/ map of /etc zaken. En niet te vergeten /home.

Uiteraard is 't wel op te lossen, door ACLs toe te passen bijvoorbeeld.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • daft_dutch
  • Registratie: December 2003
  • Laatst online: 08-09 21:46

daft_dutch

>.< >.< >.< >.<

kan je niet een /usr/local/ scriptje maken met de rsync commandos en dat script via sudo NOPASS aanroepen?

>.< >.< >.< >.<


Acties:
  • 0 Henk 'm!

  • Demo
  • Registratie: Juni 2000
  • Laatst online: 30-09 11:31

Demo

Probleemschietende Tovenaar

PermitRootLogin=forced-commands-only en dan een key toevoegen aan je root-account waar je alleen rsync mee toestaat. Sudo brengt een hoop gekloot met zich mee en is uiteindelijk niet veiliger.

Unix doesn't prevent a user from doing stupid things, because that would necessarily prevent them from doing brilliant things.
while true ; do echo -n "bla" ; sleep 1 ; done


Acties:
  • 0 Henk 'm!

  • begintmeta
  • Registratie: November 2001
  • Niet online

begintmeta

Moderator General Chat
Hero of Time schreef op vrijdag 10 oktober 2014 @ 12:29:
[...]

Wel als het 600 of 640 van andere gebruikers/groepen is dan de gebruiker die rsync draait. Denk aan een /var/ map of /etc zaken. En niet te vergeten /home.

Uiteraard is 't wel op te lossen, door ACLs toe te passen bijvoorbeeld.
Je hebt alleen (hooguit) root-lezen toegang nodig, en maar een commando, dus je kan de boel nog wel behoorlijk afsluiten, kijken naar hoe je ACLs/MACs zinvol kan aanbrengen inderdaad.

Acties:
  • 0 Henk 'm!

  • FRidh
  • Registratie: Januari 2004
  • Laatst online: 08:34
Is het wellicht niet een idee om dit anders aan te pakken? Bijvoorbeeld, draai op de server een cron job die met tar een archief maakt. Je kan dan op de client een anacrontab draaien welke het archief vervolgens zeg dagelijks download en roteert. Okee, het is niet waar je naar vroeg maar misschien nog niet zo'n gek idee.

Research is to see what everybody else has seen, and to think what nobody else has thought - Albert Szent-Györgyi


Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 29-09 19:12
En de rol omdraaien .. vanaf de server backuppen naar bijvb een webdavs server (met bijvb duplicity) ?

Acties:
  • 0 Henk 'm!

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 01-10 08:15

deadinspace

The what goes where now?

FRidh schreef op vrijdag 10 oktober 2014 @ 23:39:
Is het wellicht niet een idee om dit anders aan te pakken? Bijvoorbeeld, draai op de server een cron job die met tar een archief maakt. Je kan dan op de client een anacrontab draaien welke het archief vervolgens zeg dagelijks download en roteert. Okee, het is niet waar je naar vroeg maar misschien nog niet zo'n gek idee.
Dan heb je geen incremental backups (en dus veel dataverkeer), en geen deduplication dmv hard links (dus veel disk storage als je meerdere versies wil bewaren).

Acties:
  • 0 Henk 'm!

Verwijderd

Kijk eens naar rdiff-backup.
http://www.nongnu.org/rdiff-backup/

Met alleen rsync kun je niet backuppen want je hebt dan geen retentie. Een fout die je niet onmiddellijk ziet kan heel snel een probleem worden.

Acties:
  • 0 Henk 'm!

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 01-10 08:15

deadinspace

The what goes where now?

Verwijderd schreef op zaterdag 11 oktober 2014 @ 14:53:
=Met alleen rsync kun je niet backuppen want je hebt dan geen retentie.
Tuurlijk wel, daar is --link-dest voor :)

Acties:
  • 0 Henk 'm!

  • SadisticPanda
  • Registratie: Februari 2009
  • Niet online

SadisticPanda

Heet patatje :o

Duplicty!!! Is je boel nog encrypted en signed ook. Enige nadeel, backupt geen hardlinks, maar daar zijn scripts voor te vinden.

Backups zijn ofc wel incrementeel en lekker simpel terug te zetten. (Retentie)

[ Voor 12% gewijzigd door SadisticPanda op 11-10-2014 19:53 ]

Marstek 5.12kw v151, CT003 v117, Sagecom Xs212 1P,


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik zie alle reacties hier nu pas, bedankt voor alle info. Ik heb het nu inderdaad opgelost door passphraseless key access aan root te geven met alleen toegang tot rsync. Dit lijkt voor alsnog de beste combinatie van simplicity en mate van security die mijn data vereist.
Pagina: 1