Verwenden der SSH-Schlüsselauthentifizierung

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

Sie können eine Verbindung mit Ihren Git-Repositorys über SSH unter macOS, Linux oder Windows herstellen, um eine sichere Verbindung mit Azure DevOps herzustellen.

Voraussetzungen

Funktionsweise der SSH-Schlüsselauthentifizierung

Die SSH-Authentifizierung mit öffentlichem Schlüssel funktioniert mit einem asymmetrischen Paar von generierten Verschlüsselungsschlüsseln. Der schlüssel public wird für Azure DevOps freigegeben und verwendet, um die anfängliche SSH-Verbindung zu überprüfen. 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):

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

Schritt 1: Erstellen Ihrer SSH-Schlüssel

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 Ed25519 verwendet.

Um Schlüsseldateien mithilfe des RSA-Algorithmus zu generieren, der von Azure DevOps unterstützt wird (entweder RSA-SHA2-256 oder RSA-SHA2-512), führen Sie einen der folgenden Befehle aus einer PowerShell oder einer anderen Shell wie bash auf Ihrem Client aus:

ssh-keygen -t rsa-sha2-256

Oder

ssh-keygen -t rsa-sha2-512

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

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, wird jedoch nicht empfohlen. Die Passphrase funktioniert zusammen mit der Schlüsseldatei, um eine zweistufige Authentifizierung bereitzustellen.

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

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 von Leerzeichen oder neuen Zeilen in das Feld Key Data, da sie dazu führen können, dass Azure DevOps einen ungültigen öffentlichen Schlüssel verwenden. Beim Einfügen des Schlüssels wird häufig am Ende ein Zeilenvorschub hinzugefügt. Entfernen Sie ggf. diesen Zeilenvorschub.

   

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

   SSH-Schlüssel, die in Azure DevOps gespeichert sind, laufen nach einem Jahr ab, es sei denn, die Richtlinie auf Organisationsebene wurde festgelegt. Weitere Informationen finden Sie unter Ändern von Anwendungsverbindungssicherheitsrichtlinien & für Ihre organization.

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 den Fingerabdruck mit dem SHA256-Fingerabdruck, der auf der Seite mit den zuvor erwähnten öffentlichen SSH-Schlüsseln angezeigt wird. Fahren Sie nur fort, wenn sie ü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 mit 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.

Fragen und Problembehandlung

F: Mein SSH-Schlüssel ist abgelaufen, was sollte ich tun?

Ein: Die empfohlene Vorgehensweise besteht darin, die oben genannten Schritte auszuführen, 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 Ablaufrichtlinie für die Überprüfung von SSH-Schlüsseln aktiviert. Weitere Informationen finden Sie unter SSH-Schlüsselrichtlinien.

Sie erhalten automatisch 7 Tage vor dem Ablauf Ihres Schlüssels und bei Ablauf eine Benachrichtigung. Zusammen mit diesen Benachrichtigungen sehen Sie auch 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.

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

A: Es gibt zwei verschiedene Warnmeldungen, die Sie sehen könnten:

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, und stellen Sie sicher, dass rsa-sha2-256 und/oder rsa-sha2-512 zugelassen sind.

Weitere Informationen finden Sie im Blogbeitrag.

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

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.
  

  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, und stellen Sie sicher, dass rsa-sha2-256 und/oder rsa-sha2-512 zugelassen sind.

  Weitere Informationen finden Sie im Blogbeitrag.

• 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
  

  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 wurde in Version 6.9 von OpenSSH und diffie-hellman-group14-sha1 in Version 8.2 standardmäßig deaktiviert.

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

A: Sie können einen SSH-Agenten verwenden. 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 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ü Konvertierungen, und wählen Sie OpenSSH-Schlüssel exportieren aus. Speichern Sie die Datei des privaten Schlüssels, und führen Sie dann die Schritte aus, um nicht standardmäßige Schlüssel einzurichten. 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 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> -- use this for MD5 fingerprints
ssh-keygen -l -E sha256 -f <path_to_your_public_key> -- use this for SHA-256 fingerprints

Anschließend können Sie die 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 Bedenken hinsichtlich des fehlerhaften Einfügens des öffentlichen Schlüssels in das Feld Key Data bestehen.

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

A: Sie müssen das origin remote 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 SSH.

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 mehrere Identitäten verfügbar sind.

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

Dieser Fehler liegt daran, dass 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. Beispielsweise wird git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo zu git@devops_fabrikam:v3/Fabrikam/Project1/fab_repo.

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

A: Es gibt einige Benachrichtigungen, die Sie möglicherweise bezüglich Ihrer SSH-Schlüssel erhalten.

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

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

• Ein MIT Ihrem Konto verknüpfter SSH-Schlüssel 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?

A: Wenn Sie eine SSH-Schlüsselregistrierungsbenachrichtigung erhalten, die Sie nicht initiiert haben, könnten Ihre Anmeldeinformationen kompromittiert worden sein.

Sie müssten dann untersuchen, ob Ihr Kennwort kompromittiert wurde. 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/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?

A: Einige Linux-Distributionen wie Fedora Linux verfügen über Kryptorichtlinien, die stärkere SSH-Signaturalgorithmen erfordern als Azure DevOps unterstützt (ab 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

Frage: 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.