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. Peu importe qu’il s’agisse 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.
Sur le système Linux, installez et démarrez le serveur OpenSSH :
sudo apt install openssh-server sudo service ssh start
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
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.
Dans la boîte de dialogue Gestionnaire des connexions, choisissez le bouton Ajouter pour ajouter une nouvelle connexion.
Dans le volet Options, Multiplateforme > C++ > Gestionnaire des connexions est sélectionné, et le bouton Ajouter est mis en évidence.
Pour modifier une connexion existante, choisissez Modifier. Dans les deux cas, la fenêtre Se connecter au système distant s’affiche.
Dans la fenêtre Se connecter au 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 défini est le port 22. Le type d’authentification est « Mot de passe ».
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 ne pouvez pas cliquer sur le bouton Se connecter tant que tous les champs obligatoires ne sont pas renseignés, et que le port n’a pas la valeur d’un entier compris entre 1 et 65535.
Vous pouvez utiliser un mot de passe ou un fichier de clé avec une phrase secrète pour l’authentification. Les fichiers clés sont plus sécurisés que le nom d’utilisateur/mot de passe. 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 Elliptic Curve (EC), Rivert-Shamir-Adleman (RSA) et DSA (Digital Signature Algorithm) pour les connexions à distance. Pour des raisons de sécurité, les clés RSA et DSA ne sont plus prises en charge dans Visual Studio 17.10 et les versions ultérieures. Seules les clés EC sont prises en charge. Pour créer une paire de clés compatible avec le Gestionnaire des 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 avecssh-keygen -p -f <FILE> -m pem
.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.
En cas d’échec de la connexion, une barre d’info avec des informations sur l’erreur s’affiche, et les champs que vous pouvez être amené à changer sont encadrés en rouge.
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 aulocalhost
WSL.
Vérification de la clé d’hôte
Dans Visual Studio 16.10 ou version ultérieure, vous êtes invité à vérifier l’empreinte digitale de clé d’hôte du serveur 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 à distance, il vous est demandé d’accepter ou de refuser l’empreinte digitale de clé d’hôte présentée 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 d’abord invité à accepter l’empreinte digitale de clé d’hôte. 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 anciens algorithmes SSH 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 :
Les options sont ouvertes pour Multiplateforme > Gestionnaire des connexions > Journalisation. La case Activer la journalisation est cochée, la case Journaliser dans un fichier est cochée, l’emplacement du répertoire des fichiers journaux est défini dans le dossier documents, et la case Journaliser dans le volet Journalisation multiplateforme de la fenêtre Sortie est cochée.
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 réacheminement de port TCP n’est pas activé sur le système distant, cette erreur se produit au début du téléchargement des en-têtes distants pour IntelliSense :
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 réacheminement de port TCP est désactivé sur votre système distant, une erreur s’affiche dans la fenêtre Sortie de CMake la première fois que rsync
est appelé.
La fenêtre Sortie comprend les messages suivants : Vérifiez que le transfert TCP est activé sur le serveur, rsync : message d’accueil du serveur non visible, erreur rsync : erreur de démarrage du protocole client-serveur (code 5) à main.c(1675) [sender=3.1.3]. Impossible d’ouvrir un canal SSH.
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, changez le port sur lequel ssh
attend les 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