迷惑な問題があります。
SSH経由で特定のホストにログインすると、次のメッセージが表示されます。
X11 connection rejected because of wrong authentication.
約1分に1回発生し、一見ランダムに3回発生します。どこから出てくるのか分からない。
実際、X11転送には問題はなく、魅力的に動作します。ところがこのメッセージがずっと来て私を狂わせる。
誰でもそれを削除する方法を知っていますか?
私がどこから来たかに関係なく、この問題に直面します。この問題は、Gnomeデスクトップだけでなく、PuTTY、MobaXterm、Cygwinなどを使用するWindowsシステムでも発生します。
もう少し調整した後、原因が監視エージェント(check_mk)であることがわかりました。これは実行中のジョブのいくつかのランタイムパラメータを確認し、このエージェントが監視システムでトリガされるたびに、つまりPostgreSQLの状態を確認するときにこのメッセージが表示されます。プロセスはX11接続を開こうとしましたが失敗しました。その後、転送されたX11セッションを使用しようとすると、メッセージが端末セッションに表示されます。
このメッセージを完全に無効にする方法はありますか?
答え1
興味深いバージョンがありますが、目そしてxマーク有効ですがクロムいいえ。
スナップを利用してChromeをインストールする機能です。
クイックフィックス:
export XAUTHORITY=$HOME/.Xauthority
chromium
もっと見る:
答え2
ディスク容量が不足していないことを確認してください。
dfを実行し、十分なディスク容量があることを確認してください。ディスク容量が足りない場合は、システムから不要なファイルを削除してください。
$ df -h
ファイルシステムにクォータがある場合は、それを超えていないことを確認してください。
$ quota -s
~/.Xauthorityがあなたの所有であることを確認してください。
所有権を見つけるには、次のコマンドを実行します。
$ ls -l ~/.Xauthority
権限の問題を解決するには、chown と chmod を実行します。 [user:group を実際のユーザー名とグループ名に置き換えます]:
$ chown user:group ~/.Xauthority
$ chmod 0600 ~/.Xauthority
X11 SSHD転送が有効になっていることを確認してください
sshd_config ファイルに次の行があることを確認します。
$ grep X11Forwarding /etc/ssh/sshd_config
出力例:
X11Forwarding yes
X11が無効になっている場合は、sshd_cofingに次の行を追加してSSHサーバーを再起動します。
X11Forwarding yes
X11 クライアント転送が有効になっていることを確認してください
ローカルssh_configに次の行があることを確認してください。
Host remote-host.com
ForwardX11 yes
最後に、リモートサーバーにログインし、次のようにMac OS XまたはLinuxデスクトップシステムでX11を実行します。
ssh [email protected]
情報源は次のとおりです。http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-authentication/
お役に立てば幸いです。
答え3
私は同じ問題があり、これは私に役立ちました。 (ノート:これは私の解決策ではありませんが、それを見つけるために苦労したので、ここに再投稿します。オリジナルを閲覧できますここそしてここ)
1. リモートサーバーにログイン
echo $DISPLAY
これで現在のX11モニターが表示されます。
xauth list
コンソールに何も印刷されない場合は、sshがローカルディスプレイにX11認証Cookieを自動的に正しく生成しないことを意味します。
2. 認証クッキーの追加
xauth add $DISPLAY - `mcookie`
これにより、ディスプレイの認証クッキーがxauthに追加されます。
xauth list
モニターが追加されていることを確認してください。
3. クッキーをローカルコンピュータとマージする
xauth nextract ~/xcookie $DISPLAY
exit
場所で:scp user@remote:~/xcookie ~/xcookie
場所で:xauth nmerge ~/xcookie
最後に、リモートサーバーに再度ログインすると問題が解決します。
答え4
SELINUXを適用し、ホームディレクトリが/ homeディレクトリの下にない場合、これは問題です。ターゲットSELINUX設定は、すべてのユーザーのホームディレクトリが/ homeの下にあると想定しているため、ホームディレクトリのSELINUXタイプが正しくないため、xauthは正しく機能しません。編集内容をおすすめしたいのですが、私が見つけた修正は機能しません。この問題を解決するためにSELINUXを許可するように設定しました。正しいラベルを設定することをお勧めします。たとえば、次のようになります。
semanage fcontext -a -e /home <custom_path>
restorecon -R -v <custom_path>