web-dev-qa-db-ja.com

SSH経由でXを転送してグラフィックアプリケーションをリモートで実行する方法

私はFedora 14マシンからSSHで接続するUbuntuを実行しているマシンを持っています。 XをUbuntuマシンからFedoraに転送して、グラフィカルプログラムをリモートで実行できるようにしたいと考えています。両方のマシンがLAN上にあります。

-Xオプションを使用すると、SSHでX11転送が有効になりますが、いくつかの手順が欠けているように感じます。

SSHを介してUbuntuマシンからFedoraにXを転送するために必要な手順は何ですか？

sshxorgxforwarding
390
Mr. Shickadance

X11転送は、クライアント側とサーバー側の両方で有効にする必要があります。

クライアント側では、sshへの-X（大文字のX）オプションによりX11転送が有効になり、これを行うことができます ForwardX11 yes の~/.ssh/configを使用したデフォルト（すべての接続または特定の接続）。

サーバー側では、_ X11Forwarding yes に/etc/ssh/sshd_configを指定する必要があります。デフォルトは転送なし（一部のディストリビューションではデフォルトで/etc/ssh/sshd_configをオンにする）であり、ユーザーはこの設定をオーバーライドできないことに注意してください。

xauthプログラムはサーバー側にインストールする必要があります。そこにX11プログラムがある場合、xauthが存在する可能性が非常に高くなります。まれなケースとして、xauthが標準以外の場所にインストールされた場合は、 ~/.ssh/rc （サーバー上！）から呼び出すことができます。

サーバーに環境変数を設定する必要はありません。 DISPLAYとXAUTHORITYは自動的に適切な値に設定されます。 sshを実行し、DISPLAYが設定されていない場合、sshがX11接続を転送していないことを意味します。

SshがX11を転送していることを確認するには、Requesting X11 forwarding出力にssh -v -Xを含む行を確認します。 サーバーはどちらの方法でも応答しないことに注意してください。これは、潜在的な攻撃者から詳細を隠すというセキュリティ上の予防策です。

452
Gilles 'SO- stop being evil'

Ssh経由でX11転送を機能させるには、3つのものが必要です。

  1. X11を転送するようにクライアントを設定する必要があります。
  2. X11転送を許可するようにサーバーを設定する必要があります。
  3. サーバーはX11認証を設定できる必要があります。

＃1と＃2の両方があり、＃3がない場合は、空のDISPLAY環境変数になります。

Soup-to-nuts、これがX11フォワーディングを機能させる方法です。

  1. サーバーで、/ etc/ssh/sshd_configに以下が含まれていることを確認します。

    X11Forwarding yes
X11DisplayOffset 10

    これらの変更が反映されるように、sshdをSIGHUPする必要がある場合があります。

    cat /var/run/sshd.pid | xargs kill -1

  2. サーバーに、xauthがインストールされていることを確認してください。

    belden@skretting:~$ which xauth
/usr/bin/xauth

    Xauthがインストールされていない場合、「空のDISPLAY環境変数」の問題が発生します。

  3. クライアントで、サーバーに接続します。 X11転送を許可するようにsshに指示してください。私は好む

    belden@skretting:~$ ssh -X blyman@the-server

しかしあなたは好きかもしれません

    belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server

または、これを〜/ .ssh/configで設定できます。

今日、私が管理していない新しいサーバーにsshを実行するときに、この空のDISPLAY環境変数に遭遇しました。欠落しているxauth部分を追跡するのは少し楽しかったです。これが私がやったこととあなたができることです。

私が管理者であるローカルワークステーションで、/ etc/ssh/sshd_configがX11を転送するように設定されていることを確認しました。 ssh -Xをlocalhostに戻すと、DISPLAYが正しく設定されます。

DISPLAYを強制的に設定解除することはそれほど難しくありませんでした。私はそれを正しく設定するためにsshdとsshが何をしていたかを観察する必要があるだけでした。ここに私が行ったすべての完全な出力があります。

    blyman@skretting:~$ mkdir ~/dummy-sshd
    blyman@skretting:~$ cp -r /etc/ssh/* ~/dummy-sshd/
    cp: cannot open `/etc/ssh/ssh_Host_dsa_key' for reading: Permission denied
    cp: cannot open `/etc/ssh/ssh_Host_rsa_key' for reading: Permission denied

Sudoを使用してssh_Host_ {dsa、rsa} _keyファイルを強制的にコピーする代わりに、ssh-keygenを使用して自分用にダミーのファイルを作成しました。

    blyman@skretting:~$ ssh-keygen -t rsa -f ~/dummy-sshd/ssh_Host_rsa_key
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/blyman/dummy-sshd/ssh_Host_rsa_key.
    Your public key has been saved in /home/blyman/dummy-sshd/ssh_Host_rsa_key.pub.

-t dsaを使用してすすぎと繰り返し：

    blyman@skretting:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_Host_dsa_key
    # I bet you can visually copy-paste the above output down here

〜/ dummy-sshd/sshd_configを編集して、正しい新しいssh_Hostキーファイルを指すようにします。

    # before
    blyman@skretting:~$ grep ssh_Host /home/blyman/dummy-sshd/sshd_config 
    HostKey /etc/ssh/ssh_Host_rsa_key
    HostKey /etc/ssh/ssh_Host_dsa_key

    # after
    blyman@skretting:~$ grep ssh_Host /home/blyman/dummy-sshd/sshd_config 
    HostKey /home/blyman/dummy-sshd/ssh_Host_rsa_key
    HostKey /home/blyman/dummy-sshd/ssh_Host_dsa_key

非分離モードで新しいポートでsshdを起動します。

    blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    sshd re-exec requires execution with an absolute path

おっと、そのパスを正しく修正します。

    blyman@skretting:~$ /usr/sbin/sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
    debug1: read PEM private key done: type RSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
    debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
    debug1: private Host key: #0 type 1 RSA
    debug1: read PEM private key done: type DSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
    debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
    debug1: private Host key: #1 type 2 DSA
    debug1: setgroups() failed: Operation not permitted
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-p'
    debug1: rexec_argv[2]='50505'
    debug1: rexec_argv[3]='-f'
    debug1: rexec_argv[4]='/home/blyman/dummy-sshd/sshd_config'
    debug1: rexec_argv[5]='-d'
    Set /proc/self/oom_adj from 0 to -17
    debug1: Bind to port 50505 on 0.0.0.0.
    Server listening on 0.0.0.0 port 50505.
    debug1: Bind to port 50505 on ::.
    Server listening on :: port 50505.

新しい端末をポップし、ポート50505のlocalhostにSSHで接続します。

    blyman@skretting:~$ ssh -p 50505 localhost
    The authenticity of Host '[localhost]:50505 ([::1]:50505)' can't be established.
    RSA key fingerprint is 81:36:a5:ff:a3:5a:45:a6:90:d3:cc:54:6b:52:d0:61.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '[localhost]:50505' (RSA) to the list of known hosts.
    Linux skretting 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64 GNU/Linux
    Ubuntu 10.10

    Welcome to Ubuntu!
     * Documentation:  https://help.ubuntu.com/

    1 package can be updated.
    0 updates are security updates.

    Last login: Thu Aug 16 15:41:58 2012 from 10.0.65.153
    Environment:
      LANG=en_US.UTF-8
      USER=blyman
      LOGNAME=blyman
      HOME=/home/blyman
      PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
      MAIL=/var/mail/blyman
      Shell=/bin/bash
      SSH_CLIENT=::1 43599 50505
      SSH_CONNECTION=::1 43599 ::1 50505
      SSH_TTY=/dev/pts/16
      TERM=xterm
      DISPLAY=localhost:10.0
    Running /usr/bin/xauth remove unix:10.0
    /usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 79aa9275ced418dd445d9798b115d393

そこの最後の3行を見てください。幸いにもDISPLAYが設定されていて、/ usr/bin/xauthから見栄えの良い2行がありました。

そこから、私の/ usr/bin/xauthを/usr/bin/xauth.oldに移動し、sshから切断してsshdを停止し、sshdとsshを起動してlocalhostに戻すのは子供の遊びでした。

/ usr/bin/xauthがなくなったとき、環境にDISPLAYが反映されていませんでした。

ここで素晴らしいことは何もありません。ほとんどの場合、私は自分のローカルマシンでこれを再現するための健全なアプローチを選択できました。

98
Belden

次のことを確認してください。

  • サーバーにxauthがインストールされました（参照：xauth info/xauth list）。

  • サーバー上であなたの/etc/ssh/sshd_configファイルには次の行があります：

    X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no

  • クライアント側では~/.ssh/configファイルには次の行があります：

    Host *
  ForwardAgent yes
  ForwardX11 yes

  • クライアント側に、Xサーバーがインストールされています（例：macOS：XQuartz、Windows：Xming）。

次に、SSHを使用してX11転送を行うには、add -Xをsshコマンドに追加します。

ssh -v -X user@Host

次に、あなたのDISPLAYがないであることを確認します。

echo $DISPLAY

そうであれば、ssh（-v）、警告などを確認します。

debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated

上記のようにuntrusted X11がある場合は、試してください-Y flag代わりに（ホストを信頼する場合）：

ssh -v -Y user@Host

参照： 「警告：信頼できないX11転送設定が失敗しました：xauthキーデータが生成されませんでした」とは、-Xでsshを実行することを意味します

警告が発生した場合：xauthデータがない場合は、新しい.Xauthorityファイル、例：.

xauth generate :0 . trusted
xauth list

参照： 新しい.Xauthorityファイルの作成/再構築

上記とは異なる警告が表示される場合は、さらに手がかりをたどってください。

43
kenorb

修正は、この行を/etc/ssh/sshd_configに追加することです：

X11UseLocalhost no

https://joshua.hoblitt.com/rtfm/2013/04/how_to_fix_x11_forwarding_request_failed_on_channel_0/

21
Ace

Windows 10でUbuntu bashが_ssh -X_を実行して、リモートサーバーでGUI環境を取得できるようにする

  • 最初

以下をすべてインストールします。ウィンドウで、Xmingをインストールします。ターミナルのUbuntuでは、_Sudo apt install_を使用して_ssh xauth xorg_をインストールします。

_Sudo apt install ssh xauth xorg
_
  • 二番目

_ssh_config_ファイルを含むフォルダーに移動します。私のものは_/etc/ssh_です。

  • 第三

管理者として_ssh_config_を編集します（USE Sudo）。 _ssh_config_内で、ForwardAgent、_#_、_ForwardX11_の行のハッシュ_ForwardX11Trusted_を削除し、対応する引数をyesに設定します。

_# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
_
  • 前方へ

_ssh_config_ファイルで、_#_と_Port 22_の前にあるフロントハッシュ_Protocol 2_を削除し、ファイルの最後に新しい行を追加して、xauthファイルの場所を記述します_XauthLocation /usr/bin/xauth_、xauthファイルの独自のパスを記述してください。

_# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocation /usr/bin/xauth
_
  • 第五

これで_ssh_config_ファイルの編集が完了したので、エディターを終了するときにファイルを保存します。次に、フォルダ_~_または_$HOME_に移動し、_export DISPLAY=localhost:0_ファイルに_.bashrc_を追加して保存します。

_# ~/.bashrc
...
...
export DISPLAY=localhost:0
_
  • 最終

あと少しで完了です。 bashシェルを再起動し、Xmingプログラムを開いて_ssh -X yourusername@yourhost_を使用します。次に、GUI環境をお楽しみください。

_ssh -X yourusername@yourhost
_

問題はWindowsのUbuntuサブシステムにもあり、リンクは

https://Gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

5
DestinyOne

追加 X11UseLocalhost no〜/etc/ssh/sshd_configとSSHサーバーを再起動します。

DISPLAYが表示されない場合は、xauthが正しくインストールされていることを確認してから、再試行してください。

RHE/CEntosにはこの問題はありません。これはUbuntuの問題です！

4
stephen cooke

私にとっては、問題はnodev/tmpファイルシステムのマウントオプションにありました。 X11では、そこに作成する特殊ファイルが必要です。

そのために別のパーティションまたはディスクを使用する場合は、/ tmpファイルシステムのマウントオプションを確認してください。

1
yakovpol

以前の優れた回答に追加するには（~/.ssh/configおよびDISPLAY環境変数がクライアントで設定されているかどうかを確認し、/etc/ssh/sshd_configおよびxauthをサーバーにインストールします）、また、xtermがクライアントにインストールされていることを確認します。

Sudo apt-get install xterm
1
Aliz Rao

xauthはロックされる可能性があります。

   -b      This  option  indicates  that  xauth  should  attempt to break any authority file locks before proceeding.  Use this
           option only to clean up stale locks.

使用する

xauth -b

sshを使おうとしたマシンで、xauthのロックを解除しました。 xauth -bを発行した後にsshセッションからログアウトし、再びログインすると、echo $DISPLAYを正常に実行できました。 .Xauthorityを再作成する前に、ぜひお試しください

1
Barton Chittenden

X11Forwardingは、SSHサーバー（あなたの場合はUbuntuボックス）のsshd_configに設定する必要があります。また、-Xオプションを使用するか、ssh_configファイルを編集してForwardX11デフォルトを追加します。

1
Caleb