Utiliser l’authentification par clé SSH

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

Utilisez SSH sur macOS, Linux ou Windows pour vous authentifier en toute sécurité auprès de Azure Repos référentiels Git dans Azure DevOps.

Cet article explique comment créer une paire de clés RSA, ajouter la clé publique à votre profil et cloner des dépôts à l’aide de SSH.

Importante

Les URL SSH ont changé, mais les anciennes URL SSH continuent de fonctionner. Si vous avez déjà configuré SSH, mettez à jour vos URL distantes au nouveau format :

Les URL SSH à jour commencent par ssh.dev.azure.com. Les URL précédentes utilisent vs-ssh.visualstudio.com.

• Vérifiez quels dépôts distants utilisent SSH. Exécutez git remote -v dans votre shell ou utilisez plutôt un client GUI.
• Visitez votre référentiel sur le Web et sélectionnez Cloner.
• Sélectionnez SSH et copiez la nouvelle URL SSH.
• Dans votre shell, exécutez git remote set-url <remote name> <new SSH URL> pour chaque dépôt distant d’un référentiel que vous souhaitez mettre à jour. Vous pouvez également utiliser un client GUI pour mettre à jour les URL distantes.

Prerequisites

Catégorie	Spécifications
Permissions	Accès pour cloner le référentiel
Politiques	Authentification SSH activée
Outils locaux	Git et un client OpenSSH disponible à partir d’un terminal ou d’un interpréteur de commandes
environnement Windows	Si vous utilisez Windows, Git pour Windows ou un autre environnement où gitssh, et ssh-keygen sont disponibles
Accès local	Accès à votre dossier local .ssh et autorisation de créer des fichiers clés

Fonctionnement de l’authentification par clé SSH

L’authentification par clé publique SSH fonctionne avec une paire asymétrique de clés de chiffrement générées. Vous partagez la clé publique avec Azure DevOps pour vérifier la connexion SSH initiale. Gardez la clé privée en lieu sûr et protégée sur votre système.

Configurer l’authentification par clé SSH

Pour utiliser SSH avec Azure Repos, générez une paire de clés RSA, ajoutez la clé publique à votre profil Azure DevOps, vérifiez l’empreinte digitale du serveur, puis clonez ou mettez à jour votre dépôt pour utiliser l’URL SSH.

Si vous avez uniquement besoin du chemin le plus rapide, effectuez l’étape 1, l’étape 2 et l’étape 3 dans l’ordre, puis utilisez résoudre les problèmes d’authentification SSH uniquement si une commande échoue.

Les étapes suivantes couvrent la configuration de l’authentification par clé SSH sur les plateformes suivantes à l’aide de la ligne de commande (également appelée shell) :

• Linux
• macOS
• systèmes Windows exécutant Git pour Windows

Conseil

Sur Windows, utilisez Git Credential Manager au lieu de SSH.

Étape 1 : Créer vos clés SSH

Remarque

Si vous avez déjà créé des clés SSH RSA sur votre système, ignorez cette étape et passez à l’étape 2. Pour vérifier cela, accédez à votre répertoire de base et recherchez le .ssh dossier (%UserProfile%\.ssh\sur Windows ou ~/.ssh/ sur Linux, macOS et Windows avec Git Bash). Si vous voyez deux fichiers nommés id_rsa et id_rsa.pub, passez à l’étape 2.

Pour utiliser l’authentification basée sur des clés, vous devez d’abord générer une paire de clés publique/privée pour votre client. OpenSSH peut générer plusieurs types de clés, mais Azure DevOps prend en charge les clés RSA pour l’authentification SSH.

Remarque

Azure DevOps prend en charge les clés RSA et utilise des algorithmes de signature RSA-SHA2 lors de l’authentification. Générez une clé RSA et laissez votre client SSH négocier la signature RSA-SHA2 prise en charge lorsqu’il se connecte.

Pour générer une paire de clés RSA pour Azure DevOps, exécutez la commande suivante à partir de PowerShell ou d’un autre interpréteur de commandes tel que bash sur votre client :

ssh-keygen -t rsa -b 3072

La sortie de la commande doit afficher la sortie suivante (où username se trouve votre nom d’utilisateur) :

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

Appuyez sur Entrée pour accepter la valeur par défaut, ou spécifiez un chemin d’accès et/ou un nom de fichier dans lequel vous souhaitez générer vos clés. À ce stade, vous êtes invité à utiliser une phrase secrète pour chiffrer vos fichiers de clé privée. La phrase secrète peut être vide, mais n’est pas recommandée. La phrase secrète ajoute une autre couche de protection pour votre clé privée si le fichier est exposé.

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

Vous disposez maintenant d’une paire de clés RSA publique/privée à l’emplacement que vous avez spécifié. Les .pub fichiers sont des clés publiques et les fichiers sans extension sont des clés privées :

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

Importante

Ne partagez jamais le contenu de votre clé privée. Si la clé privée est compromise, les personnes malveillantes peuvent l’utiliser pour inciter les serveurs à penser que la connexion vient de vous. Les fichiers de clé privée sont l'équivalent d'un mot de passe et doivent être protégés de la même manière.

Étape 2 : Ajouter la clé publique à Azure DevOps

Associez la clé publique générée à l’étape précédente à votre ID d’utilisateur.

Remarque

La clé publique SSH est associée à votre profil utilisateur. Dans la plupart des cas, vous pouvez utiliser une clé entre les organisations pour la même identité. Ajoutez une clé distincte uniquement lorsque vous utilisez une identité ou un compte différent.

1. Ouvrez vos paramètres de sécurité en accédant au portail Web et en sélectionnant l'icône à côté de l'avatar en haut à droite de l'interface utilisateur. Sélectionnez les clés publiques SSH dans le menu qui s’affiche.

   

2. Sélectionnez + Nouvelle clé.

   

3. Copiez le contenu de la clé publique (par exemple, id_rsa.pub) que vous avez générée dans le champ Données de clé publique.

   Importante

   Évitez d’ajouter des espaces supplémentaires ou des sauts de ligne au milieu de la valeur de clé, car ils peuvent rendre la clé non valide. Si le collage ajoute des artefacts de mise en forme, supprimez-les avant d’enregistrer.

   

4. Donnez à la clé une description utile (cette description est affichée sur la page des clés publiques SSH de votre profil) afin que vous puissiez vous en souvenir plus tard. Sélectionnez Enregistrer pour stocker la clé publique. Une fois enregistré, vous ne pouvez pas modifier la clé. Vous pouvez supprimer la clé ou créer une entrée pour une autre clé. Il n’existe aucune restriction quant au nombre de clés que vous pouvez ajouter à votre profil utilisateur.

   Remarque

   La stratégie d’organisation peut appliquer l’expiration de la clé SSH. Pour plus d’informations, consultez Modifier la connexion d’application et les stratégies de sécurité pour votre organisation.

5. Sur la page de vue d’ensemble SSH Public Keys, les empreintes digitales du serveur sont affichées. Notez l’empreinte digitale SHA256 à utiliser lorsque vous vous connectez pour la première fois à Azure DevOps via SSH.

   

6. Testez la connexion en exécutant la commande suivante :

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

   Si vous vous connectez pour la première fois, vous devriez recevoir la sortie suivante :

   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])?
   

   Comparez cette empreinte digitale avec l’empreinte digitale SHA256 affichée sur la page des clés publiques SSH . Continuez uniquement si les valeurs correspondent.

7. Entrez yes pour continuer. Si tout est configuré correctement, le résultat devrait ressembler à ceci :

    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
   

   Sinon, consultez la section Questions et dépannage.

Étape 3 : Cloner le référentiel Git à l’aide de SSH

Remarque

Pour utiliser SSH avec un référentiel que vous avez précédemment cloné à l’aide de HTTPS, consultez Comment puis-je commencer à utiliser SSH dans un référentiel où j’utilise actuellement HTTPS ?

1. Copiez l’URL du clone SSH à partir du portail web. Dans cet exemple, l'URL du clone SSH concerne un dépôt dans une organisation nommée fabrikam-fiber, comme l'indique la première partie de l'URL après dev.azure.com.

   

   Remarque

   Avec Azure DevOps Services, le format de l’URL du projet est dev.azure.com/{your organization}/{your project}. Toutefois, le format précédent qui fait référence au format visualstudio.com est toujours pris en charge. Pour plus d’informations, consultez Présentation de Azure DevOps, changer les organisations existantes pour utiliser la nouvelle URL de nom de domaine.

2. Exécutez git clone à partir de l’invite de commandes.

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

   Si vous n’utilisez pas d’agent SSH, vous êtes invité à entrer votre phrase secrète :

   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.
   

   Si vous êtes plutôt invité à vérifier une empreinte digitale, lisez Step 2 : ajoutez à nouveau la clé publique à Azure DevOps. Pour d’autres problèmes, lisez la section Questions et dépannage.

Conseil

Pour tirer le meilleur parti de SSH, utilisez un agent SSH pour gérer vos clés SSH. La configuration d’un agent n’entre pas dans le cadre de cet article.

Utiliser l’IA pour utiliser des référentiels authentifiés SSH

Si vous utilisez des référentiels Git avec GitHub Copilot ou le serveur MCP Azure DevOps, vous pouvez utiliser des invites en langage naturel pour valider votre configuration SSH et diagnostiquer les problèmes d’authentification.

Task	Exemple d’invite
Vérifier quel remote utilise un dépôt	Check whether this repository uses SSH or HTTPS for origin, and show me how to switch it to SSH if needed.
Vérifier la configuration SSH	Review my Git remote configuration and explain whether it matches the Azure Repos SSH format.
Diagnostiquer une défaillance d’authentification	Help me troubleshoot this Azure Repos SSH error: remote: Public key authentication failed.
Vérifier la clé SSH utilisée	Explain how to tell which SSH key my client is offering to ssh.dev.azure.com and what to change if it is the wrong one.

Conseil

Dans Visual Studio Code, le mode agent est utile pour vérifier les distances, examiner la configuration SSH et suggérer les étapes de résolution des problèmes suivantes à partir de la sortie du terminal.

Résolution des problèmes et questions courantes

Utilisez les sections suivantes pour rechercher le problème qui correspond à votre problème d’installation SSH.

• Si votre clé a expiré ou n’est pas valide, commencez par des clés expirées ou non valides.
• Si SSH ne parvient pas à se connecter, commencez par des échecs de connexion courants.
• Si vous êtes invité à plusieurs reprises à entrer une phrase secrète, commencez par des problèmes d’agent SSH et de phrase secrète.
• Si vous utilisez plusieurs clés ou organisations, accédez à La gestion de plusieurs clés et organisations.
• Si vous avez besoin de notifications ou de conseils sur le compte, accédez aux notifications et aux problèmes de compte.

Clés expirées ou non valides

Q : Ma clé SSH a expiré. Que dois-je faire ?

A: Suivez les étapes précédentes pour créer et téléverser une nouvelle clé SSH.

A une autre option, un administrateur de collection Project peut désactiver la stratégie qui valide la date d’expiration de la clé SSH. Par défaut, la stratégie Valider l’expiration de la clé SSH est activée. Pour plus d’informations, consultez stratégies de clé SSH.

Vous recevez automatiquement une notification sept jours avant et lorsque votre clé expire. En plus de ces notifications, vous voyez la messagerie suivante :

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.

Échecs de connexion courants

Q : Je vois des avertissements liés à ssh-rsa. Que dois-je faire ?

A: Il se peut que vous voyiez l’un des messages d’avertissement suivants :

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.

ou

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.

Si vous avez modifié votre configuration SSH pour rétrograder vos paramètres de sécurité pour Azure DevOps en ajoutant les éléments suivants à votre fichier ~/.ssh/config (%UserProfile%\.ssh\config sur Windows) :

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

Supprimez ces lignes maintenant et assurez-vous que rsa-sha2-256 et rsa-sha2-512 sont autorisés.

Pour plus d’informations, consultez le billet de blog.

Cette correction est le correctif de référence pour les avertissements ssh-rsa obsolètes et les erreurs ssh-rsa non prises en charge. Utilisez-le comme première étape pour ces scénarios.

Q : SSH ne parvient pas à établir une connexion. Que dois-je faire ?

A: Vous pouvez rencontrer plusieurs problèmes différents :

• Utilisation de ssh-rsa non pris en charge

  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.
  

  Appliquez la même remédiation décrite dans la question précédente concernant les avertissements ssh-rsa : supprimez toute surcharge HostkeyAlgorithms +ssh-rsa et utilisez rsa-sha2-256 et/ou rsa-sha2-512.

• Aucune clé hôte correspondante

  Ce problème ne doit pas se produire sur Azure DevOps Service ou sur des versions de Azure DevOps Server plus récentes, comme indiqué dans le billet blog post.

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

  Modifiez votre configuration SSH pour rétrograder vos paramètres de sécurité pour Azure DevOps en ajoutant les éléments suivants à votre fichier ~/.ssh/config (%UserProfile%\.ssh\config sur Windows) :

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

  Utilisez cette solution de contournement uniquement pour les scénarios de compatibilité hérités, généralement pour les anciennes configurations de Azure DevOps Server auto-hébergées. Pour Azure DevOps Services, conservez les valeurs par défaut sécurisées et évitez les remplacements persistantsssh-rsa.

  Importante

  OpenSSH a rendu obsolète l'algorithme de signature à clé publique ssh-rsa dans la version 8.2 et l'a désactivé par défaut dans la version 8.8.

• Aucun MAC correspondant

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

  Modifiez votre configuration SSH pour rétrograder vos paramètres de sécurité pour Azure DevOps en ajoutant les éléments suivants à votre fichier ~/.ssh/config (%UserProfile%\.ssh\config sur Windows) :

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

• Aucune méthode d’échange de clé correspondante

  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
  

  Modifiez votre configuration SSH pour rétrograder vos paramètres de sécurité pour Azure DevOps en ajoutant les éléments suivants à votre fichier ~/.ssh/config (%UserProfile%\.ssh\config sur Windows) :

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

  Importante

  L’algorithme diffie-hellman-group1-sha1 d’échange de clés est désactivé par défaut dans la version 6.9 d’OpenSSH et diffie-hellman-group14-sha1 dans la version 8.2.

Conseil

Pour les instances auto-hébergées de Azure DevOps Server, utilisez le nom d’hôte approprié dans la Host ligne au lieu de ssh.dev.azure.com ou vs-ssh.visualstudio.com.

Problèmes liés à l’agent SSH et à la phrase secrète

Q : L’agent SSH n’est pas en cours d’exécution, ou ma clé n’est pas chargée. Que dois-je faire ?

R : Si votre clé existe mais que SSH demande toujours une phrase secrète chaque fois, ou si le clonage échoue une fois la clé créée avec succès, vérifiez si l’agent SSH est en cours d’exécution et si votre clé est chargée.

Utilisez la commande suivante pour voir quelles identités l’agent a actuellement chargé :

ssh-add -l

Si la sortie indique que l’agent n’a aucune identité, ajoutez votre clé privée à l’agent :

ssh-add ~/.ssh/id_rsa

Sur Windows, si vous utilisez PowerShell avec l'agent OpenSSH intégré, vérifiez que le ssh-agent service est en cours d'exécution avant d'ajouter la clé. Si vous utilisez Git Bash ou un autre client SSH, consultez la documentation de ce client pour démarrer son agent et charger des clés.

Si vous préférez ne pas utiliser un agent, SSH peut toujours fonctionner, mais vous êtes invité à entrer la phrase secrète de clé plus souvent.

Q : Comment puis-je faire en sorte que Git se souvienne de la phrase secrète de ma clé ?

A: Utilisez un agent SSH. Linux, macOS et Windows (à partir de Windows 10 (build 1809) ou à l’aide de Git pour Windows avec Git Bash) tous fournis avec un agent SSH. L’agent SSH peut mettre en cache vos clés SSH pour une utilisation répétée. Consultez le manuel de votre fournisseur SSH pour savoir comment l’utiliser.

Q : J’utilise PuTTY comme client SSH et j’ai généré mes clés avec PuTTYgen. Puis-je utiliser ces clés avec Azure DevOps Services ?

R : Oui. Chargez la clé privée avec PuTTYgen, accédez au menu Conversions et sélectionnez Exporter la clé OpenSSH. Enregistrez le fichier de clé privée, puis suivez la question suivante dans cet article sur l’utilisation d’un emplacement de clé non définie. Copiez votre clé publique directement à partir de la fenêtre PuTTYgen et collez-la dans le champ Données clés dans vos paramètres de sécurité.

Q : Comment puis-je vérifier que la clé publique que j'ai téléchargée est la même que ma clé locale ?

A: Vérifiez l’empreinte de la clé publique que vous avez téléversée en la comparant à celle affichée dans votre profil. Exécutez la commande suivante ssh-keygen sur votre clé publique à l’aide de la ligne de commande. Vous devez modifier le chemin et le nom du fichier de clé publique si vous n’utilisez pas les valeurs par défaut.

Remarque

Préférer les empreintes digitales SHA-256. Utilisez MD5 uniquement lorsque vous devez effectuer une comparaison avec un format d’empreinte digitale hérité.

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

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

Comparez ensuite la signature à celle de votre profil. Cette vérification est utile si vous rencontrez des problèmes de connexion ou que vous avez des préoccupations concernant le collage incorrect de la clé publique dans le champ Données clés lors de l’ajout de la clé à Azure DevOps.

Q : Comment puis-je commencer à utiliser SSH dans un référentiel dans lequel j'utilise actuellement HTTPS ?

R : Mettez à jour le origin dépôt distant dans Git pour remplacer une URL HTTPS par une URL SSH. Après avoir obtenu l’URL du clone SSH, exécutez la commande suivante :

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

Les commandes Git qui accèdent au dépôt distant appelé origin utilisent SSH.

Gestion de plusieurs clés et de plusieurs organisations

Q : J'utilise Git LFS avec Azure DevOps Services et j'obtiens des erreurs lors de l'extraction de fichiers suivis par Git LFS.

A : Azure DevOps Services ne prend actuellement pas en charge LFS via SSH. Utilisez HTTPS pour vous connecter aux dépôts avec les fichiers suivis par Git LFS.

Q : Comment puis-je utiliser un emplacement de clé non définie, autrement dit, pas ~/.ssh/id_rsa et ~/.ssh/id_rsa.pub ?

R : Pour utiliser une clé stockée à un emplacement différent de celui par défaut, effectuez ces deux tâches :

1. Les clés doivent se trouver dans un dossier que vous pouvez uniquement lire ou modifier. Si le dossier dispose d’autorisations plus larges, SSH n’utilise pas les clés.

2. Vous devez indiquer à SSH l’emplacement de la clé, par exemple en le spécifiant comme « Identité » dans la configuration SSH :

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

Le paramètre IdentitiesOnly yes garantit que SSH n’utilise aucune autre identité disponible pour s’authentifier. Ce paramètre est particulièrement important si plusieurs identités sont disponibles.

Q : J’ai plusieurs clés SSH. Comment utiliser la clé SSH correcte pour Azure DevOps ?

R : En général, lorsque vous configurez plusieurs clés pour un client SSH, le client tente de s’authentifier avec chaque clé séquentiellement jusqu’à ce que le serveur SSH en accepte une.

Toutefois, cette approche ne fonctionne pas avec Azure DevOps en raison de contraintes techniques liées au protocole SSH et à la structure de nos URL SSH Git. Azure DevOps accepte la première clé fournie par le client pendant l’authentification. Si cette clé est invalide pour le référentiel demandé, la demande échoue sans tenter d’autres clés disponibles, ce qui entraîne l’erreur suivante :

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

Pour Azure DevOps, vous devez configurer SSH pour utiliser explicitement un fichier de clé spécifique. La procédure est la même que lors de l’utilisation d’une clé stockée dans un emplacement nondefault. Indiquez à SSH d’utiliser la clé SSH correcte pour l’hôte Azure DevOps.

Q : Comment utiliser différentes clés SSH pour différentes organisations sur Azure DevOps ?

R : Azure DevOps accepte la première clé que le client fournit pendant l’authentification. Si cette clé est invalide pour le référentiel demandé, la demande échoue avec l’erreur suivante :

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

Cet échec se produit parce que toutes les URL Azure DevOps partagent le même nom d’hôte (ssh.dev.azure.com), ce qui rend impossible pour SSH de les distinguer par défaut. Cependant, vous pouvez modifier votre configuration SSH pour différencier les différentes organisations en fournissant des clés distinctes pour chacune. Utilisez des alias d’hôte pour créer des sections Host séparées dans votre fichier de configuration 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.

# 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

Ensuite, au lieu d'utiliser les vraies URL, indiquez à Git que vous souhaitez utiliser ces URL pour chaque référentiel comme distant en remplaçant le nom d'hôte dans les distants existants par devops_fabrikam et devops_contoso respectivement. Par exemple, git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo devient git@devops_fabrikam:v3/Fabrikam/Project1/fab_repo.

Notifications et problèmes de compte

Q : Quelles notifications puis-je recevoir sur mes clés SSH ?

Un: Vous pouvez recevoir quelques notifications concernant vos clés SSH.

• Une nouvelle clé SSH a été ajoutée à votre organisation.

• Une clé SSH associée à votre compte expire dans 7 jours et n’est pas valide pour l’authentification.

• Une clé SSH associée à votre compte a expiré et n’est plus valide pour l’authentification.

  Exemple de notification

  

Q : Que dois-je faire si je crois que quelqu’un autre que moi ajoute des clés SSH sur mon compte ?

R : Si vous recevez une notification d’inscription de clé SSH que vous n’avez pas lancée, vos informations d’identification peuvent être compromises.

L’étape suivante consiste à déterminer si votre mot de passe est compromis. La modification de votre mot de passe constitue toujours une bonne première étape pour se défendre contre ce vecteur d’attaque. Si vous êtes un utilisateur Microsoft Entra, contactez votre administrateur pour vérifier si votre compte a été utilisé à partir d'une source ou d'un emplacement inconnu.

Q : Que dois-je faire si on me demande toujours mon mot de passe GIT_SSH_COMMAND="ssh -v" git fetch et affiche no mutual signature algorithm ou corresponding algo not in PubkeyAcceptedAlgorithms ?

A: Certaines distributions Linux, telles que Fedora Linux, appliquent des politiques cryptographiques qui nécessitent des algorithmes de signature SSH plus robustes que n’autorise votre configuration SSH actuelle d’Azure DevOps.

Pour contourner le problème, ajoutez le code suivant à votre configuration SSH (~/.ssh/config) :

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

Si votre version d’OpenSSH prend uniquement en charge l’ancien nom du paramètre, utilisez PubkeyAcceptedKeyTypes à la place.

Utilisez ce code comme solution de contournement de compatibilité temporaire. Si possible, mettez à niveau votre client SSH ou la configuration de votre serveur, puis supprimez cette dérogation une fois les tests effectués.

Questions générales

Q : Puis-je utiliser SSH avec Azure DevOps Server ?

R : Oui. Pour les instances auto-hébergées Azure DevOps Server, utilisez le nom d’hôte de votre serveur dans la configuration SSH et les URL distantes au lieu de ssh.dev.azure.com. Où cet article affiche ssh.dev.azure.com ou vs-ssh.visualstudio.comremplacez le nom d’hôte de votre serveur.

Q : Pourquoi ma clé SSH Azure DevOps Services a-t-elle cessé de fonctionner ?

Un: L’authentification par clé SSH vous oblige à vous connecter régulièrement à Azure DevOps Services à l’aide du flux d’authentification complet (web). La connexion une fois toutes les 30 jours est suffisante pour de nombreux utilisateurs, mais vous devrez peut-être vous connecter plus fréquemment en fonction de votre configuration de Microsoft Entra. Si votre clé SSH cesse de fonctionner, essayez d’abord de vous connecter à votre organisation et d’effectuer l’invite d’authentification complète. Si votre clé SSH ne fonctionne toujours pas, vérifiez si elle a expiré.

Conseil

Pour les instances auto-hébergées de Azure DevOps Server, utilisez le nom d’hôte approprié dans la Host ligne au lieu de ssh.dev.azure.com ou vs-ssh.visualstudio.com.

Contenu connexe

• Configurer des gestionnaires d’informations d’identification
• Vue d’ensemble du serveur MCP Azure DevOps
• Gérer les fichiers volumineux
• Définir les autorisations du dépôt Git