回答:
これらのメッセージは、SSHオプションのみを使用して、3つの方法のうち1つで削除できます。いつでもメッセージを送信すること/dev/null
もできますが、これらのメソッドは、単にメッセージをトラップおよびダンプするのではなく、設定によってメッセージを処理しようとします。
リモーティング先のサーバーは、インストールされていない.Xauthority
ため、ユーザーのファイルにエントリを作成できないという苦情を言っていますxauth
。したがって、各サーバーにインストールして、この迷惑なメッセージを取り除くことができます。
Fedora 19ではxauth
、次のようにインストールします。
$ sudo yum install xorg-x11-xauth
その後ssh
、サーバーに.Xauthority
アクセスしようとすると、ユーザーのファイルにエントリが作成されているというメッセージが表示されます。
$ ssh root@server
/usr/bin/xauth: creating new authority file /root/.Xauthority
$
その後のログインでは、このメッセージは表示されなくなります。
ssh
SSHパラメータForwardX11を含めることにより、X11転送を有効にしないようにクライアントに指示できます。
$ ssh -o ForwardX11=no root@server
-x
スイッチでも同じことができます。
$ ssh -x root@server
これはこのメッセージを一時的に無効にするだけですがxauth
、リモートサーバーにインストールできない、またはインストールしたくない場合に適したオプションです。
通常はこれがデフォルトですが、そうでない場合はsshd
、X11Forwardingがオフになるようにサーバーをセットアップできます/etc/ssh/sshd_config
。
X11Forwarding no
X11Forwarding
ほとんどのサーバーで頻繁にオンにしたいが、X11....
警告を見たくないので、私は通常#2を使用する3つの方法のうち
ほとんどの場合、これらのメッセージは表示されません。これらは通常、$HOME/.ssh/config
ファイルの上部に次のエントリがある場合にのみ表示されます。
ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes
GatewayPorts yes
したがって、最終的にこれらのX11..
メッセージの生成を駆動するのはこのセットアップです。したがってForwardX11 yes
、デフォルトでonを使用する場合は、方法#2が最も適切に思えますが、ssh
クライアントの観点から特定の接続に対して選択的に無効にします。
ForwardX11 yes
常にonで実行することはお勧めしません。したがって、可能な限り最も安全な方法でSSH接続を操作する場合は、次のことを行うのが最善です。
ForwardX11 yes
でください$HOME/.ssh/config
ssh -X user@server
X11Forwarding
、サーバーで完全に無効にして、許可されないようにしますクライアントを冗長モード(ssh -v user@host
)で実行すると、
debug1: Remote: No xauth program; cannot forward with spoofing.
しかし、xauth
実際にサーバにインストールされている、それはおそらくあるためのsshdを探しXAUTH間違った場所にある実行ファイル(は/ usr / X11R6 / binに/ XAUTH通常)。設定することで修正できます
XAuthLocation /usr/bin/xauth
で、/ etc / sshd / sshd_configファイル(または任意のサーバーを用いて構成されています)。
すでにここにある優れた回答のすべてに加えてForwardX11
、ホストごとに構成できるため、server
このように失敗しただけの場合~/.ssh/config
は、次の形式のエントリをファイルに追加できます。
Host server server.domain.dom
ForwardX11 no
このようなエントリを、構成セット全体のエイリアスとして使用することもできます
Host my.server
HostName server.domain.dom
User user
Port 1234
ForwardX11 no
これは、SSHとSCPのオートコンプリートサーバー名を設定している場合に特に便利です。
sshd-xauth
10年近く前のバグに遭遇した後、この質問に出会いました。2つのソリューションが報告されています。1つ目はバイパスxauth
、2つ目はバグに対処します。
解決策1-xauthをバイパスする
リモート/etc/ssh/sshd_config
:
X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes
リモート~/.Xauthority
が空か、存在しません
ローカルで:
Xephyr -ac -screen 1280x800 -br -reset :2 &
DISPLAY=:2 ssh -fR 6010:/tmp/.X11-unix/X2 user@remote "DISPLAY=:10 xeyes"
テストでは、ローカルはUbuntu 18.05を実行し、リモートはDebian Jesseを実行していました。
また、このソリューションを別の質問への回答として投稿しました。
解決策2- sshd / xauthのバグに対処する
このソリューションは、上記の @systempoetのソリューションに近いものですが、それだけでは十分ではありませんでした。
/etc/ssh/sshd_config
リモートでの変更に加えて:
AddressFamily inet
/etc/hosts
リモートでも変更されました:
::1 localhost ip6-localhost ip6-loopback
どちらかがコメントアウトされている場合、エラーメッセージ
X11 forwarding request failed on channel 0
ssh -X ...
呼び出し後に登場しました。さらに/var/log/auth.log
、エラーが表示されました:
sshd[...]: error: Failed to allocate internet-domain X11 display socket
バグを生成するためのテスト(修正前):
ローカルマシン:
$ Xephyr -ac -screen 1280x800 -br -reset -terminate :2 &
$ DISPLAY=:2 ssh -X user@remote
X11 forwarding request failed on channel 0
/etc/ssh/sshd_config
RHELホストで次の2つのオプションを設定します
X11Forwarding yes
X11UseLocalhost no
sudo /etc/init.d/sshd reload
sudo yum install xauth
ssh -X yourname@rhelbox