web-dev-qa-db-fra.com

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

J'ai une machine exécutant Ubuntu vers laquelle je SSH depuis ma machine Fedora 14. Je veux transférer X de la machine Ubuntu vers Fedora pour pouvoir exécuter des programmes graphiques à distance. Les deux machines sont sur un LAN.

Je sais que l'option -X Permet le transfert X11 en 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?

sshxorgxforwarding
390
Mr. Shickadance

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

Du côté client , le -X (X majuscule) pour ssh active 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 yes dans ~/.ssh/config .

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

Le programme xauth doit être installé côté serveur. S'il existe des programmes X11, il est très probable que xauth sera là. Dans le cas peu probable xauth a été installé dans un emplacement non standard, il peut être appelé via ~/.ssh/rc (sur le serveur!).

Notez que vous n'avez pas besoin de définir de variables d'environnement sur le serveur. DISPLAY et XAUTHORITY seront automatiquement définis sur leurs valeurs appropriées. Si vous exécutez ssh et que DISPLAY n'est pas défini, cela signifie que ssh ne transfère pas la connexion X11.

Pour confirmer que ssh transfère X11, recherchez une ligne contenant Requesting X11 forwarding dans le ssh -v -X production. Notez que le serveur ne répondra pas de toute façon, une précaution de sécurité pour cacher les détails aux attaquants potentiels.

452
Gilles 'SO- stop being evil'

Pour que la redirection X11 fonctionne sur ssh, vous aurez besoin de 3 choses en place.

  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 à la fois # 1 et # 2 en place mais que vous manquez # 3, alors vous vous retrouverez avec une variable d'environnement DISPLAY vide.

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

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

    X11Forwarding yes
X11DisplayOffset 10

    Vous devrez peut-être SIGHUP sshd afin qu'il reprenne ces modifications.

    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 vous n'avez pas installé xauth, vous rencontrerez le problème "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 aimerez peut-être

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

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

Plus tôt dans la journée, je rencontrais cette variable d'environnement DISPLAY vide lorsque je suis entré dans un nouveau serveur que je n'administre pas. Retrouver la partie xauth manquante é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. Lorsque je retourne ssh -X à localhost, mon affichage est correctement réglé.

Forcer DISPLAY à se désinstaller n'était pas trop difficile. J'avais juste besoin de regarder ce que sshd et ssh faisaient pour le régler correctement. Voici la sortie complète 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 en place, j'ai utilisé ssh-keygen pour créer des fichiers factices pour moi-même.

    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.

Rincer et répéter 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

Modifiez ~/dummy-sshd/sshd_config pour pointer vers les nouveaux fichiers de clés ssh_Host corrects.

    # 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 non détachable:

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

Oups, mieux 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.

Ajoutez un nouveau terminal et connectez-vous à 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'ai eu fortuitement DISPLAY réglé, et j'avais ces deux lignes de Nice-look 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 le sshd, puis de lancer sshd et ssh pour revenir à localhost.

Quand/usr/bin/xauth a disparu, je n'ai pas vu 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.

98
Belden

Sois sûr que:

  • Vous avez xauth installé sur le serveur (voir: xauth info/xauth list).

  • Sur le serveur, votre /etc/ssh/sshd_config le fichier a ces lignes:

    X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no

  • Côté client, votre ~/.ssh/config le fichier a ces lignes:

    Host *
  ForwardAgent yes
  ForwardX11 yes

  • Côté client, vous avez installé le serveur X (par exemple macOS: XQuartz; Windows: Xming).

Ensuite, pour effectuer le transfert X11 à l'aide de SSH, vous devez ajouter -X à votre commande ssh, par exemple.

ssh -v -X user@Host

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

echo $DISPLAY

Si c'est le cas, avoir un paramètre détaillé pour ssh (-v), recherchez d'éventuels avertissements, par exemple.

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

Dans le cas où vous avez X11 non fiable comme indiqué ci-dessus, alors essayez -Y flag à la place (si vous faites confiance à l'hôte):

ssh -v -Y user@Host

Voir: Que signifie "Avertissement: configuration de transfert X11 non approuvée: données de clé xauth non générées" signifie lorsque vous utilisez Ssh avec -X?

Si vous avez avertissement: aucune donnée xauth, vous pouvez essayer de générer un nouveau .Xauthority fichier, par exemple.

xauth generate :0 . trusted
xauth list

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

Si vous avez un avertissement différent de celui ci-dessus, suivez les autres indices.

43
kenorb

Le correctif consiste à 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/

21
Ace

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

  • Première

Installez tous les éléments suivants. Sur Windows, installez Xming. Sur Ubuntu dans le terminal, utilisez Sudo apt install à installer ssh xauth xorg.

Sudo apt install ssh xauth xorg
  • Seconde

Accédez au dossier contenant ssh_config fichier, le mien est /etc/ssh.

  • Troisième

Éditer ssh_config en tant qu'administrateur (USE Sudo). À l'intérieur ssh_config, supprimez le hachage # dans les lignes ForwardAgent, ForwardX11, ForwardX11Trusted et définissez les arguments correspondants sur yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
  • Forth

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

# /etc/ssh/ssh_config

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

Maintenant que nous avons terminé l'édition ssh_config fichier, enregistrez-le lorsque nous quittons l'éditeur. Maintenant, allez dans le dossier ~ ou $HOME, ajouter export DISPLAY=localhost:0 à ton .bashrc fichier et enregistrez-le.

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

On a presque fini. Redémarrez votre shell bash, ouvrez votre programme Xming et utilisez ssh -X yourusername@yourhost. Profitez ensuite de l'environnement GUI.

ssh -X yourusername@yourhost

Le problème est également dans le sous-système Ubuntu sous Windows, et le lien est à

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

5
DestinyOne

Ajouter X11UseLocalhost no à /etc/ssh/sshd_config et redémarrez le serveur SSH.

Si vous n'obtenez aucun AFFICHAGE, vérifiez si xauth est installé correctement, puis réessayez.

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

4
stephen cooke

Pour moi, le problème était dans nodev option de montage 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.

1
yakovpol

Pour compléter les excellentes réponses précédentes (configuration de ~/.ssh/config et vérifier si la variable d'environnement DISPLAY est définie sur le client, en configurant /etc/ssh/sshd_config et en installant xauth sur le serveur), assurez-vous également que xterm est installé sur le client, par ex.

Sudo apt-get install xterm
1
Aliz Rao

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 que j'essayais de ssh en a cassé le verrou sur xauth. Déconnexion de la session ssh après l'émission de xauth -b puis me reconnecter m'a finalement permis de réussir echo $DISPLAY. Essayez certainement ceci avant de recréer .Xauthority

1
Barton Chittenden

X11Forwarding doit être défini sur le serveur SSH (dans votre cas, la boîte Ubuntu) dans son sshd_config, et vous devez autoriser le transfert de X11 pour le client SSH (votre boîte Fedora) en passant -X option ou modifier le ssh_config fichier pour ajouter le ForwardX11 défaut.

1
Caleb