SSH XForwarding schlägt fehl - xauth falscher Anzeigename


9

Ich versuche, XForwarding über ssh einzurichten, aber es schlägt fehl. Das gleiche Ergebnis tritt auf, wenn ich das Argument -X oder -Y für ssh verwende. Den Fehler bekomme ich.

a@ASUS-N53SM:~$ ssh -X -p 6623 pinker@192.168.0.200
pinker@192.168.0.200'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".

In der Client-Datei ~ / .ssh / config

ForwardX11 yes

In der Client-Datei / etc / ssh / ssh_config (Kommentare entfernt).

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

In der Serverdatei / etc / ssh / sshd_config (Kommentare entfernt).

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

Ich habe diese ähnliche Frage gefunden , aber keine der Antworten funktioniert.

AKTUALISIEREN:

Auf dem Server habe ich der Datei / etc / hosts hinzugefügt.

127.0.0.1       pinker-server

Auf dem Server habe ich das Paket installiert xbase-clients. Auf der SSH - Verbindung echo $DISPLAYgibt :0.0.

Jetzt bekomme ich einen neuen Fehler.

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".

Antworten:



5

Jedes Mal, wenn ich auf ein SSH-Problem stoße, führe ich den Befehl fast sofort erneut aus, wobei ausführlicheres Messaging aktiviert ist. Ich verwende diese Technik gerne, um die Protokolldatei auf dem Server zu sammeln, auf dem ich ausgeführt werde ssh. Wenn Sie weitere Details benötigen, fügen Sie einfach weitere -vSchalter hinzu (maximal 3).

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

X11-Verbindung wegen falscher Authentifizierung abgelehnt.

Diese Meldung weist fast immer auf ein Berechtigungsproblem mit Ihrer .XauthorityDatei hin. Sie können entweder das vorhandene vorübergehend aus dem Weg räumen oder versuchen, dessen Besitz und Berechtigungen zu reparieren.

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

Wenn das Problem durch einen dieser Vorgänge nicht behoben wird, können Sie versuchen, die xauthmagischen Cookies selbst zu diagnostizieren .

als lokaler Benutzer, der ssh ausführt

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

als pinker auf server

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

Fügen Sie dann den Schlüssel manuell hinzu:

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

Verweise


4

Dieser Fehler tritt auf, wenn der Remotecomputer seinen eigenen Hostnamen nicht kennt oder einen falschen Hostnamen mit 127.0.1.1 verknüpft ist (HINWEIS: Nicht 127.0.0.1, der immer in localhost aufgelöst werden sollte).

Stellen Sie zur Korrektur sicher, dass der Eintrag in / etc / hosts für 127.0.1.1 mit dem vollqualifizierten Domänennamen und dem kurzen Hostnamen des Computers übereinstimmt.


Vielen Dank, genau das war bei mir auf meinem OpenBSD 5.9-Desktop (aktuell) der Fall.
Jason Robinson

Ein guter Hinweis darauf, dass dies der Fall ist, ist, wenn "xauth list" zwei unterschiedliche Hostnamen anzeigt. root @ sdi-playout: ~ # xauth liste ubuntu-NANOCOM-BT / unix: 1 MIT-MAGIC-COOKIE-1 ... sdi-playout / unix: 0 MIT-MAGIC-COOKIE-1 ...
kevinf

Vielen Dank! Dies hat mir geholfen, den X-Forwarding-Fehler für meinen VPS zu beheben.
llinfeng

1

Ich habe die meisten dieser Informationen von http://openvz.org/X_inside_VE#X_forwarding erhalten

Überprüfen Sie X in SSH

Überprüfen Sie nach der Anmeldung über SSH, ob die X-Weiterleitung funktioniert, indem Sie nach der Umgebungsvariablen DISPLAY suchen:

echo $DISPLAY

Die Antwort sollte so etwas wie sein localhost:8.0

Stellen Sie sicher, dass sshd die X-Weiterleitung zulässt

Bearbeiten /etc/ssh/sshd_configund sicherstellen, dass es hatX11Forwarding yes

Wenn nicht, bearbeiten oder fügen Sie die Zeile mit X11Fordwarding hinzu und starten Sie sshd neu:

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

Dann abmelden und wieder anmelden

Stellen Sie sicher, dass xauth eingerichtet ist

Stellen Sie sicher, dass das xauth-Paket installiert wurde. In Debian ist dies Teil des xbase-clientsPakets.

Es funktioniert immer noch nicht

In der Frage, die ich beantworte, lautet die Fehlermeldung: /usr/bin/xauth: (stdin):1: bad display name "pinker-server:10.0" in "remove" command

Eine mögliche Lösung, die unten vorgeschlagen wird, besteht darin, sicherzustellen, dass die entsprechende Zeile sshd_configwie folgt aussieht:

X11UseLocalhost yes

Es sieht so aus, als würden wir uns der Lösung nähern? Ich habe die obigen Informationen aktualisiert. Vielen Dank.
Rucent88

3
Es ist im Allgemeinen eine schlechte Idee, 127.0.0.1 einen Hostnamen hinzuzufügen.
slm

Ich habe die Antwort bearbeitet, um dies widerzuspiegeln.
Samiam

1

Dieses Problem ist nach dem Gentoo-Upgrade aufgetreten. Diese Seite ist das erste Google-Ergebnis für "Add Display Name Unix in Add Command". Keine der hier beschriebenen Lösungen hat geholfen. Die Problemumgehung ist in der Debian-Fehlerbeschreibung (zweiter Link auf der oben genannten Google-Suchseite) beschrieben:

sethostname any-name-here

Nach der Ausführung von 'sethostname vvk' kann ich mich wie zuvor mit X-Forwarding anmelden. Diese Antwort wird über den Browser eingegeben, der in der ersten richtigen Shell ausgeführt wird, die auf dem Remote-Server angemeldet ist.


0

Für mich funktioniert wie ein Zauber 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,umac-64@openssh.com,hmac-ripemd160

ssh_config

Host *
   ForwardX11trusted yes
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes

Und verwenden

ssh -X remotehost

Natürlich muss der Xorg-Server vollständig installiert sein (mit Gruppeninstallation, gute Idee)


typische sshd config, nichts besonderes.
Vladimir Kunschikov
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.