Rootとして、コマンドを実行するためにリモートホストに接続しています。 「標準ユーザー」だけが適切なidファイルと正しい.ssh/configを持っているので、最初にユーザーを切り替えます。
su standarduser -c 'ssh -x remotehost ./remotecommand'
コマンドは正常に機能しますが、 "-x"(X11-Forwardingを無効にする)を使用し、/etc/ssh/ssh_config
でX11Forwardsを無効にしたにもかかわらず、エラーメッセージが表示されます。
X11 connection rejected because of wrong authentication.
「standarduser」としてログインしているときにエラーメッセージが表示されません。
コマンドをcronジョブファイルに統合したいので、これは非常に迷惑です。エラーメッセージがルートの.XAuthファイルの誤った認証を参照していることを理解していますが、X11経由で接続することすらしていません。
「ssh -x」がX11接続を無効にせず、エラーメッセージをスローしないのはなぜですか?
[〜#〜] update [〜#〜]:メッセージは、ローカルマシン自体(画面なし)で上記のコマンドを使用したときに、画面内でログインした場合にのみ表示されます。エラーメッセージが表示されないので、cronでも問題ありません。
また、同じコマンドを-v
で開始しましたが、SSHからのステータス情報の前であっても、驚くほど最初にエラーメッセージが表示されました。
root@localhost:~# su standarduser -c 'ssh -x remotehost ./remotecommand'
X11 connection rejected because of wrong authentication.
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013
これは私自身を問題に導きました、それはエラーメッセージを投げているssh
ではなく、それはsu
です:
root@localhost:~# su standarduser -c 'echo Hi'
X11 connection rejected because of wrong authentication.
Hi
screen
内でのみこのエラーが発生するのはなぜですか?このエラーメッセージを無効にするにはどうすればよいですか?
ルートには、standarduser
が持っている.Xauthority
のX11 マジックCookie が不足しているようです。これを修正する方法は次のとおりです。
SHORT VERSION(thanks to @ bmaupin )
standarduser@localhost:~$ xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
standarduser@localhost:~$ Sudo su
root@localhost:~$ xauth add `cat /tmp/xauth`
注意:バッククォートをチェックしてください!引用符で置き換えることはできません! 2番目のコマンドを続行するには、Sudo
をインストールする必要があります!
オリジナルロングバージョン
問題を修正するには、最初にstandarduser
が使用するディスプレイ番号を検出します。
standarduser@localhost:~$ echo $DISPLAY
localhost:21.0
この場合は21.0
です。次に、standarduser
のCookieリストを表示します。
standarduser@localhost:~$ xauth list
localhost/unix:1 MIT-MAGIC-COOKIE-1 51a3801fd7776704575752f09015c61d
localhost/unix:21 MIT-MAGIC-COOKIE-1 0ba2913f8d9df0ee9eda295cad7b104f
localhost/unix:22 MIT-MAGIC-COOKIE-1 22ba6595c270f20f6315c53e27958dfe
localhost/unix:20 MIT-MAGIC-COOKIE-1 267f68b51726a8a381cfc10c91783a13
21.0
ディスプレイのCookieはリストの2番目であり、104f
で終わります。
最後に、この特定のCookieをルートの.Xauthority
に追加します。 rootとしてログインし、以下を実行します。
root@localhost:~$ xauth add localhost/unix:21 MIT-MAGIC-COOKIE-1 0ba2913f8d9df0ee9eda295cad7b104f
これは、Bashスクリプトまたはsu
で別のユーザーとしてscreen
を実行した場合のX11 connection rejected because of wrong authentication
エラーを軽減する方法です。
インスピレーションを与えてくれた this guy に感謝します。
より簡単な解決策:
1.- ssh user@Host
2.- $ Sudo su
3.- # xauth merge /home/user/.Xauthority
それで全部です
もちろん $DISPLAY
変数を設定する必要があります。
私のニーズは少し違っていたので、少し違う解決策を思いつきました。 X11アプリを別のユーザー(root以外)として実行する機能が必要でした。 CentOSを実行しているため、ubuntuの幸運な犬がXauthマジックを実行するような甘いgksudoツールを持っていません。
ログインしてユーザーを切り替え、アプリを実行するだけのカスタムスクリプトを作成したくありませんでした。それは少し不必要に思えます。
ステップ1:
$ XAUTHORITYがSudoセッション間で実行されることを許可します。
/ etc/sudoersの残りのenv_keepステートメントの下に次の行を追加します。
Defaults env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
ステップ2:
ターゲットユーザーが.Xauthorityを読み取ることができるようにします(そうですね、セキュリティを叫んでください! rootとしてコマンドを実行する機能だけが必要な場合は、これをスキップできます。
ターゲットユーザーは私と同じグループを共有しているので、グループの読み取り権限をオンにします。
$ chmod g+r user ~/.Xauthority
ステップ3:
CentOSは、デフォルトでは$ XAUTHORITYの値を設定しません。プロファイルに行を追加します(私は〜/ .bash_profileです):
export XAUTHORITY=$HOME/.Xauthority
それでおしまい。これ以上の調整は必要ありません。 PolicyKitを機能させるために.XMLを作成する必要はありません。ログインごとに実行中のスクリプトはありません。 xauthをコピーするためにSudoを2回実行する必要はありません。ここからは、簡単に次のことができます。
$ Sudo -u user xcalc
MobaXTermでうまく動作します。
ターゲットユーザーに完全に切り替える必要があります。つまり、「-
"とsu
(su - standarduser ...
)。そうでない場合、ルートのXのものは環境内でドラッグされます。
私の場合、そのエラーが発生したとき、暗号化されたユーザーディレクトリがありました。 ecrypt-mount-private
を呼び出した後、エラーが解消され、X11転送を続行できました。
ホームフォルダーが暗号化されているかどうかを判断するには、これを試してみてください( この回答 に従って):ls -A /home
。 .ecryptfs
フォルダーが表示される場合は、ホームディレクトリが暗号化されている可能性があります。その場合は、回答の最初に置いたコマンドを実行してみてください。
私は頻繁にルートスカッシュされたネットワークファイル共有をルートにするので、上記の解決策はどれもうまくいきませんでした。 (xubuntu 14.04)。私のシステムで動作する次のスクリプトをまとめました。それはあなたのもので働くかもしれません。もう一度、そうではないかもしれませんが、無料で試すことができます...
-Yオプションを使用してsshしたと仮定します。
#!/bin/bash
if [[ $DISPLAY =~ localhost(:[[:digit:]]+) ]] ;then
port=${BASH_REMATCH[1]}
else
echo "Unexpected DISPLAY $DISPLAY"
exit 1
fi
h=$(hostname)
cookie=$(xauth list|grep $h.*$port)
Sudo -i xauth -i add $cookie
Sudo -i $*