SSH XForwarding échoue - xauth mauvais nom d'affichage

9

J'essaie de configurer XForwarding sur ssh, mais cela échoue. Le même résultat se produit que j'utilise l'argument -X ou -Y pour ssh. L'erreur que j'obtiens.

a@ASUS-N53SM:~$ ssh -X -p 6623 [email protected]
[email protected]'s password: 
Last login: Sun Feb  2 18:42:08 2014 from 192.168.0.201
/usr/bin/xauth: (stdin):1:  bad display name "pinker-server:10.0" in "remove" command
/usr/bin/xauth: (stdin):2:  bad display name "pinker-server:10.0" in "add" command
xdpyinfo:  unable to open display "pinker-server:10.0".

Dans le fichier client ~ / .ssh / config

ForwardX11 yes

Dans le fichier client / etc / ssh / ssh_config (commentaires supprimés).

Host *
ForwardX11 yes
ForwardX11Trusted yes
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes 
GSSAPIDelegateCredentials no

Dans le fichier serveur / etc / ssh / sshd_config (commentaires supprimés).

Port 6623
Port 6624
Port 6625
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
X11UseLocalhost no
AllowTcpForwarding yes

J'ai trouvé cette question similaire , mais aucune des réponses ne fonctionne.

MISE À JOUR:

Sur le serveur, j'ai ajouté au fichier / etc / hosts.

127.0.0.1       pinker-server

Sur le serveur, j'ai installé le package xbase-clients. Sur les echo $DISPLAYsorties de connexion ssh :0.0.

Maintenant, je reçois une nouvelle erreur.

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.
xdpyinfo:  unable to open display "pinker-server:10.0".
ssh xforwarding xauth Rucent88
la source

Réponses:

6

Cette erreur se produit lorsque la machine distante ne sait pas que c'est son propre nom d'hôte ou a un nom d'hôte incorrect associé à 127.0.1.1 (REMARQUE: pas 127.0.0.1 qui doit toujours être résolu en localhost).

Pour le corriger, assurez-vous que l'entrée dans / etc / hosts pour 127.0.1.1 correspond au nom de domaine complet de la machine et au nom d'hôte court.

AGB
la source
Merci, c'était exactement le cas pour moi sur mon bureau OpenBSD 5.9 (-current).
Jason Robinson
un bon indice que c'est le cas, est quand "xauth list" montre deux noms d'hôte différents. root @ sdi-playout: ~ # xauth list ubuntu-NANOCOM-BT / unix: 1 MIT-MAGIC-COOKIE-1 ... sdi-playout / unix: 0 MIT-MAGIC-COOKIE-1 ...
kevinf
Merci! Cela m'a aidé à résoudre l'échec de la transmission X pour mon VPS.
llinfeng
5

Chaque fois que je rencontre un problème SSH, je réexécute presque immédiatement la commande avec une messagerie plus verbeuse activée. J'aime utiliser cette technique pour collecter le fichier journal sur le serveur sur lequel je cours ssh. Si vous avez besoin d'obtenir plus de détails, ajoutez simplement plus de -vcommutateurs (le maximum est 3).

$ ssh -v user@remoteserver |& tee /path/to/sshv1.log
-or-
$ ssh -vv user@remoteserver |& tee /path/to/sshv2.log

Connexion X11 rejetée en raison d'une mauvaise authentification.

Ce message indique presque toujours un problème d'autorisations avec votre .Xauthorityfichier. Vous pouvez soit déplacer temporairement l'existant, soit tenter de corriger sa propriété et ses autorisations.

$ chown user:group ~/.Xauthority
$ chmod 0600 ~/.Xauthority

Si le problème n'est pas résolu par l'une de ces opérations, vous pouvez essayer de diagnostiquer les xauthcookies magiques eux-mêmes.

en tant qu'utilisateur local exécutant ssh

$ xauth list
localhost/unix:13 MIT-MAGIC-COOKIE-1 c77169a6fa8139ea36f538e1c72e1b98

en rose sur le serveur

$ xauth
Using authority file /home/pinker/.Xauthority

Ajoutez ensuite la clé manuellement:

xauth> add localhost/unix:13 MIT-MAGIC-COOKIE-1 c77169a6fa8139ea36f538e1c72e1b98

Références

slm
la source
1

J'ai obtenu la plupart de ces informations sur http://openvz.org/X_inside_VE#X_forwarding

Vérifiez X dans SSH

Après la connexion via SSH, vérifiez que le transfert X fonctionne en recherchant la variable d'environnement DISPLAY:

echo $DISPLAY

La réponse devrait être quelque chose comme localhost:8.0

Assurez-vous que sshd autorise le transfert X

Modifiez /etc/ssh/sshd_configet assurez-vous qu'il aX11Forwarding yes

Sinon, modifiez ou ajoutez la ligne avec X11Fordwarding puis redémarrez sshd:

service sshd restart( /etc/init.d/sshd restartutilise CentOS 5)

Déconnectez-vous et reconnectez-vous

Assurez-vous que xauth est configuré

Assurez-vous que le package xauth a été installé. Dans Debian, cela fait partie du xbase-clientspaquet.

Ça ne marche toujours pas

Dans la question à laquelle je réponds, le message d'erreur est le suivant: /usr/bin/xauth: (stdin):1: bad display name "pinker-server:10.0" in "remove" command

Une solution possible, suggérée ci-dessous, consiste à s'assurer que la ligne correspondante sshd_configressemble à ceci:

X11UseLocalhost yes
samiam
la source
Il semble que nous puissions nous rapprocher de la solution? J'ai mis à jour les informations ci-dessus. Je vous remercie.
Rucent88
3
C'est généralement une mauvaise idée d'ajouter un nom d'hôte à 127.0.0.1.
slm
J'ai édité la réponse pour refléter cela.
samiam
1

A rencontré ce problème après la mise à niveau de Gentoo. Cette page est le premier résultat google pour 'ajouter le nom d'affichage unix dans la commande add'. Aucune des solutions décrites ici n'a aidé. La solution de contournement est écrite dans la description du bogue Debian (deuxième lien dans la page de recherche Google mentionnée ci-dessus):

sethostname any-name-here

après l'exécution de 'sethostname vvk', je peux me connecter avec X-forwarding comme auparavant. Cette réponse est saisie à partir du navigateur qui s'exécute dans le tout premier shell approprié connecté sur un serveur distant.

Vladimir Kunschikov
la source
0

Pour moi fonctionne comme un charme sshd_config

    Protocol 2
AuthorizedKeysFile  .ssh/authorized_keys
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
X11Forwarding yes
X11UseLocalhost yes
UsePrivilegeSeparation yes      # Default for new installations.
Banner /etc/issue.net
Subsystem   sftp    /usr/libexec/openssh/sftp-server
Ciphers aes256-ctr,aes192-ctr,aes128-ctr,arcfour256
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],hmac-ripemd160

ssh_config

Host *
   ForwardX11trusted yes
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes

Et utilise 

ssh -X remotehost

bien sûr, le serveur Xorg doit être installé complètement (en utilisant groupinstall, bonne idée)

elbarna
la source
config sshd typique, rien de spécial.
Vladimir Kunschikov