web-dev-qa-db-ja.com

ssh -Xを使用する場合、X11接続は異なる認証プロトコルを使用します

サーバーの1つでXアプリケーションを使用できません。 （同じクライアントが他のサーバーへの接続に成功するため、問題はクライアント側にありません）。

ssh -vvv -Y -4 jet（-Xの代わりに-Yでも試してみましたが、同じ問題です）を使用してIPv4を強制します（これにより、以前のエラーはすでに解決されています）。しかし、Xを必要とするアプリケーションを起動すると、次のようになります。

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は私に

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

echo $DISPLAYは私に

JET:10.0

だから私はこのディスプレイ用のクッキーを持っています。

サーバー上のSSHバージョンは次のとおりです。

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

ウェブ上で見つかったさまざまなソリューションから、次のようなものがありました

xauth generate $DISPLAY MIT-MAGIC-COOKIE-1

ただし、このコマンドを実行すると、Xプログラムを実行した場合と同じエラーが発生します（直前にrm ~/.Xauthorityを実行した場合でも）。

私はsshの後でsudoしたことはありません、私は秘密鍵を介して認証します。私のサーバーはCentO上にあり、次のsshサーバー構成がありますSudo 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

これを引き起こす可能性のあるものについてのヒントはありますか？

sshxorgxauth
5
jolivier

以下は私にとって問題を解決しました。 ssh-x11-not-working by azat ：

Ssh X転送が機能しなかった理由は、_/etc/ssh/sshrc_構成ファイルがあるためです。

sshd(8)のマニュアルページの終わりには次のように記載されています。

 〜/ .ssh/rcが存在する場合、
はそれを実行します。それ以外の場合、/ etc/ssh/sshrcが存在する場合は、それを実行します。それ以外の場合はxauth 
を実行します

そこで、サーバー側の_/etc/ssh/sshrc_（これもsshdのマニュアルページから）に次のコマンドを追加します。

_    # 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
_

そしてそれはうまくいきます！

注：sshrcの例では、2セットのバッククォートが明確になるように編集されています。コピーするときは注意してください！

5
Heinrich Hartmann

ここでは暗闇の中で写真を撮っていますが、xauthの問題が発生しているため、信頼できるX11転送に関係している可能性があります。 ssh -vvv -X -4 jetを介して確立されたssh接続から同じ手順を実行しようとしましたか？

1
Anthony DiSanti