ssh -Xを使用したリモートxサーバー

次を使用して、リモートgnomeセッションを開始しようとしています。 ssh -X username@192.168.1.107 gnome-session

クライアントとサーバーの両方がUbuntuバージョン12.04です

私は次のようになります（多くは起こりません）...

GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_PID=3573
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to get contents of /sys/class/dmi/id/board_version: Failed to open file '/sys/class/dmi/id/board_version': No such file or directory

** (gnome-settings-daemon:3572): WARNING **: You can only run one xsettings manager at a time; exiting

** (gnome-settings-daemon:3572): WARNING **: Unable to start xsettings manager: Could not initialize xsettings manager.
compiz (core) - Error: Screen 0 on display "localhost:10.0" already has a window manager; try using the --replace option to replace the current window manager.
Initializing nautilus-gdu extension
Created new window in existing browser session.
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon

(gnome-settings-daemon:3572): keyboard-plugin-WARNING **: Failed to set the keyboard layouts: GDBus.Error:org.freedesktop.Accounts.Error.PermissionDenied: Not authorized

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused

(gnome-settings-daemon:3572): clipboard-plugin-WARNING **: Clipboard manager is already running.

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to create device: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-device auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-profile auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: no xrandr-Samsung Electric Company-SAMSUNG device found: Failed to find output xrandr-Samsung Electric Company-SAMSUNG
Shutting down nautilus-gdu extension

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

ssh xserver

— ベンラッド
ソース

リモートサーバーのディスプレイで何が起こるかを変更せずに、メディアサーバー/プレーヤーとして使用されるUbuntuマシンにリモートでアクセスしたかった。また、私はそれが何ができるかを見るためにこのようなもので遊んでみたかっただけです。:

— ベンラッド

試してみたい場合は、キーを生成してリモートホストにコピーするなど、コマンドラインから基本的なsshを使用するためのいくつかのヒントを含む回答を入力しました。sshの使用方法を学習すると、それを使用してどれだけのことができるかに驚くかもしれません。

— マーティフライド

回答:

あなたがやろうとしているのは、ローカルマシンに表示される完全なリモートGnomeセッションを開始することだと思います。Xサーバーの表示を制御するローカルセッションマネージャーが既にあるため、これは失敗します。

オプションは次のとおりです。

を使用して、個々のリモートアプリケーションを起動するだけです ssh -X user@192.168.1.107 xclock
XDMCPがリモートマシンで有効になっていると仮定します...

2a。Xnest -query 192.168.1.107 -geometry 1024x768 :1ローカルウィンドウでリモートログインセッションを開始するために使用します。

2b。Xephyr :1 -screen 1024x768 -query 192.168.1.107どのXサーバーよりも優れている使用Xnest
また、リモートマシンでXDMCPを想定し、起動時に標準のグリッターの代わりにXDMCPチューザーを使用するようにローカルマシンを構成します。

XDMCPを有効にすることは、単に

[xdmcp]
Enable=true

で/etc/gdm/custom.conf再起動gdmまたは再起動します（実行していると仮定gdm）。

少数のアプリケーションのみをリモートで実行する場合、オプション1は最も単純で、SSH暗号化トラフィックを引き続き使用しますが、他のどのトラフィックも使用しません（したがって、信頼できるローカルネットワークでのみ使用するのが最適です）。

もっと複雑なものが必要な場合は、2b（Xephyr）の方が良いかもしれませんが、通常ssh -X ... &は複数のリモートアプリケーションに使用するだけで十分であることがわかりました。

すべてをリモートで行う場合、つまりローカルマシンが単なるディスプレイサーバーであり、それ自体は何もしない場合、オプション3を使用して、標準ログインの代わりにXDMCPチューザーを起動する必要があります。

PS：としては、両方の、コメントで指摘Xnestし、XephyrXサーバのプロトコルを処理し、ウィンドウに、セッション全体を置くアプリケーションです。XnestローカルXサーバーが提供する機能を使用する一方Xephyrで、サーバープロトコル自体をより多く処理するため、より堅牢です。平均的なユーザーはこれらを使用しないため、デフォルトではインストールされない場合があります。

PPS：やや考えた後、XephyrまたはXnestセッションを暗号化する方法は明らかだ...

ssh -X username@192.168.1.107 Xephyr :1 -query localhost -screen 1280x1024

— StarNamer
ソース

Xnest / Xephyrが何をするのか、なぜそれらをデフォルトでインストールしていないのかを示すのに役立つかもしれません。私はxdmcpを使用する必要性を発見したことはないので、自分にはわかりません。ssh -Yターミナルからsimpleを使用し、そこから必要なものを実行します。

— マーティフライド

@MartyFried：どちらもウィンドウ内で実行できるXサーバーのようです。ユーザーがセッション/ディスプレイ全体をX転送したいようです。個人的には、VNCを使用するだけです。VNCは、既存のXサーバー上に新しいディスプレイを作成し、頭痛を軽減します。

— -ish

@izx：私は過去にWindowsシステムにVNCを使用しましたが、2つのUbuntuシステムでは、組み込みのsshが好きです。しかし、私がしていること（主にサーバーからの編集またはサーバーの管理）では、それが最もうまくいくようです。

— マーティフライド

@MartyFried VNCの欠点は、単にリモートマシンのディスプレイを制御していることです。そのため、あるユーザーがそのディスプレイにログインし、別のユーザーがリモートで接続することはできません。XDMCPソリューションは、完全に独立したセッションを作成し、2人以上のユーザーが同じマシンを使用できるようにします。

— StarNamer

あなたの2bソリューションはとてもうまくいきました。sshバージョンを試しましたが、sshキーに関する問題がありました。メッセージは長すぎてここに投稿できません。今のところ機能するメソッドを使用します。

— ベンラッド

ターミナルから標準のsshを使用することを学びたい場合、sshキーの使用に問題があったので、簡単に説明すると思います。利点は、より普遍的であり、非常に柔軟であることです。

キーを1回入力するだけで済むため、より安全で必要な場合があり便利なsshキーを使用するには、リモートsshサーバーでこれを1回行う必要があります。

キーを生成します（必要に応じて、rsaの代わりにdsaを使用できます）

ssh-keygen -t rsa

キーをリモートホストに転送する

ssh-copy-id <username>@<host>

標準のポート22でない場合は、これを使用します：引数の前後の引用符に注意してください

ssh-copy-id "<username>@<host> -p <port_nr>"

dsaを使用している場合は、わずかに異なるコマンドが追加されます。 -i <homedirectory>/.ssh/id_dsa

この後、通常のログインパスワードとは別のパスワードを入力する必要があります。しばらく経ちましたが、正確なシーケンスを忘れてしまいましたが、明らかなはずです。次に、初めて接続するときに、このパスワードの入力を一度求められます。同じログイン名を使用しているため、ユーザー名を入力する必要はありません（リモートユーザー名と同じであると想定しています）。また、LAN上のサーバーの場合、IPアドレスの代わりに「.local」と入力できます（私にとってはうまくいきます）。

sshfsを使用してリモートファイルシステムをマウントすることもできます（sshfsがインストールされている場合）。local-mount-directoryをディレクトリパスに置き換えます。

sshfs remote-host: local-mount-directory

（を使用してアンマウントしますfusermount -u local-mount-directory）

local-mount-directoryを省略すると、デフォルトでホームディレクトリが使用されると思います。`

ファイルのコピーはscpで実行できます。

— マーティフライド
ソース