web-dev-qa-db-fra.com

ssh X11 forwarding ne fonctionnera pas

J'ai essayé de faire fonctionner la redirection de port X11 à partir de mon ordinateur portable. Je n'arrive pas à comprendre pourquoi ça ne marche pas.

Je reçois ce message lorsque j'essaie de lancer xterm:

X11 connection rejected because of wrong authentication.
xterm Xt error: Can't open display: localhost:10.0

Je ne sais pas si c'est lié ou non, mais quand je me connecte, je reçois ce message:

/usr/bin/xauth:  timeout in locking authority file /home/sphillips/.Xauthority

Je me suis demandé si le problème est que mon utilisateur local sur mon ordinateur portable est skp et que le nom d'utilisateur sur ce serveur est sphillips. J'ai réussi à faire en sorte que la redirection X11 fonctionne avec mes autres ordinateurs utilisant le même identifiant skp.

De plus, la redirection de port X11 fonctionne à partir d'une machine Windows utilisant Xming et PuTTY sur le même serveur. Je dois configurer manuellement la variable DISPLAY sur l'adresse IP et afficher 0,0, mais cela fonctionne.

J'ai exécuté un xhost + sur ma machine pour tenter de contourner les problèmes de sécurité. Cela n'a toujours pas fonctionné.

Sur le serveur, je vérifie la configuration:

$ Sudo grep X11Forwarding /etc/ssh/sshd_config
#X11Forwarding no
X11Forwarding yes
#   X11Forwarding no

Et sur ma machine aussi:

$ Sudo grep X11Forwarding /etc/ssh/sshd_config
[Sudo] password for skp: 
#X11Forwarding no
X11Forwarding yes
#   X11Forwarding no

Mon serveur est RedHat Enterprise Linux 6 et mon ordinateur portable est Fedora 15.

Est-ce que quelqu'un peut me donner des idées sur la manière de faire fonctionner la redirection SSH X11 depuis mon ordinateur portable?

sshx11-forwarding
13
digitaleagle

J'ai enfin trouvé la réponse (au moins pour ma situation)! Le problème était SELinux. J'ai désactivé SELinux et cela a fonctionné sans problème.

Si vous êtes intéressé par tous les détails sanglants, vous pouvez lire à ce sujet sur mon blog , mais laissez-moi détailler les faits pertinents ici ...

Sur la machine distante, j’ai utilisé dmesg pour afficher les messages de journalisation:

dmesg | tail

J'ai trouvé un certain nombre de messages comme celui-ci:

type=1400 audit(1332520527.110:51337): avc: denied { read } for pid=25240 comm="sshd" name="authorized_keys" dev=dm-5 ino=167 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file

Vous pouvez vérifier le statut de SELinux avec cette commande:

$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: targeted

Vous pouvez le faire passer en mode permissif avec cette commande:

setenforce 0

Pour plus d'informations sur SELinux, j'ai trouvé Le guide de Red Hat utile . En outre, pour d’autres problèmes liés à SSH, j’ai trouvé le blog de David utile pour que la journalisation aide.

Pour moi, après cela, mon transfert X11 a commencé à fonctionner sans problème.

SELinux empêchait plusieurs autres choses différentes. Il n'a pas pu créer les fichiers nécessaires pour que l'authentification par clé fonctionne. J'ai aussi trouvé que cela empêchait ssh-keygen de créer des clés dans le répertoire personnel.

12
digitaleagle

J'ai eu le même problème sur un conteneur Debian OpenVZ et le problème semblait provenir de mon fichier/etc/hosts où "localhost" était affecté à l'IP du LAN, pas à 127.0.0.1.

Avant :

192.168.0.15  dagi dagi.domain.net localhost localhost.localdomain

Après :

192.168.0.15  dagi dagi.domain.net
127.0.0.1     localhost localhost.localdomain

Après cela, ssh -X et ssh -Y ont fonctionné comme un charme sans même redémarrer sshd.

2
Chl

Je suis tombé dessus aussi. Mais dans mon cas, c’est parce que j’ai retiré le support IPv6 il ya quelques jours. Je suis ensuite tombé sur ce fil en expliquant comment s'assurer que sshd utilise uniquement IPv4.

Voici comment je l'ai fait, ajoutez ceci:

AddressFamily inet

dans votre fichier ssh_config (sous Ubuntu/etc/ssh/sshd_config) et faites sshd recharger sa configuration (kill -SIGHUP pid-of-sshd).

2
gkephorus

Outre la réponse ci-dessus de @Chl, j’avais également un fichier corrompu ~/.Xauthority.

Pour une raison quelconque, il appartenait à root même sous mon répertoire personnel. Je devais donc Sudo -s et ensuite supprimé.

Puis recréez-le avec touch ~/.Xauthority

Après cela, la redirection a fonctionné pour moi sous Ubuntu 14.04.

1
Deesbek
Sudo grep X11Forwarding /etc/ssh/sshd_config

X11Forwarding yes 
#sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: targeted
#You can turn it to permissive mode with this command:
#setenforce 0
0
nagaraju