SSH-sleutelverificatie gebruiken

Azure DevOps Services-| Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Maak verbinding met uw Git-opslagplaatsen via SSH op macOS, Linux of Windows om veilig verbinding te maken met behulp van HTTPS-verificatie. In Windows raden we het gebruik van Git Credential Manager - of Persoonlijke toegangstokens aan.

Belangrijk

De SSH-URL's zijn gewijzigd, maar de oude SSH-URL's blijven werken. Als u SSH al hebt ingesteld, moet u uw externe URL's bijwerken naar de nieuwe indeling:

  • Controleer welke externe apparaten SSH gebruiken door deze uit te voeren git remote -v in uw Git-client.
  • Ga naar de opslagplaats op het web en selecteer de knop Klonen in de rechterbovenhoek.
  • Selecteer SSH en kopieer de nieuwe SSH-URL.
  • Voer in uw Git-client het volgende uit: git remote set-url <remote name, e.g. origin> <new SSH URL>. U kunt ook in Visual Studio naar Opslagplaatsinstellingen gaan en uw externe apparaten bewerken.

Notitie

Vanaf Visual Studio 2017 kan SSH worden gebruikt om verbinding te maken met Azure DevOps Git-opslagplaatsen.

Hoe SSH-sleutelverificatie werkt

Verificatie met openbare SSH-sleutels werkt met een asymmetrisch paar gegenereerde versleutelingssleutels. De openbare sleutel wordt gedeeld met Azure DevOps en gebruikt om de eerste ssh-verbinding te verifiëren. De persoonlijke sleutel wordt veilig en veilig op uw systeem bewaard.

SSH-sleutelverificatie instellen

De volgende stappen hebben betrekking op de configuratie van SSH-sleutelverificatie op de volgende platforms:


  • Linux
  • macOS met ten minste Leopard (10.5)
  • Windows-systemen met Git voor Windows

Configureer SSH met behulp van de opdrachtregel. bash is de algemene shell in Linux en macOS en de Installatie van Git voor Windows voegt een snelkoppeling toe aan Git Bash in het startmenu. Andere shell-omgevingen werken, maar worden niet behandeld in dit artikel.

Stap 1: uw SSH-sleutels maken

Notitie

Als u al SSH-sleutels op uw systeem hebt gemaakt, slaat u deze stap over en gaat u naar het configureren van SSH-sleutels.

Met de opdrachten hier kunt u nieuwe standaard-SSH-sleutels maken, bestaande standaardsleutels overschrijven. Voordat u doorgaat, controleert u de ~/.ssh map (bijvoorbeeld /home/jamal/.ssh of C:\Users\jamal\.ssh) en zoekt u de volgende bestanden:

  • id_rsa
  • id_rsa.pub

Als deze bestanden bestaan, hebt u al SSH-sleutels gemaakt. U kunt de sleutels overschrijven met de volgende opdrachten of deze stap overslaan en naar SSH-sleutels gaan om deze sleutels opnieuw te gebruiken.

Maak uw SSH-sleutels met de ssh-keygen opdracht vanaf de bash prompt. Met deze opdracht maakt u een 3072-bits RSA-sleutel voor gebruik met SSH. U kunt een wachtwoordzin voor uw persoonlijke sleutel geven wanneer u hierom wordt gevraagd. Deze wachtwoordzin biedt een andere beveiligingslaag voor uw persoonlijke sleutel. Als u een wachtwoordzin geeft, moet u ervoor zorgen dat u de SSH-agent configureert om uw wachtwoordzin in de cache op te slaan, zodat u deze niet telkens hoeft in te voeren wanneer u verbinding maakt.

$ ssh-keygen -C "jamal@fabrikam.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/jamal/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Users/jamal/.ssh/id_rsa.
Your public key has been saved in /c/Users/jamal/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:******************************************* jamal@fabrikam.com
The key's randomart image is:
+---[RSA 3072]----+
|+.   +yX*o .     |
|... ..E+*=o      |
|  ..o.=E=.o      |
|   . * =.o .     |
|    . S o o..    |
|       + .oo     |
|        S+.  .   |
|        ..+.+    |
|          o*..   |
+----[SHA256]-----+

Met deze opdracht worden de twee sleutels geproduceerd die nodig zijn voor SSH-verificatie: uw persoonlijke sleutel ( id_rsa ) en de openbare sleutel ( id_rsa.pub ). Het is belangrijk om nooit de inhoud van uw persoonlijke sleutel te delen. Als de persoonlijke sleutel is aangetast, kunnen aanvallers deze gebruiken om servers te misleiden om te denken dat de verbinding van u afkomstig is.

Stap 2: De openbare sleutel toevoegen aan Azure DevOps Services/TFS

Koppel de openbare sleutel die in de vorige stap is gegenereerd aan uw gebruikers-id.

  1. Open uw beveiligingsinstellingen door naar de webportal te bladeren en uw avatar in de rechterbovenhoek van de gebruikersinterface te selecteren. Selecteer openbare SSH-sleutels in het menu dat wordt weergegeven.

    Schermopname van het menu-item openbare SSH-sleutels en de gebruikers avatar die is geselecteerd in Azure DevOps Services.

  2. Selecteer + Nieuwe sleutel.

    Toegang tot beveiligingsconfiguratie in Azure DevOps Services

  3. Kopieer de inhoud van de openbare sleutel (bijvoorbeeld id_rsa.pub) die u hebt gegenereerd in het veld Openbare sleutelgegevens .

    Belangrijk

    Vermijd het toevoegen van witruimte of nieuwe regels in het veld Sleutelgegevens , omdat ze ervoor kunnen zorgen dat Azure DevOps Services een ongeldige openbare sleutel gebruikt. Wanneer u de sleutel plakt, wordt er vaak een nieuwe regel aan het einde toegevoegd. Zorg ervoor dat u deze nieuwe regel verwijdert als deze optreedt.

    Openbare sleutel configureren in Azure DevOps Services

  4. Geef de sleutel een handige beschrijving (deze beschrijving wordt weergegeven op de pagina openbare SSH-sleutels voor uw profiel), zodat u deze later kunt onthouden. Selecteer Opslaan om de openbare sleutel op te slaan. Nadat u de sleutel hebt opgeslagen, kunt u de sleutel niet meer wijzigen. U kunt de sleutel verwijderen of een nieuwe vermelding voor een andere sleutel maken. Er zijn geen beperkingen voor het aantal sleutels dat u aan uw gebruikersprofiel kunt toevoegen. Houd er ook rekening mee dat SSH-sleutels die zijn opgeslagen in Azure DevOps na vijf jaar verlopen. Als uw sleutel verloopt, kunt u een nieuwe sleutel of dezelfde sleutel uploaden om via SSH toegang te blijven krijgen tot Azure DevOps.

  5. Test de verbinding door de volgende opdracht uit te voeren: ssh -T git@ssh.dev.azure.com. Als alles goed werkt, ontvangt u een antwoord met de volgende tekst: remote: Shell access is not supported. Als dat niet het probleem is, raadpleegt u de sectie vragen en probleemoplossing.

Stap 2: De openbare sleutel toevoegen aan Azure DevOps

Koppel de openbare sleutel die in de vorige stap is gegenereerd aan uw gebruikers-id.

  1. Open uw beveiligingsinstellingen door naar de webportal te bladeren en uw avatar in de rechterbovenhoek van de gebruikersinterface te selecteren. Selecteer Beveiliging in het menu dat wordt weergegeven.

    Toegang tot gebruikersprofiel in Azure DevOps Services

  2. Selecteer + Nieuwe sleutel.

    Toegang tot beveiligingsconfiguratie in Azure DevOps Services

  3. Kopieer de inhoud van de openbare sleutel (bijvoorbeeld id_rsa.pub) die u hebt gegenereerd in het veld Openbare sleutelgegevens .

    Notitie

    U kunt de opdracht $ cat ~/.ssh/id_rsa.pub gebruiken om de inhoud van het bestand id_rsa.pub in de terminal af te drukken en deze vervolgens naar het klembord te kopiëren. Als uw openbare SSH-sleutelbestand een andere naam heeft dan de voorbeeldcode, wijzigt u de bestandsnaam zodat deze overeenkomt met uw huidige installatie. Wanneer u uw sleutel kopieert, voegt u geen nieuwe regels of witruimte toe. U kunt ook de verborgen .ssh-map zoeken, het bestand openen in uw favoriete teksteditor en het naar het klembord kopiëren.

    Belangrijk

    Vermijd het toevoegen van witruimte of nieuwe regels in het veld Sleutelgegevens , omdat ze ervoor kunnen zorgen dat Azure DevOps Services een ongeldige openbare sleutel gebruikt. Wanneer u de sleutel plakt, wordt er vaak een nieuwe regel aan het einde toegevoegd. Zorg ervoor dat u deze nieuwe regel verwijdert als deze optreedt.

    Openbare sleutel configureren in Azure DevOps Services

  4. Geef de sleutel een handige beschrijving (deze beschrijving wordt weergegeven op de pagina openbare SSH-sleutels voor uw profiel), zodat u deze later kunt onthouden. Selecteer Opslaan om de openbare sleutel op te slaan. Nadat u de sleutel hebt opgeslagen, kunt u de sleutel niet meer wijzigen. U kunt de sleutel verwijderen of een nieuwe vermelding voor een andere sleutel maken. Er zijn geen beperkingen voor het aantal sleutels dat u aan uw gebruikersprofiel kunt toevoegen.

  5. Test de verbinding door de volgende opdracht uit te voeren: ssh -T git@ssh.dev.azure.com. Als alles goed werkt, ontvangt u een antwoord met de volgende tekst: remote: Shell access is not supported. Als dat niet het probleem is, raadpleegt u de sectie vragen en probleemoplossing.

Stap 3: De Git-opslagplaats klonen met SSH

Notitie

Als u verbinding wilt maken met SSH vanuit een bestaande gekloonde opslagplaats, raadpleegt u het bijwerken van uw afstandsbedieningen naar SSH.

  1. Kopieer de SSH-kloon-URL vanuit de webportal. In dit voorbeeld is de SSL-kloon-URL voor een opslagplaats in een organisatie met de naam fabrikam-fiber, zoals aangegeven door het eerste deel van de URL na dev.azure.com.

    SSH-kloon-URL voor Azure-opslagplaatsen

    Notitie

    Met Azure DevOps Services is dev.azure.com/{your organization}/{your project}de indeling voor de project-URL. De vorige indeling die verwijst naar de visualstudio.com indeling wordt echter nog steeds ondersteund. Zie Introductie van Azure DevOps voor meer informatie, schakel over van bestaande organisaties om de nieuwe domeinnaam-URL te gebruiken.

  2. Uitvoeren git clone vanaf de opdrachtprompt.

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

SSH kan de SSH-vingerafdruk van de server weergeven en u vragen deze te verifiëren. Controleer of de weergegeven vingerafdruk overeenkomt met een van de vingerafdrukken op de pagina openbare SSH-sleutels .

In SSH wordt deze vingerafdruk weergegeven wanneer deze verbinding maakt met een onbekende host om u te beschermen tegen man-in-the-middle-aanvallen. Zodra u de vingerafdruk van de host accepteert, wordt u met SSH niet meer gevraagd, tenzij de vingerafdruk wordt gewijzigd.

$ git clone git@ssh.dev.azure.com:v3/fabrikam-fiber/FabrikamFiber/FabrikamFiber
Cloning into 'FabrikamFiber'...
The authenticity of host 'ssh.dev.azure.com (65.52.8.37)' can't be established.
RSA key fingerprint is SHA256:********************************************
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ssh.dev.azure.com,65.52.8.37' (RSA) to the list of known hosts.
Enter passphrase for key '/c/Users/jamal/.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.

Wanneer u wordt gevraagd of u wilt doorgaan met verbinden, typt yesu. Git kloont de opslagplaats en stelt de origin externe in om verbinding te maken met SSH voor toekomstige Git-opdrachten.

Tip

Om problemen te voorkomen, moeten Windows-gebruikers een opdracht uitvoeren om Git hun wachtwoordzin voor SSH-sleutels opnieuw te laten gebruiken.

Vragen en probleemoplossing

V: Na uitvoering git clonekrijg ik de volgende fout. Wat moet ik doen?

Host key verification failed. 
fatal: Could not read from remote repository.

A: Noteer de SSH-sleutel handmatig door het volgende uit te voeren: ssh-keyscan -t rsa ssh.dev.azure.com >> ~/.ssh/known_hosts

V: Hoe kan ik Git de wachtwoordzin voor mijn sleutel in Windows onthouden?

A: Voer de volgende opdracht uit die is opgenomen in Git voor Windows om het ssh-agent proces in PowerShell of de Windows-opdrachtprompt te starten. ssh-agent slaat uw wachtwoordzin in de cache op, zodat u deze niet telkens hoeft op te geven wanneer u verbinding maakt met uw opslagplaats.

start-ssh-agent.cmd

Als u de Bash-shell gebruikt (inclusief Git Bash), start u de ssh-agent met:

eval `ssh-agent`

V: Ik gebruik PuTTY als mijn SSH-client en heb mijn sleutels gegenereerd met PuTTYgen. Kan ik deze sleutels gebruiken met Azure DevOps Services?

A: Ja. Laad de persoonlijke sleutel met PuTTYgen, ga naar het menu Conversies en selecteer OpenSSH-sleutel exporteren. Sla het bestand met de persoonlijke sleutel op en volg de stappen om niet-standaardsleutels in te stellen. Kopieer uw openbare sleutel rechtstreeks vanuit het PuTTYgen-venster en plak deze in het veld Sleutelgegevens in uw beveiligingsinstellingen.

V: Hoe kan ik controleren of de openbare sleutel die ik heb geüpload, dezelfde sleutel is als die ik lokaal heb?

A: U kunt de vingerafdruk controleren van de openbare sleutel die is geüpload met de vingerafdruk die in uw profiel wordt weergegeven via de volgende ssh-keygen opdracht die wordt uitgevoerd op uw openbare sleutel met behulp van de bash opdrachtregel. U moet het pad en de bestandsnaam van de openbare sleutel wijzigen als u de standaardinstellingen niet gebruikt.

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

Vervolgens kunt u de MD5-handtekening vergelijken met de handtekening in uw profiel. Deze controle is handig als u verbindingsproblemen hebt of problemen ondervindt bij het onjuist plakken van de openbare sleutel in het veld Sleutelgegevens bij het toevoegen van de sleutel aan Azure DevOps Services.

V: Hoe kan ik SSH gaan gebruiken in een opslagplaats waar ik momenteel HTTPS gebruik?

A: U moet de origin afstandsbediening in Git bijwerken om over te schakelen van een HTTPS naar SSH-URL. Zodra u de SSH-kloon-URL hebt, voert u de volgende opdracht uit:

git remote set-url origin git@ssh.dev.azure.com:v3/fabrikam-fiber/FabrikamFiber/FabrikamFiber

U kunt nu elke Git-opdracht uitvoeren waarmee verbinding wordt gemaakt origin.

V: Ik gebruik Git LFS met Azure DevOps Services en ik krijg fouten bij het ophalen van bestanden die worden bijgehouden met Git LFS.

A: Azure DevOps Services biedt momenteel geen ondersteuning voor LFS via SSH. Gebruik HTTPS om verbinding te maken met opslagplaatsen met door Git LFS bijgehouden bestanden.

V: Hoe kan ik een niet-standaardsleutellocatie gebruiken, d.w.z. niet ~/.ssh/id_rsa en ~/.ssh/id_rsa.pub?

A: Als u sleutels wilt gebruiken die zijn gemaakt met ssh-keygen een andere locatie dan de standaardinstelling, voert u deze twee taken uit:

  1. De sleutels moeten zich in een map bevinden die alleen u kunt lezen of bewerken. Als de map bredere machtigingen heeft, gebruikt SSH de sleutels niet.
  2. U moet SSH de locatie van de sleutels laten weten. U maakt SSH op de hoogte van sleutels via de ssh-add opdracht, waardoor het volledige pad naar de persoonlijke sleutel wordt opgegeven.
ssh-add /home/jamal/.ssh/id_jamal.rsa

Voordat u windows uitvoert ssh-add, moet u de volgende opdracht uitvoeren vanuit Git voor Windows:

start-ssh-agent.cmd

Deze opdracht wordt uitgevoerd in PowerShell en de opdrachtprompt. Als u Git Bash gebruikt, is de opdracht die u moet gebruiken:

eval `ssh-agent`

U kunt deze vinden ssh-add als onderdeel van de Git voor Windows-distributie en deze ook uitvoeren in elke shell-omgeving in Windows.

Op macOS en Linux moet u ook worden ssh-agent uitgevoerd voordat u wordt uitgevoerd ssh-add, maar de opdrachtomgeving op deze platforms zorgt er meestal voor dat u begint ssh-agent .

V: Ik heb meerdere SSH-sleutels. Hoe kan ik verschillende SSH-sleutels gebruiken voor verschillende SSH-servers of opslagplaatsen?

A: Als u meerdere sleutels voor een SSH-client configureert en verbinding maakt met een SSH-server, kan de client de sleutels één voor één proberen totdat de server er een accepteert.

Dit werkt echter niet met Azure DevOps om technische redenen met betrekking tot het SSH-protocol en hoe onze Git SSH-URL's zijn gestructureerd. Azure DevOps accepteert blind de eerste sleutel die de client biedt tijdens de verificatie. Als deze sleutel ongeldig is voor de aangevraagde opslagplaats, mislukt de aanvraag met de volgende fout:

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

Voor Azure DevOps moet u SSH configureren om expliciet een specifiek sleutelbestand te gebruiken. U kunt dit als volgt doen om uw ~/.ssh/config bestand te bewerken (bijvoorbeeld /home/jamal/.ssh of C:\Users\jamal\.ssh):

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

# Most common scenario: to use the same key across all hosted Azure DevOps
# organizations, add a Host entry like this:
Host ssh.dev.azure.com
  IdentityFile ~/.ssh/your_private_key
  IdentitiesOnly yes

# This model will also work if you still use the older SSH URLs with a
# hostname of vs-ssh.visualstudio.com:
Host vs-ssh.visualstudio.com
  IdentityFile ~/.ssh/your_private_key
  IdentitiesOnly yes

# OpenSSL 8.7 has DEPRECATED RSA. IF using OpenSSL version > 8.6 you will need to 
# add the 'HostkeyAlgorithms' and 'PubkeyAcceptedAlgorithms' entries below. You can 
# check the version of OpenSSL/OpenSSH you're using by running the command 'ssh -v localhost'    
Host ssh.dev.azure.com
  IdentityFile ~/.ssh/id_rsa
  HostkeyAlgorithms +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa   

# Less common scenario: if you need different keys for different organizations,
# you'll need to use host aliases to create separate Host sections.
# This is because all hosted Azure DevOps URLs have the same hostname
# (ssh.dev.azure.com), so SSH has no way to distinguish them by default.
#
# 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
#
# Then, instead of using the real URLs, tell Git you want to use these URLs:
# * git@devops_fabrikam:v3/Fabrikam/Project1/fab_repo
# * git@devops_contoso:v3/Contoso/Project2/con_repo
#

# At the end of the file, you can put global defaults for other SSH hosts you
# may connect to.  Note that "*" also matches any hosts that match the sections
# above, and remember that SSH uses the first matching line for each parameter name.
Host *
# 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.

# Say your on-premises Azure DevOps Server instance has SSH URLs like this:
#   ssh://someHost:22/someCollection/some_project/_git/some_repo
# Add the following Host section:
Host someHost
  IdentityFile ~/.ssh/your_private_key
  IdentitiesOnly yes

# At the end of the file, you can put global defaults for other SSH hosts you
# may connect to.  Note that "*" also matches any hosts that match the sections
# above, and remember that SSH uses the first matching line for each parameter name.
Host *

V: Hoe kan ik fouten oplossen die vermelden dat er geen overeenkomende methode voor sleuteluitwisseling is gevonden?

A: Git voor Windows 2.25.1 is geleverd met een nieuwe versie van OpenSSH, waardoor standaard enkele protocollen voor sleuteluitwisseling zijn verwijderd. Specifiek, diffie-hellman-group14-sha1 is geïdentificeerd als problematisch voor sommige Azure DevOps Server en TFS-klanten. U kunt het probleem omzeilen door het volgende toe te voegen aan uw SSH-configuratie (~/.ssh/config):

Host <your-azure-devops-host>
    KexAlgorithms +diffie-hellman-group14-sha1

Vervang <your-azure-devops-host> door de hostnaam van uw Azure DevOps- of TFS-server, zoals tfs.mycompany.com.

V: Welke meldingen kan ik ontvangen over mijn SSH-sleutels?

A: Wanneer u een nieuwe SSH-sleutel registreert bij Azure DevOps Services, ontvangt u een e-mailmelding met de mededeling dat er een nieuwe SSH-sleutel is toegevoegd aan uw account.

Voorbeeld van SSH-melding

V: Wat moet ik doen als ik geloof dat iemand anders dan ik SSH-sleutels toevoegt aan mijn account?

A: Als u een melding ontvangt van een SSH-sleutel die wordt geregistreerd en u deze niet handmatig hebt geüpload naar de service, zijn uw referenties mogelijk aangetast.

De volgende stap is om te onderzoeken of uw wachtwoord al dan niet is aangetast. Het wijzigen van uw wachtwoord is altijd een goede eerste stap om deze aanvalsvector te beschermen. Als u een Azure Active Directory-gebruiker bent, neem dan contact op met uw beheerder om te controleren of uw account is gebruikt vanuit een onbekende bron/locatie.

V: Wat moet ik doen als ik nog steeds om mijn wachtwoord wordt gevraagd en GIT_SSH_COMMAND="ssh -v" git fetch wordt weergegeven no mutual signature algorithm?

A: Sommige Linux-distributies, zoals Fedora Linux, hebben cryptobeleid dat sterkere SSH-handtekeningalgoritmen vereist dan Azure DevOps ondersteunt (vanaf januari 2021). Er is een open functieaanvraag om deze ondersteuning toe te voegen.

U kunt het probleem omzeilen door de volgende code toe te voegen aan uw SSH-configuratie (~/.ssh/config):

Host ssh.dev.azure.com
  PubkeyAcceptedKeyTypes=ssh-rsa

Vervang ssh.dev.azure.com door de juiste hostnaam als u Azure DevOps Server gebruikt.