web-dev-qa-db-fra.com

Ssh x11 ne fonctionne pas

J'ai un ordinateur de travail et de travail, l'ordinateur à domicile a une adresse IP statique.

Si je suis SSH de mon ordinateur de travail à mon ordinateur à domicile, la connexion SSH fonctionne, mais les applications X11 ne sont pas affichées.

Dans mon /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_config Au travail:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Mon ~/.ssh/config Au travail:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Mon ~/.Xauthority Au travail:

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

Mon ~/.Xauthority À la maison:

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

mais ça ne marche pas

Après avoir créé 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.

pd. avec -vvv

[. Transfert avec l'entrepoiffage d'authentification. 
 Débogou2: Channel 1: Demande X11-Req Confirmez 1 [. ____] Débug12: Client_session2_Setup: Id 1 [ Channel 1: Demande Pty-Req Confirmer 1 [.____] ...

Lorsque vous essayez de lancer kate:

 débogué1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 [ fd 8 est o_nonblock 
 Débug1: canal 2: nouveau [x11] 
 Débug1: Confirmer x11 [.____] Débug2: x11 Connexion utilise un protocole d'authentification différent. 
 X11 Connexion rejetée parce que de mauvaise authentification. 
 Débogou2: x11 rejeté 2 i0/o0 [.____] Débug12: Channel 2: Lire a échoué [.____] Débug2: Channel 2: Close_read 
 Debug2: Channel 2: Entrée ouverte -> Drain 
 Debug2: Channel 2: Ibuf vide 
 Débugou2: Channel 2: Envoyer eof 
 Débugou 2: Drain de l'entrée -> Fermé 
 Débugou2 : Channel 2: échec de l'écriture [.____] Débug2: canal 2: close_write [.____] debug2: canal 2: sortie ouverte -> fermé 
 Debug2: x11 Fermé 2 I3/O3 [.____] DEBUG2: Channel 2: Envoyer Fermer 
 Débugou2: Channel 2: RCVD Fermer [.____] Débugou: Channel 2: est mort 
 Debug2: canal 2: poubelle 
 Débug1: Channel 2: Gratuit: X11, Nchannel 3 [.____] Débug3: Channel 2: Statut: Les connexions suivantes sont ouvertes: [.____] # 1 Séance client (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 Comme ci-dessus répété environ 7 fois [.____] [.____] Kate: Impossible de se connecter à X Server localhost localhost: 10.0 
 [.____]

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

[.____] azat: ~ $ KDED4 -Version 
 Qt: 4.7.4 [.____] Plate-forme de développement KDE: 4.6.5 (4.6.5) 
 KDE Daemon: $ ID $

Invoquant-tu directement SSH sur une ligne de commande d'une fenêtre de terminal?
Quel terminal utilisez-vous? xterm, gnome-terminal ou?
[.____] Comment avez-vous démarré le terminal en cours d'exécution dans l'environnement X? À partir d'un menu? Hotkey? ou ?

[.____] de l'émulateur de terminal `Yakuake` 
 Manualy Appuyez sur` Ctrl + N` et écrivez des commandes [.____]

Pouvez-vous exécuter Xeyes 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

Appliquez-vous la commande SSH comme le même utilisateur que vous êtes connecté à la session X?
[.____] From the same user

pd

Je télécharge aussi des sources ssh [$ var] et utilisez debug2() Écrivez pourquoi il est indiqué que la version est différente
[.____] Cela voit des cookies, et l'un d'entre eux est vide, un autre est MIT-MAGIC-COOKIE-1

sshx11x11forwarding
15
azat

La Raison SSH X X ne fonctionnait pas, c'est parce que j'ai un fichier de configuration /etc/ssh/sshrc.

La fin de la page sshd(8) Page d'homme indique:

Si ~/.ssh/rc existe, le gère; sinon si /etc/ssh/sshrc existe, le gère; sinon court xauth

Donc, j'ajoute les commandes suivantes à /etc/ssh/sshrc (également à partir de la page SSHD Man) sur le 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!

21
azat

Chaque fois que vous rencontrez des problèmes avec SSH, la première chose à faire est de gérer le client avec le -v Option de fournir cette sortie aux autres à inspecter:

ssh -v user@somewhere

Je vais deviner que le problème est sur votre système local. Comment appelez-vous la commande SSH? Est-ce que vous l'utilisez manuellement dans une coquille? Ou est-il exécuté dans le cadre d'un script? Dans les deux cas, vous voudrez vous assurer que votre système local dispose du jeu d'environnement DISPLAY correctement. Il doit également être réglé correctement sur le côté distant, mais cette valeur sera différente sur le côté distant que le côté local.

D'après ce que vous avez écrit, il semble qu'il soit réglé correctement sur l'hôte distant (et par extension, le transfert X11 est en cours de configuration correctement par SSH). Sur le système distant que 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 une coquille à la fois en faisant écho à la valeur, ainsi que de démarrer une application X de cette coquille ... Vous pouvez toujours utiliser le vénérable xeyes pour ce type de test, bien sûr! :)

D'autre part, si vous appelez la commande SSH à partir d'un script ou attaché à une touche de raccourci, il peut ne pas hériter de l'environnement que vous attendez, alors DISPLAY variable d'environnement sur le côté local pourrait ne pas être défini du tout.

En outre, comme ça sonne comme si vous vous trompiez avec votre .Xauthority Fichier Vous voudrez peut-être le supprimer entièrement, puis vous déconnecter de votre session x et reconnectez-vous de manière à ce qu'il le recevera automatiquement. Il y a rarement un besoin de muck avec votre .Xauthority, essayant donc qui est probablement 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 une coquille, vous ne devez pas avoir besoin de la définir à la main, il doit être hérité de l'environnement qui a commencé votre coquille. Cependant, j'ai vu des configurations de gestionnaire de fenêtres/raccourcies qui ne manipulent pas correctement l'héritage variable d'environnement. Si vous avez du système Linux en marche gnome-session ou kde-session que vous utilisez pour lancer vos coquilles ou vos scripts à partir de vos variables d'environnement X de session doit être réglée correctement comme décrit dans la section 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 "Bash" (le processus parent) crée "Gedit" (processus enfant), le processus enfant hérite de toutes les variables d'environnement et valeurs que le processus parent a eu.

...

Remarque: Dans l'environnement GNOME Graphical Desktop, GNOME-SESSION est le processus parent de tous les processus exécutés sur le bureau. Ce fait (ainsi que 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 de KDE est KDE-SESSION.

[~ # ~] Mise à jour [~ # ~ #]

Merci d'avoir posté la sortie de ssh -vvv. Dans ce cas, la verbosité supplémentaire de -vvv versus juste -v est utile. La sortie de débogage me dit que le transfert X11 est en cours de configuration correctement:

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 le :0 Dans la première ligne me conduit à croire qu'il reste encore une erreur de configuration du côté local de la manière dont vous invoquez SSH. Sur de nombreux systèmes, la valeur par défaut pour DISPLAY est :0.0, ne pas :0. Êtes-vous en quelque sorte réglées la valeur de DISPLAY manuellement vous-même avant d'invoquer la commande SSH?

Plus d'informations sur votre système local et comment vous invoquez la commande SSH serait utile à ce stade.

  • Veuillez fournir votre numéro de distribution et de version Linux.
  • Utilisez-vous un environnement GNOME ou KDE par défaut pour X ou quelque chose d'autre que vous avez personnalisé vous-même?
  • Invoquant-tu directement SSH sur une ligne de commande d'une fenêtre de terminal?
  • Quel terminal utilisez-vous? xterm, gnome-terminal ou?
  • Comment avez-vous démarré le terminal en cours d'exécution dans l'environnement X? À partir d'un menu? Hotkey? ou ?
  • Pouvez-vous exécuter xeyes de la même fenêtre de terminal où le ssh -X échoue?
  • Appliquez-vous la commande SSH comme le même utilisateur que vous êtes connecté à la session X?

Ce dernier article est important. Si vous exécutez SSH comme un autre utilisateur (par exemple, si vous ouvrez 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=:0 Depuis que vous n'avez pas d'autorisations pour vous connecter au serveur X par défaut comme un autre utilisateur (même en tant que root!)

2
aculich

Vos configuries semblent être correctes, mais essayez "SSHX Home" à mesure que Agemen vous a suggéré.

En outre, si tout échoue, essayez ceci:

Après vous SSH sur votre machine à domicile du travail, sur "Accueil" Type:

xauth list

Ensuite, sur "travail", tapez

xauth

Qui vous donnera une invite "xauth>". À partir de là, tapez "Ajouter", puis Copy Coller la sortie de la "liste Xauth", une ligne à la fois (chaque ligne préférée par "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.

1
DictatorBob