ssh -X [email protected] gnome-session
を使用してリモートgnomeセッションを開始しようとしています。
クライアントとサーバーの両方が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
あなたがやろうとしているのは、ローカルマシンに表示される完全なリモートGnomeセッションを開始することだと思います。 Xサーバーの表示を制御するローカルセッションマネージャーが既にあるため、これは失敗します。
オプションは次のとおりです。
ssh -X [email protected] xclock
を使用して個々のリモートアプリケーションを起動するだけです
XDMCPがリモートマシンで有効になっていると仮定します...
2a。 Xnest -query 192.168.1.107 -geometry 1024x768 :1
を使用して、ローカルウィンドウでリモートログインセッションを開始します。
2b。 Xephyr :1 -screen 1024x768 -query 192.168.1.107
を使用します。これはXnest
よりも優れたXサーバーです。
また、リモートマシンでXDMCPを想定して、起動時に標準のグリッターの代わりにXDMCPチューザーを使用するようにローカルマシンを構成します。
XDMCPを有効にすることは、単に
[xdmcp]
Enable=true
/etc/gdm/custom.conf
で再起動gdm
または再起動(gdm
を実行していると仮定)。
少数のアプリケーションのみをリモートで実行する場合、オプション1は最も単純で、SSH暗号化トラフィックを引き続き使用しますが、他のどのアプリケーションも使用しません(したがって、信頼できるローカルネットワークでのみ使用するのが最適です)。
もっと複雑なものが必要な場合は、2b(Xephyr)の方が良いかもしれませんが、通常、複数のリモートアプリケーションにssh -X ... &
を使用するだけで十分であることがわかりました。
すべてをリモートで実行している場合、つまりローカルマシンが単なるディスプレイサーバーであり、それ自体何も実行していない場合は、オプション3を使用して、標準ログインの代わりにXDMCPチューザーを起動する必要があります。
PS:コメントで述べたように、Xnest
とXephyr
は両方ともXサーバープロトコルを処理し、セッション全体をウィンドウに入れるアプリケーションです。 Xnest
はローカルXサーバーが提供する機能を使用し、Xephyr
はより多くのサーバープロトコル自体を処理するため、より堅牢です。平均的なユーザーはこれらを使用しないため、デフォルトではインストールされない場合があります。
PPS:少し考えた後、Xephyr
またはXnest
セッションを暗号化する方法は明らかです...
ssh -X [email protected] Xephyr :1 -query localhost -screen 1280x1024
ターミナルから標準の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
を追加するわずかに異なるコマンドがあります
この後のどこかで、通常のログインパスワードとは別のパスワードを入力する必要があります。しばらく経ちましたが、正確なシーケンスを忘れてしまいましたが、明らかなはずです。次に、最初に接続するときに、このパスワードを1回要求されます。同じログイン名を使用しているため、ユーザー名を入力する必要はありません(リモートユーザー名と同じであると想定しています)。また、LAN上のサーバーの場合、IPアドレスの代わりに「.local」と入力できます(私にとってはうまくいきます)。
Sshfsを使用してリモートファイルシステムをマウントすることもできます(sshfsがインストールされている場合)。 local-mount-directoryをディレクトリパスに置き換えます。
sshfs remote-Host: local-mount-directory
(fusermount -u local-mount-directory
を使用してアンマウントします)
Local-mount-directoryを省略した場合、デフォルトでホームディレクトリが使用されると思います。 `
ファイルのコピーはscpで実行できます。