☰

「認証が間違っているため X11 接続が拒否されました」をデバッグするにはどうすればいいですか?

tag-icon • tag-icon ssh logging debug x11-forwarding
「認証が間違っているため X11 接続が拒否されました」をデバッグするにはどうすればいいですか?

SSH 経由の X 転送に問題があります。長い間苦労してきましたが、誰も助けてくれないようです。

今は別の方法を取っています。エラーをどのようにデバッグするかを知りたいです。

どのログを確認すればよいですか、どのような追加フラグを設定すればよいですか (-v など)、何に注意すればよいですか?

さらに編集:

Putty でサーバーにログインして を実行しようとするとxeyes、次のメッセージが表示されます。

PuTTY X11 プロキシ: 間違った認証プロトコルを試行しましたエラー: ディスプレイを開けません: localhost:10.0

もし私がxauth generate $DISPLAY以下を取得した場合:

PuTTY X11 プロキシ: 間違った認証プロトコルを試行しましたxauth: (argv):1: ディスプレイ "localhost:10.0" を開けません。

答え1

私の解決策のステップバイステップ：

1) オプション -X リモートホストログイン root でログイン

$ ssh -X[メールアドレス]

2) .Xauthorityファイルが存在するかどうかを確認する

[root@localhost ~]# ls -al
[root@localhost ~]# vim .Xauthority

3) .Xauthorityファイルを他のユーザーのディレクトリにコピーする

[root@localhost ~]# cp .Xauthority /home/oracle/
cp: `/home/oracle/.Xauthority' を上書きしますか? y

4) このファイルの権限を設定する

[root@localhost ~]# chown oracle:oinstall .Xauthority
[root@localhost ~]# chmod 0600 .Xauthority

5) Oracleユーザーでログイン

[root@localhost ~]# su - oracle

6) localhost:10.0 での表示設定

[oracle@localhost ~]$ echo $DISPLAY
ローカルホスト:10.0
[oracle@localhost ~]$ ls -al

7) 存在するxauthクッキーをリストする

[oracle@localhost ~]$ xauthリスト
ローカルホスト.localdomain/unix:11 MIT-MAGIC-COOKIE-1 310f1b02c1080e73059391c193a1881b
ローカルホスト.localdomain/unix:10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb759

8) 追加

[oracle@localhost ~]$ xauth で localhost.localdomain/unix:10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75 を追加します

9) テスト

[oracle@localhost ~]$ xclock

役に立つことを祈ります！@wcaraza

答え2

SSH サーバーにxauthツールがインストールされており、ファイルが書き込み可能であることを確認してください。(作成できる~/.Xauthority限り、ファイルが存在しないことも問題ありません。)xauth

xauth データが更新されているかどうかを確認します。

server$ xauth list

ダミーの xauth データを手動で追加して (これも SSH サーバー上で)、xauth問題が発生するかどうかを確認します (例: ロックファイルを作成できない、または Xauthority ファイル自体を変更できない)。

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

必要に応じて、 で再実行してくださいstrace。

LogLevel DEBUG2サーバー構成 ( /etc/ssh/sshd_config) を設定するか、sshd をデバッグ モードで直接起動して、SSH サービスをデバッグ モードで実行します。

server$ sshd -rddp 12234

(この例では、12234は接続する必要がある一時的な SSH ポートです。空いているポートであればどれでもかまいません。)

答え3

効いてるよ、効いてるよ。ハハハ。

ついに。

それがシステムの問題ではないことがわかった後、テスト ユーザーを追加して (x 転送は「すぐに」機能しました)、.bash* スタートアップ ファイルをコピーして、「壊れた」ユーザーを正常に処理しようと考えました。

どのファイルも違いがなかったので、次にユーザーの .ssh ディレクトリを削除しました。ssh でログインすると、「サーバーがキーを拒否しました」というメッセージが表示されましたが、パスワードを使用してログインできました。ログインすると、x 転送は完璧にできました。

もう一度キーを設定してみて、それが機能するかどうかを確認します。その後、正常に戻ります。

答え4

rm ~/.Xauth*その後再接続します。

これは私にとってはうまくいきました。詳細については詳細

関連情報