Git Repo per SSH klonen

Dafuq?

Zitat von carlosspicyweener

Dafuq?

GIT ist eine Plattform zur Versionsverwaltung/Entwicklung. Da wird beispielsweise offener Quellcode gespeichert, den man gemeinsam bearbeitet. Er hat Code auf dem PC und möchte den per SSH (Fernzugriff über eine Shell, also eine Eingabeaufforderung) auf einen Server kopieren.

Sorry, ich kann leider nicht helfen, weil ich mich nicht auskenne in dem Bereich.

Kopier mit scp dein repo zum ueber-ssh-verbundenen computer: https://unix.stackexchange.com…hine-to-another-using-ssh. Nicht vergessen das .git Unterverzeichnis mitzukopieren, da sind die ganzen Git-Daten drin.

Git ist verteilt, da gibts an sich keinen "server".

willst Du das GIT repo hoch oder runterladen? Clonen ist ja normalerweise runterladen. Deshalb verwirrt mich das lokale Repo

Um ein lokales Git-Repository auf einen Server zu klonen, gibt es mehrere Schritte, die du befolgen musst:

1. Öffne ein Terminal auf dem Server, auf den du das Repository klonen möchtest, und navigiere in das Verzeichnis, in dem du das Repository speichern möchtest.

2. Erstelle ein neues leeres Verzeichnis, in dem das Repository gespeichert werden soll, indem du den folgenden Befehl ausführst:

bash
mkdir repository-name.git

Beachte, dass es üblich ist, den Namen des Verzeichnisses mit ".git" zu beenden, um anzuzeigen, dass es sich um ein Git-Repository handelt.

3. Navigiere in das neue Verzeichnis, indem du den folgenden Befehl ausführst:
bash
cd repository-name.git

4. Initialisiere das leere Verzeichnis als ein Git-Repository, indem du den folgenden Befehl ausführst:
csharp
git init --bare

Dies erstellt ein leeres Repository ohne Arbeitsverzeichnis, das ausschließlich für die Speicherung von Git-Objekten und -Referenzen verwendet wird.

5. Gehe nun zum lokalen Git-Repository, das du auf den Server klonen möchtest. Öffne ein Terminal auf deinem lokalen Computer und navigiere in das Verzeichnis des lokalen Repositorys.

6.Füge den Server als Remote hinzu, indem du den folgenden Befehl ausführst und den Platzhalter "username" und "server" durch deine eigenen Werte ersetzt:

csharp
git remote add server-alias ssh://username@server:/path/to/repository-name.git

Dies erstellt einen Remote-Namen ("server-alias"), der auf die SSH-URL des Servers zeigt, auf dem das Repository gespeichert wird. Der Pfad muss zum Verzeichnis des Repositorys auf dem Server führen, das du im Schritt 2 erstellt hast.

7. Führe den Klonvorgang aus, indem du den folgenden Befehl ausführst:
csharp
git push server-alias master

Dies kopiert das lokale Repository auf den Server und erstellt eine Kopie im Verzeichnis, das du im Schritt 2 erstellt hast.

Das Repository auf dem Server ist nun ein exakter Klon des lokalen Repositorys und kann von anderen Benutzern heruntergeladen und aktualisiert werden, indem sie sich auf den Server verbinden und den Remote-Namen verwenden, den du im Schritt 6 erstellt hast.

_{Das sagt ChatGPT dazu}

Wann kommt host key verification failed? Beim ssh connecten? In dem Fall am besten deinen Hoster fragen

Zitat von El Vulpes

Und wenn da nun "Host key verification failed" kommt?

Habe selber keinen Root-Zugriff, muss also meinen Provider Ergänzungen/Tools installieren lassen.

Er schreibt nun was von "Verbindung mit dem Debug Parameter aufbauen und den Output senden".

Was genau ist da der Debug-Parameter? -v?

Also, einfach mit ssh -v user@ip einloggen und dann den Debug-Krams kopieren, oder ist das ein anderer Parameter der an anderer Stelle irgendwo eingefügt werden muss?

Alles anzeigen

If you receive a "host key verification failed" error, it means that the host key of the remote host was changed[1]
. To fix this issue, you can add the new host key to your known_hosts file by running ssh-keyscan -t rsa your.server.example.com >> ~/.ssh/known_hosts[2]
. If you still have issues, you can connect with the debug parameter (-v) and send the output to troubleshoot further[3]

The debug parameter in SSH is -v, which stands for verbose. It provides more detailed information about the connection process and can help diagnose issues such as "host key verification failed"[1]
[2]
. To use it, you would add it to your SSH command like this: ssh -v user@your.server.example.com[3]
. The output will show you what is happening during the connection process and may provide clues as to why the error occurred. If you are still having trouble after using the -v parameter, you may need to manually edit your known_hosts file or remove the offending key[1]
[2]
[4]

_{sagt perplexity AI}

Falls du das was -v ausgibt noch analysieren möchtest kannst du das hier: https://www.perplexity.ai/

Gibts auch als praktische Plugin. Für alles was mit Code zutun hat sind die AIs meistens sehr hilfreich.

El Vulpes üblicherweise ist der Startpunkt bei git eher das Remote Repository was sich jeder der darauf arbeiten möchte dann als Lokale Repository mit Upstream zum Remote "cloned". Dann macht man Änderungen Lokal, "commited" diese in sein Lokales Repository und "pusht" es dann auf das Remote Repository. Arbeitet man mit mehreren Personen auf dem gleichen Remote Repository sollte man regelmäßig ein "pull" machen um die Änderungen der anderen vom Remote auch Lokal zu aktualisieren.

Zur Frage wie bekommst du Daten in dein Repo, ja du kannst dort einfach neue Files anlegen. Git stellt dann fest welche Dateien schon unter versionskontrolle stehen (bereits "getracked" sind) und welche neu sind, also erstmalig ins Remote Repository geschoben werden müssen. Bei schon existierenden Dateien wird in der Regel nur noch das Delta zum Remote übertragen nicht die ganze Datei.

Die Tutorials mit Bezug zu GitHub sind grundsätzlich nicht verkehrt weil letztendlich ist GitHub auch nichts anderes als ein Hoster für das Remote Repository.

Es gibt übrigens auch eine ganze Reihe GUI-Tools die das ganze gerade für Einsteiger etwas benutzerfreundlicher machen. Die helfen dir aber bei so grundsätzlichen Sachen wie Connection Problemen auch nur bedingt weiter.

Ich kann dir gern mal live ein paar Grundlagen zu git zeigen und wie man das benutzt, aber vor Freitag habe ich dafür leider keine Zeit.

Zitat von IamSalvation

Zitat von El Vulpes

Und wenn da nun "Host key verification failed" kommt?

If you receive a "host key verification failed" error, it means that the host key of the remote host was changed[1]
. To fix this issue, you can add the new host key to your known_hosts file by running ssh-keyscan -t rsa your.server.example.com >> ~/.ssh/known_hosts[2]
. If you still have issues, you can connect with the debug parameter (-v) and send the output to troubleshoot further[3]

The debug parameter in SSH is -v, which stands for verbose. It provides more detailed information about the connection process and can help diagnose issues such as "host key verification failed"[1]
[2]
. To use it, you would add it to your SSH command like this: ssh -v user@your.server.example.com[3]
. The output will show you what is happening during the connection process and may provide clues as to why the error occurred. If you are still having trouble after using the -v parameter, you may need to manually edit your known_hosts file or remove the offending key[1]
[2]
[4]

_{sagt perplexity AI}

Alles anzeigen

Manchmal hilft es, wenigstens die Grundlagen zu kennen... seufz.

Also: SSH ist eine verschlüsselte Verbindung. Damit Du weißt, daß Du mit der richtigen Stelle redest, muß sich der Server ausweisen. Das tut er mit dem host key, den er üblicherweise bei Einrichtung neu generiert hat. Loggst Du Dich das erste mal bei einem Server ein, stellt der SSH-client fest, daß er den key nicht kennt, gibt Dir einen Fingerabdruck davon aus und fragt Dich, was er tun soll. Jetzt liegt es an Dir, den Fingerabdruck zu überprüfen; sei es, weil der Serveranbieter ihn irgendwo veröffentlich hat, sei es, weil er im Bootlog Deiner VM in Äscher/AWS/GurgelKlaut/WoAuchImmer steht, oder sei es, weil Du Dich lokal vor die betreffende Kiste setzen und nachschauen kannst. Hast Du keine derartige Option, bleibt Dir nur TOFU (= Trust On First Use): Du hoffst, daß wenigstens die erste Verbindung nicht von einem bösen Hacker abgezweigt worden ist. Jedenfalls, falls Du den host key anhand des Fingerabdrucks akzeptieren möchtest, sagst Du das SSH. Selbiges speichert dann den host key zu sowohl der IP als auch dem hostnamen ab. Verbindest Du Dich später erneut mit dem gleichen host, dann überprüft SSH, ob er den gleichen host key bekommt, und beschwert sich heftigst, falls das nicht paßt. Letzteres sollte man ernst nehmen; der böse Sozialingenieur wird Dir natürlich sagen, daß Du das ignorieren sollst. Nichts desto trotz sagt Dir SSH, wie Du den Eintrag löschen kannst (Befehlszeile dafür, oder Zeile in der known_hosts-Datei), für den Fall, daß der key geändert wurde (zB Server neu eingerichtet oder sowas).

Die Option -v hilft Dir dafür herzlich wenig. SSH hat Dir in der Ausgabe schon gesagt, was falsch war... Das brauchst Du, wenn Du auf TCP-Ebene gar nicht erst hinkommst oder sonstige komische Dinge falsch sind.

Da ich damit viel geschäftlich und Privat arbeite mal ein kurzer Hilfe + Erklärversuch von mir.

Git arbeitet im Prinzip mit Kopien von Repositories (Versionsverwalteten Datengräbern).

Bei dir ist es vermutlich so, dass das Hauptrepository, dass verwendet wird auf deinem Webserver (Server) liegt.

Der Entwickler hat vermutlich bei sich das Repository dort geklont, macht lokal seine Änderungen und über einen commit "speichert" er diese.

Mit einem anschließenden "Push" kann er diese auf das Hauptrepository schieben. Wenn dann dort die Änderungen auch aktiv sind (branch, working copy usw. ist das ganze auch produktiv.).

Aus welchem Grund du das Repository bei dir lokal Klonen sollst verstehe ich nicht aber kurz ein Beispiel von meinem Server:

Auf dem Server liegt das Repository (im Dateiformat). Ich klone auf einem system per ssh:

(deck@steamdeck ~)$ git clone ssh://bioh4z4rd@homeone:/srv/git/awesomewm.git
Cloning into 'awesomewm'...
remote: Enumerating objects: 199, done.
remote: Counting objects: 100% (199/199), done.
remote: Compressing objects: 100% (173/173), done.
remote: Total 199 (delta 59), reused 106 (delta 9), pack-reused 0
Receiving objects: 100% (199/199), 3.18 MiB | 2.85 MiB/s, done.
Resolving deltas: 100% (59/59), done.

SSH merkt sich wie von anderen angemerkt zu der Server Adresse den Fingerprint (im Endeffekt das "Gesicht"). Ändert sich dieses kommt die Fehlermeldung mit dem Hostkey. Der Fingerprint ist lokal in der Datei ~/.ssh/known_hosts gespeichert:

deck@steamdeck ~)$ cat .ssh/known_hosts
homeone ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILkrucHGIP0mftMU0eA4hsbFKbJvJBvlKbSz9Vwd+MPC

Ich habe diesen kurz geändert und daraufhin wieder versucht zu klonen:

(deck@steamdeck ~)$ git clone ssh://bioh4z4rd@homeone:/srv/git/awesomewm.git
Cloning into 'awesomewm'...
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:w2c3qw43isDtuCqEtZh2j5MtpgwMwGE2PLgj0p4eB20.
Please contact your system administrator.
Add correct host key in /home/deck/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/deck/.ssh/known_hosts:1
Host key for homeone has changed and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.

Ich denke hier stehst du.

Folgendes Schlage ich dir vor: Frage den Provider nach dem SSH host key. Diesen vertraust du, indem du den Eintrag für deinen server in der ~/.ssh/known_hosts änderst. Nichts anderes hier bitte.

Dann sendest du dem Provider zusätzlich deinen sogenannten Public key. Ist in der Regel in ~/.ssh/id_ed25519.pub.
Hast du keinen, dann generier ihn über "ssh-keygen -t ed25519". Das ist ein state of the art key und älteres Material sollte eher nicht verwendet werden.

Ganz wichtig: Nur die .pub schicken. Die id_ed25519 ist im Grunde der Ausweis deines PCs.

Dein Provider hinterlegt nun diesen Key als sogenannten "authorized_key" auf dem Server. ~/.ssh/authorized_keys ist der Pfad hierfür.

Der Server erkennt den Fingerabdruck (Das Gesicht bzw. die Identität deines Computers) und erlaubt dir mit dem spezifizierten User sich einzuloggen.

Sieht bei mir dann so aus:

bioh4z4rd@homeone ~ % cat .ssh/authorized_keys 
ssh-ed25519 AAAAC3NzaC1lZDI1NTEICHZEIGEUCHDOCHNICHTMEINEIDENTITY deck@steamdeck

Ab dem Moment kannst du Klonen / einloggen per SSH ohne Passwort mit deinem PC, du hast den korrekten Host "gemerkt".

Es gibt eigentlich nur 2 Fälle in denen sich der HostKey ändert:

1. Ein Idiot war am Werk und hat einen neuen Key generiert oder den PC neu aufgesetzt

2. Der PC ist ein neuer / anderer.

Bist du dir sicher, dass du wirklich mit deinem Hoster redest?

Falls es bis morgen abend zeit hat, dann kann ich dir gerne per Videocall aushelfen

Zitat von El Vulpes

Rolle rückwärts. Mein Entwickler meint, dass ihm das nichts bringt in der Form, da er die Möglichkeit haben muss, Änderungen zum Repo zu pushen, was aber nicht funktionieren würde… Es beginnt mich grad langsam zu nerven…

Wäre es sonst nicht vielleicht sinnvoll, ein Github-Repository zu erstellen und anschließend die GitHub Actions zu nutzen, um bei Änderungen im Repo die Sachen auf den Server zu übertragen?