Verwenden der SSH-Schlüsselauthentifizierung

  • Artikel

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

Stellen Sie eine Verbindung mit Ihrem Git-Repository über SSH auf macOS, Linux oder Windows her, um eine sichere Verbindung mit HTTPS-Authentifizierung herzustellen.

Wichtig

SSH-URLs wurden geändert, aber alte SSH-URLs funktionieren weiterhin. Wenn Sie SSH bereits eingerichtet haben, aktualisieren Sie Ihre Remote-URLs auf das neue Format:

Aktuelle SSH-URLs beginnen mit ssh.dev.azure.com. Die vorherigen URLs verwenden vs-ssh.visualstudio.com.

  • Überprüfen Sie, welche Remotes SSH verwenden. Führen Sie git remote -v in der Shell aus, oder verwenden Sie stattdessen einen GUI-Client.
  • Besuchen Sie Ihr Repository im Web, und wählen Sie Klonen aus.
  • Wählen Sie SSH aus, und kopieren Sie die neue SSH-URL.
  • Führen Sie in Ihrer Shell git remote set-url <remote name> <new SSH URL> für die entfernte URL von jedem Repository aus, das Sie aktualisieren möchten. Alternativ können Sie einen GUI-Client verwenden, um die Remote-URLs zu aktualisieren.

Funktionsweise der SSH-Schlüsselauthentifizierung

Die SSH-Authentifizierung mit öffentlichem Schlüssel funktioniert mit einem asymmetrischen Paar von generierten Verschlüsselungsschlüsseln. Der öffentliche Schlüssel wird für Azure DevOps mitgeteilt und zum Überprüfen der anfänglichen SSH-Verbindung verwendet. Der private Schlüssel wird auf Ihrem System sicher aufbewahrt.

Einrichten der SSH-Schlüsselauthentifizierung

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

Hinweis

Ab Visual Studio 2017 kann SSH für Verbindungen mit Azure DevOps Git-Repositorys verwendet werden.

Tipp

Unter Windows empfehlen wir die Verwendung von Git Credential Manager oder persönlichen Zugriffstoken.

Schritt 1: Erstellen Ihrer SSH-Schlüssel

Hinweis

Wenn Sie bereits RSA SSH-Schlüssel auf Ihrem System erstellt haben, überspringen Sie diesen Schritt, und konfigurieren Sie Ihre SSH-Schlüssel. Um dies zu überprüfen, wechseln Sie zu Ihrem Startverzeichnis und sehen Sie sich den Ordner .ssh an (%UserProfile%\.ssh\ unter Windows oder ~/.ssh/ unter Linux, macOS und Windows mit Git Bash). Wenn zwei Dateien mit den jeweiligen Namen id_rsa und id_rsa.pub angezeigt werden, fahren Sie mit der Konfiguration Ihrer SSH-Schlüsselfort.

Sie müssen für den Client zunächst Schlüsselpaare aus öffentlichen und privaten Schlüsseln generieren, um die schlüsselbasierte Authentifizierung verwenden zu können. ssh-keygen.exe wird verwendet, um Schlüsseldateien zu generieren, und die Algorithmen DSA, RSA, ECDSA oder Ed25519 können angegeben werden. Wenn kein Algorithmus angegeben ist, wird RSA verwendet.

Hinweis

Der einzige von Azure DevOps unterstützte SSH-Schlüsseltyp ist RSA.

Um Schlüsseldateien mithilfe des RSA-Algorithmus zu generieren, führen Sie den folgenden Befehl über eine PowerShell oder eine andere Shell wie bash auf Ihrem Client aus:

ssh-keygen

Die Ausgabe des Befehls sollte die folgende Ausgabe anzeigen (wobei username durch Ihren Benutzernamen ersetzt wird):

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

Sie können die EINGABETASTE drücken, um die Standardeinstellung zu übernehmen, oder einen Pfad und/oder Dateinamen angeben, in 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, ist jedoch nicht empfehlenswert. Zusammen mit der Schlüsseldatei kann mit der Passphrase die zweistufige Authentifizierung bereitgestellt werden.

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 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

Wichtig

Teilen Sie niemals den Inhalt Ihres privaten Schlüssels. Wenn der private Schlüssel kompromittiert wurde, können Angreifer damit Servern vorgaukeln, dass die Verbindung von Ihnen stammt. Private Schlüsseldateien entsprechen einem Kennwort und sollten auf die gleiche Weise geschützt werden.

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.

Hinweis

Sie müssen diesen Vorgang für jede Organisation wiederholen, auf die Sie Zugriff haben und SSH verwenden möchten.

  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.

    Screenshot, der das Menüelement „Öffentliche SSH-Schlüssel“ und den in Azure DevOps ausgewählten Benutzeravatar zeigt.

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

    Screenshot, der den Zugriff auf „Sicherheitskonfiguration“ in Azure DevOps zeigt.

  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

    Fügen Sie keine Leerzeichen oder neuen Zeilen in das Feld mit den Schlüsseldaten ein, da dies dazu führen kann, dass Azure DevOps einen ungültigen öffentlichen Schlüssel verwendet. Beim Einfügen des Schlüssels wird häufig am Ende ein Zeilenvorschub hinzugefügt. Entfernen Sie ggf. diesen Zeilenvorschub.

    Screenshot, der das Konfigurieren eines öffentlichen Schlüssels in Azure DevOps illustriert.

  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. Beachten Sie außerdem, dass in Azure DevOps gespeicherte SSH-Schlüssel nach einem Jahr ablaufen. Wenn Ihr Schlüssel abläuft, können Sie einen neuen oder denselben Schlüssel hochladen, um weiterhin über SSH auf Azure DevOps zuzugreifen.

  5. Auf der Übersichtsseite wird oben eine Notiz mit den Serverabdrücken angezeigt. Notieren Sie sich diese, da sie beim ersten Herstellen einer Verbindung mit Azure DevOps über SSH erforderlich sind.

    Screenshot des Zugriffs auf die Sicherheitskonfiguration in Azure DevOps Services.

  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 den gegebenen Fingerabdruck mit den Fingerabdrücken, die auf der oben genannten Einstellungsseite angeboten werden. Fahren Sie nur fort, wenn sie übereinstimmen!

    Wenn alles richtig konfiguriert ist, sollte die Ausgabe wie folgt aussehen:

    remote: Shell access is not supported.

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

Schritt 3: Klonen des Git-Repositorys mit SSH

Hinweis

Informationen zum Verwenden von SSH mit einem Repository, das zuvor über HTTPS geklont wurde, finden Sie unter Aktualisieren Ihrer Remotedaten auf 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.

    Screenshot, der die von AZURE Repos SSH geklonte URL zeigt

    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, Wechseln vorhandener Organisationen zur Verwendung der neuen Domänennamen-URL.

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

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

    Sie sollten jetzt aufgefordert werden, Ihre Passphrase für Ihren SSH-Schlüssel einzugeben, bevor Sie fortfahren können, es sei denn, sie wird von einem SSH-Agent verwaltet:

    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 Schritt 2: Hinzufügen des öffentlichen Schlüssels zu Azure DevOps erneut. Weitere Probleme finden Sie im Abschnitt Fragen und Problembehandlung.

Tipp

Um SSH optimal zu nutzen, ist es üblich, einen SSH-Agent zum Verwalten Ihrer SSH-Schlüssel zu verwenden. Das Einrichten eines Agents geht jedoch über den Rahmen dieses Artikels hinaus.

Fragen und Problembehandlung

A: Es gibt zwei mögliche Warnmeldungen:

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.

Möglicherweise haben Sie zuvor Ihre SSH-Konfiguration geändert, um Ihre Sicherheitseinstellungen für Azure DevOps herabzustufen, indem Sie die folgenden Zeilen zu Ihrer ~/.ssh/config-Datei (%UserProfile%\.ssh\config unter Windows) hinzugefügt haben:

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

Bitte entfernen Sie diese Zeilen, und stellen Sie sicher, dass rsa-sha2-256 und/oder rsa-sha2-512 zugelassen sind.

Weitere Einzelheiten finden Sie im Blog-Beitrag.

F: SSH kann keine Verbindung herstellen. Was soll ich tun?

A: Es gibt mehrere verschiedene Probleme, die auftreten können:

  • 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.

    Möglicherweise haben Sie zuvor Ihre SSH-Konfiguration geändert, um Ihre Sicherheitseinstellungen für Azure DevOps herabzustufen, indem Sie die folgenden Zeilen zu Ihrer ~/.ssh/config-Datei (%UserProfile%\.ssh\config unter Windows) hinzugefügt haben:

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

    Bitte entfernen Sie diese Zeilen, und stellen Sie sicher, dass rsa-sha2-256 und/oder rsa-sha2-512 zugelassen sind.

    Weitere Einzelheiten finden Sie im Blog-Beitrag.

  • Kein passender Host-Schlüssel

    Dies sollte weder auf Azure DevOps Services noch auf neueren Azure DevOps Server-Versionen auftreten, wie im Blog-Beitrag 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 Ihrer ~/.ssh/config-Datei (unter Windows %UserProfile%\.ssh\config) Folgendes hinzufügen:

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

    Wichtig

    OpenSSH hat den Signaturalgorithmus für öffentliche ssh-rsa-Schlüssel in Version 8.2 veraltet und ihn in Version 8.8 standardmäßig 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 Ihrer ~/.ssh/config-Datei (unter Windows %UserProfile%\.ssh\config) 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 Ihrer ~/.ssh/config-Datei (unter Windows %UserProfile%\.ssh\config) 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 wurde in Version 6.9 von OpenSSH und diffie-hellman-group14-sha1 in Version 8.2 standardmäßig deaktiviert.

Tipp

Verwenden Sie für selbst gehostete Instanzen von Azure DevOps Server und TFS den entsprechenden Hostnamen in der Host-Zeile anstelle von ssh.dev.azure.com vs-ssh.visualstudio.com.

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

A: Sie können dafür einen SSH-Agent verwenden. Linux, macOS und Windows (ab Windows 10 (Build 1809) oder die Verwendung von Git für Windows mit Git Bash) werden alle mit einem SSH-Agent ausgeliefert. Der SSH-Agent kann verwendet werden, um Ihre SSH-Schlüssel zur wiederholten Verwendung zwischenzuspeichern. 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ü Conversions , und wählen Sie Export OpenSSH key aus. Speichern Sie die Datei mit dem privaten Schlüssel, und führen Sie dann die Schritte zum Einrichten nicht standardmäßiger Schlüssel aus. 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: Sie können den Fingerabdruck des öffentlichen hochgeladenen Schlüssels mit dem in Ihrem Profil angezeigten Schlüssel vergleichen, indem Sie den folgenden ssh-keygen-Befehl für Ihren öffentlichen Schlüssel über die Befehlszeile ausführen. Sie müssen den Pfad und den Dateinamen der öffentlichen Schlüsseldatei ändern, wenn Sie nicht die Standardwerte verwenden.

ssh-keygen -l -E md5 -f ~/.ssh/id_rsa.pub

Anschließend können Sie die MD5-Signatur mit der Signatur in Ihrem Profil vergleichen. Diese Überprüfung ist nützlich, wenn beim Hinzufügen des Schlüssels zu Azure DevOps Verbindungsprobleme auftreten oder sie befürchten, dass der öffentliche Schlüssel falsch in das Feld Schlüsseldaten eingefügt wurde.

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

A: Sie müssen das origin-Remoterepository in Git aktualisieren, um von einer HTTPS-URL zu einer SSH-URL zu wechseln. Führen Sie den folgenden Befehl aus, wenn Sie über die URL des SSH-Klons verfügen:

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

Git-Befehle, die auf das entfernte origin zugreifen, verwenden nun SSH.

F: Ich verwende Git LFS mit Azure DevOps Services und erhalte Fehlermeldungen, wenn ich Dateien abrufe, die von Git LFS nachverfolgt werden.

A: Azure DevOps Services unterstützt derzeit kein LFS über SSH. Verwenden Sie HTTPS, um sich mit Repository mit Git LFS-nachverfolgten Dateien zu verbinden.

F: Wie kann ich einen nicht standardmäßigen Schlüsselspeicherort verwenden, d. h. nicht „~/.ssh/id_rsa“ bzw. „~/.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 aufweist, 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. Dies ist besonders wichtig, wenn mehrere Identitäten verfügbar sind.

F: Ich habe mehrere SSH-Schlüssel. Gewusst wie der richtige SSH-Schlüssel für Azure DevOps verwendet wird?

A: Wenn Sie mehrere Schlüssel für einen SSH-Client konfigurieren und eine Verbindung mit einem SSH-Server herstellen, kann der Client die Schlüssel jeweils einzeln nacheinander ausprobieren, bis der Server einen akzeptiert.

Dies funktioniert jedoch aus technischen Gründen im Zusammenhang mit dem SSH-Protokoll und der Struktur unserer Git-SSH-URLs nicht mit Azure DevOps. Azure DevOps akzeptiert blind 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 fehl, ohne andere verfügbare Schlüssel aufgrund des folgenden Fehlers zu versuchen:

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

Für Azure DevOps müssen Sie SSH explizit so konfigurieren, dass 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 einfach an, den richtigen SSH-Schlüssel für den Azure DevOps-Host zu verwenden.

F: Gewusst wie unterschiedliche SSH-Schlüssel für verschiedene Organisationen in Azure DevOps verwendet werden?

A: Azure DevOps akzeptiert blind 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.

Sie können ihre SSH-Konfiguration jedoch ändern, um zwischen verschiedenen Organisationen zu unterscheiden und für jeden einzelnen Schlüssel unterschiedliche Schlüssel bereitzustellen. Dazu müssen Sie Hostalias verwenden, um separate Host-Abschnitte in Ihrer SSH-Konfiguration zu erstellen. Dies liegt daran, dass alle gehosteten Azure DevOps-URLs denselben Hostnamen haben (ssh.dev.azure.com), sodass SSH keine Möglichkeit hat, sie standardmäßig zu unterscheiden.

# 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. Zum Beispiel würde git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo zu git@devops_fabrikam:v3/Fabrikam/Project1/fab_repo werden.

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

A: Wenn Sie einen neuen SSH-Schlüssel bei Azure DevOps Services registrieren, erhalten Sie eine E-Mail-Benachrichtigung mit der Information, dass Ihrem Konto ein neuer SSH-Schlüssel hinzugefügt wurde.

Beispiel für eine SSH-Benachrichtigung

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

A: Wenn Sie eine Benachrichtigung erhalten, dass ein SSH-Schlüssel registriert wird, der nicht manuell von Ihnen in den Dienst hochgeladen wurde, wurden Ihre Anmeldeinformationen möglicherweise kompromittiert.

Im nächsten Schritt müsste untersucht werden, ob Ihr Kennwort kompromittiert wurde. Das Ändern Ihres Kennworts ist immer ein guter erster Schritt zum Schutz vor diesem Angriffsvektor. Wenden Sie sich als Azure Active Directory-Benutzer an Ihren Administrator, um zu überprüfen, ob Ihr Konto von einer unbekannten Quelle/einem unbekannten Standort aus 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?

A: Einige Linux-Distributionen, z. B. Fedora Linux, verfügen über Kryptorichtlinien, die stärkere SSH-Signaturalgorithmen erfordern, als Azure DevOps unterstützt (Stand Januar 2021). Es gibt eine offene Featureanforderung, um dies zu unterstützen.

Sie können das Problem umgehen, indem Sie Ihrer SSH-Konfiguration (~/.ssh/config) folgenden Code hinzufügen:

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

Tipp

Verwenden Sie für selbst gehostete Instanzen von Azure DevOps Server und TFS den entsprechenden Hostnamen in der Host-Zeile anstelle von ssh.dev.azure.com vs-ssh.visualstudio.com.