web-dev-qa-db-ja.com

サードパーティツールなしでSSHを介してデスクトップ全体を転送する

いつも私を悩ませている何かと私は良い情報を見つけることができませんでした：

どうすればorデスクトップ全体をSSH（ssh -X）で転送できないのですか？

私はssh -Xを使用した個々のウィンドウの転送に精通しています。しかし、自分のLinuxラップトップを別のLinuxマシンのダム端末として使用したい場合があります。

私は常に、ラップトップのデスクトップ環境をシャットダウンしてから、コマンドラインからsshを実行して別のマシンに接続し、ラップトップに転送されたデスクトップ環境を起動できると考えていました。

オンラインでの検索では、VNCやXephyrなどのサードパーティのツールがたくさん出てくるか、単一のウィンドウのsshコマンドと設定が出てくる。しかし、それは私が探しているものではありません。私は、（xwindows？、wayland？、gdm？の）構造を少し理解して、これをどのように行うのかを理解しようとしています。OR.

注意：

  1. Xephyrは、リモートデスクトップをウィンドウで実行しようとするため、私が探しているものではありません。
  2. VNCは、X11フォワーディングではなくビットマップのフォワーディングであるため、さまざまな理由で私が探しているものではありません。
sshx11display
3
Philip Couling

どうやってできますか？

（現在停止中の）Xmoduloサイトから以下の方法を使用して、UbuntuマシンからRaspberry Piデスクトップ全体にリモートでアクセスしています。元のRPi、RPi2、RPi3で動作します。もちろん、リモートマシンでのX11転送を許可するには、sshd_configを変更する必要があります（クライアント/ホストと言いますが、X11では他の用途とは異なるため、混乱するかもしれません）。スペースに注意してください。タイプできないときに、この手順が頻繁に中断されます。

これでデスクトップ全体ができ、物理的に接続されているかのようにマシンを実行できます。 CTRL + ALT + F7を使用してUbuntuに切り替えてから、CTRL + ALT + F2を使用してRPiに戻ります。 YMMV。気まぐれ：前後に切り替えるときに別のファンクションキーを押す前に、CTRL + ALTを物理的にリリースする必要があります。

元のリンク： http://xmodulo.com/2013/12/remote-control-raspberry-pi.html

原作の帰属：Kristophorus Hadiono。残念ながら、参照された画像は失われています。

============== 8 <==============

方法＃3：SSHを介したデスクトップのX11転送

X11 + SSH転送を使用すると、スタンドアロンのGUIアプリケーションだけでなく、Raspberry Piのデスクトップ全体をリモートで実際に実行できます。

ここでは、X11転送を介して2番目の仮想端末（つまり、仮想端末8）でリモートRPiデスクトップを実行する方法を示します。 Linuxデスクトップは、デフォルトで最初の仮想端末（仮想端末＃7）で実行されています。以下の手順に従って、RPiデスクトップを2番目の仮想端末に表示します。

コンソールまたはターミナルを開き、rootユーザーに変更します。 $ Sudo su

以下のコマンドを入力すると、仮想端末8でxinitがアクティブになります。仮想端末8に自動的に切り替えられることに注意してください。CTRL+ ALT + F7を押すと、元の仮想端末7に切り替えることができます。

＃xinit-：1＆

仮想端末8に切り替えた後、次のコマンドを実行して、RPiデスクトップをリモートで起動します。尋ねられたら、piユーザーのパスワードを入力します（下の画像を参照）。

＃DISPLAY =：1 ssh -X [email protected] lxsession

新しい仮想端末8にリモートRPiデスクトップと、アクティブな仮想端末7から起動された小さな端末を持ち込みます（下の画像を参照）。

その端末を閉じないでください。それ以外の場合、RPiデスクトップはすぐに閉じます。

CTRL + ALT + F7またはCTRL + ALT + F8を押すと、1番目と2番目の仮想端末間を移動できます。

X11 + SSHでリモートRPiデスクトップを閉じるには、アクティブな仮想端末8に表示されている小さな端末を閉じるか（上の画像を参照）、仮想端末7で実行されているsuセッションを終了します。

3
Mike

私はこれをテストしていませんが、私の知る限り、ローカルX11サーバーをシャットダウンすることは可能であるはずです（通常、gdm、sddm、クラシックxdmまたはその他の*dm）を使用して、仮想コンソールにログインし、GNOMEの場合は次のようにカスタムX11セッションを開始します。

xinit ssh -X user@remote-server gnome-session

または、KDEの場合は次のようにします。

xinit ssh -X user@remote-server startkde

通常、X11 Display ManagerはX11サーバーを起動し、ログインダイアログを表示して認証を処理し（オプションで、認証の前後にrootとしていくつかの初期化スクリプトを実行し）、ログインユーザーとして単一のコマンドまたはスクリプトを実行します。セッションのバックボーンとして機能します。そのスクリプトのクラシックなデフォルトバージョンは/etc/X11/Xsessionとして見つかるかもしれませんが、GnomeやKDEなどのデスクトップ環境では、独自のコマンドに置き換えられる場合があります。このコマンド/スクリプトは、セッションの存続期間中存続します。何らかの理由で停止した場合、X11 Display Managerはセッションがログアウトまたはクラッシュしたと見なし、X11サーバーをリセットして最初からやり直します。

startxを使用して、X11 Display Managerなしの仮想コンソールから単一のX11セッションを開始する場合、xinitを使用してX11サーバーとセッションコマンド/スクリプトを開始するラッパースクリプトです。

やりたいことは、X11サーバーを起動することですが、ローカルセッションコマンドの代わりにssh -Xを使用して、リモートホストでactual X11セッションコマンド/スクリプトを実行します。

xinitコマンドはローカルX11サーバーを起動しますが、その唯一のクライアントはsshコマンドです。そのsshは、X11転送を確立し、リモートホストに接続してログインし、リモートホストで適切なデスクトップ環境セッションを開始するために必要なコマンドを実行します。 $DISPLAY変数と~/.Xauthorityファイルはssh -Xによって設定されるため、X11ウィンドウマネージャーを含むすべてのX11アプリケーションを実行できるはずです。

ただし、X11サーバーにローカルでアクセスできないため、パフォーマンスを向上させるさまざまなX11プロトコル拡張機能が自動的に使用できなくなり、ネットワーク接続+ SSH暗号化により、顕著な遅延が発生します。ウィンドウマネージャーと他のX11アプリケーションとの間のやり取りはすべて、X11サーバーを経由する必要があります。つまり、ネットワークを介して2往復する必要があります。したがって、ローカルデスクトップを実行するよりも確実に遅くなります。

一部のデスクトップウィジェットも混乱している可能性があります。リモートで実行しているときに、ハードウェアデバイスやホストのシステムD-Busへの予想されるすべてのレベルのアクセス権が必要になるとは限らないためです。

3
telcoM