Die X11-Verbindung verwendet bei der Verwendung von ssh -X ein anderes Authentifizierungsprotokoll

2896
jolivier

Ich kann keine X-Anwendungen auf einem meiner Server verwenden. (Der gleiche Client kann keine Verbindung zu anderen Servern herstellen, daher liegt das Problem nicht auf der Clientseite).

Ich verbinde mich mit ssh -vvv -Y -4 jet(versuchte auch mit -Xstatt -Y, dasselbe Problem), um IPv4 zu erzwingen (was bereits einen vorherigen Fehler löst). Wenn ich dann eine Anwendung starte, die XI erfordert, erhalte ich Folgendes:

debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 42026 debug2: fd 7 setting O_NONBLOCK debug3: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug2: X11 rejected 1 i0/o0 debug2: channel 1: read failed debug2: channel 1: close_read debug2: channel 1: input open -> drain debug2: channel 1: ibuf empty debug2: channel 1: send eof debug2: channel 1: input drain -> closed debug2: channel 1: write failed debug2: channel 1: close_write debug2: channel 1: output open -> closed debug2: X11 closed 1 i3/o3 debug2: channel 1: send close debug2: channel 1: rcvd close debug2: channel 1: is dead debug2: channel 1: garbage collecting debug1: channel 1: free: x11, nchannels 2 debug3: channel 1: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) #1 x11 (t7 r3 i3/0 o3/0 fd 7/7 cc -1)  xterm Xt error: Can't open display: JET:10.0

xauth list gibt mir

JET:11 MIT-MAGIC-COOKIE-1 8d5c49524a122751ec382da3613c9408 JET:10 MIT-MAGIC-COOKIE-1 6582c5c546ca979132e2d32c64ef481d

echo $DISPLAY gibt mir

JET:10.0

Ich habe also Cookies für diese Anzeige.

Meine SSH-Version auf dem Server ist:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010

Von verschiedenen Lösungen im Internet gab es so etwas 

xauth generate $DISPLAY MIT-MAGIC-COOKIE-1

Wenn ich diesen Befehl ausführen, erhalte ich jedoch die gleiche Fehlermeldung wie beim Ausführen eines X-Programms (auch wenn ich rm ~/.Xauthoritygerade davor bin ).

Ich habe nicht nach ssh sudoed, ich gebe mich über einen privaten Schlüssel ein. Mein Server ist auf CentOs und ich habe die folgende SSH-Serverkonfigurationsudo cat /etc/ssh/sshd_config|egrep -v "^#"

ListenAddress 0.0.0.0 Protocol 2 SyslogFacility AUTHPRIV LogLevel DEBUG3 PasswordAuthentication yes ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost no Subsystem sftp /usr/libexec/openssh/sftp-server

Irgendein Hinweis, was das verursachen könnte?

4
See http://serverfault.com/questions/278743/ssh-x11-not-working I had the same problem, removing ~/.ssh/rc fixed it. vor 10 Jahren 1

2 Antworten auf die Frage

2
Heinrich Hartmann

Im Folgenden wurde das Problem für mich gelöst, vgl. ssh-x11-nicht funktionierend von azat :

Der Grund für das ssh X-Forwarding war nicht, weil ich eine /etc/ssh/sshrcKonfigurationsdatei habe.

Am Ende der sshd(8)Manpage heißt es:

 Wenn ~ / .ssh / rc vorhanden ist, lässt es laufen; Wenn / etc / ssh / sshrc vorhanden ist, wird es ausgeführt. sonst läuft xauth

Also füge ich /etc/ssh/sshrcauf der Serverseite folgende Befehle hinzu (auch von der sshd-Manpage):

 # example sshrc file 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

Und es funktioniert!

Hinweis: Diese Option wurde so bearbeitet, dass die beiden Backticks in der Beispielshrsc klarer dargestellt werden. Seien Sie vorsichtig beim Kopieren!

1
Anthony DiSanti

Ich mache hier nur einen Schuss im Dunkeln, aber da Sie Probleme mit Xauth haben, hat es vielleicht etwas mit der vertrauenswürdigen X11-Weiterleitung zu tun. Hast du versucht, die gleichen Schritte von einer SSH-Verbindung über durchzuführen ssh -vvv -X -4 jet?

Ja, ich habe sowohl -X als auch -Y versucht, in beiden Fällen derselbe Fehler jolivier vor 11 Jahren 0

Verwandte Probleme