J'ai un accès SSH et j'ai installé Xming, ainsi que les polices Xming. J'ai configuré PuTTY pour transférer x11 et lui ai dit de placer le bureau à localhost: 0, selon les instructions ici .

Cependant, après m'être connecté, et startxje ne reçois ... rien. Ou plutôt, il exécute un tas de messages qui semblent dire que tout fonctionne, mais je reçois un curseur dans ma fenêtre de console qui agit comme s'il était en attente. Et c'est tout.

Qu'est-ce que je rate? Dois-je ouvrir quelque chose pour voir le bureau?

Je veux transférer mon bureau vers mon PC de travail, afin de pouvoir jouer avec RasPi au déjeuner sans brancher physiquement le matériel. Veuillez aider.

ÉDITER:

Capture d'écran de ce qui se passe avec Xming en cours d'exécution, et je SSH et appeler startx:

EDIT 2:

Cette réponse dit startxest inutile, car il démarre le serveur X Raspi, et j'utilise le serveur Xming sur Windows. Dans ce cas, comment accéder au bureau / à l'interface graphique sur Xming depuis Windows? Parce que, même avec Xming en cours d'exécution et SSH activé, je ne reçois rien d'autre qu'une invite de console normale. Peut-être que je me trompe. Ce que je veux, c'est mon interface graphique RasPi normale et complète fonctionnant dans une fenêtre sur mon PC Windows distant. Je ne veux pas utiliser VNC. J'achemine sur Internet. Comment puis-je y arriver?

Si vous démarrez Xming sur votre ordinateur Windows, vous disposez déjà d'un serveur X en cours d'exécution. Vous n'avez pas besoin de démarrer le serveur X de votre Raspberry Pi avec startx. Vos applications X s'exécuteront sur le Raspberry Pi mais l'application s'appuiera sur le serveur Xming X de Windows.

La documentation que vous avez liée indique que vous devez démarrer le serveur X sous Windows et ne mentionne pas que vous devez démarrer le serveur X sous Linux. Dans la dernière phrase de la documentation:

Vous devriez maintenant pouvoir exécuter des applications X à partir de l'hôte sur votre bureau local

"Applications X" ne fait pas référence au serveur X (qui doit être démarré par startx) mais à des applications comme xclock, xeyes, etc.

Une application X spéciale est lxsession qui démarrera le gestionnaire de session standard de LXDE (au moins sur mon Raspbian). Le démarrage de cette application sur la console vous donnera la "GUI complète" que vous recherchez:

lxsession

Personnellement, je ne trouve pas utile de démarrer lxsession, démarrer les applications X sur la console est beaucoup plus facile pour moi.

Utilisation de Cygwin / X

Si vous n'êtes pas lié à Xming, vous pouvez utiliser à la place Cygwin / X pour exécuter un serveur X sous Windows.

Préparation du Raspberry Pi

Essayez d'établir une connexion SSH régulière de Windows au Raspberry Pi à l'aide de PowerShell:

Étant donné que Raspbian Buster inclut X11Forwarding yesdans /etc/ssh/sshd_config, votre Raspberry Pi devrait également être en mesure de transmettre la sortie visuelle des applications X11 à un serveur X sous Windows.

L'étape suivante montre comment installer ce serveur X.

Installer Cygwin / X sur Windows

Cygwin / X fournit un serveur X pour Windows qui affiche les applications GUI s'exécutant sur le Raspberry Pi.

1. Téléchargez et exécutez à setup-x86_64.exepartir du site Web de Cygwin .

2. Pour le "répertoire de packages local" de Cygwin, vous pouvez utiliser C:\Users\me\AppData\Roaming\Cygwin.

3. Choisissez un serveur près de chez vous pour télécharger des packages.

4. Réglez «Afficher» sur «Complet» et recherchez xinit.

5. Dans la colonne "Nouveau", utilisez le menu déroulant pour changer la valeur de "Ignorer" vers xinitla dernière version de:

6. Installez le package de opensshla même manière.

Se connecter à Raspberry Pi depuis Windows

1. Démarrez le serveur X en utilisant le menu de démarrage Windows: Cygwin-X → XWin Server. Cela n'ouvrira aucune fenêtre, mais vous devriez voir deux nouvelles icônes dans votre barre d'état système:

2. Démarrez le terminal Cygwin: Cygwin → Cygwin64 Terminal

3. Définissez la DISPLAYvariable d'environnement sur l'emplacement d'exécution du serveur X sous Windows:

   export DISPLAY=:0.0

4. Connectez-vous à votre Raspberry Pi avec la redirection X11:

   ssh -Y pi@raspberrypi

Dans la session SSH, vous pouvez maintenant démarrer une application X sur le Raspberry Pi comme Thonny :

Alternativement, comme user1297 l'a mentionné dans les commentaires de la question, vous pouvez exécuter x-session-managerpour émuler l'expérience que vous obtiendriez lors de la connexion au Raspberry Pi via HDMI sur un moniteur externe:

Si vous souhaitez démarrer une application directement sans d'abord taper son nom dans le shell, utilisez ceci:

ssh -Y pi@raspberrypi x-session-manager

Sur macOS

XQuartz fournit un serveur X pour macOS.

Installez XQuartz, déconnectez-vous et reconnectez-vous (pour rendre la nouvelle valeur DISPLAYeffective), puis lancez des applications avec SSH à partir de Bash:

ssh -Y pi@raspberrypi thonny

Si vous utilisez déjà un serveur X sous Windows (comme vous le faites avec Xming), le côté Windows est généralement terminé (mais voir ci-dessous pour quelques détails importants). Le bit clé restant est de dire aux applications X11 sur le pi d'envoyer leurs données X11 à votre PC Windows.

Cela se fait via la DISPLAYvariable d'environnement. Normalement, si le serveur X et l'application s'exécutent sur le même ordinateur, DISPLAY spécifie simplement le numéro de serveur (par exemple, :0si vous utilisez un seul serveur X) ou peut-être un serveur et un écran (par exemple :0.0). Comme il n'y a pas d'adresse IP, cela indique à la bibliothèque X des applications que le serveur est local et que les connexions seront établies en conséquence (probablement via une sorte de transport de mémoire partagée).

Pour indiquer à l'application d'envoyer des données X11 à un nœud distant, incluez une adresse IP dans la DISPLAYvariable. Par exemple export DISPLAY=192.168.1.10:0,. Cela indiquera à toutes les applications X11 dont elles ont besoin pour ouvrir une connexion TCP au serveur X # 0 sur le nœud 192.168.1.10. Les noms d'hôte DNS sont bien ici, si vous les avez sur votre réseau.

Deux problèmes potentiels

Comme je l'ai écrit dans le premier paragraphe, exécuter simplement Xming peut ne pas être suffisant. Une configuration supplémentaire peut être nécessaire.

La première est que votre serveur X11 doit être configuré pour accepter les connexions des nœuds distants via TCP. De nombreux serveurs X distribués aujourd'hui (je ne connais pas Xming) n'acceptent que les connexions des applications exécutées localement, sauf si vous les configurez explicitement autrement. Il s'agit d'une fonction de sécurité, car chaque socket ouvert est un vecteur potentiel d'attaque.

La seconde est que votre serveur X11 gère une base de données d'hôtes / utilisateurs autorisés à se connecter. Vous devez mettre en liste blanche l'adresse IP de votre Raspberry Pi. Vous pouvez le faire en exécutant la xhostcommande à partir de Xming sur Windows, par exemple, à partir d'une console exécutée dans un xterm. Vous pouvez également taper xhost +pour désactiver ce contrôle de sécurité, mais c'est dangereux car cela permettra à n'importe quelle application de n'importe où dans le monde d'ouvrir des connexions à votre écran. Si vous êtes derrière un pare-feu sur un LAN où vous faites confiance à tout le monde (par exemple votre propre maison), c'est l'approche la plus simple, mais prenez le temps de configurer correctement xhostsi vous ne l'êtes pas.

Alternative: ssh -Y

En utilisant l'approche ci-dessus, vos applications X11 essaieront toutes d'ouvrir des connexions TCP à votre serveur X. Ces connexions ne sont pas sécurisées. Quelqu'un sur vos paquets d'espionnage LAN peut les intercepter.

Pour résoudre ce problème, au lieu de définir la variable DISPLAY sur le Raspberry pi, utilisez le -Yparamètre lors de la connexion (par exemple slogin -Y hostname). Le paramètre -Y (comme -X) créera un tunnel entre les nœuds pour transporter le trafic X11. Cela gardera le trafic X11 crypté et sécurisé. Il affectera également sa propre variable d'environnement DISPLAY afin que les applications utilisent le tunnel. Cela peut également éliminer la nécessité de jouer avec xhost(car en ce qui concerne votre serveur X) les connexions proviennent localement (du côté d'origine du tunnel SSH).