Servidor x remoto con ssh -X

Estoy tratando de iniciar una sesión remota de gnome usando: ssh -X [email protected] gnome-session

Tanto el cliente como el servidor son Ubuntu versión 12.04

Me sale lo siguiente (y no pasa mucho) ...

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
fuente

Quería acceder a una máquina Ubuntu utilizada como servidor / reproductor multimedia de forma remota sin cambiar lo que sucede en la pantalla de la máquina remota. Además, solo quería jugar con estas cosas para ver qué podía hacer. :-)

benlad

Si desea jugar, ingresé una respuesta con algunos consejos para usar ssh básico desde una línea de comandos, incluida la generación de una clave y copiarla al host remoto. Una vez que aprenda a usar ssh, es posible que se sorprenda de cuánto se puede hacer al usarlo.

Marty Fried

Respuestas:

Supongo que lo que está intentando hacer es iniciar una sesión completa de Gnome remota en su máquina local. Esto falla porque ya tiene un administrador de sesión local que controla la pantalla de su servidor X.

Sus opciones son:

Simplemente inicie aplicaciones remotas individuales usando ssh -X [email protected] xclock
Asumiendo que XDMCP está habilitado en la máquina remota ...

2a. Use Xnest -query 192.168.1.107 -geometry 1024x768 :1para iniciar una sesión de inicio de sesión remota en una ventana local.

2b. Utilice Xephyr :1 -screen 1024x768 -query 192.168.1.107cuál es un mejor servidor X queXnest
Suponiendo también que XDMCP en la máquina remota, configure su máquina local para usar el selector XDMCP en lugar del saludo estándar en el inicio.

Habilitar XDMCP es simplemente un caso de poner

[xdmcp]
Enable=true

en /etc/gdm/custom.confy reiniciar gdmo reiniciar (suponiendo que se está ejecutando gdm).

Si solo tiene la intención de ejecutar algunas aplicaciones de forma remota, entonces la opción 1 es más simple y continúa usando tráfico encriptado SSH, que ninguno de los otros hace (por lo que es mejor usarlo solo en una red local de confianza).

Si necesita algo más complicado, entonces 2b (Xephyr) puede ser mejor, pero generalmente he encontrado que el uso ssh -X ... &de múltiples aplicaciones remotas es adecuado.

Si está haciendo todo de forma remota, es decir, la máquina local es solo un servidor de visualización y no hace nada por sí misma, entonces debe considerar el uso de la opción 3, iniciando el selector XDMCP en lugar del inicio de sesión estándar.

PD: Como se ha señalado en los comentarios, tanto Xnesty Xephyrson aplicaciones que manejan el protocolo de servidor X y poner toda la sesión en una ventana. Xnestusa las funciones proporcionadas por el servidor X local mientras Xephyrmaneja mucho más del protocolo del servidor en sí mismo, por lo que es más robusto. Es posible que no se instalen de manera predeterminada porque el usuario promedio no los usaría.

PPS: después de pensar un poco, es obvio cómo cifrar una sesión Xephyro Xnest...

ssh -X [email protected] Xephyr :1 -query localhost -screen 1280x1024

StarNamer
fuente

Podría ser útil para indicar qué hacen Xnest / Xephyr y por qué, dado que no están instalados de forma predeterminada, no creo. Nunca he encontrado la necesidad de usar xdmcp, así que no tengo ni idea. Utilizo simple ssh -Ydesde una terminal, luego ejecuto lo que necesito desde allí.

Marty Fried

@MartyFried: Parece que ambos son servidores X que pueden ejecutarse en una ventana. Parece que el usuario desea reenviar X una sesión / pantalla completa. Personalmente, solo usaría VNC, que crea una nueva pantalla en el servidor X existente y me ahorro el dolor de cabeza.

ish

@izx: He usado VNC en el pasado para sistemas Windows, pero con dos sistemas Ubuntu, generalmente me gusta el ssh incorporado, aunque a veces me confundo al ejecutar aplicaciones GUI, ya que es difícil diferenciar las aplicaciones locales de las remotas. Pero por lo que hago (principalmente editando o administrando un servidor), parece funcionar mejor.

Marty Fried

@MartyFried La desventaja de VNC es que simplemente está controlando la pantalla de la máquina remota. Por lo tanto, no puede tener un usuario conectado en esa pantalla con otro usuario conectado de forma remota. Las soluciones XDMCP crean sesiones completamente separadas que permiten que 2 o más usuarios usen la misma máquina.

StarNamer

Su solución 2b funcionó de maravilla. Probé la versión ssh, pero tuve un problema con las claves ssh. El mensaje es demasiado largo para publicarlo aquí. Usaré el método que funciona por ahora.

benlad

En caso de que quiera aprender a usar el ssh estándar desde un terminal, pensé que le daría un resumen rápido, ya que al parecer tuvo problemas para usar las teclas ssh. La ventaja es que es más universal y muy flexible.

Para usar las claves ssh, que son más seguras, a veces requeridas y más convenientes, ya que solo necesita ingresar la clave una vez, debe hacerlo una vez para cualquier servidor ssh remoto:

generar clave (puede usar dsa en lugar de rsa, si es necesario)

ssh-keygen -t rsa

transferir la clave al host remoto

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

si no es el puerto 22 estándar, use esto: tenga en cuenta las citas alrededor del argumento

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

Si usa dsa, hay un comando ligeramente diferente, agregando -i <homedirectory>/.ssh/id_dsa

En algún lugar después de esto, deberá ingresar una contraseña, que es independiente de su contraseña de inicio de sesión normal. Ha pasado un tiempo y he olvidado la secuencia exacta, pero debería ser obvio. Luego, la primera vez que se conecte, se le pedirá esta contraseña, una vez. Utilizo el mismo nombre de inicio de sesión, por lo que no necesito ingresar el nombre de usuario (se supone lo mismo que el nombre de usuario remoto). Además, para los servidores en su lan, puede ingresar ".local" en lugar de la dirección IP, creo (funciona para mí).

Incluso puede montar un sistema de archivos remoto utilizando sshfs (suponiendo que sshfs esté instalado); sustituya una ruta de directorio por local-mount-directory:

sshfs remote-host: local-mount-directory

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

Creo que usará su directorio de inicio de forma predeterminada, si deja el directorio de montaje local. ``

La copia de archivos se puede hacer con scp.

Marty Fried
fuente