Verwenden der SSH-Schlüsselauthentifizierung

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Verwenden Sie SSH unter macOS, Linux oder Windows, um sich sicher bei Azure Repos Git-Repositorys in Azure DevOps zu authentifizieren.

In diesem Artikel wird gezeigt, wie Sie ein RSA-Schlüsselpaar erstellen, den öffentlichen Schlüssel zu Ihrem Profil hinzufügen und Repositorys mithilfe von SSH klonen.

Voraussetzungen

Funktionsweise der SSH-Schlüsselauthentifizierung

Die SSH-Authentifizierung mit öffentlichem Schlüssel funktioniert mit einem asymmetrischen Paar von generierten Verschlüsselungsschlüsseln. Sie teilen den öffentlichen Schlüssel mit Azure DevOps, um die anfängliche SSH-Verbindung zu überprüfen. Bewahren Sie den privaten Schlüssel sicher und geschützt auf Ihrem System auf.

Einrichten der SSH-Schlüsselauthentifizierung

Um SSH mit Azure Repos zu verwenden, generieren Sie ein RSA-Schlüsselpaar, fügen Sie ihrem Azure DevOps Profil den öffentlichen Schlüssel hinzu, überprüfen Sie den Fingerabdruck des Servers, und klonen oder aktualisieren Sie dann Ihr Repository, um die SSH-URL zu verwenden.

Wenn Sie nur den schnellsten Pfad benötigen, führen Sie Schritt 1, Schritt 2 und Schritt 3 in der Reihenfolge aus, und verwenden Sie dann die Problembehandlung bei der SSH-Authentifizierung nur, wenn ein Befehl fehlschlägt.

Die folgenden Schritte behandeln die Konfiguration der SSH-Schlüsselauthentifizierung auf den folgenden Plattformen mithilfe der Befehlszeile (auch genannt shell):

• Linux
• macOS
• Windows Systeme mit Git für Windows

Schritt 1: Erstellen Ihrer SSH-Schlüssel

Um die schlüsselbasierte Authentifizierung zu verwenden, müssen Sie zuerst ein Öffentliches/privates Schlüsselpaar für Ihren Client generieren. OpenSSH kann mehrere Schlüsseltypen generieren, aber Azure DevOps unterstützt RSA-Schlüssel für die SSH-Authentifizierung.

Um ein RSA-Schlüsselpaar für Azure DevOps zu generieren, führen Sie den folgenden Befehl in PowerShell oder einer anderen Shell wie bash auf Ihrem Client aus:

ssh-keygen -t rsa -b 3072

Die Ausgabe des Befehls sollte die folgende Ausgabe anzeigen (wobei username Ihr Benutzername ist):

Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\username/.ssh/id_rsa):

Drücken Sie die EINGABETASTE , um den Standardwert zu akzeptieren, oder geben Sie einen Pfad und/oder Dateinamen an, an dem Die Schlüssel generiert werden sollen. An diesem Punkt werden Sie aufgefordert, eine Passphrase zum Verschlüsseln der Dateien für den privaten Schlüssel zu verwenden. Die Passphrase kann leer sein, wird jedoch nicht empfohlen. Die Passphrase fügt eine weitere Schutzebene für Ihren privaten Schlüssel hinzu, wenn die Datei verfügbar gemacht wird.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\username/.ssh/id_rsa.
Your public key has been saved in C:\Users\username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:FHK6WjcUkcfQjdorarzlak1Ob/x7AmqQmmx5ryYYV+8 username@LOCAL-HOSTNAME
The key's randomart image is:
+---[RSA 3072]----+
|      . ** o     |
|       +.o= .    |
|      . o+       |
|      .+. .      |
|     .ooS  .     |
|  . .oo.=.o      |
|   =.= O.= .     |
|  . B BoE + . .  |
|   . *+*o. .o+   |
+----[SHA256]-----+

Jetzt verfügen Sie über ein öffentliches/privates RSA-Schlüsselpaar an dem von Ihnen angegebenen Speicherort. Die .pub Dateien sind öffentliche Schlüssel, und Dateien ohne Erweiterung sind private Schlüssel:

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        10/11/2022   6:29 PM           2610 id_rsa
-a----        10/11/2022   6:29 PM            578 id_rsa.pub

Schritt 2: Hinzufügen des öffentlichen Schlüssels zu Azure DevOps

Ordnen Sie den im vorherigen Schritt generierten öffentlichen Schlüssel Ihrer Benutzer-ID zu.

1. Öffnen Sie Ihre Sicherheitseinstellungen, indem Sie zum Webportal navigieren und das Symbol neben dem Avatar oben rechts auf der Benutzeroberfläche auswählen. Wählen Sie im daraufhin angezeigten Menü Öffentlicher SSH-Schlüssel aus.

   

2. Wählen Sie + Neuer Schlüssel aus.

   

3. Kopieren Sie den Inhalt des öffentlichen Schlüssels (z. B. id_rsa.pub), den Sie generiert haben, in das Feld Öffentliche Schlüsseldaten.

   Wichtig

   Vermeiden Sie das Hinzufügen zusätzlicher Leerzeichen oder Zeilenumbrüche in der Mitte des Schlüsselwerts, da sie den Schlüssel ungültig machen können. Wenn beim Einfügen Formatierungsartefakte hinzugefügt werden, entfernen Sie sie, bevor Sie speichern.

   

4. Weisen Sie dem Schlüssel eine nützliche Beschreibung zu, damit Sie ihn später erkennen können. (Diese Beschreibung wird auf der Seite Öffentlicher SSH-Schlüssel für Ihr Profil angezeigt). Wählen Sie Speichern aus, um den öffentlichen Schlüssel zu speichern. Nach dem Speichern können Sie den Schlüssel nicht mehr ändern. Sie können den Schlüssel löschen oder einen neuen Eintrag für einen anderen Schlüssel erstellen. Es gibt keine Einschränkungen für die Anzahl der Schlüssel, die Sie Ihrem Benutzerprofil hinzufügen können.

   Hinweis

   Organisationsrichtlinien können das Ablaufen von SSH-Schlüsseln erzwingen. Weitere Informationen finden Sie unter Ändern von Anwendungsverbindungs- und Sicherheitsrichtlinien für Ihre Organisation.

5. Auf der Übersichtsseite mit öffentlichen SSH-Schlüsseln werden die Fingerabdrücke des Servers angezeigt. Notieren Sie sich den SHA256-Fingerabdruck, der beim ersten Herstellen einer Verbindung mit Azure DevOps über SSH verwendet werden soll.

   

6. Testen Sie die Verbindung, indem Sie den folgenden Befehl ausführen:

   ssh -T git@ssh.dev.azure.com
   

   Wenn Sie zum ersten Mal eine Verbindung herstellen, sollten Sie die folgende Ausgabe erhalten:

   The authenticity of host 'ssh.dev.azure.com (<IP>)' can't be established.
   RSA key fingerprint is SHA256:ohD8VZEXGWo6Ez8GSEJQ9WpafgLFsOfLOtGGQCQo6Og.
   This key is not known by any other names
   Are you sure you want to continue connecting (yes/no/[fingerprint])?
   

   Vergleichen Sie diesen Fingerabdruck mit dem SHA256-Fingerabdruck, der auf der Seite mit öffentlichen SSH-Schlüsseln angezeigt wird. Fahren Sie nur fort, wenn die Werte übereinstimmen.

7. Geben Sie yes ein, um fortzufahren. Wenn alles korrekt konfiguriert ist, sollte die Ausgabe wie folgt aussehen:

    Warning: Permanently added 'ssh.dev.azure.com' (RSA) to the list of known hosts.
    remote: Shell access is not supported.
    shell request failed on channel 0
   

   Wenn nicht, lesen Sie den Abschnitt zu Fragen und Problembehandlung.

Schritt 3: Klonen des Git-Repositorys mithilfe von SSH

1. Kopieren Sie die URL des SSH-Klons aus dem Webportal. In diesem Beispiel gilt die URL des SSH-Klons für ein Repository in einer Organisation namens fabrikam-fiber, wie im ersten Teil der URL nach dev.azure.com ersichtlich ist.

   

   Hinweis

   Bei Azure DevOps Services ist das Format für die Projekt-URL dev.azure.com/{your organization}/{your project}. Das vorherige Format, das auf das Format visualstudio.com verweist, wird jedoch weiterhin unterstützt. Weitere Informationen finden Sie unter Einführung in Azure DevOps: Bestehende Organisationen auf die Verwendung der neuen Domain-URL umstellen.

2. Führen Sie git clone an einer Eingabeaufforderung aus.

   git clone git@ssh.dev.azure.com:v3/fabrikam-fiber/FabrikamFiber/FabrikamFiber
   

   Wenn Sie keinen SSH-Agent verwenden, werden Sie aufgefordert, Ihre Passphrase einzugeben:

   Cloning into 'FabrikamFiber'...
   Enter passphrase for key '/c/Users/username/.ssh/id_rsa':
   remote: Azure Repos
   remote: Found 127 objects to send. (50 ms)
   Receiving objects: 100% (127/127), 56.67 KiB | 2.58 MiB/s, done.
   Resolving deltas: 100% (15/15), done.
   

   Wenn Sie stattdessen aufgefordert werden, einen Fingerabdruck zu überprüfen, lesen Sie Step 2: Fügen Sie den öffentlichen Schlüssel erneut zu Azure DevOps hinzu. Leisen Sie bei anderen Problemen den Abschnitt Fragen und Problembehandlung.

Verwenden von KI zum Arbeiten mit SSH-authentifizierten Repositorys

Wenn Sie Git-Repositorys mit GitHub Copilot oder dem Azure DevOps MCP-Server verwenden, können Sie Anweisungen in natürlicher Sprache verwenden, um Ihre SSH-Einrichtung zu überprüfen und Authentifizierungsprobleme zu diagnostizieren.

Problembehandlung und häufige Fragen

Verwenden Sie die folgenden Abschnitte, um das Problem zu finden, das Ihrem SSH-Setupproblem entspricht.

• Wenn Ihr Schlüssel abgelaufen oder ungültig ist, beginnen Sie mit abgelaufenen oder ungültigen Schlüsseln.
• Wenn SSH keine Verbindung herstellen kann, beginnen Sie mit häufig auftretenden Verbindungsfehlern.
• Wenn Sie wiederholt zur Eingabe einer Passphrase aufgefordert werden, beginnen Sie mit SSH-Agent- und Passphrasenproblemen.
• Wenn Sie mehrere Schlüssel oder Organisationen verwenden, wechseln Sie zum Verwalten mehrerer Schlüssel und Organisationen.
• Wenn Sie Benachrichtigungen oder Kontoanleitungen benötigen, wechseln Sie zu Benachrichtigungen und Kontoproblemen.

Abgelaufene oder ungültige Schlüssel

F: Mein SSH-Schlüssel ist abgelaufen. Wie sollte ich vorgehen?

A: Führen Sie die vorhergehenden Schritte aus, um einen neuen SSH-Schlüssel zu erstellen und hochzuladen.

Als alternative Option kann ein Project Collection Admin die Richtlinie deaktivieren, die das Ablaufdatum des SSH-Schlüssels überprüft. Standardmäßig ist die Richtlinie zum Validieren des SSH-Schlüsselablaufdatums aktiviert. Weitere Informationen finden Sie unter SSH-Schlüsselrichtlinien.

Sie erhalten automatisch eine Benachrichtigung sieben Tage vor und wann Ihr Schlüssel abläuft. Zusammen mit diesen Benachrichtigungen sehen Sie die folgenden Nachrichten:

remote: Authentication failed: your SSH key has expired. To restore access, visit https://aka.ms/ado-ssh-public-key-expired for guidance.
remote: Public key authentication failed.
fatal:  Could not read from remote repository.

Häufige Verbindungsfehler

F: Ich sehe Warnungen im Zusammenhang mit ssh-rsa. Wie sollte ich vorgehen?

A: Möglicherweise wird eine der folgenden Warnmeldungen angezeigt:

ssh-rsa is about to be deprecated and your request has been throttled. Please use rsa-sha2-256 or rsa-sha2-512 instead. Your session will continue automatically. For more details see https://devblogs.microsoft.com/devops/ssh-rsa-deprecation.

Oder

You’re using ssh-rsa that is about to be deprecated and your request has been blocked intentionally. Any SSH session using ssh-rsa is subject to brown out (failure during random time periods). Please use rsa-sha2-256 or rsa-sha2-512 instead. For more details see https://devblogs.microsoft.com/devops/ssh-rsa-deprecation.

Wenn Sie Ihre SSH-Konfiguration so geändert haben, dass Ihre Sicherheitseinstellungen für Azure DevOps heruntergestuft werden, indem Sie der Datei ~/.ssh/config (%UserProfile%\.ssh\config auf Windows) Folgendes hinzufügen:

Host ssh.dev.azure.com vs-ssh.visualstudio.com
  HostkeyAlgorithms +ssh-rsa

Entfernen Sie diese Zeilen jetzt und stellen Sie sicher, dass rsa-sha2-256 und rsa-sha2-512 zugelassen sind.

Weitere Informationen finden Sie im Blogbeitrag.

Diese Korrektur ist der kanonische Fix für veraltete ssh-rsa Warnungen und nicht unterstützte ssh-rsa Fehler. Verwenden Sie sie als ersten Schritt für diese Szenarien.

F: SSH kann keine Verbindung herstellen. Wie sollte ich vorgehen?

A: Es könnten mehrere unterschiedliche Probleme auftreten:

• Verwendung von nicht unterstütztem ssh-rsa

  You’re using ssh-rsa that is unsupported. Please use rsa-sha2-256 or rsa-sha2-512 instead. For more details see https://devblogs.microsoft.com/devops/ssh-rsa-deprecation.
  

  Wenden Sie dieselbe Abhilfemaßnahme an, die in der vorherigen Frage zu ssh-rsa-Warnungen beschrieben wurde: Entfernen Sie jede HostkeyAlgorithms +ssh-rsa-Außerkraftsetzung und verwenden Sie rsa-sha2-256 und/oder rsa-sha2-512.

• Kein passender Host-Schlüssel

  Dieses Problem sollte nicht bei Azure DevOps Dienst oder in neueren Azure DevOps Server Versionen auftreten, wie im beitrag blog post erwähnt.

  Unable to negotiate with <IP> port 22: no matching host key type found. Their offer: ssh-rsa
  

  Ändern Sie Ihre SSH-Konfiguration so, dass Ihre Sicherheitseinstellungen für Azure DevOps herabgestuft werden, indem Sie Der Datei ~/.ssh/config (%UserProfile%\.ssh\config für Windows) Folgendes hinzufügen:

  Host ssh.dev.azure.com vs-ssh.visualstudio.com
     HostkeyAlgorithms +ssh-rsa
  

  Verwenden Sie diese Problemumgehung nur für Legacykompatibilitätsszenarien, in der Regel für ältere selbst gehostete Azure DevOps Server Konfigurationen. Behalten Sie für Azure DevOps Services sichere Standardwerte bei, und vermeiden Sie dauerhafte ssh-rsa Außerkraftsetzungen.

  Wichtig

  OpenSSH hat den Signaturalgorithmus für öffentliche ssh-rsa-Schlüssel in Version 8.2 als veraltet markiert und ihn in Version 8.8 deaktiviert.

• Keine passende MAC

  Unable to negotiate with <IP> port 22: no matching MAC found. Their offer: hmac-sha2-256,hmac-sha2-512
  

  Ändern Sie Ihre SSH-Konfiguration so, dass Ihre Sicherheitseinstellungen für Azure DevOps herabgestuft werden, indem Sie Der Datei ~/.ssh/config (%UserProfile%\.ssh\config für Windows) Folgendes hinzufügen:

  Host ssh.dev.azure.com vs-ssh.visualstudio.com
     MACs +hmac-sha2-512,+hmac-sha2-256
  

• Keine passende Methode für den Schlüsselaustausch

  Unable to negotiate with <IP> 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256
  

  Ändern Sie Ihre SSH-Konfiguration so, dass Ihre Sicherheitseinstellungen für Azure DevOps herabgestuft werden, indem Sie Der Datei ~/.ssh/config (%UserProfile%\.ssh\config für Windows) Folgendes hinzufügen:

  Host ssh.dev.azure.com vs-ssh.visualstudio.com
     KexAlgorithms +diffie-hellman-group-exchange-sha256,+diffie-hellman-group14-sha1,+diffie-hellman-group1-sha1
  

  Wichtig

  Der Schlüsselaustauschalgorithmus diffie-hellman-group1-sha1 ist in Version 6.9 von OpenSSH und diffie-hellman-group14-sha1 in Version 8.2 standardmäßig deaktiviert.

SSH-Agent- und Passphrasenprobleme

F: Der SSH-Agent wird nicht ausgeführt, oder mein Schlüssel wird nicht geladen. Wie sollte ich vorgehen?

A: Wenn Ihr Schlüssel vorhanden ist, SSH aber trotzdem jedes Mal nach einer Passphrase fragt oder wenn das Klonen fehlschlägt, nachdem der Schlüssel erfolgreich erstellt wurde, überprüfen Sie, ob der SSH-Agent läuft und ob Ihr Schlüssel geladen ist.

Verwenden Sie den folgenden Befehl, um zu sehen, welche Identitäten der Agent aktuell geladen hat:

ssh-add -l

Wenn die Ausgabe anzeigt, dass der Agent keine Identitäten hat, fügen Sie dem Agenten Ihren privaten Schlüssel hinzu:

ssh-add ~/.ssh/id_rsa

Stellen Sie auf Windows sicher, dass der ssh-agent Dienst ausgeführt wird, bevor Sie den Schlüssel hinzufügen, wenn Sie PowerShell mit dem integrierten OpenSSH-Agent verwenden. Wenn Sie Git Bash oder einen anderen SSH-Client verwenden, lesen Sie die Dokumentation dieses Clients zum Starten des Agents und Laden von Schlüsseln.

Wenn Sie einen Agent nicht verwenden möchten, kann SSH weiterhin funktionieren, Sie werden jedoch häufiger zur Eingabe der Schlüsselpassphrase aufgefordert.

F: Wie kann ich die Passphrase für meinen Schlüssel in Git speichern?

A: Verwenden Sie einen SSH-Agent. Linux, macOS und Windows (beginnend mit Windows 10 (Build 1809) oder mit Git für Windows mit Git Bash) werden alle mit einem SSH-Agent ausgeliefert. Der SSH-Agent kann Ihre SSH-Schlüssel zur wiederholten Verwendung zwischenspeichern. Weitere Informationen zur Verwendung finden Sie im Handbuch Ihres SSH-Anbieters.

F: Ich verwende PuTTY als SSH-Client und generierte meine Schlüssel mit PuTTYgen. Kann ich diese Schlüssel mit Azure DevOps Services verwenden?

A: Ja. Laden Sie den privaten Schlüssel mit PuTTYgen, wechseln Sie zum Menü Konvertierungen, und wählen Sie OpenSSH-Schlüssel exportieren aus. Speichern Sie die Datei des privaten Schlüssels, und folgen Sie dann der späteren Frage in diesem Artikel zur Verwendung eines nicht standardmäßigen Schlüsselspeicherorts. Kopieren Sie Ihren öffentlichen Schlüssel direkt aus dem PuTTYgen-Fenster, und fügen Sie ihn in das Feld Schlüsseldaten in Ihren Sicherheitseinstellungen ein.

F: Wie kann ich überprüfen, ob der hochgeladene öffentliche Schlüssel derselbe Schlüssel ist wie mein lokaler Schlüssel?

A: Überprüfen Sie den Fingerabdruck des öffentlichen Schlüssels, den Sie hochgeladen haben, indem Sie ihn mit dem in Ihrem Profil angezeigten Fingerabdruck vergleichen. Führen Sie den folgenden ssh-keygen Befehl für Ihren öffentlichen Schlüssel mithilfe der Befehlszeile aus. Sie müssen den Pfad und den Namen der Datei mit dem öffentlichen Schlüssel ändern, wenn Sie nicht die Standardwerte verwenden.

ssh-keygen -l -E md5 -f <path_to_your_public_key>

ssh-keygen -l -E sha256 -f <path_to_your_public_key>

Vergleichen Sie dann die Signatur mit der Signatur in Ihrem Profil. Diese Überprüfung ist nützlich, wenn Sie Verbindungsprobleme haben oder Bedenken haben, dass der öffentliche Schlüssel beim Hinzufügen des Schlüssels zu Azure DevOps falsch in das Feld "Schlüsseldaten" eingefügt wird.

F: Wie kann ich SSH in einem Repository verwenden, in dem bis jetzt HTTPS verwendet wird?

A: Aktualisieren Sie das origin Remote in Git, um es von einer HTTPS- auf eine SSH-URL zu ändern. Führen Sie nach dem Abrufen der SSH-Klon-URL den folgenden Befehl aus:

git remote set-url origin <SSH URL to your repository>

Git-Befehle, die auf den Remotezugriff origin aufrufen, verwenden SSH.

Verwalten mehrerer Schlüssel und Organisationen

F: Ich verwende Git LFS mit Azure DevOps Services und erhalte Fehler beim Abrufen von Dateien, die von Git LFS nachverfolgt werden.

A: Azure DevOps Dienste unterstützen derzeit LFS über SSH nicht. Verwenden Sie HTTPS, um eine Verbindung zu Repositories mit Git LFS-nachverfolgten Dateien herzustellen.

F: Wie kann ich einen nicht standardmäßigen Schlüsselspeicherort verwenden, d. h. nicht ~/.ssh/id_rsa und ~/.ssh/id_rsa.pub?

A: Um einen Schlüssel zu verwenden, der an einem anderen Speicherort als dem Standardspeicherort gespeichert wurde, führen Sie die folgenden beiden Aufgaben aus:

1. Sorgen Sie dafür, dass sich die Schlüssel in einem Ordner befinden, den nur Sie lesen oder bearbeiten können. Wenn der Ordner weitergehende Berechtigungen hat, verwendet SSH die Schlüssel nicht.

2. Sie müssen SSH über den Speicherort des Schlüssels informieren, z. B. indem Sie ihn als „Identität“ in der SSH-Konfiguration angeben:

   Host ssh.dev.azure.com
     IdentityFile ~/.ssh/id_rsa_azure
     IdentitiesOnly yes
   

Die Einstellung IdentitiesOnly yes stellt sicher, dass SSH keine andere verfügbare Identität zur Authentifizierung verwendet. Diese Einstellung ist besonders wichtig, wenn mehr als eine Identität verfügbar ist.

F: Ich habe mehrere SSH-Schlüssel. Wie verwende ich den richtigen SSH-Schlüssel für Azure DevOps?

A: Wenn Sie mehrere Schlüssel für einen SSH-Client konfigurieren, versucht der Client, sich nacheinander mit den einzelnen Schlüsseln zu authentifizieren, bis der SSH-Server einen davon akzeptiert.

Dieser Ansatz funktioniert jedoch nicht mit Azure DevOps aufgrund technischer Einschränkungen im Zusammenhang mit dem SSH-Protokoll und der Struktur unserer Git SSH-URLs. Azure DevOps akzeptiert den ersten vom Client während der Authentifizierung bereitgestellten Schlüssel. Wenn dieser Schlüssel für das angeforderte Repository ungültig ist, schlägt die Anforderung fehl, ohne dass andere verfügbare Schlüssel versucht werden; dies führt zur folgenden Fehlermeldung:

remote: Public key authentication failed.
fatal: Could not read from remote repository.

Für Azure DevOps müssen Sie SSH so konfigurieren, dass explizit eine bestimmte Schlüsseldatei verwendet wird. Die Prozedur ist identisch mit der Verwendung eines Schlüssels, der an einem nicht standardmäßigen Speicherort gespeichert ist. Weisen Sie SSH an, den richtigen SSH-Schlüssel für den Azure DevOps-Host zu verwenden.

F: Wie verwende ich unterschiedliche SSH-Schlüssel für verschiedene Organisationen in Azure DevOps?

A: Azure DevOps akzeptiert den ersten Schlüssel, den der Client während der Authentifizierung bereitstellt. Wenn dieser Schlüssel für das angeforderte Repository ungültig ist, schlägt die Anforderung mit dem folgenden Fehler fehl:

remote: Public key authentication failed.
fatal: Could not read from remote repository.

Dieser Fehler tritt auf, da alle Azure DevOps URLs denselben Hostnamen (ssh.dev.azure.com) gemeinsam verwenden, sodass SSH nicht standardmäßig zwischen ihnen unterscheiden kann. Sie können ihre SSH-Konfiguration jedoch ändern, um zwischen verschiedenen Organisationen zu unterscheiden, indem Sie für jede unterschiedliche Schlüssel bereitstellen. Verwenden Sie Host-Aliasnamen, um separate Host-Abschnitte in Ihrer SSH-Konfigurationsdatei zu erstellen.

# The settings in each Host section are applied to any Git SSH remote URL with a
# matching hostname.
# Generally:
# * SSH uses the first matching line for each parameter name, e.g. if there's
#   multiple values for a parameter across multiple matching Host sections
# * "IdentitiesOnly yes" prevents keys cached in ssh-agent from being tried before
#   the IdentityFile values we explicitly set.
# * On Windows, ~/.ssh/your_private_key maps to %USERPROFILE%\.ssh\your_private_key,
#   e.g. C:\Users\<username>\.ssh\your_private_key.

# Imagine that we have the following two SSH URLs:
# * git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo
#   * For this, we want to use `fabrikamkey`, so we'll create `devops_fabrikam` as
#     a Host alias and tell SSH to use `fabrikamkey`.
# * git@ssh.dev.azure.com:v3/Contoso/Project2/con_repo
#   * For this, we want to use `contosokey`, so we'll create `devops_contoso` as
#     a Host alias and tell SSH to use `contosokey`.
#
# To set explicit keys for the two host aliases and to tell SSH to use the correct
# actual hostname, add the next two Host sections:
Host devops_fabrikam
  HostName ssh.dev.azure.com
  IdentityFile ~/.ssh/private_key_for_fabrikam
  IdentitiesOnly yes

Host devops_contoso
  HostName ssh.dev.azure.com
  IdentityFile ~/.ssh/private_key_for_contoso
  IdentitiesOnly yes

Anschließend teilen Sie Git mit, dass Sie statt der echten URLs diese URLs für jedes Repository als Remote verwenden möchten, indem Sie den Hostnamen in den vorhandenen Remotes durch devops_fabrikam bzw. devops_contoso ersetzen. git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo wird beispielsweise zu git@devops_fabrikam:v3/Fabrikam/Project1/fab_repo.

Benachrichtigungen und Kontoprobleme

F: Welche Benachrichtigungen kann ich über meine SSH-Schlüssel erhalten?

Eine: Möglicherweise erhalten Sie einige Benachrichtigungen zu Ihren SSH-Schlüsseln.

• Ihrer Organisation wurde ein neuer SSH-Schlüssel hinzugefügt.

• Ein MIT Ihrem Konto verknüpfter SSH-Schlüssel läuft in sieben Tagen ab und ist nicht für die Authentifizierung gültig.

• Ein SSH-Schlüssel, der Ihrem Konto zugeordnet ist, ist abgelaufen und ist nicht mehr gültig für die Authentifizierung.

  Beispielbenachrichtigung

  

F: Was gehe ich vor, wenn ich glaube, dass jemand anderes als ich SSH-Schlüssel zu meinem Konto hinzufügt?

Eine: Wenn Sie eine SSH-Schlüsselregistrierungsbenachrichtigung erhalten, die Sie nicht initiiert haben, werden Ihre Anmeldeinformationen möglicherweise kompromittiert.

Der nächste Schritt besteht darin, zu untersuchen, ob Ihr Kennwort kompromittiert ist. Das Ändern Ihres Kennworts ist immer ein guter erster Schritt zum Schutz vor diesem Angriffsvektor. Wenn Sie ein Microsoft Entra Benutzer sind, wenden Sie sich an Ihren Administrator, um zu überprüfen, ob Ihr Konto von einer unbekannten Quelle oder einem unbekannten Speicherort verwendet wurde.

F: Wie gehe ich vor, wenn ich weiterhin zur Eingabe meines Kennworts aufgefordert werde und GIT_SSH_COMMAND="ssh -v" git fetch den Text no mutual signature algorithm oder corresponding algo not in PubkeyAcceptedAlgorithms anzeigt?

Eine: Einige Linux-Distributionen, z. B. Fedora Linux, erzwingen Kryptorichtlinien, die stärkere SSH-Signaturalgorithmen erfordern, als Ihre aktuelle Azure DevOps SSH-Konfiguration zulässt.

Um das Problem zu umgehen, fügen Sie Ihrer SSH-Konfiguration den folgenden Code hinzu (~/.ssh/config):

Host ssh.dev.azure.com vs-ssh.visualstudio.com
   PubkeyAcceptedAlgorithms +ssh-rsa

Wenn Ihre OpenSSH-Version nur den älteren Einstellungsnamen unterstützt, verwenden Sie PubkeyAcceptedKeyTypes stattdessen.

Verwenden Sie diesen Code als temporäre Kompatibilitätsumgehung. Aktualisieren Sie nach Möglichkeit Ihren SSH-Client oder Ihre Serverkonfiguration, und entfernen Sie diese Ausnahme nach dem Test.

Allgemeine Fragen

F: Kann ich SSH mit Azure DevOps Server verwenden?

A: Ja. Verwenden Sie für selbst gehostete Azure DevOps Server Instanzen Ihren Serverhostnamen in ssh-Konfiguration und Remote-URLs anstelle von ssh.dev.azure.com. Wo in diesem Artikel ssh.dev.azure.com oder vs-ssh.visualstudio.com steht, ersetzen Sie dies durch den Hostnamen Ihres Servers.

F: Warum funktionierte mein Azure DevOps Services SSH-Schlüssel nicht mehr?

A: Für die SSH-Schlüsselauthentifizierung müssen Sie sich regelmäßig mit dem vollständigen Authentifizierungsfluss (Web) bei Azure DevOps Services anmelden. Die Anmeldung ist einmal alle 30 Tage für viele Benutzer ausreichend, sie müssen sich jedoch je nach Microsoft Entra Konfiguration häufiger anmelden. Wenn Ihr SSH-Schlüssel nicht mehr funktioniert, versuchen Sie zuerst, sich bei Ihrer Organisation anzumelden und die vollständige Authentifizierungsaufforderung abzuschließen. Wenn Ihr SSH-Schlüssel immer noch nicht funktioniert, überprüfen Sie, ob er abgelaufen ist.

Verwandte Inhalte

• Anmeldeinformationsmanager einrichten
• Übersicht über azure DevOps MCP Server
• Verwalten großer Dateien
• Festlegen von Git-Repositoryberechtigungen