web-dev-qa-db-fra.com

Serveur x distant avec ssh -X

J'essaie de démarrer une session gnome à distance à l'aide de: ssh -X [email protected] gnome-session

Ubuntu version 12.04 est le client et le serveur

Je reçois ce qui suit (et il ne se passe pas beaucoup de choses) ...

GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_PID=3573
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to get contents of /sys/class/dmi/id/board_version: Failed to open file '/sys/class/dmi/id/board_version': No such file or directory

** (gnome-settings-daemon:3572): WARNING **: You can only run one xsettings manager at a time; exiting

** (gnome-settings-daemon:3572): WARNING **: Unable to start xsettings manager: Could not initialize xsettings manager.
compiz (core) - Error: Screen 0 on display "localhost:10.0" already has a window manager; try using the --replace option to replace the current window manager.
Initializing nautilus-gdu extension
Created new window in existing browser session.
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon

(gnome-settings-daemon:3572): keyboard-plugin-WARNING **: Failed to set the keyboard layouts: GDBus.Error:org.freedesktop.Accounts.Error.PermissionDenied: Not authorized

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused

(gnome-settings-daemon:3572): clipboard-plugin-WARNING **: Clipboard manager is already running.

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to create device: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-device auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-profile auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: no xrandr-Samsung Electric Company-SAMSUNG device found: Failed to find output xrandr-Samsung Electric Company-SAMSUNG
Shutting down nautilus-gdu extension

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
sshxserver
12
benlad

Je suppose que ce que vous essayez de faire est de démarrer une session Gnome à distance complète affichée sur votre ordinateur local. Cela échoue car un gestionnaire de session local contrôle déjà l’affichage de votre serveur X.

Vos options sont:

  1. Démarrez simplement des applications distantes individuelles avec ssh -X [email protected] xclock

  2. En supposant que XDMCP est activé sur la machine distante ...

    2a. Utilisez Xnest -query 192.168.1.107 -geometry 1024x768 :1 pour démarrer une session de connexion à distance dans une fenêtre locale.

    2b. Utilisez Xephyr :1 -screen 1024x768 -query 192.168.1.107 qui est un meilleur serveur X que Xnest

  3. En supposant également que XDMCP se trouve sur la machine distante, configurez votre machine locale pour qu’elle utilise le sélecteur XDMCP au lieu de la machine de surveillance standard au démarrage.

Activer XDMCP est simplement un cas de mise

[xdmcp]
Enable=true

dans /etc/gdm/custom.conf et en redémarrant gdm ou en redémarrant (en supposant que vous exécutiez gdm).

Si vous avez seulement l'intention d'exécuter quelques applications à distance, l'option 1 est la plus simple et continue d'utiliser le trafic crypté SSH, ce qu'aucun autre ne fait (il est donc préférable de ne l'utiliser que sur un réseau local approuvé).

Si vous avez besoin de quelque chose de plus compliqué, alors 2b (Xephyr) est peut-être mieux, mais je trouve généralement que le simple fait d'utiliser ssh -X ... & pour plusieurs applications distantes est suffisant.

Si vous faites tout à distance, c’est-à-dire que la machine locale n’est qu’un serveur d’affichage et ne fait rien elle-même, vous devez vous pencher sur l’option 3, en démarrant le sélecteur XDMCP au lieu de la connexion standard.

PS: comme indiqué dans les commentaires, Xnest et Xephyr sont des applications qui gèrent le protocole de serveur X et placent la session entière dans une fenêtre. Xnest utilise les fonctions fournies par le serveur X local tandis que Xephyr gère beaucoup plus du protocole de serveur lui-même, ce qui le rend plus robuste. Ils ne peuvent pas être installés par défaut car l'utilisateur moyen ne les utiliserait pas.

PPS: Après un peu de réflexion, il est évident de chiffrer une session Xephyr ou Xnest ...

ssh -X [email protected] Xephyr :1 -query localhost -screen 1280x1024
12
StarNamer

Au cas où vous voudriez apprendre à utiliser le standard ssh depuis un terminal, je pensais vous présenter un bref aperçu, car vous aviez du mal à utiliser les clés ssh, semble-t-il. L'avantage est qu'il est plus universel et très flexible.

Pour utiliser les clés ssh, qui sont plus sécurisées, parfois requises et plus pratiques, car vous ne devez entrer la clé qu'une seule fois, vous devez le faire une fois pour tout serveur ssh distant:

générer la clé (peut utiliser dsa au lieu de rsa, si nécessaire)

ssh-keygen -t rsa

transférer la clé sur l'hôte distant

ssh-copy-id <username>@<Host>

s'il ne s'agit pas du port standard 22, utilisez ceci: La note cite autour de l'argument 

ssh-copy-id "<username>@<Host> -p <port_nr>"

Si vous utilisez dsa, il existe une commande légèrement différente, ajoutant -i <homedirectory>/.ssh/id_dsa

Quelque temps après, vous devrez entrer un mot de passe, distinct de votre mot de passe de connexion habituel. Cela fait longtemps et j'ai oublié la séquence exacte, mais cela devrait être évident. Ensuite, lors de votre première connexion, ce mot de passe vous sera demandé une fois. J'utilise le même nom d'utilisateur, je n'ai donc pas besoin d'entrer le nom d'utilisateur (il est identique au nom d'utilisateur distant). En outre, pour les serveurs de votre réseau local, vous pouvez entrer ".local" à la place de l'adresse IP, je crois (fonctionne pour moi).

Vous pouvez même monter un système de fichiers distant en utilisant sshfs (en supposant que sshfs soit installé); substituez un chemin de répertoire pour local-mount-directory:

sshfs remote-Host: local-mount-directory

(démontez avec fusermount -u local-mount-directory)

Je pense qu'il utilisera votre répertoire personnel par défaut, si vous quittez le répertoire de montage local. `

La copie de fichiers peut être effectuée avec scp.

0
Marty Fried