rsync datei gehört root

[michaa7]

Sehe ich das richtig?

Wenn ich root login in ssh verboten habe, dann kann ich keine Datei, die root gehört per rsync von Rechner A nach Rechner B kopieren, unter Beibehaltung aller Dateirechte?

Wie dann?

[cosinus]

Äh, das ist dann aber ungünstig. Der User muss dann zumindest Leserechte auf die Datei haben und muss das Verzeichnis auch betreten können dürfen.

[michaa7]

Angenommen ich wollte per rsync eine installation transferieren, dann wird es da Dateien geben die nur root lesen und/oder nur root schreiben darf ....

[cosinus]

Nee, das geht dann nicht. Da musst du dann schon root sein.
Ist das ein Server, der im Internet steht? Wenn nicht, kannst du PermitRootLogin ruhig auf yes setzen. Oder du kloppst auf dem Server in der Datei /root/.ssh/authorized_keys den Key von deinem User deines Clients ein. Geht auch per ssh-copy-id:

Code: Alles auswählen

ssh-copy-id root@neuertower

Dazu müsste dann aber zumindest temporär root Login möglich sein. Oder du machst es mit

Code: Alles auswählen

ssh-copy-id loginuser@neuertower

und kopierst denn den Inhalt von /home/loginuser/.ssh/authorized_keys nach /root/.ssh/authorized_keys

Auf keinen Fall darf dann aber in der sshd_config PermitRootLogin auf no stehen. Also ändere es nach der "Schlüsselübergabe" dann auf without-password.

[michaa7]

...
Ist das ein Server, der im Internet steht?

nein, das ist alles im LAN.
Wenn ich in der sshd_config für ListenAddress die LAN IP eingebe, dann ist doch ein direkter root login, so ich ihn ermögliche, zusätzlich auf Rechner aus dem LAN beschränkt, richtig? Und rsync basier beim login auf den settings in sshd_config, richtig?

[cosinus]

Login mit root geht nur, wenn PermitRootLogin auf yes oder without-password steht bzw. prohibit-password.
Wenn das Ding nur aus dem internen LAN erreichbar ist, setze es einfach auf yes. Du hast doch niemanden, der in deinem internen LAN ist und das Teil angreifen will?

[michaa7]

Login mit root geht nur, wenn PermitRootLogin auf yes oder without-password steht bzw. prohibit-password....

Und wie findet dann die Authentifizierung statt? Wenn da ein Schlüssel benötigt wird, wo kommt der her? Braucht man dann nicht einen gpg schlüssel o.ä?

[cosinus]

Achso, ja. Das hab ich in der Aufregung vergessen. Den musst du dir mit ssh-keygen vorher erstellen. Fallsnicht vorhanden, leg dir noch vorsichtshalber das Verzeichnis .ssh in deinem $HOME an:

Code: Alles auswählen

mkdir ~/.ssh
ssh-keygen -t rsa

Normalerweise wird der private Schlüssel dann als id_rsa gespeichert und der öffentliche in id_rsa.pub, so wie hier in meinem Beispiel:

Code: Alles auswählen

toor@fuckup:~/.ssh$ ls -la
insgesamt 16
drwxr-x---  2 toor toor 4096  7. Dez 23:03 .
drwx------ 15 toor toor 4096  7. Dez 23:03 ..
-rw-------  1 toor toor 2590  7. Dez 23:03 id_rsa
-rw-r-----  1 toor toor  565  7. Dez 23:03 id_rsa.pub

[michaa7]

...
ssh-keygen -t rsa
...

Ist das egal in welchem Verzeichnis ich mich dabei befinde? Kommt mir komisch vor ...

Und will will ja einen Schlüssel für root, also kommt der nach /root/.ssh

Und muss der pub schlüssel dann nicht auf den Rechner von dem aus ich mich verbinden möchte? Das wäre dann aber henne und ei ... oder ?

[cosinus]

Nein nein, das ist das Schlüsselpaar für deinen User auf dem Client. Das muss schon nach ~/.ssh
Wenn du dann dich mit einem entfernten PC als verbinden willst, dann muss das was in id_rsa.pub steht auf dem entfernten PC nach /root/.ssh/authorized_keys. In authorized_keys steht also eine Liste der öffentlichen Schlüssel, die berechtigt sind. Und wie gesagt, ssh-copy-id nimmt das für dich ab.

[michaa7]

Nein nein, das ist das Schlüsselpaar für deinen User auf dem Client. Das muss schon nach ~/.ssh
Wenn du dann dich mit einem entfernten PC als verbinden willst, dann muss das was in id_rsa.pub steht auf dem entfernten PC nach /root/.ssh/authorized_keys. In authorized_keys steht also eine Liste der öffentlichen Schlüssel, die berechtigt sind. Und wie gesagt, ssh-copy-id nimmt das für dich ab.

OMG, ich verstehe es nicht..., aber vielleicht reden wir aneinander vorbei.

*ich* rede nur vom root login, nicht vom user login. Ich will in jedem Fall eine Trennung zwischen user und root (so wie ich z.b. auch kein sudo nutze!)

Mir scheint aber du beschreibst da irgendein user-als-root scenario, oder sehe ich das falsch? Oder gar ein reines user login via key.

[cosinus]

Du willst dich von deinem Rechner, sagen wir dein User heißt michaa, als root auf dem entfernten Rechner einloggen oder nicht?
Dann tippst du das ein:

Code: Alles auswählen

ssh root@neuertower

Wenn vorher der öffentliche Schlüssel von "micha" auf dem entfernten Rechner in /root/.ssh/authorized_keys drinsteht, dann bist du nach Ausführen des Befehls sofort per SSH als root drauf. Ok, vllt musst du noch ne Passphrase für deinen privaten key eingeben, aber das ist nur optional. Mit User als root also sowas wie sudo hat das nichts zu tun.

Wenn das erstmal zuviel ist mach dich erstmal so mit ssh vertraut ohne das Key-Gedöns.

[michaa7]

Du willst dich von deinem Rechner, sagen wir dein User heißt michaa, als root auf dem entfernten Rechner einloggen oder nicht?
Dann tippst du das ein:

Code: Alles auswählen

ssh root@neuertower

Wenn vorher der öffentliche Schlüssel von "micha" auf dem entfernten Rechner in /root/.ssh/authorized_keys drinsteht, dann bist du nach Ausführen des Befehls sofort per SSH als root drauf. Ok, vllt musst du noch ne Passphrase für deinen privaten key eingeben, aber das ist nur optional. Mit User als root also sowas wie sudo hat das nichts zu tun.

Wenn das erstmal zuviel ist mach dich erstmal so mit ssh vertraut ohne das Key-Gedöns.

ssh nutze ich seit fast zwei jahrzehnten ....aber halt mit PW UND mir geht es ja weniger um ssh sondern um rsync.

Was mir im Moment nicht klar ist ist ob deine Vorgehensweise ein Trick ist oder die einzige vorgehnsweise sich als root einzugoggen. Denn das gibt ja einem user rootrechte auf einem fremden rechner. Deshalb empfinde ich das nicht als sauber getrennt.

[cosinus]

???

Du wolltest doch zuerst, dass man sich als root NICHT einloggen darf. Das hab ich dann versucht zu erklären. Entweder ja, nein oder man nimmt den Kompromiss, dass man sich als root nur mit Key-Auth einloggen darf. Such dir was aus.

rsync greift dann auf ssh zurück, also das muss dann schon funktionieren.

[michaa7]

Du verstehst wahrscheinlich WORAUF du antwortest, ich nicht mehr.

Ich lasse das jetzt und baue morgen die Platten jeweils aus und in den neuen Rechner ein und kopiere was ich brauche.

Danke dir für den Versuch.

n8

[cosinus]

Vergiss das einfach mi dem Key. Wir haben uns da wohl verhaspelt, weil ich dachte du willst nicht, dass man sich mit normalen Mitteln also einfach per Passwort als root einlogen darf.

Mach im SSH-Server einfach die Zeile mit PermitRootLogin mit einem yes rein. Dann den SSH-Dienst reloaden oder restarten.

Dann kannst du dich von einem anderen Rechner per root direkt einloggen. Natürlich mit dem Passwort für root von "neuertower". Das musst du dann natürlich gesetzt haben. Wenn dann alles funktioniert, kannst du vom Client aus beliebige Verzeichnisse des entfernten Rechners mounten zB

Code: Alles auswählen

mount.sshfs root@neuertower:/etc /media/neuertower

Dann ist das Verzeichnis /etc vom "Server" eingebunden in /media/neuertower auf deinem Client. Dann kannst mit rsync oder einem anderen Tool machen was du willst.

[michaa7]

Ok, obwohl ich das ja schon beendet hatte, dieser Vorschlag erscheint mir im LAN ok und ich glaube ihn zu durchblicken ... ist ja recht transparent. Jetzt bin ich definitiv zu müde, aber morgen werde ich das versuchen ... und es wird klappen.

Es scheint mir für eine temporäre Lösung sogar besser als die anderen Optionen.

Danke.

Jetzt wirklich n8.

EDIT:
hm, nicht mehr ganz so sicher:

1) ist mount.sshfs richtig? Weil ich weder in man mount noch in man sshfs diese notierung findet.

2)

By default, file permissions are ignored by SSHFS. Any user that can
access the filesystem will be able to perform any operation that the
remote server permits - based on the credentials that were used to con‐
nect to the server. If this is undesired, local permission checking can
be enabled with -o default_permissions.

Ich bin mir nicht sicher ob es sinnvoll ist systemverzeichnisse auf diese Weise zu kopieren. Ich muss sicher sein anschließend keinen userrechtesalat im kopierten System zu hinterlassen.

[cosinus]

Du kannst auch mit rsync direkt auf ein ssh-Ziel speichern oder lesen lassen. Aber mit sshfs gemountet stellt sich das entfernte Verzeichnis dann wie ein lokales dar.

[HumiNi]

Wenn es dir "nur" ums Kopieren (also nicht Synchronisieren) geht - Stichwort: installation transferieren) - und du genügend Platz hast, könntest du unter Umgehung des root-logins folgenden Weg gehen:
- Archiv (z.B tar-Ball) erzeugen als root
- Kopieren des Archivs als "normaler" User auf das remote-System
- Auspacken des Archivs als root

[michaa7]

Wenn es dir "nur" ums Kopieren (also nicht Synchronisieren) geht - Stichwort: installation transferieren) - und du genügend Platz hast, könntest du unter Umgehung des root-logins folgenden Weg gehen:
- Archiv (z.B tar-Ball) erzeugen als root
- Kopieren des Archivs als "normaler" User auf das remote-System
- Auspacken des Archivs als root

Klingt gut, aber ausser Platz braucht man wohl auch zeit, und dann die doppelte, oder? 20GB packen, bei (großzügig nur wg prinzip) 50% packvolumen 10GB kopieren, und dann wieder auf 20GB entpacken ...
Ich habe es nie gemacht, aber da kommt mehr als die doppelte Zeit raus, oder?

[HumiNi]

Ich habe dazu keine praktischen Erfahrungen. Das war nur eine Idee. Die Zeit hängt aber garantiert von deiner Hardware ab.
Wenn du es geschickt anstellst, speicherst du das Archiv nicht ab, sondern schickst es in eine Pipe. Ebenso auf dem Zielsystem: Nicht speichern, sondern in einer Pipe root zum Entpacken vorwerfen.

[michaa7]

Ich habe dazu keine praktischen Erfahrungen. Das war nur eine Idee. Die Zeit hängt aber garantiert von deiner Hardware ab.
Wenn du es geschickt anstellst, speicherst du das Archiv nicht ab, sondern schickst es in eine Pipe. Ebenso auf dem Zielsystem: Nicht speichern, sondern in einer Pipe root zum Entpacken vorwerfen.

Ja klingt toll, aber überfordert mich. Und klitzekleine Anmerkung: In einer pipe kann ich zweimal den user wechseln? Das geht (wenn man weiß wie)???

[cosinus]

Die Idee ist aber nicht schlecht. Man könnte das noch weiterspinnen und in Erwägung ziehen, regelmäßig per cronjob so ein Archiv zu erstellen und das dann auf einem Volume mit genügend Platz abzulegen. Das könnte man dann auch einfach per samba oder nfs verfügbar machen und dann aus dem Archiv direkt auf dem Zielsystem/Client entpacken bei Bedarf.

[michaa7]

Die Idee ist aber nicht schlecht. Man könnte das noch weiterspinnen und in Erwägung ziehen, regelmäßig per cronjob so ein Archiv zu erstellen und das dann auf einem Volume mit genügend Platz abzulegen. Das könnte man dann auch einfach per samba oder nfs verfügbar machen und dann aus dem Archiv direkt auf dem Zielsystem/Client entpacken bei Bedarf.

Das beantwortet nicht die Frage: kann man in der vorgeschlagenen pipe wirklich zwei mal den user wechseln?

[cosinus]

Das beantwortet nicht die Frage: kann man in der vorgeschlagenen pipe wirklich zwei mal den user wechseln?

Muss man das denn, wenn das Archiv schon fertig da liegt? Du musst doch nur vom Client aus an das Archiv herankommen, zB nach /mnt mounten und dann kannste es mit root (auch am Client) überall hin entpacken.