Comment transférer X sur SSH pour exécuter des applications graphiques à distance?

345

J'ai une machine sous Ubuntu à laquelle je suis SSH depuis ma machine Fedora 14. Je souhaite renvoyer X de la machine Ubuntu à Fedora pour pouvoir exécuter des programmes graphiques à distance. Les deux machines sont sur un réseau local.

Je sais que l' -Xoption active le transfert X11 dans SSH, mais j'ai l'impression de manquer certaines étapes.

Quelles sont les étapes requises pour transférer X d'une machine Ubuntu vers Fedora via SSH?

M. Shickadance
la source
6
Je sais que c'est assez courant, mais j'ai des problèmes. Une réponse définitive à cette question serait utile pour beaucoup. Beaucoup d'exemples semblent omettre des détails importants.
M. Shickadance

Réponses:

413

Le transfert X11 doit être activé à la fois du côté client et du côté serveur.

Du côté client , l' -Xoption (majuscule X) sshpermet d' activer le transfert X11 et vous pouvez en faire la valeur par défaut (pour toutes les connexions ou pour une connexion spécifique) avec ForwardX11 yesin ~/.ssh/config.

Côté serveur , X11Forwarding yesdoit être spécifié dans /etc/ssh/sshd_config. Notez que la valeur par défaut est aucun transfert (certaines distributions l'activent par défaut /etc/ssh/sshd_config) et que l'utilisateur ne peut pas remplacer ce paramètre.

Le xauthprogramme doit être installé côté serveur. S'il existe des programmes X11, il est fort probable qu'ils le xauthseront. Dans le cas peu probable où il a xauthété installé dans un emplacement non standard, il peut être appelé via ~/.ssh/rc(sur le serveur!).

Notez qu'il n'est pas nécessaire de définir des variables d'environnement sur le serveur. DISPLAYet XAUTHORITYsera automatiquement mis à leurs valeurs appropriées. Si vous exécutez ssh et DISPLAYn’est pas défini, cela signifie que ssh ne transfère pas la connexion X11.

Pour confirmer que ssh est en train de transférer X11, recherchez une ligne Requesting X11 forwardingdans la ssh -v -Xsortie. Notez que le serveur ne répondra dans aucun cas, une précaution de sécurité consistant à cacher des détails à des attaquants potentiels.

Gilles
la source
31
@user: Non, vous ne devez jamais xhost +. xhostvient d'une époque plus douce quand une machine connectée au réseau signifiait que vous étiez digne de confiance. xhost +signifie que quiconque peut usurper votre adresse IP peut prendre le contrôle de votre session sur le serveur X. ssh -Xmettra en place toutes les autorisations requises. Si le transfert X11 est désactivé dans la configuration du serveur, contactez votre administrateur. Si cela ne fonctionne pas, voir Redirection de X11 sur SSH si la configuration du serveur ne le permet pas .
Gilles
6
Merci d'avoir mentionné xauth! Le manque de cela sur un serveur barebones me causait des problèmes.
Vasi
5
+1 pour faire la distinction entre ~/.ssh/configet /etc/ssh/sshd_configau même endroit. Je ne pouvais pas dire s’il s’agissait de fichiers différents ou s’il s’agissait simplement d’un changement de nomenclature.
puk
1
@KhurshidAlam Peu importe que le serveur exécute également un environnement graphique. Vérifiez les autorisations sur le .Xauthorityfichier. Si vous utilisez Red Hat ou un autre système avec SELinux, vérifiez le contexte SELinux, voir unix.stackexchange.com/questions/36540/…
Gilles
8
après ssh -Xcourse xterm &pour obtenir un terminal graphique comme le test ultime pour voir si elle fonctionne.
Alexander Taylor
88

Pour que la redirection X11 fonctionne sur ssh, vous devez disposer de 3 éléments.

  1. Votre client doit être configuré pour transférer X11.
  2. Votre serveur doit être configuré pour autoriser le transfert X11.
  3. Votre serveur doit pouvoir configurer l'authentification X11.

Si vous avez les n ° 1 et n ° 2 en place mais qu'il vous manque la n ° 3, vous obtiendrez une variable d'environnement DISPLAY vide.

De la soupe aux noix, voici comment faire fonctionner la transmission X11.

  1. Sur votre serveur, assurez-vous que / etc / ssh / sshd_config contient:

    X11Forwarding yes
    X11DisplayOffset 10
    

    Vous devrez peut-être SIGHUP pour qu'il prenne ces modifications en compte.

    cat /var/run/sshd.pid | xargs kill -1
    
  2. Sur votre serveur, assurez-vous que xauth est installé.

    belden@skretting:~$ which xauth
    /usr/bin/xauth
    

    Si xauth n'est pas installé, vous rencontrerez le problème de "variable d'environnement DISPLAY vide".

  3. Sur votre client, connectez-vous à votre serveur. Assurez-vous de dire à ssh d'autoriser le transfert X11. je préfère

    belden@skretting:~$ ssh -X blyman@the-server
    

mais vous pouvez aimer

    belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server

ou vous pouvez le configurer dans votre ~ / .ssh / config.


Je rencontrais cette variable d’environnement DISPLAY vide plus tôt aujourd’hui lorsque ssh s’est inséré dans un nouveau serveur que je n’administre pas. Repérer la partie manquante de xauth était un peu amusant. Voici ce que j'ai fait et ce que vous pouvez faire aussi.

Sur mon poste de travail local, où je suis administrateur, j'ai vérifié que / etc / ssh / sshd_config était configuré pour transférer X11. Quand je ssh -X retourne à localhost, mon DISPLAY est configuré correctement.

Forcer DISPLAY à se désinstaller n'était pas trop difficile. J'avais juste besoin de regarder ce que sshd et ssh faisaient pour le configurer correctement. Voici le résultat complet de tout ce que j'ai fait en cours de route.

    blyman@skretting:~$ mkdir ~/dummy-sshd
    blyman@skretting:~$ cp -r /etc/ssh/* ~/dummy-sshd/
    cp: cannot open `/etc/ssh/ssh_host_dsa_key' for reading: Permission denied
    cp: cannot open `/etc/ssh/ssh_host_rsa_key' for reading: Permission denied

Au lieu d'utiliser sudo pour forcer la copie de mes fichiers ssh_host_ {dsa, rsa} _key, j'ai utilisé ssh-keygen pour en créer des factices.

    blyman@skretting:~$ ssh-keygen -t rsa -f ~/dummy-sshd/ssh_host_rsa_key
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.
    Your public key has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.pub.

Rincez et répétez avec -t dsa:

    blyman@skretting:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_host_dsa_key
    # I bet you can visually copy-paste the above output down here

Éditez ~ / dummy-sshd / sshd_config pour qu'il pointe vers les nouveaux fichiers de clé ssh_host appropriés.

    # before
    blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config 
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key

    # after
    blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config 
    HostKey /home/blyman/dummy-sshd/ssh_host_rsa_key
    HostKey /home/blyman/dummy-sshd/ssh_host_dsa_key

Lancez sshd sur un nouveau port en mode sans détachement:

    blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    sshd re-exec requires execution with an absolute path

Oups, mieux vaut corriger ce chemin:

    blyman@skretting:~$ /usr/sbin/sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
    debug1: read PEM private key done: type RSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
    debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
    debug1: private host key: #0 type 1 RSA
    debug1: read PEM private key done: type DSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
    debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
    debug1: private host key: #1 type 2 DSA
    debug1: setgroups() failed: Operation not permitted
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-p'
    debug1: rexec_argv[2]='50505'
    debug1: rexec_argv[3]='-f'
    debug1: rexec_argv[4]='/home/blyman/dummy-sshd/sshd_config'
    debug1: rexec_argv[5]='-d'
    Set /proc/self/oom_adj from 0 to -17
    debug1: Bind to port 50505 on 0.0.0.0.
    Server listening on 0.0.0.0 port 50505.
    debug1: Bind to port 50505 on ::.
    Server listening on :: port 50505.

Ouvrez un nouveau terminal et ssh dans localhost sur le port 50505:

    blyman@skretting:~$ ssh -p 50505 localhost
    The authenticity of host '[localhost]:50505 ([::1]:50505)' can't be established.
    RSA key fingerprint is 81:36:a5:ff:a3:5a:45:a6:90:d3:cc:54:6b:52:d0:61.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '[localhost]:50505' (RSA) to the list of known hosts.
    Linux skretting 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64 GNU/Linux
    Ubuntu 10.10

    Welcome to Ubuntu!
     * Documentation:  https://help.ubuntu.com/

    1 package can be updated.
    0 updates are security updates.

    Last login: Thu Aug 16 15:41:58 2012 from 10.0.65.153
    Environment:
      LANG=en_US.UTF-8
      USER=blyman
      LOGNAME=blyman
      HOME=/home/blyman
      PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
      MAIL=/var/mail/blyman
      SHELL=/bin/bash
      SSH_CLIENT=::1 43599 50505
      SSH_CONNECTION=::1 43599 ::1 50505
      SSH_TTY=/dev/pts/16
      TERM=xterm
      DISPLAY=localhost:10.0
    Running /usr/bin/xauth remove unix:10.0
    /usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 79aa9275ced418dd445d9798b115d393

Regardez les trois dernières lignes. J'avais fortuitement le jeu DISPLAY et ces deux jolies lignes de / usr / bin / xauth.

À partir de là, c’était un jeu d’enfant de déplacer mon / usr / bin / xauth vers /usr/bin/xauth.old, de se déconnecter de ssh et d’arrêter sshd, puis de relancer sshd et ssh dans localhost.

Lorsque / usr / bin / xauth était parti, je ne voyais pas DISPLAY reflété dans mon environnement.


Il n'y a rien de brillant ici. La plupart du temps, j'ai eu la chance de choisir une approche sensée pour essayer de reproduire cela sur ma machine locale.

Belden
la source
1
Wow, merci beaucoup pour votre réponse. Je faisais tout bon sauf le export DISPLAY=:10. Je n'ai jamais deviné ce nombre d'affichage.
erm3nda
C'est un décalage d'affichage de 10! : D
41754
34

Sois sûr que:

  • Vous avez xauthinstallé sur le serveur (voir: xauth info/ xauth list).
  • Sur le serveur, votre /etc/ssh/sshd_configfichier contient ces lignes:

    X11Forwarding yes
    X11DisplayOffset 10
    X11UseLocalhost no
    
  • Du côté client, votre ~/.ssh/configfichier contient les lignes suivantes:

    Host *
      ForwardAgent yes
      ForwardX11 yes
    
  • Du côté client, vous avez installé le serveur X (par exemple, macOS: XQuartz; Windows: Xming).


Ensuite, pour faire le transfert X11 avec SSH, vous devez ajouter -Xà votressh commande, par exemple

ssh -v -X user@host

puis vérifiez que votre DISPLAYn'est pas vide par:

echo $DISPLAY

S'il est, puis d' avoir le paramètre bavard pour ssh ( -v), vérifier les mises en garde, par exemple

debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated

Si vous avez un X11 non fiable comme indiqué ci-dessus, essayez-Y plutôt flag (si vous faites confiance à l'hôte):

ssh -v -Y user@host

Voir: Que signifie «Avertissement: la configuration du transfert X11 non fiable a échoué: les données de clé xauth non générées» signifient-elles lorsque ssh passe avec -X?


Si vous avez un avertissement: pas de données xauth , vous pouvez essayer de générer un nouveau .Xauthorityfichier, par exemple

xauth generate :0 . trusted
xauth list

Voir: Créer / reconstruire un nouveau fichier .Xauthority


Si vous avez des avertissements différents de ceux mentionnés ci-dessus, suivez les autres indices.


Kenorb
la source
1
Le guide définitif: La configuration côté client marque la différence
user2928048
2
et X11UseLocalhost non côté serveur
utilisateur2928048 le
17

Le correctif est d'ajouter cette ligne à votre /etc/ssh/sshd_config:

X11UseLocalhost no

https://joshua.hoblitt.com/rtfm/2013/04/how_to_fix_x11_forwarding_request_failed_on_channel_0/

Ace
la source
J'ai 2 serveur Ubuntu. Sur celui dont j'avais besoin, il devait être réglé sur oui, sur l'autre, il devait être non. Je suis sûr qu'il existe une explication, mais cela vaut la peine d'essayer les deux.
Alfonx
1
Ce correctif a fonctionné pour moi!
rigon
3
Veuillez préciser si vous souhaitez définir ce paramètre sur le serveur ou le client
Klik
5

Laisser Ubuntu bash sur Windows 10 s'exécuter ssh -X pour obtenir un environnement graphique sur un serveur distant

  • Première

Installez tout ce qui suit. Sur la fenêtre, installez Xming. Sur Ubuntu bash, utilisez sudo apt installpour installer ssh xauth xorg.

sudo apt install ssh xauth xorg
  • Seconde

Allez dans le dossier contient le ssh_configfichier, le mien est /etc/ssh.

  • Troisième

Modifier en ssh_configtant qu'administrateur (USE sudo). A l' intérieur ssh_config, supprimer la valeur de hachage #dans les lignes ForwardAgent, ForwardX11, ForwardX11Trusted, et définir les arguments correspondants yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
  • 4ème

Dans le ssh_configfichier, supprimez le hachage #avant avant Port 22et Protocol 2ajoutez également une nouvelle ligne à la fin du fichier pour indiquer l'emplacement du fichier xauth XauthLocaion /usr/bin/xauth. Rappelez-vous d'écrire votre propre chemin d'accès au fichier xauth.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocaion /usr/bin/xauth
  • Cinquième

Maintenant que nous avons terminé l'édition du ssh_configfichier, enregistrez-le lorsque nous quittons l'éditeur. Maintenant, allez dans le dossier ~ou $HOME, ajoutez export DISPLAY=localhost:0à votre .bashrcfichier et enregistrez-le.

# ~/.bashrc
...
...
export DISPLAY=localhost:0
  • Dernier

On a presque fini. Redémarrez votre shell bash, ouvrez votre Xmingprogramme et utilisez-le ssh -X yourusername@yourhost. Ensuite, profitez de l'environnement graphique.

ssh -X yourusername@yourhost

Le problème concerne également le sous-système Ubuntu sous Windows et le lien se trouve à l'adresse suivante:

https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

DestinyOne
la source
3

Ajouter X11UseLocalhost noà /etc/ssh/sshd_configet redémarrer le serveur SSH.

Si vous n'obtenez pas de DISPLAY, vérifiez si xauth est installé correctement, puis réessayez.

RHE / CEntos n'a pas ce problème, c'est une affaire Ubuntu!

stephen cooke
la source
1

Pour moi, le problème était dans l' option de montage nodev pour le système de fichiers / tmp. X11 a besoin d’un fichier spécial pour y être créé.

Vérifiez donc quelles sont les options de montage pour le système de fichiers / tmp si vous utilisez une partition ou un disque séparé pour cela.

Yakovpol
la source
1
Je pense que vous voudrez peut-être voir d’autres réponses à la question initiale et prendre un moment pour réfléchir à l’amélioration de votre propre réponse.
Sami Laine
1

Pour ajouter aux excellentes réponses précédentes (configurer ~/.ssh/configet vérifier si la DISPLAYvariable d’environnement est définie sur le client, configurer /etc/ssh/sshd_configet installer xauthsur le serveur), assurez-vous également qu’il xtermest installé sur le client, par exemple

sudo apt-get install xterm
Aliz Rao
la source
1

xauth peut être verrouillé.

   -b      This  option  indicates  that  xauth  should  attempt to break any authority file locks before proceeding.  Use this
           option only to clean up stale locks.

En utilisant

xauth -b

Sur la machine dans laquelle j'essayais de sshbriser le verrou xauth. Se déconnecter de la sshsession après l’émission, xauth -bpuis se reconnecter, m’a finalement permis de réussir echo $DISPLAY. Essayez certainement ceci avant de recréer.Xauthority

Barton Chittenden
la source
0

X11Forwardingdoit être défini sur le serveur SSH (dans votre cas, la boîte Ubuntu) sshd_configet vous devez autoriser le transfert de X11 pour le client SSH (votre boîte Fedora) en passant l' -Xoption ou en modifiant le ssh_configfichier pour ajouter la ForwardX11valeur par défaut.

Caleb
la source
1
Vous devez également être xauthinstallé sur la machine distante, sinon le matériel autorité x ne fonctionnera pas.
Faheem Mitha
Qu'en est- il établir DISPLAY?
M. Shickadance
1
ssh définira automatiquement $DISPLAYsi X11Forwardingest activé et xauthest présent sur le système client.
Shadur
1
@Shadur Pas pour moi. Cela fonctionne quand je export DISPLAY=:10.0mais pas autrement. Sinon, il se plaint qu'il ne peut pas trouver :0. Peut-être que quelque chose d'autre est nécessaire pour que cela se produise automatiquement?
cfr