SSH X11 ne fonctionne pas

J'ai un ordinateur personnel et professionnel, l'ordinateur personnel a une adresse IP statique.

Si je passe de mon ordinateur professionnel à mon ordinateur personnel, la connexion ssh fonctionne mais les applications X11 ne sont pas affichées.

Chez moi /etc/ssh/sshd_configà la maison:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Au travail, j'ai essayé les commandes suivantes:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Mon /etc/ssh/ssh_configau travail:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Mon ~/.ssh/configau travail:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Mon ~/.Xauthorityau travail:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Mon ~/.Xauthoritychez moi:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Mais ça ne marche pas

Après avoir établi une connexion ssh à la maison:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

J'utilise iptablesà la maison, mais j'ai autorisé le port 22. Selon ce que j'ai lu, c'est tout ce dont j'ai besoin.

UPD. Avec-vvv

...
debug2: début de rappel
debug2: x11_get_proto: / usr / bin / xauth liste: 0 2> / dev / null
debug1: demande de redirection X11 avec usurpation d'authentification.
debug2: canal 1: demande x11-req confirm 1
debug2: client_session2_setup: id 1
debug2: paramètre fd 3 TCP_NODELAY
debug2: canal 1: demande pty-req confirm 1
...

Quand essayez de lancer kate:

debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: demande de 127.0.0.1 55486
debug2: paramètre fd 8 O_NONBLOCK
debug3: fd 8 est O_NONBLOCK
debug1: canal 2: nouveau [x11]
debug1: confirme x11
debug2: la connexion X11 utilise un protocole d'authentification différent.
Connexion X11 rejetée en raison d'une mauvaise authentification.
debug2: X11 a rejeté 2 i0 / o0
debug2: canal 2: échec de lecture
debug2: canal 2: close_read
debug2: canal 2: entrée ouverte -> drain
debug2: canal 2: ibuf vide
debug2: canal 2: envoyer eof
debug2: canal 2: drain d'entrée -> fermé
debug2: canal 2: échec d'écriture
debug2: canal 2: close_write
debug2: canal 2: sortie ouverte -> fermée
debug2: X11 fermé 2 i3 / o3
debug2: canal 2: envoyer fermer
debug2: canal 2: fermeture du rcvd
debug2: canal 2: est mort
debug2: canal 2: garbage collection
debug1: canal 2: gratuit: x11, nchannels 3
debug3: canal 2: état: Les connexions suivantes sont ouvertes:
  Session client # 1 (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Le même que ci-dessus répéter environ 7 fois

kate: impossible de se connecter au serveur X localhost: 10.0

UPD2 Veuillez fournir votre distribution Linux et votre numéro de version.
Utilisez-vous un environnement GNOME ou KDE par défaut pour X ou autre chose que vous avez personnalisé vous-même?

azat: ~ $ kded4 -version
Qt: 4.7.4
Plateforme de développement KDE: 4.6.5 (4.6.5)
Démon KDE: $ Id $

Invoquez-vous ssh directement sur une ligne de commande à partir d'une fenêtre de terminal?
Quel terminal utilisez-vous? xterm, gnome-terminal ou?
Comment avez-vous démarré le terminal fonctionnant dans l'environnement X? À partir d'un menu? Raccourci clavier? ou ?

De l'émulateur de terminal `yakuake`
Appuyez manuellement sur «Ctrl + N» et écrivez les commandes

Pouvez-vous exécuter xeyes à partir de la même fenêtre de terminal où le ssh -X échoue?

`xeyes` - n'est pas installé
Mais `kate` ou une autre application kde est en cours d'exécution

Invoquez-vous la commande ssh comme le même utilisateur que celui avec lequel vous êtes connecté à la session X?
From the same user

UPD3

Je télécharge également des sshsources, et debug2()j'écris pourquoi je signale que la version est différente.Il
voit des cookies, et l'un d'eux est vide, un autre estMIT-MAGIC-COOKIE-1

La raison pour laquelle le transfert ssh X ne fonctionnait pas était parce que j'ai un /etc/ssh/sshrcfichier de configuration.

La fin de la sshd(8)page de manuel indique:

S'il ~/.ssh/rcexiste, l'exécute; sinon s'il /etc/ssh/sshrcexiste, l'exécute; sinon exécute xauth

J'ajoute donc les commandes suivantes /etc/ssh/sshrc(également à partir de la page de manuel sshd) côté serveur:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

Et il fonctionne!

Chaque fois que vous rencontrez des problèmes avec ssh, la première chose que vous devez faire est d'exécuter le client avec la -vpossibilité de fournir cette sortie à d'autres pour inspection:

ssh -v user@somewhere

Je vais deviner que le problème est sur votre système local. Comment invoquez-vous la commande ssh? Le lancez-vous manuellement dans un shell? Ou est-il exécuté dans le cadre d'un script? Dans les deux cas, vous voudrez vous assurer que votre système local a l' DISPLAYenvironnement correctement défini. Il doit également être correctement défini du côté distant, mais cette valeur sera différente du côté distant que du côté local.

D'après ce que vous avez écrit, il semble qu'il soit correctement configuré sur l'hôte distant (et par extension, le transfert X11 est correctement configuré par ssh). Sur le système distant, vous avez:

$ echo $DISPLAY
localhost:10.0

Qu'est-ce que cela montre du côté local? Cela devrait être facile à vérifier si vous êtes dans un shell à la fois en faisant écho à la valeur, ainsi qu'en démarrant une application X à partir de ce shell ... vous pouvez toujours utiliser le vénérable xeyespour ce type de test, bien sûr! :)

D'un autre côté, si vous invoquez la commande ssh à partir d'un script ou si vous l'attachez à un raccourci clavier, il se peut qu'elle n'hérite pas de l'environnement que vous attendez, donc DISPLAYla variable d'environnement du côté local peut ne pas être définie du tout.

De plus, comme il semble que vous ayez manipulé votre .Xauthorityfichier, vous pouvez le supprimer entièrement, puis déconnectez-vous de votre session X et reconnectez-vous pour qu'il le recrée automatiquement. Il est rarement nécessaire de vous embrouiller .Xauthority, alors essayer est probablement juste une mesure désespérée qui n'aidera pas.

Ce que vous devriez voir du côté local est:

$ echo $DISPLAY
:0.0

Sur un système correctement configuré, si vous ouvrez un shell, vous ne devriez pas avoir besoin de le définir à la main, il devrait être hérité de l'environnement qui a démarré votre shell. Cependant, j'ai vu des configurations de gestionnaire de fenêtres / raccourcis clavier qui ne gèrent pas correctement l'héritage des variables d'environnement. Si vous avez un système Linux en cours d'exécution gnome-sessionou kde-sessionque vous utilisez pour lancer vos shells ou scripts à partir de, alors vos variables d'environnement de session X doivent être définies correctement comme décrit dans la documentation Ubuntu sur l'héritage des variables d'environnement :

Lorsqu'un processus parent crée un processus enfant, par exemple lorsque nous exécutons la commande "gedit" à partir du terminal et que "bash" (le processus parent) crée "gedit" (le processus enfant), le processus enfant hérite de toutes les variables d'environnement et valeurs du processus parent.

...

Remarque: dans l'environnement de bureau graphique Gnome, gnome-session est le processus parent de tous les processus en cours d'exécution sur le bureau. Ce fait (avec le principe d'héritage) est la clé de notre capacité à influencer puissamment le fonctionnement de notre bureau avec des variables d'environnement. Le processus équivalent dans KDE est kde-session.

MIS À JOUR

Merci d'avoir publié la sortie de ssh -vvv. Dans ce cas, la verbosité supplémentaire de -vvvversus juste -vest utile. La sortie de débogage me dit que le transfert X11 est correctement configuré:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Mais la :0première ligne m'amène à croire qu'il y a toujours une erreur de configuration du côté local dans la façon dont vous invoquez ssh. Sur de nombreux systèmes, la valeur par défaut de DISPLAYest :0.0, non :0. Définissez-vous vous-même la valeur de DISPLAYmanuellement avant d'appeler la commande ssh?

Plus d'informations sur votre système local et comment vous appelez la commande ssh seraient utiles à ce stade.

• Veuillez fournir votre distribution Linux et votre numéro de version.
• Utilisez-vous un environnement GNOME ou KDE par défaut pour X ou autre chose que vous avez personnalisé vous-même?
• Invoquez-vous ssh directement sur une ligne de commande à partir d'une fenêtre de terminal?
• Quel terminal utilisez-vous? xterm, gnome-terminal ou?
• Comment avez-vous démarré le terminal fonctionnant dans l'environnement X? À partir d'un menu? Raccourci clavier? ou ?
• Pouvez-vous exécuter à xeyespartir de la même fenêtre de terminal où l' ssh -Xéchec?
• Invoquez-vous la commande ssh comme le même utilisateur que celui avec lequel vous êtes connecté à la session X?

Ce dernier élément est important. Si vous exécutez ssh en tant qu'un autre utilisateur (par exemple, si vous avez ouvert une fenêtre de terminal racine au lieu d'une fenêtre de terminal utilisateur), vous rencontrerez ce problème même si vous définissez explicitement DISPLAY=:0car vous n'avez pas les autorisations pour se connecter au serveur X par défaut en tant qu'autre utilisateur (même en tant que root!)

Vos configurations semblent correctes, mais essayez "ssh -X home" comme l'a suggéré Agemen.

En outre, si tout le reste échoue, essayez ceci:

Après que vous ssh vers votre machine à domicile du travail, sur le type "home":

xauth list

Ensuite, sur "travail", tapez

xauth

Ce qui vous donnera une invite "xauth>". De là, tapez "ajouter", puis copiez et collez la sortie de la "liste xauth", une ligne à la fois (chaque ligne précédée de "ajouter"). Par exemple:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Faites le nous savoir.

Je ne comprends pas clairement si vous souhaitez afficher vos applications distantes sur votre écran local ( work), ou si vous souhaitez les afficher sur le système distant ( home).

Dans le premier cas, je pense que cela ssh -X hostdevrait suffire, sans avoir besoin d'utiliser xhost.

Dans le second cas, le système où vous devez utiliser xhost est home, et ce n'est pas suffisant, vous devez également exporter la variable d'affichage.

xhost +work
export DISPLAY=:0.0

Je ne suis pas totalement sûr de ce que vous voulez faire ... et comme je ne sais pas quelles différences existent entre votre système et le mien, d'une part, et la configuration exacte nécessaire pour votre cas d'autre part (comme Je ne suis pas spécialiste ^ _ ^). J'espère que cela vous aidera à certains égards, car ces configurations ont également fonctionné pour moi.