Fedora 14マシンからSSHで送信するUbuntuを実行しているマシンがあります。XをUbuntuマシンからFedoraに戻し、グラフィカルプログラムをリモートで実行できるようにします。両方のマシンがLAN上にあります。

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

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

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

上のクライアント側、-Xに（資本X）オプションはsshX11フォワーディングを有効にし、あなたがこの（特定たっすべての接続用または用）をデフォルトにすることができます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出力に含まれている行を確認します。ことに注意してください、サーバーが応答しませんいずれかの方法、潜在的な攻撃者から詳細を隠すのセキュリティ対策を。

X11フォワーディングをssh経由で機能させるには、3つの場所が必要です。

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

＃1と＃2の両方を配置しているが、＃3が欠落している場合、空のDISPLAY環境変数になります。

スープからナッツへ、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. クライアントで、サーバーに接続します。sshにX11転送を許可するようにしてください。私は好む

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

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

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

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

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

私が管理者であるローカルワークステーションで、X11を転送するために/ etc / ssh / sshd_configがセットアップされていることを確認しました。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を起動してlocalhostにsshするという子供の遊びでした。

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

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

以下を確認してください：

• あなたはしました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転送を行うには、コマンドに追加-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

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

ssh -v -Y user@host

^{参照：「警告：信頼できないX11転送セットアップが失敗しました：xauth鍵データが生成されません」は、-Xを使用してsshする場合の意味は何ですか？}

あなたがきた場合には警告：いいえXAUTHデータを、あなたは新しい生成しようとする.Xauthorityファイル、例えば

xauth generate :0 . trusted
xauth list

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

上記とは異なる警告がある場合は、さらに手がかりに従ってください。

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

X11UseLocalhost no

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

Windows 10でUbuntu bashを実行ssh -X して、リモートサーバーでGUI環境を取得する

• 最初

以下をすべてインストールします。WindowにインストールしXmingます。Ubuntu bashでは、を使用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ファイルの場所を述べるために、ファイルの末尾に新しい行を追加し、XauthLocaion /usr/bin/xauth、XAUTHファイルの独自のパスを書き覚えておいてください。

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocaion /usr/bin/xauth

• 5番目

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

SSHサーバーに追加X11UseLocalhost noし/etc/ssh/sshd_configて再起動します。

DISPLAYが表示されない場合は、xauthが正しくインストールされているかどうかを確認してから、もう一度試してください。

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

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

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

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

sudo apt-get install xterm

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。以下からのログアウトssh発行した後にセッションxauth -bそして最後に再びログインすると、私が正常に許可しましたecho $DISPLAY。再作成する前に間違いなくこれを試してください.Xauthority

X11ForwardingSSHサーバー（この場合はUbuntuボックス）でsshd_configを設定する必要があり、-Xオプションを渡すか、ssh_configファイルを編集してForwardX11デフォルトを追加することにより、SSHクライアント（Fedoraボックス）にX11を転送できるようにする必要があります。