Tag Archives: SSH

firejail firecfg – Problem mit dem KDE-Login unter Opensuse Leap 42.3 – .ssh-Dateien und ssh-agent als Ursache

Posted on by

Experimentiert man unbedarft mir neuen Dingen, muss man sich nicht wundern, wenn man sich Probleme schafft. Jetzt passierte mir das mit firejail.

Ich muss manchmal Skype benutzen. Zu meinem großen Ärger, da jede Art von Closed Source UDP-Streaming Applikation ein prinzipielles Sicherheitsrisiko darstellt. In einen UDP-Datenstrom können immer Pakete integriert werden, die ganz anderen Zwecken dienen als der Übertragung der eigentlichen Audio- und Videodaten. Und wenn man dann den Code nicht kennt … Neben dem Aufsetzen eines speziell konfigurierten Containers ist die Nutzung von Firejail eine Gegenmaßnahme, solchen Applikationen das Vordringen ins System zu erschweren.

Opensuse 42.3 bietet im Repository “Virtualization”
ein RPM-Paket firejail 0.9.5 zum Download an. Das habe ich installiert. nach der Installation war zunächst auch ein kein Problem feststellbar.

Aber dann habe ich ein wenig in der Dokumentation gestöbert. Auf der Seite https://firejail.wordpress.com/documentation-2/ findet man dann unter dem Titel “I’ve just installed Firejail, now what?!” Hinweise zu bestimmten Kommandos, um “pulseaudio” [PA] zu korrigieren (wundert mich nicht) und auch das Kommando “firecfg” auszuführen:

$ firecfg –fix-sound
$ sudo firecfg

Beides hat u.U. aber unangenehme Nebenwirkungen:

1) Pulseaudio zunächst nicht mehr deaktivierbar
Das erste Kommando korrigiert “pulseaudio”-Konfigurationsdateien zwar; es sorgt aber auch dafür, dass man unter Opensuse PA nicht mehr einfach über YaST und die dortige Audio-Konfiguraiton abschalten kann. Bekanntermaßen verwende ich PA nur, wenn nicht umgehbar. So erzwangen etwa frühere Skype Versionen für Linux ( u.a. die Version 4.3) die Nutzung von PA. Das ist beim aktuellen “skypeforlinux” (Beta) nicht der Fall; das kooperiert auch direkt mit Alsa.

Das ist auf meinem Laptop auch gut so, denn PA erzeugt dort ein dauerhaftes unangenehmes Hintergrundsgeräusch (niederfrequenter Pfeifton; keine Rückkopplung) auf meinem eingebauten Mikrophon (unabhängig von Skype). Das ließ sich auch durch Ändern der Empfindlichkeit und der Regelung von Verstärkungsfaktoren unter dem PA-eigenen “pavucontrol” nie beseitigen. Ein solches Geräusch tritt bei mir im reinen Alsa-Betrieb dagegen nicht auf.

Beseitigt habe ich die Aktivierung von PA dann durch Umbenennen/Verschieben der Datei “~/.pulseaudio” und anschließende erneute Deaktivierung von PA über YaST.

2) Kein KDE-Login und kein X11-Start mehr für bestimmte Accounts möglich
Schlimmer ist dagegen eine Auswirkung des zweiten Kommandos: Es erzeugt eine Liste von Links unter dem Verzeichnis von “/usr/local/bin“, die alle auf firejail verweisen. Normalerweise führt das dazu, dass viele Programme/Anwendungen über firejail gestartet und geschützt werden. Leider ist die Liste der Profile für Anwendungen aber keineswegs vollständig. Wird für eine Anwendung nichts gefunden, dann kommt wohl ein “default.profile” zum Einsatz. Letzteres verhindert aber den Zugriff u.a. auf ~/.ssh und ~/.gnupg-Verzeichnisse und dortige Dateien. Das wird aber unter Umständen unter Opensuse zu einem Megaproblem beim Start von KDE aus SDDM oder KDM heraus:

Ich konnte mich unter bestimmten Accounts nach dem Absetzen von firecfg nicht mehr von KDM oder SDDM aus in KDE (Plasma 5) einloggen. X11 wurde nicht gestartet; man landet nach ca. 1 Sekunde wieder auf dem KDM oder SDDM-Login-Schirm.

Die Fehlermeldungen hierzu waren unzureichend. Nach mühsamen Experimenten mit Konfigurationsdateien stieß ich schließlich darauf, dass allein die Existenz eines “~/.ssh“-Verzeichnisses zu Fehlern beim KDE-Start
führte. Entfernte ich das Verzeichnis komplett, ließen sich KDE und X11 wieder regulär starten.

Wer oder was will im Start “~/.ssh” auslesen? Mir fiel dazu zunächst nichts ein. Dann stieß ich auf ssh-agent. Und tatsächlich ergab sich unter Opensuse Leap 42.3 folgendes Bild: 

mytux:~ # ps aux | grep ssh
root      1574  0.0  0.0  53492  5816 ?        Ss   13:30   0:00 /usr/sbin/
sshd -D
myself       4065  0.0  0.0  20136  1868 ?        S    13:30   0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/
agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc
myself       4067  0.0  0.0  13312   332 ?        Ss   13:30   0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc

Offenbar klappt diese Art des X-Starts nicht mit dem komplett gefüllten “/usr/local/bin” (genauer mit den dortigen Links). Ich sehe die Ursache – wie gesagt – im “default.profile”.

Die Link-Orgie unter “/usr/local/bin” beseitigt man übrigens mit

firecfg –clean

Danach klappt der Login in das X11/KDE-Gespann alles wieder. Meine Strategie ist im Moment, die Profile für verschiedene Anwendungen zu checken und “/usr/local/bin” langsam und systematisch mit Links zu füllen, die nur bestimmte Anwendungen betreffen.

Bei manchen alten Accounts habe ich zudem festgestellt, dass die Anlage der Links unter /usr/local/bin” auch dazu führt, dass jeglicher Netzwerkzugriff unterbunden ist. Hier bin ich noch an der Ursachenforschung.

Merke: Nicht gleich alles machen, was Manuals vorschlagen, wenn man von einer neuen Anwendung noch zu wenig versteht.

Veracrypt, SSHFS und kryptierte Datenhaltung auf gehosteten Servern – I

Posted on by

Ich kenne einige Kleinstunternehmen und Freiberufler, die Kunden- oder gar Patientendaten bei einem Provider lagern wollen. Zu Backup-Zwecken oder gar für einen Remote-Zugriff. Für mich stellt sich da die Frage:

Wie weit kann und darf man seinem Provider für gehostete Server oder Cloud-Dienste eigentlich trauen?

Administratoren haben bei Internet-Providern ja nicht nur theoretisch, sondern je nach Berechtigungsstufe faktischen, d.h. administrativ-digitalen oder womöglich gar physikalischen Zugriff auf die gehosteten Systeme und angebundene Datenhaltungssysteme. Der potentielle Zugriff ist in vielen Hosting-Szenarien (Container-Technologie etc.) inhärent gegeben und für den ordnungsgemäßen Betrieb z.T. sogar notwendig; unabhängig davon, ob sich Administratoren für die gelagerten Inhalte interessieren oder nicht. Einen potentiellen Zugriff von IT-Verantwortlichen auf die Inhalte von Daten oder Datenströme auf gehosteten Systemen verhindert auch eine ISO 27001-Zertifizierung des Providers (z.B. von Strato) nicht zwingend. Gesetzliche Datenschutz- und Geheimhaltungsvorgaben – insbesondere für Patientendaten – sind in simplen Hosting-Szenarien deshalb nur schwer einzuhalten. Hinzu kommt das Risiko potentieller Schwachstellen in der Technik zur Isolation gehosteter Dienste oder virtualisierter Server gegeneinander – insbesondere bei Einsatz von Container-Technologien.

Für Daten, die im eigenen oder – oft noch wichtiger – im Kundeninteresse zwingend geheimzuhalten sind, ist daher folgende Regel angebracht: “Im Internet und in der “Cloud” gibt es keine Freunde”.

Sichere Ablage von privaten Dateien oder Kunden-Daten auf gehosteten Systemen?

Was also tun, wenn man oft unterwegs ist und eine Art sicheren, privaten Cloud-Dienst benötigt, der es einem bei Bedarf erlaubt, z.B. vom Notebook aus zumindest auf einzelne, wichtige Dateien zuzugreifen? Die aber niemand anderes einsehen soll?

Aufwand und Kosten für Betrieb und Absicherung eines eigenen, im Internet exponierten Servers sind für kleine Firmen und Freiberufler durchaus ein Thema … Dann will man einerseits gerne auf Hosting-Angebote zurückgreifen, andererseits aber auch seine Geheimhaltungspflichten nicht verletzen … Und was tun, wenn der gewünschte Datenzugriff gar für mehrere Personen (in begrenzter Anzahl) ermöglicht werden soll?

Oftmals reichen in einem Szenario mit Remote-Zugang rein lesende Zugriffe auf die zentral gelagerten Daten aus. Zu ändernde Inhalte synchronisiert man ggf. rollierend in einem speziellen organisatorischen Prozess über einen definierten administrativen User.

Ein anderes, einfacheres Szenario ist die sichere Lagerung von verschlüsselten Daten als Backup bei einem Cloud-Dienst. Da will ein beauftragter Admin bei Gelegenheit ggf. nur einige Files oder Verzeichnisse austauschen oder zum aktuellen Bestand hinzufügen – und nicht alle zu sichernden Daten komplett neu hinterlegen. Umgekehrt will er bei Bedarf nur bestimmte Versionen von einigen Dateien aus dem verschlüsselten Archiv zurückholen. Andere Benutzer haben zum Backup jedoch keinen Zugang.

Unter diesen Voraussetzungen beginnt man sich als Linux-Anwender dafür zu interessieren, ob und wie man verschlüsselte Container-Files auf einem Server nutzen und bei Bedarf auf einem Client sicher über das Internet öffnen oder mounten kann. Geht so was? Wenn ja, ist das auch hinreichend schnell?

Ich bespreche nachfolgend einen Ansatz, der auf einem gehosteten Linux-Server, Linux-Endgeräten und Veracrypt aufbaut. Ich gehe davon aus, dass die geheimzuhaltenden Daten auf dem gehosteten Server in einem Veracrypt-“Container” lagern. Ich setze den Umgang mit und Wissen über Veracrypt [VC] voraus. Unter https://www.veracrypt.fr/ en/ Documentation.html findet man u.a ein Tutorial.
Das grafische VC-Interface macht das Erstellen und Mounten von Container-Dateien zu einer relativ einfachen Übung.

Das jeweilige (mobile) Endgerät, das auf den gehosteten Server zugreifen soll, bezeichne ich nachfolgend schlicht als “Client”. Es geht in diesem Artikel primär um die sichere Lagerung der Daten auf dem Server; dennoch halte ich ein einem zweiten ergänzenden Artikel auch ein paar grundsätzliche Anmerkungen zur Sicherheit der Daten auf den Clients für angebracht.

Einschränkung:
Ich behaupte und impliziere mit diesem Artikel keineswegs, dass die Nutzung von verschlüsselten Containern eine Maßnahme ist, die für sich schon Datenschutzvorschriften und Gesetzen, die die Geheimhaltung von Daten regeln, genügen würde. Das nachfolgende Diskutierte kann höchstens ein mögliches Element in einer ganzen Kette von Sicherheitsmaßnahmen sein. Genaueres muss man in jedem Fall mit seinem Datenschutzbeauftragten und auch Anwälten klären.

Verschlüsselung

Die dauerhafte Lagerung der Daten soll bei einem Provider oder Cloud-Dienst erfolgen. Aus der Einschränkung, dass Fremde und das Personal beim Provider die Daten in keinem Fall einsehen dürfen, ergibt sich:

Die geheimzuhaltenden Daten dürfen nur auf dem eigenen Endgerät bzw. den Endgeräten der eigenen Mitarbeiter in eine unverschlüsselte Form gebracht werden – und auch dort nur temporär.

Wesentlich ist einerseits also eine (hochwertige) Verschlüsselung auf allen relevanten Ebenen des Zugriffs und der Lagerung. Anderseits sind Vorkehrungen zu treffen, dass eine Entschlüsselung nur auf bestimmten Geräten abseits des Servers stattfindet:

  1. Anforderung 1: Ausschließlich verschlüsselte Ablage der Daten auf dem gehosteten Linux-Server. Das bedeutet aber auch: Auf dem Server dürfen keine unverschlüsselten Daten/Dateien/Dateifragmente im Speicher oder gar den Datenhaltungssystemen auftreten und verbleiben.
  2. Anforderung 2: Verschlüsselung des Transportwegs zum und vom Server.
  3. Anforderung 3: Entschlüsselung der Daten nur auf dem Client.
  4. Anforderung 4: Verschlüsselung bearbeiteter Dateien auf dem Client vor dem Rücktransfer zum Server.

Ein paar ergänzende Hinweise sind aus meiner Sicht angebracht:

Hinweis 1:

Da ein Betriebssystem, Linux-Desktop-Systeme und nicht zuletzt Anwendungen Daten in allen möglichen Verzeichnissen puffern und/oder im Hinhtergrund Sicherungskopien erstellen, bedeuten die Anforderungen 1 und 3, dass wir das Container-File nie (!) auf dem Server mounten und dort auch nie auf dessen Inhalte zugreifen dürfen. Würde man das tun, stünden die geheimzuhaltenden Daten dort ja irgendwo unkontrolliert im Klartext bereit. Besonders kritisch sind in diesem Zusammenhang übrigens SSDs mit Wear Leveling zu sehen (s. den kommenden 2-ten Artikel dieser Miniserie). Heute sind solche SSDs aber fast immer Teil von Hosting-Angeboten. Also:

Ein Szenario, bei dem Anwender über das Internet auf einen auf dem Server gemounteten und entschlüsselten VC-Container zugreifen, der für externe Nutzung (z.B. über NFS) freigegeben wurde, verbietet sich in unserem Szenario von vornherein.

Das ist eine ziemlich massive Einschränkung! Klassische VPN-Ansätze sind somit ohne weitere Maßnahmen unzureichend. Und auch der “Multiuser”-Zugriff auf per NFS bereitgestellte Containerinhalte fällt flach. Um erst gar nicht in Versuchung zu kommen, installiert man das Tool Veracrypt auf dem Server am besten überhaupt nicht. (Es wird dort auch nicht benötigt.)

Hinweis 2:

Die meisten Hosting-/Cloud-Angebote bzgl. Speicherplatz – u.a. auch Stratos HiDrive – verschlüsseln zwar den Transportweg, erfüllen aber nicht die Bedingung einer verschlüsselten Lagerung der Dateien im technisch meist unspezifizierten “Cloud”-Speicher. Tatsächlich empfiehlt z.B. Strato für die sichere Lagerung von Daten eine “Synchronisation” – genauer ein Up- und Downloaden – von verschlüsselten Containerdateien.

Obwohl nicht primäres Thema dieses Artikels wollen wir bereits erste Bedingungen bzgl. der Sicherheit der Daten auf dem Client formulieren. Schließlich will man Dateien, die man aus dem Server-Archiv kopiert hat, ja auch auf seinem eigenen Endgerät vor der Einsichtname durch Fremde schützen – z.B. für den Fall eines Verlusts des Laptops/Notebooks. Eine vollständige Sicherheitskette muss deshalb u.a. auch folgenden Anforderungen gerecht werden:

  • Anforderung C1: Haltung/Lagerung von Dateien, die aus dem zentralen VC-Container auf den Client (Notebook/Laptop) kopiert wurden, nur in verschlüsselter Form.
  • Anforderung C2: Vermeidung der Ablage von Dateien/Dateifragmenten, die durch das Öffnen von Dateien aus dem Container auf dem Client in unverschlüsselter Form entstehen und ggf. an verschiedenen Stellen des Verzeichnisbaums gespeichert werden.

Hinweis 3:
Vielen Anwendern ist nicht klar, dass die eigentliche Herausforderung bzgl. einer durchgehenden Datensicherheit in der Anforderung C2 besteht. Siehe hierzu die Anmerkungen und Hinweise im zweiten Artikel dieser Serie.

Einsatz von verschlüsselten Veracrypt-Containern

Würde man nur lokal arbeiten, könnte man zur Erfüllung der Anforderungen 1 und 3 auf Tools zur Erstellung verschlüsselter Container-Dateien zurückgreifen, die dann (als Loop-Device) im Dateisystem des Clients unter gleichzeitiger Dekryptierung gemounted werden. Entsprechende Anwendungen erledigen die Ver- und Entschlüsselung quasi “en passant”.

In Frage kommen hierfür unter Linux etwa LUKS, aber eben auch Veracrypt. Letzteres betrachten viele als verbesserten Nachfolger von Truecrypt.

Der Hauptentwickler von Veracrypt ist übrigens Franzose. Vive la France! Die Entwickler haben VC mit Hilfe von Sponsoren im Jahr 2016 einem Sicherheitsaudit unterziehen lassen. Das weckt Vertrauen. [Der Vollständigkeit halber sei darauf hingewiesen, dass meines Wissens aber noch nicht alle Mängel aus dem Sicherheitsaudit von 2016 behoben sind – sehr wohl aber die wichtigsten (s. die entsprechenden Links am Ende des Artikels)]. Für uns relevant ist hier aber folgende Aussage der Entwickler:

Note that VeraCrypt never saves any decrypted data to a disk – it only stores them temporarily in RAM (memory). Even when the volume is mounted, data stored in the volume is still encrypted.

Zitiert nach “https://www.veracrypt.fr/ en/ Beginner%27s%20 Tutorial.html“. (Hervorhebung von mir.)

So wie das geschrieben ist, sollte das also auch gelten, wenn das Verzeichnis, auf dem die Veracrypt-Container-Datei liegt, mit einem geeignetem Tool auf einem Remote-System gemounted wird. Der Container auf dem Server enthält und erhält auch dann nur kryptierte Daten.

1-User-Szenario mit Veracrypt

Wir betrachten zunächst ein 1-User-Szenario. Der User habe auf dem Server den Usernamen “smy” und auf dem Client “myself“.

Ich gehe davon aus, dass der Anwender mit Hilfe von Veracrypt bereits ein verschlüsseltes Container-File angelegt und dieses über SFTP oder SCP auf dem gehosteten Server hinterlegt hat. (Der Anwender hat es dort aber wegen der oben angeführten Gründe nie geöffnet!)

Das
Container-File selbst sei auf dem Server als Datei “/mydirs/conts/vc_cont_srv” gespeichert, also im Verzeichnis “/mydirs/conts”.

Weiter gehe ich davon aus, dass der Anwender auch lokal (auf dem Client) einen verschlüsselten Veracrypt-Container angelegt hat, um dort Dateien (evtl. Datei-Kopien vom Server-Container) verschlüsselt abzulegen. Der lokale Veracrypt-Container sei in Form der Datei “/home/myself/mycont/vc_cont_cli” gespeichert.

Auf dem Client seien mehrere Mount-Punkte für Remote-Verzeichnisse und VC-Container vorgesehen.

Mount-Punkte auf dem Client:

  • “/home/myself/mnt_remote” für das Mounten eines beliebigen Remote-Verzeichnisses (hier etwa von “conts”).
  • “/home/myself/mnt_vc_srv” für das Mounten des Veracrypt-Containers vom Server (“vc_cont_srv”).
  • “/home/myself/mnt_vc_cli” für das Mounten des lokalen Veracrypt-Containers (“vc_cont_cli”).

Zielsetzung: Zweistufiges Mounten statt Hin- und Herschieben kompletter Containerfiles

Wir möchten in unserem Szenario nicht größere Containerfiles vom Server zum Client kopieren, dort lokal mounten, damit arbeiten und danach wieder das geänderte Veracrypt-Containerfile vollständig auf den Server zurückschieben. Das ist unbequem und kostet bei großen Containern in Abhängigkeit von der Bandbreite der Internet-Anbindung des Clients natürlich Zeit – besonders beim Upload.

Unser Lösungsansatz besteht vielmehr darin, das Verzeichnis des Servers, das den VC-Container enthält, remote auf dem Client zu mounten. Anschließend hängen wir das Containerfile mit Hilfe von Veracrypt in den lokalen Verzeichnisbaum des Clients ein. In der obigen Skizze sind beide sukzessiven Schritte des Mountens angedeutet.

Die Dekryptierung und bei Änderungen auch die Kryptierung von Container-Inhalten (neue oder geänderte Files/Verzeichnisse) würde im Zuge eines solchen Verfahrens allein im RAM des Clients vor sich gehen.

Nun ist Mounten ein Prozess, bei dem nicht das gesamte Filesystem durchforstet werden muss, und der deshalb schnell ist. Unsere Hoffnung ist also, dass dies auch für das Mounten des VC-Containers aus einem remote gemounteten Verzeichnis gilt. Falls das so funktionieren würde, läge der wünschenswerte Unterschied gegenüber einem Hin- und Her-Kopieren des gesamten Container-Files vor allem darin, dass bei Zugriffen auf Container-Inhalte nur diejenigen (verschlüsselten) Datenbereiche über Inodes addressiert und transferiert würden, die am Client tatsächlich benötigt werden.

Zunächst (beim Mounten) vor allem Veracrypt-Header und Verzeichnisstrukturinformationen. Blöcke, die zu einzelnen Dateien gehören, welche anschließend dem Client mit lokalen Instrumenten wie Editoren geöffnet werden, müssten allerdings vollständig übertragen werden (soweit es sich nicht um streambare Dateien handelt) – aber eben nur die Blöcke der zu bearbeitenden Dateien. Und nicht der komplette Container. Ein vollständiger Datei-Transfer ist ggf. auch für Schritte zum (Zwischen-) Speichern geänderter Dateien zu erwarten (s.u.). Deshalb arbeiten wir auf dem Client evtl. effizienter mit Kopien (s.u.), die wir nach Abschluss der Arbeiten wieder in den gemounteten Container laden.

Einsatz von SSH für die Verschlüsselung des Transportweges

Um der Anforderung 2 nachzukommen, können wir unter Linux z.B. auf SSH (genauer: OpenSSH mit Key-Authentication) setzen. Ansonsten müssten wir uns mit einer aufwändigen Kerberos- und NFS4- Konfiguration herumschlagen,
um eine hinreichende Verschlüsselung zu erreichen. SSH bringt zugegebenermaßen Latenzprobleme mit sich – aber bei aDSL/vDSL-Verbindungen mit begrenzten Upload-Geschwindigkeiten ist das vermutlich nicht mal das primäre Problem, über das es sich nachzudenken lohnt.

Wie man SSH für eine schlüsselbasierte Authentifizierung konfiguriert, habe ich in diesem Blog schon mehrfach an anderer Stelle besprochen. Ich gehe daher davon aus, dass für den SSH-Zugang zum gehosteten Server auf dem Client ein (passwortgeschütztes) Keyfile etwa unter “~/.ssh/KEYFILE” bereitsteht.

Zu weiteren Maßnahmen für eine Absicherung der SSH-Verbindung gegenüber Angriffen siehe etwa https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html. In Sinne des genannten Artikels hat man sich natürlich um aktuelle OpenSSH-Versionen zu kümmern. Vor allem aber sollte man die einzusetzenden asymmetrischen SSH-KEX-Algorithmen, symm. Verschlüsselungs- und Hash-Algorithmen auf noch als sicher geltende Verfahren einschränken!

Einsatz von SSHFS

SSH erlaubt zunächst nur eine verschlüsselte Verbindung. Wir wollen in unserem Szenario ja aber das Verzeichnis “conts” vom Server mounten. Dafür haben wir mehrere Möglichkeiten, u.a.

  • CIFS über einen SSH-Tunnel,
  • NFS3/4 über einen SSH-Tunnel.
  • NFS4 mit Kerberos
  • SSHFS.

Vermutlich ist NFS4 die performanteste und skalierbarste unter den genannten Alternativen. NFS4 erfordert jedoch Einiges an grundsätzlicher Konfigurationsarbeit – im Besonderen bzgl. der Benutzerberechtigungen. Hinzu kommt die Einrichtung der SSH-Tunnel. Will man SSH-bedingte Latenzprobleme vermeiden, führt kein Weg an NFS4 und Kerberos vorbei. Damit sind manche User evtl. überfordert.

Ich greife in diesem Artikel daher mal zu SSHFS; das kombiniert mir den Einsatz von FUSE bei gleichzeitiger Verschlüsselung der Verbindung: FUSE erlaubt es, Filesysteme auf einfache Weise im Userspace zu mounten. SSHFS erlaubt das Mounten von Remote-Verzeichnissen über FUSE und unter SSH. Dabei werden u.a. Fähigkeiten von SFTP genutzt. Letzteres ist bei OpenSSH dabei. Voraussetzung der Nutzung ist die Installation der Distributionspakete zu FUSE und SSHFS. Auf dem Server muss OpenSSH natürlich hinreichend eingerichtet sein. Der zugehörige Port muss in der Firewall geöffnet sein. Zugangsberechtigungen sollten auf User-, Gruppen-Ebene und Host-Ebene geregelt sein.

Es ist – wie bei SFTP auch – möglich, bestimmte SSHFS-Benutzer auf das Mounten definierter Verzeichnisse unterhalb eines CHROOT-Verzeichnis einzuschränken. Dafür nimmt man als Admin normale SFTP-Einstellungen für User- und Gruppen-Zugriffe auf ein definiertes CHROOT-Directory vor. Siehe hierzu etwa
https://wiki.archlinux.org/ index.php/SSHFS
https://wiki.archlinux.org/ index.php/ SCP_and_SFTP
SFTP mit Key-Authentication auf (gehosteten) Linux-Servern für Web-Entwickler mit unterschiedlichen Privilegien – II

Performance von SSHFS?

Man sollte sich bei Gelegenheit mit den Parametern von SSHFS zum Caching, zur Komprimierung etc. befassen. Das Schöne ist, dass man bei etwas Optimierung in einigen Anwendungsfällen sehr wohl an die Performance von NFS herankommt – mit Ausnahme von Random Read-Operationen (max. 60% der NFS-Performance ohne SSH-Tunnel). Siehe für Benchmark-Daten und Optimierungshinweise:

http://www.admin-magazine.com/ HPC/ Articles/ Sharing-Data-with-SSHFS
https://www.smork.info/ blog/ 2013/04/24/ entry130424-163842.html
http://www.linux-magazine.com/ Issues/ 2014/165/ SSHFS-MUX
http://homepages.warwick.ac.uk/ staff/ E.J.Brambley/ sshspeedtest.php
Kritik: http://julio.meroh.net/ 2016/02/ sshfs-performance-analysis-for-builds.html

Tip: Bei langsamen Leitungen sollte man unbedingt auch Performance-Vergleiche für Zugriffe mit oder ohne Kompression anstellen.

Mounten des Server-Verzeichnisses mit SSHFS

Ich gehe mal davon aus, dass auf dem Client (Laptop/Notebook/PC) zu einem bestimmten Zeitpunkt nur ein User – hier “myself” – arbeitet. Wie mounted der nun konkret ein Verzeichnis vom Server unter Beachtung des Key-Files mit SSHFS?

Der Server habe beispielsweise die Adresse “h1234567.stratoserver.net”. Der SSH-Zugang sei dort in der Firewall z.B. unter dem Port 57888 geöffnet. Der notwendige Befehl zum Mounten des oben angegebenen Remote-Verzeichnis wäre dann: 

myself@mytux:~> sshfs -p 57888 -o "IdentityFile=/home/myself/.ssh/KEYFILE"  smy@h1234567.stratoserver.net:/mydirs/conts/ ~/my_mnt -o idmap=user -o uid=$(id -u) -o gid=$(id -g) 
Enter passphrase for key '/home/myself/.ssh/KEYFILE':

 
Durch die Optionen “-o uid=$(id -u) -o gid=$(id -g)” wird eine Abbildung der UID und GID des lokalen Users “myself” auf den Remote-User “smy” und dessen Rechte geleistet! Das ist eine sicherheitsrelevanter Punkt, den man bei Konfigurationen für mehrere User im Auge haben muss.

Hinweis: Man kann die Optionen übrigens auch nur nach einem “-o”, dann aber kommasepariert angeben.

Man wird zur Eingabe des Passworts aufgefordert. Danach steht einem der Inhalt des gemounteten Verzeichnisses bereits zur Verfügung: 

myself@mytux:~> la my_mnt
insgesamt 573448
drwx------  1 myself users      4096 19. Aug 14:58 .
drwxr-xr-x 83 myself users      4096 20. Aug 15:38 ..
-rw-------  1 myself users 524288000 19. Aug 15:29 vc_cont_srv
myself@mytux:~>

Mounten des Veracrypt-Containers auf dem Client – Fehlermeldung ???

Funktioniert nun bereits der zweite Schritt, nämlich ein lokales Mounten des Containers “vc_cont_srv”, der uns auf dem Client ja nun unter “/home/myself/my_mnt/vc_cont_srv” zur Verfügung steht? Leider Nein!

Versucht man wie gewohnt, den Container mit Veracrypt auf das Zielverzeichnis “/home/myself/mnt_vc_srv” zu mounten, so erhält man eine Fehlermeldung der Art:

Keine Berechtigung:
/home/myself/my_mnt/vc_cont_srv

VeraCrypt::File::Open:232

Was ist die Ursache und wie kann man damit umgehen?

Rechteproblem beim lokalen Mounten eines Veracrypt-Containers aus einem SSHFS/Fuse-Verzeichnis heraus

Die Fehlermeldung deutet an, dass bereits der Zugriff auf das Containerfile selbst nicht klappt! Man könnte dabei auf ein Problem mit SSHFS-Rechten tippen; ggf. mit der UID und GID-Abbildung. Führt man aber einen Zugriff auf andere Dateien mit gleicher User-Berechtigung durch, so geht das einwandfrei! Also muss das Rechteproblem am Zusammenspiel von Veracrypt mit FUSE liegen. Ein wenig Recherche im Internet zeigt, dass Veracrypt den Mount-Prozess mit “root”-Rechten abwickelt. Nächste Frage: Darf “root” denn nicht auf die Inhalte des gemounteten FUSE-Filesystems zugreifen? Ein Versuch zeigt tatsächlich: 

mytux:~ # cd /home/myself/my_mnt
-bash: cd: /home/myself/my_mnt: Permission denied
mytux:~ # cd /home/myself/
mytux:/
home/myself #

Es handelt sich hier um eine (sehr sinnvolle) Sicherheitssperre unter FUSE! Die ist vor allem auf Multiuser-Systemen wichtig! Interessanterweise kommen dabei andere und mehr Gründe als nur die Sorge um reine Zugangsberechtigungen ins Spiel. Siehe hierzu: https://www.kernel.org/ doc/ Documentation/ filesystems/ fuse.txt

Kann man diese Sperre für unsere Situation umgehen? Antwort: Ja, wenn das von “root” auf dem Client erlaubt wird oder wurde! Es geht dabei um eine grundlegende FUSE-Sicherheits-Einstellung, die man in der dortigen Datei “/etc/fuse.conf” vornehmen muss. Siehe hierzu:
http://man7.org/linux/man-pages/man8/mount.fuse.8.html
https://wiki.ubuntuusers.de/ FUSE/

Auf einem Client-System unter Debian sieht diese Datei etwa wie folgt aus: 

root@deb:~# cat /etc/fuse.conf 
# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE)

# Set the maximum number of FUSE mounts allowed to non-root users.
# The default is 1000.
#mount_max = 1000

# Allow non-root users to specify the allow_other or allow_root mount options.
#user_allow_other
root@deb:~#

In unserem Fall, in dem der User “myself” allein dem Laptop nutzt, finde ich es akzeptabel, die Option

user_allow_other

zu setzen – also das Kommentarzeichen “#” zu entfernen.

Hinweis:
In einigen Linux-Distributionen (Opensuse Leap, Ubuntu) ist die Konfigurationsdatei “/etc/fuse.conf” aber nicht mal vorhanden. Macht nichts: Man kann sie einfach anlegen; sie wird dann ausgelesen.

Unser User “myself” hat nach dieser grundlegenden Systemänderung dann zwei Optionen, zwischen denen er unter SSHFS wählen kann: “allow_root” und “allow_other”. Für unsere Zwecke genügt “allow_root”. Wir müssen unseren SSHFS-Befehl noch wie folgt anpassen: 

myself@mytux:~> sshfs -p 57888 -o "IdentityFile=/home/myself/.ssh/KEYFILE"  smy@h1234567.stratoserver.net:/private-backup/private-backups/conts/ ~/my_mnt -o idmap=user -o uid=$(id -u) -o gid=$(id -g) -o allow_root   
Enter passphrase for key '/home/myself/.ssh/KEYFILE':

 
Die erforderlichen Kommandos wird man als Admin des Clients natürlich in adäquater Weise in Scripts einbauen, die man dem User bereitstellt.

Jedenfalls klappt es danach auch mit Veracrypt: Der User “myself” kann das File endlich in seinen Verzeichnisbaum einhängen. Hat man im Veracrypt-Dialog den Slot 4 gewählt und den vorgesehenen Mount-Point “/home/myself/mnt_vc_srv” explizit unter “Options” eingetragen, so sieht das Ergebnis wie folgt aus: 

myself@mytux:~> mount
smy@h1234567.stratoserver.net:/mydirs/conts/ on /home/myself/my_mnt type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1029,group_id=100,allow_other)
veracrypt on /tmp/.veracrypt_aux_mnt1 type fuse.veracrypt (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/mapper/veracrypt4 on /home/myself/mnt_vc_srv type ext4 (rw,relatime,data=ordered)

 
In meinem Testfall kontrolliere ich noch, ob der Inhalt des Containers auch angezeigt wird: 

myself@mytux:~> la ~/mnt_vc_srv
insgesamt 76127
drwxr-xr-x  3 myself  users     1024 19. Aug 16:14 .
drwxr-xr-x 83 myself  users     4096 20. Aug 15:50 ..
-rwxrwxrwx  1 myself  users 19580917 18. Nov 2011  ajax.pdf
-rw-r--r--  1 root root   3544281  6. Jan 2017  blktrace_sdb6_kernel44.zip
drwx------  2 root 
root     12288 19. Aug 15:29 lost+found
-rw-r--r--  1 myself  users 31498557  4. Jan 2017  Reiher-848x480-13064.mp4
-rw-r--r--  1 myself  users  1159382  4. Jan 2017  Reiher-848x480-600kb.mp4
-rw-r--r--  1 root root   9963112  6. Jan 2017  sdb6.blktrace.0
-rw-r--r--  1 root root   5791834  6. Jan 2017  sdb6.blktrace.1
-rw-r--r--  1 root root   3864342  6. Jan 2017  sdb6.blktrace.2
-rw-------  1 root root   2529586  6. Jan 2017  sdb6.blktrace.3
myself@mytux:~>

 
Das sind offenbar keine besonders gheimnisvollen Daten. Ist ja nur ein Test. Man sieht, dass auch der User “root” hier mal was abgelegt hat. Obwohl ich (“myself”) gemountet habe, werden die Zugriffsrechte aber natürlich nicht umgangen: 

myself@mytux:~> cat mnt_vc_srv/sdb6.blktrace.3
cat: mnt_vc_srv/sdb6.blktrace.3: Keine Berechtigung
myself@mytux:~>

Man kann nun auf dem Verzeichnis unter “/home/myself/mnt_vc_srv” nach Bedarf arbeiten. Z.B. Libreoffice-Dateien anlegen und bearbeiten.

Wie lange dauert das Mount des VC-Containers?

Das Mounten des Verzeichnisses “conts” mit SSHFS geht sehr schnell von statten. Das anschließende Mounten
eines 1GB großen Containers, der mit 500 MByte an Dateien in einem recht verzweigten Baum gefüllt war, dauerte bei Tests mit einer aDSL-Verbindung [16MBit/s] nur zwischen ca. 4 und 5 Sekunden.

Das ist akzeptabel. Es ist offensichtlich, dass hierfür (wie erwartet) nicht das gesamte Container-File transportiert wird. VC genügt offenbar der Zugriff auf Header Informationen aus dem File und den Filesysteminformationen für das Loop-Device.

Arbeiten mit größeren Files – z.B. unter LibreOffice Writer

Ich habe testweise mal ein 2,4 MByte großes odt-File unter LO-Writer editiert und zwischendrin immer wieder abgespeichert. Da sieht es dann so aus, dass das gesamte File zur Ablage über das Netz transferiert wird. Reguläres Speichern im Hintergrund gibt es unter LO ja leider nach wie vor nicht …

Das ist bei einer langsamen Verbindung natürlich nicht prickelnd – LO Writer ist während des Speicherns bei einer ADSL-Uploadgeschwindigkeit von 2.4MBit zw. ca. 7 – 8 Sek. nicht benutzbar.

Das Speichern von Wiederherstellungsinformation passiert dagegen ja lokal am Client und geht schnell. Aber reguläres Speichern eben nicht. Dafür benötigt man eine hinreichend schnelle Verbindung.

Alternativ arbeitet man jedoch am besten mit einer lokalen Kopie der Datei und lädt die dann “hoch”, indem man sie in das gemountete Verzeichnis unter dem Vercrypt-Mountpunkt /home/myself/mnt_vc_srv” des Servercontainers kopiert. Immerhin muss man so nur einzelne Dateien kopieren und nicht den ganzen Container!

Unmount?

Hat man seine Arbeiten beendet, so muss man zwei Unmounts in folgender Reihenfolge vornehmen:

  1. Unmounten des Veracrypt-Containers vom Verzeichnis “/home/myself/mnt_vc_srv”. Dies macht man am besten über das VC-Interface.
  2. Unmounten des SSHFS Remote-Verzeichnisses vom Verzeichnis “/home/myself/my_mnt”

Für Letzteres ist der Befehl “fusermount -u” heranzuziehen:

myself@mytux:~> fusermount -u my_mnt

Weiter oben hatte ich ja auf Parameter von SSHFS für eine Optimierung (Cahcing etc.) hingewiesen. Das Caching sorgt bei viel RAM auf dem Client in vielen Situationen übrigens für einen falschen Eindruck beim Dateitransfer. Kopiert man etwa mittels eines Dateimanagers wie Dolphin größere Dateien in Richtung Server, so signalisieren Dolphin bzw. KDE einem ein sehr schnelles Ende des Transfers; das findet aber nur im lokalen Puffer statt. Der echte Transfer über Netz hat dann bei langsamen Upload-Verbindungen gerade erst begonnen.

Man sollte bei größeren Dateitransfers also den
ausgehenden Netzverkehr im Auge haben, bevor man mit dem Unmounten beginnt. Oftmals ist noch nicht alles zum Server transferiert worden, was da hin muss.

Verbindungsabbruch und Folgen

Was ich im Vorfeld dieses Artikels nicht getestet habe, sind Folgen einer Verbindungsunterbrechung. Dennoch kann man dazu was sagen. Ein Verbindungsabbruch hat potentiell Konsequenzen für die Konsistenz des Container-Files, aber auch des umgebenden Filesystems auf dem Server. Probleme mit letzterem sind mit Hilfe von “fsck” auf dem Server relativ einfach zu beheben. Zumindest, wenn man das Verzeichnis auf dem Server mit einem eigenen Filesystem unterlegt hatte – wozu ich ausdrücklich rate, falls dies denn im Rahmen des Hosting-Paketes möglich ist!

Schwieriger sieht es mit der internen Konsistenz des Container-Files selbst aus. Hier muss man auf dem Client (!) eine Dekryptierung ohne Mounten vornehmen. Danach kann man dann fsck auf das dekryptierte Filesystem anwenden. Informationen, wie man das mit Truecrypt zu machen hatte, findet man hier. Angeblich gelten die Anweisungen auch für Veracrypt in analoger Weise.

http://john.wesorick.com/2012/03/running-fsck-on-truecrypt-volume.html
Siehe auch:
https://serverfault.com/ questions/ 83601/ how-to-fsck-ext3-a-truecrypt-volume
http://sebsauvage.net/ links/ ?GsfKdw

Das dauert je nach Größe des Container-Files natürlich unangenehm lange, da dabei über Netz gearbeitet werden muss. Regelmäßige Backups des Vercrypt-Containers sind in unserem Szenario nicht nur aus diesem Grunde Pflicht. Darauf weise ich ausdrücklich hin.

Größeren Schäden vorbeugen kann man auch durch reine Read-Only-Mounts. Und falls Schreiben/Änderungen an Container-Inhalten absolut erforderlich sind: Arbeiten auf Datei- oder Verzeichnis-Kopien und nur kurzzeitiges RW-Mounten zum Upload der geänderten Datei.

Gleichzeitiger Zugriff mehrer Personen? Einsatz für Firmen?

Wie sieht es nun mit Szenarien aus, bei denen mehrere User zugreifen müssen? Hierzu sind mehrere Punkte anzuführen:

Skalierung: Ich habe das nicht getestet – aber vermutlich gilt: SSHFS skaliert nicht so gut wie NFS. Ab einer durch Tests zu bestimmenden Useranzahl lohnt sich vermutlich der Umstieg auf NFS.

Read Only: Auch unter NFS können nicht mehrere User unabhängig voneinander einen VC-Container bei sich lokal zum Lesen und Schreiben auf dem jeweiligen Client mounten. Das führt unweigerlich in die Katastrophe! Die Konsistenz des VC-Containers kann am Server unter diesen Bedingungen nicht aufrechterhalten werden!

Die Vercrypt-Entwickler haben zu diesem Thema eine entsprechende Empfehlung abgegeben, die schon für Truecrypt-Container galt:

  • Für schreibende Zugriffe durch mehrere Personene muss der Container bereits am Server gemounted und dann einem Sharing-Verfahren (z.B. über NFS oder SSHFS) unterworfen werden.
  • Ansonsten darf der Container nur dann auf mehreren Endgeräten gleichzeitig gemounted werden, wenn dies ausschließlich lesend erfolgt. Dies bedeutet im Klartext, dass bereits das umgebende Verzeichnis (hier: ) nur ReadOnly gemounted wird.

Siehe: https://www.veracrypt.fr/ en/ Sharing%20over%20Network.html

Die erste Variante fällt für unseren gehosteten Server – wie oben begründet – flach. Das bedeutet:

Multiuser-Szenarien auf gehosteten Servern sind nur im rein lesenden Modus möglich, nicht aber für Schreibzugriffe.

r

Würde man den Container andererseits indirekt über einen eigenen Server in der Firma mounten und dort freigeben, stellt sich die Frage, warum man nicht gleich über diesen Server arbeitet.

Ausweg bzgl. notwendiger Änderungen:
Leider nur in Kombination mit organisatorischen Maßnahmen. So könnten Mitarbeiter inhaltliche Änderungen lokal vornehmen und in GIT-/SVN-Repositories einchecken, die spätestens beim nächsten Aufenthalt in der Firma abgeglichen werden. Das Ergebnis des Abgleichs wird dann wieder für alle sichtbar in eine Containerdatei ausgespielt, die auf den Clients der mobilen Mitarbeiter nur lesend gemounted werden darf und kann.

Ich finde, das ist für viele Anwendungsfälle keine massive Einschränkung.

Ein Mehrbenutzerszenario, bei dem User auf dem Server grundsätzlich nicht nur lesende Operationen durchführen dürfen, ist von Haus mit sekundären Sicherheits-Problemen verbunden. Man muss etwa verhindern, dass die User geheimzuhaltende Daten eigenhändig und abseits des Containers auf den Server transferieren können. Alles andere als einfach …

Hochsicherheit am Server?

Man kann für manche Dateien, deren Inhalte (z.B. Passwörter) besondere Sicherheitsvorkehrungen erfordern, das Spielchen noch etwas weiter treiben:

Man erlaubt nur RO-Zugriffe – und hinterlegt diese Dateien innerhalb des VC-Containers nochmals verschlüsselt. Am besten mit GnuPGP – das gilt noch als sicheres Verfahren. Das PGP-File oder den PGP-Container kopiert und entschlüsselt man dann mit Tools wie Kleopatra oder KGpg auf dem Client.

Ein Angreifer, der es irgendwie schafft, den VC-Container oder den Datenverkehr vom/zum Client zu knacken, sieht sich dann immer noch mit dem PGP-File/Container konfrontiert. Wohlgemerkt: Das erhöht zwar die Sicherheit auf dem gehosteten Server. Aber es verschiebt die Sicherheitsthematik ganz genau wie die VC-Entschlüsselung auf den Client.

Weitere Schwachstellen?

Sind wir nun nach menschlichem Ermessen sicher? Nun ja, jedes System kann gehackt werden. Und sicher hat auch ein böswilliger Admin beim Provider die Möglichkeit dazu. Eine manupulierte Implementierung von SSH wäre in unserem Szenario z.B. ein Ansatzpunkt für einen Angriff. Ein Minimum an weiteren Vorsichtsmaßnahmen muss daher sein, dass wir Systempakete selbst installieren (soweit möglich) – und deren Integrität mit IDS-Tools überwachen. Für einzelne Komponenten wie SSH ggf. mit Tripwire.

Man kann die Integritätsbetrachtung aber natürlich beliebig ausdehnen – bis hin zum Host-Kernel, auf den man oft keinen Einfluss hat. Das führt zur Frage des Einsatzes von Root-Servern, die man absichern muss. Die Frage ist dann: Wann hat man gesetzlichen Vorgaben auf dem Stand der Technik Genüge getan?
Wir nähern uns erneut Domäne von Vorgaben durch Datenschutzbeauftragte und Anwälten. Und das sprengt diesen Artikel. Aber es macht erneut klar: Echte Sicherheit endet nicht bei der verschlüsselten Ablage von Daten.

Ausblick

Wir haben gesehen, dass es bei einer bzw. wenigen Personen durchaus möglich ist, Veracrypt-Container auf einem Server zu nutzen, ohne jemals eine Entschlüsselung auf dem Server selbst vornehmen zu müssen. Eine einfache Möglichkeit des Zugriffs ergibt sich dabei über SSHFS und eine anschließendes Mounten des VC-Containers auf dem Client.

Szenarien für Lese- und Schreibzugriffe mehrerer Anwender sind ohne Gefährdung der Sicherheit nicht möglich. Hier ist auf ReadOnly-Szenarien und organisatorische Maßnahmen auszuweichen.

Für Einzelanwender geht dagegen sogar Lesen und Schreiben. U.a. LibreOffice erfordert aber hohe Upload-Raten der Verbindung, da das Zwischenspeichern zum Transfer der gesamten geöffneten Datei führt.
Alternativ arbeitet man mit lokalen Kopien am Client. Ein Hin- und Her-Kopieren des gesamten Containers erscheint jedoch überflüssig. Bitte
korrigiert mich, wenn ich etwas übersehen haben sollte.

Im nächsten und letzten Artikel dieser Serie

Veracrypt, SSHFS und sichere Datenhaltung auf gehosteten Servern – II – die Client-Seite …

stelle ich einige Hinweise zur Sicherheit der Daten auf unserem Client zusammen. Denn es gilt: Wir handhaben dort entschlüsselte Daten und haben damit die Sicherheitsthematik auf das Endgerät des Benutzers verschoben.

Links

Veracrypt
https://en.wikipedia.org/ wiki/ VeraCrypt
http://www.deutschlandfunk.de/ verschluesselungssoftware-veracrypt-unabhaengige.684.de.html?dram:article_id=369309
https://www.computerbase.de/ 2016-10/ truecrypt-alternative-veracrypt-audit/
http://www.linux-magazine.com/ Online/ Features/ VeraCrypt

Audit Report zu Veracrypt
https://ostif.org/ wp-content/ uploads/ 2016/10/ VeraCrypt-Audit-Final-for-Public-Release.pdf
https://www.golem.de/ news/ truecrypt-nachfolger-veracrypt-audit-findet-schwerwiegende-sicherheitsluecken-1610-123893.html

LUKS
https://wiki.ubuntuusers.de/ LUKS/ Containerdatei/

SSH mit Key Files
https://www.digitalocean.com/ community/ tutorials/ how-to-configure-ssh-key-based-authentication-on-a-linux-server
https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html
https://wiki.mozilla.org/ Security/ Guidelines/ OpenSSH

FUSE
https://de.wikipedia.org/ wiki/ Filesystem_in_Userspace

SSHFS
https://wiki.archlinux.de/ title/ Sshfs
https://wiki.archlinux.org/ index.php/ SSHFS
https://www.heise.de/ ct/ artikel/ Toolbox-Dateizugriffe-mit-sshfs-1646679.html
https://www.linode.com/ docs/ networking/ ssh/ using-sshfs-on-linux

SSHFS mit Identityfile
https://unix.stackexchange.com/ questions/ 61567/ sshfs-specify-key
https://stackoverflow.com/ questions/ 22393502/ how-do-i-specify-the-key-file-for-sshfs

Cloud-Definition
https://www.cloud.fraunhofer.de/ de/ faq/ publicprivatehybrid.html

Strato HiDrive
http://cloudlist.de/ dienst/ strato-hidrive-test/
https://strato.de/ blog/ 3-truecrypt-alternativen-fuer-
hidrive/

Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – IV

Posted on by

Ich setze mit diesem Blog-Post meine kleine Serie von Artikeln zum Thema GIT-Einsatz unter Eclipse fort. Im ersten Beitrag
Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – I
hatte ich ein einfaches Einsatz-Szenario für freiberufliche Entwickler dargestellt, die mobil unterwegs sein müssen und ihre Versionsentwicklung regelmäßig zwischen PCs, Laptops und einem oder mehreren zentralen Servern abgleichen müssen:

Im LAN des Homeoffice wird mit einem lokalen Git-Repositories auf dem Arbeitsplatz-PC gearbeitet. Änderungen sollen schon aus Backup-Gründen zeitnah in ein zentrales Git-Repository im LAN überführt werden. Über den LAN-Server soll bei Bedarf aber auch ein Laptop versorgt werden; das dortige lokale Repository wird zum Arbeiten während Reisen benutzt. Zur Sicherheit wird der Status auf dem Laptop mit einem zentralen Repository im Internet abgeglichen, wann immer sich dazu die Gelegenheit bietet.

Die Frage ist: Wir organisiert man das unter Eclipse? In den letzten zwei Beiträgen
Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – II
Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – III
habe ich mich deshalb zunächst mit der Anlage eines lokalen Repositorys auf einem PC mit Hilfe des EGit-Plugins unter Eclipse beschäftigt. [EGit ist übrigens auch als standalone Product unter dem Namen “GitEye” verfügbar.] Wir haben uns anschließend angesehen, wie man Commits durchführt, wie man Branches erzeugt und auch wieder mergt.

Im Zentrum dieses und kommender Blog-Beiträge steht aber vor allem ein zentraler Branch, der sog. “Master”-Branch”. Er stellt in unserem Szenario das wichtigste Bindeglied zwischen den verschiedenen Repositories auf PC, Laptop und zentralen Servern dar. Alle Entwicklungsaktivitäten werden in unserem Szenario letztlich auf ihn ausgerichtet. Wir merken aber bereits an dieser Stelle an, dass sich alle später dargestellten Abgleichverfahren zwischen lokalen und zentralen Repositorys realtiv zwanglos auf mehrere Branches erweitern lassen.

Ich wende mich in diesem Artikel der Anlage eines zentralen Repositorys auf einem Server im LAN zu. In einem zweiten Schritt binde ich dann das erzeugte LAN-Repository an das lokale Repositories unseres Entwicklungs-PCs an. Abschließend wird eine Änderung im lokalen Repository auf das zentrale Repository übertragen (“Push”-Operation). Das Spektrum der behandelten Themen entspricht in etwa der Lösung der Aufgaben 4 bis 7 des ersten Artikels.

Voraussetzung: Funktionierender SSH-Server

SVN-Nutzer wissen, dass ein SVN-Server eine spezielle Konfiguration über definierte Konfigurationsdateien und -verzeichnisse erfordert. U.a sind dabei spezielle Zugriffsrechte festzulegen. Weitere Sicherheitsaspekte sind zu berücksichtigen, wenn man SVN-Dienste über einen Webserver und “https” anbieten will.

Aus meiner Sicht ist die Einrichtung eines GIT-Servers für unser Szenario (aber nicht nur dafür) relativ einfach: Benötigt wird im Grunde nur ein hinreichend konfigurierter SSH-Server, auf dem man den Zugriff auf Verzeichnisstrukturen und Objekte eines “.git”-Verzeichnisses über User- und Gruppen-Accounts steuert. Ansonsten muss dort unter Linux nur das für die jeweilige Distribution passende Git-Paket installiert sein. Mehr ist zum Aufsetzen eines privaten Git-Servers unter SSH fast nicht erforderlich! Hinzu kommen lediglich zwei weitere, einfache Schritte:

  • Das auf einem PC bereits
    vorhandene Repository (hier für das Eclipse-Projekt “alien1”) ist zu klonen.
  • Der Git-Repository-Clone ist in ein definiertes Zielverzeichnis auf dem SSH-Server zu transferieren.

Man kann die oben genannten beiden Punkte mittels GIT theoretisch auch in einem Schritt erledigen; ich ziehe es aber der besseren Kontrolle wegen vor, hier zweistufig vorzugehen. Alle später einzurichtenden Git-Clients nehmen dann auf die URI des angelegten Git-Verzeichnisses auf dem Server Bezug.

Hinweis: Es gibt natürlich auch Möglichkeiten, eigene Git-Server über andere Protokolle und im Rahmen von Web-Server-Diensten einzurichten. Ich gehe in dieser Artikelserie aber nicht darauf ein. Ich sehe auch keinen Grund dafür, für unser einfaches privates Szenario nicht eine simple und sichere SSH-Variante zu nutzen.

Ich gehe in diesem Artikel zudem nicht auf die Bereitstellung und Konfiguration von SSH auf einem Server ein. Das habe ich an anderer Stelle dieses Blogs schon beschrieben. Ich gehe im LAN ferner von einem einfachen UID-bezogenen Login auf dem SSH-Server mittels eines Passwortes aus; für einen später zu kontaktierenden SSH-Server im Internet setze ich dagegen einen Login per RSA-Key (hinreichender Länge plus sicherem elliptischem KEX-Verfahren) voraus.

Unser LAN-Server heiße “debian8” und sei einer lokal definierten Domäne “lanracon.de” zugeordnet. Der Server sei aufgrund entsprechender DNS-Einträge aber auch direkt unter “debian8” ansprechbar. Ich gehe davon aus, dass wir auf diesem Server z.B. Giggle oder QGit installiert haben, um dort einen Blick auf neu installierte Repositories werfen zu können (s. hierzu auch den vorhergehenden Blog-Artikel). Das übergeordnete Zielverzeichnis für Git-Repositorys auf dem Server sei “/projekte/GIT/”. Das zentral zu erzeugende Repository beziehe sich in unserem Beispiel – wie das zuletzt betrachtete PC-Repository auch – auf unser PHP-Eclipse-Projekt namens “alien1”.

Erzeugen eines Repositories ohne Working Tree durch Klonen

Auf einem Git-Server benötigen wir in der Regel keinen Working Tree. Das Erzeugen eines Clones ohne Working Tree gelingt mit Hilfe des “git clone”-Befehls und bestimmter Optionen.

Ich bemühe an dieser Stelle die Kommandozeile einer Shell. Man kann zwar auch mit EGit ein vorhandenes Repository in lokale Verzeichnisse klonen; aber wir wollen ja anschließend die Clone-Dateien auch noch auf den Server bringen. Das ginge theoretisch zwar auch über geeignete grafische Eclipse-Tools für den Remote-Systems-Zugriff; warum aber mit Kanonen auf Spatzen schießen?

Das Repository und der Working Tree unseres Beispiels aus den letzten Blog-Posts waren auf unserem Entwicklungs-PC im Verzeichnis “/projekte/GIT/alien1” beheimatet. Ich lege mir für die Zwischenspeicherung des Clones und den anschließenden Transfer auf den Server im vorhandenen GIT-Verzeichnis des PCs (oder Laptops) aber ein separates Verzeichnis an – hier namens “alien1trans“. Also 

myself@mytux:/projekte/GIT> mkdir alien1trans
myself@mytux:/projekte/GIT> cd alien1trans/

Die Struktur des notwendigen “clone”-Befehls ist: 

git clone --bare <em>Repo-Pfad Target-Dir-Pfad</em>

Für die Erzeugung eines Repositorys ohne “Working Tree”-Verzeichnis sorgt die Option “–bare“. Wird der Target-Dir-Pfad des Verzeichnisses, in das geklont werden soll, nicht angegeben, wird der Clone im aktuellen Verzeichnis (Working Directory) angelegt. In unserem Fall ergibt sich: 

myself@mytux:/projekte/GIT/alien1trans> git clone --bare ../alien1
Klone in Bare-Repository 'alien1.git' ...
Fertig.
myself@mytux:/projekte/GIT/alien1trans> ls -la
insgesamt 12
drwxr-xr-x 3 myself entw 4096  6. Mai 09:28 .
ndrwxr-xr-x 6 myself entw 4096  6. Mai 09:27 ..
drwxr-xr-x 7 myself entw 4096  6. Mai 09:28 alien1.git
myself@mytux:/projekte/GIT/alien1trans> du -s -h
60M     .
myself@mytux:/projekte/GIT/alien1trans> cd ../alien1
myself@mytux:/projekte/GIT/alien1> du -s -h
225M    .
myself@mytux:/projekte/GIT/alien1> du -s -h .git
60M     .git
myself@mytux:/projekte/GIT/alien1>
myself@mytux:/projekte/GIT/alien1> cd ../alien1trans/
myself@mytux:/projekte/GIT/alien1trans> mv alien1.git/ .git  
myself@mytux:/projekte/GIT/alien1trans> ls -la                                                                          
insgesamt 12                                                                                                       
drwxr-xr-x 3 myself entw 4096  6. Mai 11:25 .                                                                        
drwxr-xr-x 6 myself entw 4096  6. Mai 09:27 ..
drwxr-xr-x 7 myself entw 4096  6. Mai 09:28 .git

Wie man sieht, habe ich im Anschluss an das Klonen die korrekte Größe des Clone-Verzeicnisses geprüft. Das reine Repository (hier “alien1.git”) ist offenbar deutlich kleiner als der Working Tree selbst! Am Schluss habe ich das Repository-Verzeichnis des Clones, das als Anteil immer den Namen des Ursprungsrepositories erhält, noch in “.git” umbenannt. Grund: Viele Git-GUI-Programme suchen automatisch nach einem Verzeichnis namens “.git”.

Ok, wir haben nun einen Clone auf unserem PC. Wie bringen wir den jetzt auf den Server “debian8.lanracon.de”? Natürlich mittels SSH. Ich gehe mal davon aus, dass der User “myself” aus der Gruppe “entw” auch auf dem Server vertreten ist und sich dort per Passwort anmelden darf. Er verfüge über die notwendigen Schreibrechte im übergeordneten Zielverzeichnis auf dem Server, in dem wir spezifische GIT-Repositories aufbewahren wollen. Zunächst legen wir auf dem Server ein spezielles Zielverzeichnis für das “alien1”-Repository an: 

myself@mytux:/projekte/GIT/alien1trans> ssh myself@debian8
Password: 
Last login: Sat May  6 11:41:46 2017 from xxx.xxx.xxx.xxx
Have a lot of fun...
myself@debian8:~> cd /projekte/GIT
myself@debian8:/projekte/GIT> mkdir alien1
myself@debian8:/projekte/GIT> exit
Abgemeldet
Connection to debian8 closed.
myself@mytux:/projekte/GIT/alien1trans>

Ich habe hier mal angenommen, dass wir auf dem Server bereits eine ähnliche Verzeichnisstruktur wie auf dem PC angelegt hatten. Das muss natürlich nicht so sein. Also das Zielverzeichnis bitte dort anlegen, wo man seine GIT-Repositories verwalten will.

Hinweis: An dieser Stelle können bereits Rechte (im Besonderen Gruppenrechte) eine Rolle für die spätere Nutzung des Repositories durch andere User spielen. Ich regele die korrekten Rechte auf Servern, die ich selbst komplett unter Kontrolle habe, meistens über ACLs und/oder das SGID-Bit. Das erspart einem viel Arbeit. Egal wie – es ist jedenfalls dafür zu sorgen, dass das Verzeichnis die richtige Gruppe und einen passenden Rechtekamm erhält.

Nun kopieren wir einfach die Dateien des geklonten “.git”-Verzeichnisses per “scp” vom PC auf den Server: 

myself@mytux:/projekte/GIT/alien1trans> scp -r .git myself@debian8:/projekte/GIT/alien1/
Password: 
...
....
99eaff29e3720789e5e75e9e8999a5bde77733                                           100%  290     0.3KB/s   00:00    
a816f7c5ebab36333b9fd8574d459176f3ff07                                           100% 2416     2.4KB/s   00:00    
5f11c90dbb0170c0b2082f1d5fec9a0e10522b                                           100%   17KB  17.1KB/s   00:00    
101f6958c4e18057cfdf7c975a1483eeeddea9                                           100% 1349     1.3KB/s   00:00    
2fd38f7570791c179ec4c94b886ec62027d3a3                                           100% 9190     9.0KB/s   00:00    
config                                                              
             100%  127     0.1KB/s   00:00    
description                                                                      100%   73     0.1KB/s   00:00    
packed-refs                                                                      100%  289     0.3KB/s   00:00    
pre-commit.sample                                                                100% 1642     1.6KB/s   00:00    
pre-rebase.sample                                                                100% 4951     4.8KB/s   00:00    
pre-receive.sample                                                               100%  544     0.5KB/s   00:00    
prepare-commit-msg.sample                                                        100% 1239     1.2KB/s   00:00    
post-update.sample                                                               100%  189     0.2KB/s   00:00    
commit-msg.sample                                                                100%  896     0.9KB/s   00:00    
pre-applypatch.sample                                                            100%  424     0.4KB/s   00:00    
applypatch-msg.sample                                                            100%  478     0.5KB/s   00:00    
pre-push.sample                                                                  100% 1348     1.3KB/s   00:00    
update.sample                                                                    100% 3610     3.5KB/s   00:00    
HEAD                                                                             100%   23     0.0KB/s   00:00    
exclude                                                                          100%  240     0.2KB/s   00:00    
myself@mytux:/projekte/GIT/alien1trans>

Je nach Größe des Repositorys rast hier eine Reihe von Dateien, die mit Hashes bezeichnet sind, an uns vorüber. Um zu prüfen, ob das Verzeichnis auf dem Server richtig aussieht, nutze ich z.B. Giggle: 

myself@mytux:/projekte/GIT/alien1trans> ssh myself@debian8
Password: 
Last login: Sat May  6 11:48:46 2017 from xxx.xxx.xxx.xxx
Have a lot of fun...
myself@debian8:~> export NO_AT_BRIDGE=1
myself@debian8:~> giggle &

Hinweis:

Mir passiert es auf Servern mit etwas älterem Kernel regelmäßig, dass ich die Umgebungsvariable NO_AT_BRIDGE mittels
export NO_AT_BRIDGE=1
auf dem Server setzen muss, um Giggle oder QGit (über SSH) zum Laufen zu bringen. Siehe hierzu: https://wiki.archlinux.de/title/GNOME#Tipps_und_Tricks und https://bbs.archlinux.org/viewtopic.php?id=176663 sowie auch https://bugzilla.redhat.com/show_bug.cgi?id=1056820

Unter Giggle muss man dann das “Projekt” alien1 unter dem entsprechenden Pfad zum Repository öffnen. Ich gehe auf die Bedienung von Giggle oder QGit nicht näher ein. Die meisten Git-Anwendungen sind nach ein wenig Beschäftigung mit Git weitgehend selbsterklärend. Das Ergebnis ist jedenfalls:

Gut! Wir können die Branches des geklonten Repositories offenbar auch auf dem Server mit graphischen Tools einsehen.

Hinweis:

Für diesen Artikel habe ich faktisch einen unter KVM angelegten Linux-Server auf einem Laptop benutzt. Im LAN kann man bzgl. graphischer Tools auf Servern noch performant genug mit “ssh -X” arbeiten. Wer hingegen mit einer graphischen Oberfläche auf echten Remote-Servern im Internet arbeiten muss, findet ggf. mit X2GO ein passendes Toolset; s. z.B.:
Remote Desktop für Debian 8 mit X2Go auf Strato-vServern.

Dem Leser werden Teile der Branch-Grafik bekannt vorkommen; einen ähnlichen Graphen hatte ich bereits gegen Ende des letzten Artikels abgebildet. Dort war der Zugriff aber auf das Repository des PCs erfolgt.

Hinweis: Wer Speicherplatz sparen will, kann nach diesem positiven Check das Zwischenverzeichnis “alien1trans” und seinen Inhalt löschen (“rm -r alien1trans”).

Anbinden des Master-Branches des Servers an den Master-Branch des PCs

Das Repository auf dem Server ist relativ nutzlos, wenn wir es nicht in Verbindung mit lokalen Repositories auf unseren PCs oder Laptops bringen. Wie also können wir von Eclipse/EGit aus auf das eben auf dem Server eingerichtete Repository zugreifen und wie füllen wir es mit Commits, die wir lokal durchgeführt haben?

Es gibt unter Eclipse/EGit mehrere Wege, einen Branch eines Remote-Git-Repositorys an einen korrespondierenden Branch eines lokalen Repositorys anzubinden. Ich wähle hier den Weg über den Punkt “Remotes” im hierarchisch organisierten Eclipse-View “Git Repositories” für die Darstellung lokaler Repositorys:

Im Kontextmenü zu “Remotes” findet sich ein Punkt “Create Remote”, den wir anklicken:

Im nächsten Popup-Dialog müssen wir der neuen “Remote-Git-Anbindung” einen Namen geben:

Die vorgewählte Radiobox für die Push-Konfiguration lassen wir in ihrem Zustand. Ich komme auf die Alternative in einem späteren Artikel zurück. Das Drücken des OK-Buttons führt zu einem weiteren Dialogfenster:

Dort wählen wir den Button “Change”, um die Verbindung zum Git-Server zu konfigurieren; es öffnet sich ein weiteres Dialogfenster (s.u.) mit mehreren Eingabefeldern, die wir wie folgt behandeln:

  • In das Feld “URI” geben wir zunächst nur den Pfad zum Repository auf dem Server an – also in unserem Beispiel:
    “/projekte/Git/alien1/.git”.
  • In das Feld “Host” geben wir in unserem Fall natürlich “debian8” ein. In der Combobox “Protocol” wählen wir “ssh”; ggf. müssen wir auch noch einen Nicht-Standard-Port angeben, falls SSH auf dem Server unter einem speziellen Port angeboten wird.
  • Im Feld “User” geben wir unsere UID auf dem Server ein – hier “myself”. Dann ergänzen wir noch das Password; das Feld “Store in Secure Store” lasse ich immer aktiv. Hier sammelt und verschlüsselt Eclipse die ihm anvertrauten Passwörter in einem Container, der wiederum ein Zugangspasswort erfordert.

Der Dialog baut den UR-Identifier im Zuge dieser Schritte vollständig auf:

Drücken auf den “Finish”-Button führt zum nächsten Dialog, der uns erlaubt, die sog. “Push-Reference”-Konfiguration vorzunehmen:

Worum geht es da? Für den Moment reicht es zu wissen, dass wir eine Beziehung zwischen einem lokalen Branch und einem Branch eines Remote-Repositories herstellen, so dass wir später neue, per Commit erstellte Knoten des lokalen Branches gezielt in den ausgewählten Remote-Branch überführen können.

Hinweis:

Faktisch kann man aber die nachfolgende einfache Konfiguration für genau einen Branch und einen Remote-Server auf verschiedene abzugleichende Branches und verschiedene Server im Rahmen ein und derselben Remote-Konfiguration ausdehnen. Dies ist insbesondere dann nützlich, wenn man lokale Repsitory-Änderungen gleichzeitig auf verschiedene Remote-Server übertragen will. Ich komme darauf in einem weiteren Blog-Beitrag zurück.

Wir drücken nun auf den Button “Add”. Folgende Schritte sind im nächsten Dialog zu leisten, um eine Referenz des Remote Master-Branches zum lokalen herzustellen; zunächst wählen wir den lokalen Branch; es genügt ein “m” in die betreffende Zeile einzugeben. Das Fenster bietet uns dann automatisch den (momentan einzigen) passenden Branch zur Auswahl an. Dann wählen wir den Remote-Branch:

Bei letzterem Schritt muss die SSH-Verbindung bereits funktionieren! Auch hier sollte eine Vorgabe von “m” zur Auswahl des richtigen (Remote-) Master-Branches führen.

Übrigens: Bei Einsatz von asymmetrischen Schlüsseln zur SSH-Authentifizierung müssen diese vorab im Eclipse-Dialog SSH2-Dialog unter “Preferences => General => Network Connections => SSH2” definiert worden sein.

Man wird dann ggf. zur Eingabe der Passphrase für den lokalen Schlüssel aufgefordert.

Im unserem Push-Referenz-Dialog ergibt sich nun folgendes Bild:

Und schließlich:

Weitere Git-“Remotes”

Ganz analog kann man nun weitere “Remotes” für andere Server anlegen – soweit das denn sinnvoll ist. Man erhält schließlich eine Kollektion verschiedener Remote-Verbindungen zu Git-Servern:

Jede dieser Remote-Anbindungen enthält eine separate “Push”-Konfiguration, die man nach Bedarf unabhängig von anderen Remote-Verbindungen für notwendige Abgleichvorgänge bedienen
kann. Aber Achtung:

In unserem Beispiel haben wir bisher nur eine funktionierende Push-Verbindung aufgebaut. Bereits die obige Abbildung verdeutlicht aber, dass es offenbar auch so etwas wie Fetch-Operationen gibt. Den Sinn und Zweck von “Fetches” behandle ich in einem kommenden Artikel.

Anwenden der Push-Verbindung zum LAN-Server – eine erste Push-Operation

Den Transfer lokaler Repository-Änderungen auf das Remote-Repository bezeichnet man als Push-Operation. Je nachdem, wer wann welche Änderungen auf dem Server eingespielt hat, setzt dies ggf. vorhergehende komplexe Merge-Operationen mit lokalen Branches voraus. In unserem Szenario, in dem wir alleine den Master-Branch auf dem LAN-Server beliefern, ist das aber, zumindest im Moment, noch völlig unerheblich. Die Änderungen erfolgen gemäß unserer Szenario-Beschreibung im ersten Beitrag ja sequentiell.

Also probieren wir einfach mal aus, was ein Push im momentanen ReositoryZustand bewirkt. Hierzu führen wir einen Klick mit dem rechten Mousebutton auf einer unserer angelegten Remote-Verbindungen aus; es öffnet sich ein Kontext-Menü, das u.a. die Push-Operation anbietet:

Ich habe die Push-Operation im abgebildeten Beispiel in Richtung auf einen Server durchgeführt, der sich in einem ähnlichen Zustand wie unser “debian8” aus der oben erläuterten Remote-Konfiguration befindet. Das führt dann zu folgender System-Reaktion und -Information:

Dieses Ergebnis war zu erwarten; das geklonte Repository befindet sich ja immer noch im selben Zustand wie das aktuelle auf dem PC unter Eclipse. Wir müssen lokal natürlich zuerst eine Änderung comitten; erst die lässt sich dann sinnvollerweise zum Server weiterreichen. Um die Änderung und ihren Hash lokal wie remote verfolgen zu können, lassen wir uns im Git-Repository-View unsere Branches anzeigen und öffnen dann per rechtem Mausklick das Kontextmenü des “Master”-Branches. Dort klicken wir auf den Menüpunkt “Show In => History”. Der graphische History-View sieht in meinem Beispiel wie folgt aus:

Übrigens: Die Abbildung zeigt für den obersten Knoten auch, dass die HEAD-Version des Branches bislang mit denen definierter Remote-Server-Branches “loc_deb8/master” und “strat_deb/master” übereinstimmt!

Nun führen wir – wie im letzten Artikel erläutert – eine Änderung auf einer Testdatei aus und committen die über den Commit-Button des Git-Staging-Dialogs:

Wir erhalten dann nach einem Refresh des History-Views:

Hier erkannt man, dass sich die lokale Version nun von den letzten bekannten Versionen auf den Servern “loc_deb8/master” und “strat_deb/master”
abweicht. (Wie das lokale Eclipse auf unserem PC erfährt, ob sich inzwischen möglicherweise durch andere Nutzer etwas auf den Server-Repositories geändert hat, behandle ich in einem anderen Artikel.) Man merke sich nun den Hash des letzten Knotens.

Nun führen wir nochmals die oben versuchte Push-Operation aus; ich nutze hier eine definierte Verbindung zu einem realen Server, die ich unter der Bezeichnung “loc_deb8” konserviert habe:

Wir klicken auf OK. Dann wechseln wir zur graphischen Oberfläche unseres Servers und refreshen das dort geöffnete Giggle (oder QGit, ..). Und tatsächlich:

Unsere lokale Änderung ist wohlbehalten im Remote Repository unseres Servers angekommen. Die Hashes der Knoten sind identisch.

Potentielle Probleme mit Push-Operation und Ausblick

Damit man lokale Änderungen so einfach wie oben beschrieben pushen kann, müssen diese von Git als echte Nachfolger des letzten Knotens im Remote-Branch identifiziert werden können. Es ergeben sich dann um sog. Fast-Forward-Merges, die mit keinen direkten formalen Konflikten zwischen verschiedenen Änderungen gleicher Code-Bereiche verbunden sind.

Für unser einfaches sequentielles Änderungsszenario, das wir im ersten Artikel beschrieben haben, sind Fast-Forward-Merges aus offensichtlichen Gründen immer möglich.

Man stelle sich aber eine Situation mit mehreren Anwendern vor. Dann können andere Entwickler unser zentrales Repository bereits mit ähnlichen Änderungen upgedated haben – bevor wir unsere Änderung pushen. Das führt dann potentiell zu Konflikten zwischen den verschiedenen Änderungen, die GIT nicht ohne unser Zutun auflösen kann. Unsere Push-Operation kann in einem echten Entwicklungsszenario deshalb auch schief gehen – genauer: in einen manuell zu bereinigenden Konflikt münden. (In der Praxis vermeidet man häufige Kollisionen mit den Inhalten zentraler Repositories übrigens auch durch organisatorische Maßnahmen; etwa dadurch, dass man nicht verschiedene Entwickler parallel an den gleichen Dateien bzw. gleichen Codebereichen arbeiten lässt.)

Konflikte können aber auch in einem 1-Personen-Szenario auftreten, in dem man vergessen hat, seine Änderungen auf verschiedenen Entwicklungssystemen (Laptop, PC) systematisch und sequentiell über zentrale Server abzugleichen.

Um eventuelle Konflikte vorab zu erkennen und ggf. durch Merges zu bereinigen, die man lokal vor einem Push ausführt, benötigt man eine Übertragung des Zustands eines Remote-Repositorys in das lokale System. Hierzu dienen Fetch- und Pull-Operationen; sie werden u.a. Thema unseres nächsten Artikels.

Dort wollen wir uns ferner damit befassen, wie wir den Stand unseres zentralen Repositorys auf einen Entwicklungs-Laptop übertragen.