X-server remoto con ssh -X

Sto cercando di avviare una sessione di gnome remota usando: ssh -X username@192.168.1.107 gnome-session

Sia il client che il server sono Ubuntu versione 12.04

Ottengo quanto segue (e non succede molto) ...

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

— benlad
fonte

Volevo accedere a una macchina Ubuntu utilizzata come server / lettore multimediale in remoto senza cambiare ciò che accade sul display della macchina remota. Inoltre volevo solo giocare con queste cose per vedere cosa poteva fare. :-)

— benlad

Se vuoi giocare, ho inserito una risposta con alcuni suggerimenti per l'utilizzo di ssh di base da una riga di comando, tra cui la generazione di una chiave e la copia sull'host remoto. Una volta che impari a usare ssh, potresti essere sorpreso di quanto si può fare usando.

— Marty Fried,

Risposte:

Presumo che ciò che stai cercando di fare sia avviare una sessione Gnome remota completa che viene visualizzata sul tuo computer locale. Questo non riesce perché hai già un gestore di sessioni locale che controlla la visualizzazione del tuo server X.

Le tue opzioni sono:

Basta avviare singole applicazioni remote usando ssh -X user@192.168.1.107 xclock
Supponendo che XDMCP sia abilitato sul computer remoto ...

2a. Utilizzare Xnest -query 192.168.1.107 -geometry 1024x768 :1per avviare una sessione di accesso remoto in una finestra locale.

2b. Utilizzare Xephyr :1 -screen 1024x768 -query 192.168.1.107quale sia un server X migliore diXnest
Supponendo inoltre che XDMCP sul computer remoto, configurare il computer locale in modo da utilizzare il selettore XDMCP anziché il programma di benvenuto standard all'avvio.

Abilitare XDMCP è semplicemente un caso di mettere

[xdmcp]
Enable=true

in /etc/gdm/custom.confe riavvio gdmo riavvio (presupponendo che sia in esecuzione gdm).

Se intendi eseguire solo alcune applicazioni in remoto, l'opzione 1 è la più semplice e continua a utilizzare il traffico crittografato SSH, cosa che nessuna delle altre fa (quindi è meglio utilizzarla solo su una rete locale attendibile).

Se hai bisogno di qualcosa di più complicato, allora 2b (Xephyr) potrebbe essere migliore, ma di solito ho trovato che l'uso ssh -X ... &di più applicazioni remote fosse adeguato.

Se stai facendo tutto da remoto, cioè la macchina locale è solo un server di visualizzazione e non fa nulla da sola, allora devi esaminare usando l'opzione 3, avviando il selettore XDMCP invece del login standard.

PS: Come notato nei commenti, entrambi Xneste Xephyrsono applicazioni che gestiscono il protocollo del server X e mettono l'intera sessione in una finestra. Xnestusa le funzioni fornite dal server X locale mentre Xephyrgestisce molto più del protocollo server stesso, quindi è più robusto. Potrebbero non essere installati per impostazione predefinita perché l'utente medio non li userebbe.

PPS: Dopo un piccolo pensiero è ovvio come crittografare una Xephyro una Xnestsessione ...

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

— StarNamer
fonte

Potrebbe essere utile indicare cosa fanno Xnest / Xephyr e perché, poiché non sono installati di default, non credo. Non ho mai trovato alcun bisogno di usare xdmcp, quindi non ne ho idea. Uso semplice ssh -Yda un terminale, quindi eseguo quello che mi serve da lì.

— Marty Fried,

@MartyFried: sembra che entrambi siano server X che possono essere eseguiti in una finestra. Sembra che l'utente voglia eseguire X-forward di un'intera sessione / display. Personalmente userei semplicemente VNC, che crea un nuovo display sul server X esistente e mi risparmiavo il mal di testa.

— Ish,

@izx: Ho usato VNC in passato per sistemi Windows, ma con due sistemi Ubuntu, di solito mi piace l'ssh incorporato, anche se a volte mi confondo quando eseguo app GUI, poiché è difficile differenziare le app locali rispetto a quelle remote. Ma per quello che faccio (principalmente modifica o amministrazione di un server), sembra funzionare al meglio.

— Marty Fried,

@MartyFried Il rovescio della medaglia di VNC è che stai semplicemente controllando il display della macchina remota. Quindi non è possibile avere un utente connesso su quel display con un altro utente connesso in remoto. Le soluzioni XDMCP creano sessioni completamente separate che consentono a 2 o più utenti di utilizzare la stessa macchina.

— StarNamer,

La tua soluzione 2b ha funzionato a meraviglia. Ho provato la versione ssh, ma ho avuto un problema con le chiavi ssh. Il messaggio è troppo lungo per essere pubblicato qui. Userò il metodo che funziona per ora.

— benlad

Nel caso in cui tu abbia mai voluto imparare a usare lo standard ssh da un terminale, ho pensato di darti una rapida rassegna, dal momento che hai avuto problemi ad usare i tasti ssh, a quanto pare. Il vantaggio è che è più universale e molto flessibile.

Per usare le chiavi ssh, che sono più sicure, a volte richieste e più convenienti poiché devi inserire la chiave solo una volta, devi farlo una volta per qualsiasi server ssh remoto:

genera chiave (può usare dsa invece di rsa, se necessario)

ssh-keygen -t rsa

trasferire la chiave sull'host remoto

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

se non la porta standard 22, utilizzare questo: Nota tra virgolette attorno all'argomento

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

Se si utilizza dsa, c'è un comando leggermente diverso, aggiungendo -i <homedirectory>/.ssh/id_dsa

Da qualche parte dopo questo, dovrai inserire una password, che è separata dalla tua normale password di accesso. È passato un po 'di tempo e ho dimenticato la sequenza esatta, ma dovrebbe essere ovvio. Quindi, la prima volta che ti connetti, ti verrà chiesta questa password, una volta. Uso lo stesso nome di accesso, quindi non ho bisogno di inserire il nome utente (assume lo stesso nome utente remoto). Inoltre, per i server sulla tua lan, puoi inserire ".local" invece dell'indirizzo IP, credo (funziona per me).

Puoi persino montare un filesystem remoto usando sshfs (supponendo che sshfs sia installato); sostituire un percorso di directory per local-mount-directory:

sshfs remote-host: local-mount-directory

(smonta usando fusermount -u local-mount-directory)

Penso che userà la tua directory home per impostazione predefinita, se lasci la directory mount-local. `

La copia dei file può essere eseguita con scp.

— Marty Fried
fonte