Connexion à votre système Linux cible dans Visual Studio

La prise en charge Linux est disponible dans Visual Studio 2017 et ultérieur.

Vous pouvez configurer un projet Linux pour cibler une machine virtuelle ou le sous-système Windows pour Linux (WSL). Tant pour les machines distantes que pour WSL, vous devez configurer une connexion à distance dans Visual Studio 2017.

Vous pouvez configurer un projet Linux pour cibler une machine virtuelle ou le sous-système Windows pour Linux (WSL). Pour un ordinateur distant, vous devez configurer une connexion à distance dans Visual Studio. Pour vous connecter à WSL, passez à la section Se connecter à WSL .

Lorsque vous utilisez une connexion à distance, Visual Studio génère des projets Linux C++ sur l’ordinateur distant. Ce n’est pas important s’il s’agit d’une machine physique, d’une machine virtuelle dans le cloud ou de WSL. Pour générer le projet, Visual Studio copie le code source sur votre ordinateur Linux distant. Ensuite, le code est compilé en fonction des paramètres de Visual Studio.

Notes

Depuis Visual Studio 2019 version 16.5, Visual Studio prend en charge les connexions de chiffrement conformes à la norme FIPS (Federal Information Processing Standard) 140-2 sécurisées aux systèmes Linux pour le développement à distance. Pour utiliser une connexion conforme à la norme FIPS, suivez les étapes décrites dans Configurer le développement Linux à distance sécurisé compatible FIPS.

Configurer le serveur SSH sur le système distant

Si ssh n’est pas encore configuré et en cours d’exécution sur votre système Linux, procédez comme suit pour l’installer. Les exemples de cet article utilisent Ubuntu 18.04 LTS avec le serveur OpenSSH version 7.6. Toutefois, les instructions doivent être les mêmes pour toute distribution utilisant une version modérément récente d’OpenSSH.

  1. Sur le système Linux, installez et démarrez le serveur OpenSSH :

    sudo apt install openssh-server
    sudo service ssh start
    
  2. Si vous souhaitez que le serveur ssh démarre automatiquement au démarrage du système, activez-le à l’aide de systemctl :

    sudo systemctl enable ssh
    

Configurer la connexion à distance

  1. Dans Visual Studio, choisissez Outils > Options dans la barre de menus pour ouvrir la boîte de dialogue Options. Sélectionnez ensuite Multiplateforme > Gestionnaire des connexions pour ouvrir la boîte de dialogue Gestionnaire des connexions.

    Si vous n’avez pas encore configuré de connexion dans Visual Studio, lorsque vous générez votre projet pour la première fois, Visual Studio ouvre la boîte de dialogue Gestionnaire de connexions pour vous.

  2. Dans la boîte de dialogue Gestionnaire des connexions, choisissez le bouton Ajouter pour ajouter une nouvelle connexion.

    Capture d’écran du volet Options de Visual Studio. CrossPlatform > C++ > Connecter ion Manager est sélectionné et le bouton Ajouter est mis en surbrillance.

    Dans les deux cas, la fenêtre Se connecter au système distant s’affiche.

    Capture d’écran de l’Connecter Visual Studio vers la fenêtre Système distant. Il existe des champs pour le nom d’hôte, le port, le nom d’utilisateur, le type d’authentification et le mot de passe. Le port est défini sur 22. Le type d’authentification est défini sur « Mot de passe ». :::image-end:::

  3. Entrez les informations suivantes :

    Entrée Description
    Host Name Nom ou adresse IP de votre appareil cible
    Port Port sur lequel le service SSH est exécuté, en général 22
    Nom d'utilisateur Utilisateur sous le nom duquel s’authentifier
    Type d’authentification Un mot de passe ou une clé privée sont tous deux pris en charge
    Mot de passe Mot de passe du nom d’utilisateur entré
    Fichier de clé privée Fichier de clé privée créé pour la connexion ssh
    Phrase secrète Phrase secrète utilisée avec la clé privée sélectionnée ci-dessus

    Vous pouvez utiliser un mot de passe ou un fichier de clé avec une phrase secrète pour l’authentification. Pour de nombreux scénarios de développement, l’authentification par mot de passe est suffisante, mais les fichiers clés sont plus sécurisés. Si vous avez déjà une paire de clés, il est possible de la réutiliser.

    Les versions de Visual Studio antérieures à la version 17.10 prennent en charge les clés EC, RSA et DSA pour les connexions à distance. En raison des problèmes de sécurité, les clés RSA et DSA ne sont plus prises en charge dans VS 17.10 et versions ultérieures. Seules les clés EC sont actuellement prises en charge. Pour créer une paire de clés compatible avec le gestionnaire de connexions, utilisez la commande : ssh-keygen -m pem -t ecdsa -f <key-name>

    Remarque

    Si vous utilisez ssh-keygen pour créer la clé privée, vous devez spécifier le commutateur -m pem, sinon la clé ne sera pas acceptée par Visual Studio. Si votre clé privée commence par -----BEGIN OPENSSH PRIVATE KEY-----, vous devez la convertir avec ssh-keygen -p -f <FILE> -m pem.

  4. Cliquez sur le bouton Se connecter pour tenter une connexion à l’ordinateur distant.

    Si la connexion réussit, Visual Studio configure IntelliSense pour utiliser les en-têtes distants. Pour plus d’informations, consultez IntelliSense pour les en-têtes sur les systèmes distants.

    Si la connexion échoue, les zones des entrées qui doivent être modifiées seront surlignées en rouge.

    Capture d’écran de l’Connecter Visual Studio vers la fenêtre Système distant. Le nom d’hôte et les champs de port sont décrits en rouge pour indiquer des entrées incorrectes.

    Si vous utilisez des fichiers de clé pour l’authentification, vérifiez que le serveur SSH de la machine cible est en cours d’exécution et configuré correctement.

    Si vous rencontrez des problèmes de connexion à WSL sur localhost, consultez Résoudre les problèmes de connexion au localhost WSL.

Vérification de la clé d’hôte

Dans Visual Studio version 16.10 ou ultérieure, vous êtes invité à vérifier l’hôte du serveur empreinte digitale de clé chaque fois que Visual Studio se connecte à un système distant pour la première fois. Vous connaissez peut-être ce processus si vous avez déjà utilisé le client de ligne de commande OpenSSH ou PuTTY. L’empreinte digitale identifie le serveur. Visual Studio utilise l’empreinte digitale pour s’assurer qu’il se connecte au serveur prévu et approuvé.

La première fois que Visual Studio établit une nouvelle connexion distante, vous êtes invité à accepter ou refuser l’hôte empreinte digitale de clé présenté par le serveur. Ou chaque fois qu’une empreinte digitale mise en cache est modifiée. Vous pouvez également vérifier une empreinte digitale à la demande en sélectionnant une connexion dans le Gestionnaire des connexions, puis en choisissant Vérifier.

Si vous effectuez une mise à niveau vers Visual Studio 16.10 ou version ultérieure à partir d’une version antérieure, toutes les connexions à distance existantes sont traitées comme de nouvelles connexions. Vous êtes invité à accepter d’abord l’hôte empreinte digitale de clé. Ensuite, Visual Studio établit une connexion et met en cache l’empreinte digitale acceptée.

Vous pouvez également mettre à jour les connexions à distance à partir de ConnectionManager.exe en utilisant l’argument update.

Algorithmes SSH pris en charge

Depuis Visual Studio version 16.9, la prise en charge des algorithmes SSH plus anciens non sécurisés utilisés pour chiffrer les données et les clés d’échange a été supprimée. Seuls les algorithmes suivants sont pris en charge. Ils sont pris en charge pour la communication SSH client à serveur et serveur à client :

Type d’algorithme Algorithmes pris en charge
Chiffrement aes128-cbc
aes128-ctr
aes192-cbc
aes192-ctr
aes256-cbc
aes256-ctr
HMAC hmac-sha2-256
hmac-sha2-512
Échange de clés diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
Clé hôte ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521

Configurer le serveur SSH

Tout d’abord, un peu de contexte. Vous ne pouvez pas sélectionner l’algorithme SSH à utiliser à partir de Visual Studio. Au lieu de cela, l’algorithme est déterminé lors de l’établissement de liaison initial avec le serveur SSH. Chaque côté (client et serveur) fournit une liste d’algorithmes qu’il prend en charge, puis le premier algorithme commun aux deux est sélectionné. La connexion réussit tant qu’il existe au moins un algorithme en commun entre Visual Studio et le serveur pour le chiffrement, HMAC, l’échange de clés, etc.

Le fichier de configuration Open SSH (sshd_config) ne configure pas l’algorithme à utiliser par défaut. Quand aucun algorithme n’est spécifié, le serveur SSH doit utiliser des valeurs par défaut sécurisées. Ces valeurs par défaut dépendent de la version et du fournisseur du serveur SSH. Si Visual Studio ne prend pas en charge ces valeurs par défaut, vous verrez probablement une erreur comme : « Impossible de se connecter au système distant. Aucun algorithme HMAC de client à serveur courant n’a été trouvé. » L’erreur peut également apparaître si le serveur SSH est configuré pour utiliser des algorithmes que Visual Studio ne prend pas en charge.

Le serveur SSH par défaut sur la plupart des distributions Linux modernes devrait fonctionner avec Visual Studio. Toutefois, vous exécutez peut-être un serveur SSH plus ancien configuré pour utiliser des algorithmes plus anciens non sécurisés. L’exemple suivant explique comment effectuer une mise à jour vers des versions plus sécurisées.

Dans l’exemple suivant, le serveur SSH utilise l’algorithme non sécurisé hmac-sha1 , que Visual Studio 16.9 ne prend pas en charge. Si le serveur SSH utilise OpenSSH, vous pouvez modifier le fichier /etc/ssh/sshd_config comme indiqué ci-dessous pour activer des algorithmes plus sécurisés. Pour les autres serveurs SSH, reportez-vous à la documentation du serveur pour savoir comment les configurer.

Tout d’abord, vérifiez que l’ensemble d’algorithmes que votre serveur utilise inclut les algorithmes pris en charge par Visual Studio. Exécutez la commande suivante sur l’ordinateur distant pour répertorier les algorithmes pris en charge par le serveur :

ssh -Q cipher; ssh -Q mac; ssh -Q kex; ssh -Q key

La commande produit une sortie telle que la suivante :

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
...
ecdsa-sha2-nistp521-cert-v01@openssh.com
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com

La sortie répertorie tous les algorithmes de chiffrement, de HMAC, d’échange de clés et de clé d’hôte pris en charge par votre serveur SSH. Si la liste n’inclut pas d’algorithmes pris en charge par Visual Studio, mettez à niveau votre serveur SSH avant de continuer.

Vous pouvez activer les algorithmes pris en charge par Visual Studio en modifiant /etc/ssh/sshd_config sur l’ordinateur distant. Les exemples suivants montrent comment ajouter différents types d’algorithmes à ce fichier de configuration.

Ces exemples peuvent être ajoutés n’importe où dans /etc/ssh/sshd_config. Assurez-vous qu’ils sont sur leurs propres lignes.

Après avoir modifié le fichier, redémarrez le serveur SSH (sudo service ssh restart sur Ubuntu) et réessayez de vous connecter à partir de Visual Studio.

Exemple de chiffrement

Ajouter : Ciphers <algorithms to enable>
Par exemple : Ciphers aes128-cbc,aes256-cbc

Exemple HMAC

Ajouter : MACs <algorithms to enable>
Par exemple : MACs hmac-sha2-256,hmac-sha2-512

Exemple d’échange de clés

Ajouter : KexAlgorithms <algorithms to enable>
Par exemple : KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384

Exemple de clé d’hôte

Ajouter : HostKeyAlgorithms <algorithms to enable>
Par exemple : HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384

Journalisation des connexions à distance

Vous pouvez activer la journalisation pour faciliter la résolution des problèmes. Dans la barre de menus, sélectionnez Outils>Options. Dans la boîte de dialogue Options, sélectionnez Multiplateforme > Journalisation :

Capture d’écran de l’écran options de Visual Studio.

Les options sont ouvertes à la journalisation multiplateforme > Connecter ion Manager >. L’activation de la journalisation est case activée ed, le journal d’un fichier est case activée ed, le répertoire logfile définit le dossier documents et journaliser dans le volet « Journalisation multiplateforme » dans la fenêtre de sortie est case activée ed.

Les journaux incluent les connexions, toutes les commandes envoyées à la machine distante (leur texte, le code de sortie et la durée d’exécution) et toutes les sorties de Visual Studio à dans l’interpréteur de commandes. La journalisation fonctionne pour n’importe quel projet CMake multiplateforme ou projet Linux basé sur MSBuild dans Visual Studio.

Vous pouvez configurer la sortie pour qu’elle soit écrite dans un fichier ou dans le volet de Journalisation multiplateforme dans la fenêtre Sortie. Pour les projets Linux basés sur MSBuild, les commandes MSBuild envoyées à l’ordinateur distant ne sont pas routées vers la Fenêtre Sortie, car elles sont émises hors processus. Au lieu de cela, elles sont enregistrées dans un fichier avec le préfixe « msbuild_ ».

Utilitaire de ligne de commande pour le Gestionnaire des connexions

Visual Studio 2019 version 16.5 ou ultérieure : ConnectionManager.exe est un utilitaire de ligne de commande pour gérer les connexions de développement à distance en dehors de Visual Studio. Il est utile pour des tâches telles que l’approvisionnement d’un nouvel ordinateur de développement. Vous pouvez également l’utiliser pour configurer Visual Studio pour l’intégration continue. Pour obtenir des exemples et une référence complète à la commande ConnectionManager, consultez Référence ConnectionManager.

Transfert de port TCP

La commande rsync est utilisée par les projets Linux MSBuild et les projets CMake pour copier des en-têtes de votre système distant vers Windows pour une utilisation par IntelliSense. Lorsque vous ne pouvez pas activer le transfert de port TCP, désactivez le téléchargement automatique des en-têtes distants. Pour ce faire, utilisez Outils > Options > Multiplateforme > Gestionnaire des connexions > Gestionnaire IntelliSense des en-têtes distants. Si le transfert de port TCP n’est pas activé pour le système distant, cette erreur s’affiche lorsque le téléchargement d’en-têtes distants pour IntelliSense commence :

Capture d’écran d’un message d’erreur Visual Studio indiquant que le canal SSH n’a pas pu être ouvert. Le chemin d’accès à un fichier journal est fourni.

rsync est également utilisé par le support CMake de Visual Studio pour copier les fichiers sources sur le système distant. Si vous ne pouvez pas activer le transfert de port TCP, vous pouvez utiliser sftp comme méthode de sources de copie à distance. sftp est souvent plus lent que rsync, mais n’a pas de dépendance sur le transfert de port TCP. Vous pouvez gérer votre méthode de sources de copie à distance avec la propriété remoteCopySourcesMethod dans l’Éditeur de paramètres CMake. Si le transfert de port TCP est désactivé sur votre système distant, une erreur s’affiche dans la fenêtre de sortie CMake la première fois qu’elle appelle rsync.

Capture d’écran de la fenêtre de sortie de Visual Studio affichant un message d’erreur Rsync.

La fenêtre de sortie inclut ces messages : vérifiez que le transfert TCP est activé sur le serveur, rsync : n’a pas vu le message d’accueil du serveur, erreur rsync : erreur de démarrage du protocole client-serveur (code 5) sur main.c(1675) [sender=3.1.3], Un canal SSH n’a pas pu être ouvert.

gdbserver peut être utilisé pour le débogage sur des appareils incorporés. Si vous ne pouvez pas activer le transfert de port TCP, vous devez utiliser gdb pour tous les scénarios de débogage à distance. gdb est utilisé par défaut lors du débogage de projets sur un système distant.

La prise en charge linux de Visual Studio dépend du transfert de port TCP. rsync et gdbserver sont affectés si le transfert de port TCP est désactivé sur votre système distant. Si cette dépendance vous affecte, votez pour ce ticket de suggestion sur Developer Community.

Se connecter à WSL

Dans Visual Studio 2017, vous suivez les mêmes étapes pour vous connecter à WSL que pour une machine Linux distante. Utilisez localhost pour le Nom d’hôte.

Depuis Visual Studio 2019 version 16.1, Visual Studio prend en charge nativement l’utilisation de C++ avec le Sous-système Windows pour Linux (WSL). Cela signifie que vous pouvez générer et déboguer directement votre installation WSL locale. Vous n’avez plus besoin d’ajouter une connexion à distance ou de configurer SSH. Vous trouverez des détails sur l’installation de WSL ici.

Pour configurer votre installation WSL de manière à ce qu’elle fonctionne avec Visual Studio, vous devez installer les outils suivants : gcc ou clang, gdb, make, ninja-build (requis uniquement pour les projets CMake utilisant Visual Studio 2019 version 16.6 ou ultérieure), rsync et zip. Vous pouvez les installer sur des distributions qui utilisent apt à l’aide de cette commande, qui installe également le compilateur g++ :

sudo apt install g++ gdb make ninja-build rsync zip

Résoudre les problèmes de connexion au localhost WSL

Lorsque vous vous connectez à Sous-système Windows pour Linux (WSL) sur localhost, vous pouvez rencontrer un conflit avec le client Windows ssh sur le port 22. Dans WSL, modifiez le port qui sshattend des requêtes de 23 en /etc/ssh/sshd_config :

Port 23

Si vous vous connectez en utilisant un mot de passe, vérifiez que les éléments suivants sont définis dans /etc/ssh/sshd_config :

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes

Après avoir apporté ces modifications, redémarrez le serveur SSH (sudo service ssh restart sur Ubuntu).

Ensuite, réessayez votre connexion à localhost à l’aide du port 23.

Pour plus d’informations, consultez Télécharger, installer et configurer la charge de travail Linux.

Pour configurer un projet MSBuild pour WSL, consultez Configurer un projet Linux. Pour configurer un projet CMake pour WSL, consultez Configurer un projet CMake Linux. Pour suivre les instructions pas à pas permettant de créer une application console simple avec WSL, consultez ce billet de blog d’introduction sur C++ avec Visual Studio 2019 et le sous-système Windows pour Linux (WSL).

Voir aussi

Configurer un projet Linux
Configurer un projet CMake Linux
Déployer, exécuter et déboguer un projet Linux
Configurer des sessions de débogage CMake