Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I am trying to start a remote gnome session using: ssh -X username@192.168.1.107 gnome-session

Both client and server are Ubuntu version 12.04

I get the following (and not a lot happens)...

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
share|improve this question
    
I wanted to access an Ubuntu machine used as a media server/player remotely without changing what happens on the display of the remote machine. Also I just wanted to play around with this stuff to see what it could do. :-) –  benlad Aug 15 '12 at 23:47
    
If you want to play around, I entered an answer with some tips for using basic ssh from a commandline, including generating a key and copying it to the remote host. Once you learn to use ssh, you might be surprised at how much can be done using it. –  Marty Fried Aug 16 '12 at 1:35

2 Answers 2

up vote 7 down vote accepted

I assume that what you are trying to do is start a complete remote Gnome session displaying on your local machine. This fails because you already have a local session manager controlling your X server display.

Your options are:

  1. Simply start individual remote applications using ssh -X user@192.168.1.107 xclock

  2. Assuming XDMCP is enabled on the remote machine...

    2a. Use Xnest -query 192.168.1.107 -geometry 1024x768 :1 to start a remote login session in a local window.

    2b. Use Xephyr :1 -screen 1024x768 -query 192.168.1.107 which is a better X server than Xnest

  3. Also assuming XDMCP on the remote machine, configure your local machine to use the XDMCP chooser instead of the standard greeter on startup.

Enabling XDMCP is simply a case of putting

[xdmcp]
Enable=true

in /etc/gdm/custom.conf and restarting gdm or rebooting (assuming you are running gdm).

If you only intend to run a few applications remotely, then option 1 is simplest and continues to use SSH encrypted traffic, which none of the others do (so they are best only used on a trusted local network).

If you need to so something more complicated, then 2b (Xephyr) is may be better, but I've usually found just using ssh -X ... & for multiple remote applications to be adequate.

If you are doing everything remotely, i.e. the local machine is just a display server and doesn't do anything itself, then you need to look into using option 3, starting the XDMCP chooser instead of the standard login.


PS: As noted in the comments, both Xnest and Xephyr are applications which handle the X server protocol and put the entire session into a window. Xnest uses the functions provided by the local X server while Xephyr handles much more of the server protocol itself so is more robust. They may not be installed by default because the average user wouldn't use them.


PPS: After a little thought it's obvious how to encrypt a Xephyr or Xnest session...

ssh -X username@192.168.1.107 Xephyr :1 -query localhost -screen 1280x1024
share|improve this answer
1  
Might be useful to indicate what Xnest/Xephyr do and why, since they aren't installed by default, I don't think. I've never found any need to use xdmcp, so I have no idea myself. I use simple ssh -Y from a terminal, then run what I need from there. –  Marty Fried Aug 14 '12 at 23:47
    
@MartyFried: It looks like both are X servers which can run in a window. It looks like the user wants to X-forward an entire session/display. Personally I'd just use VNC, which creates a new display on the existing X server and save myself the headache. –  izx Aug 15 '12 at 0:37
    
@izx: I've used VNC in the past for Windows systems, but with two Ubuntu systems, I usually like the built-in ssh, although sometimes I get confused when running GUI apps, as it's hard to differentiate local vs remote apps. But for what I do (mostly editing from or administering a server), it seems to work the best. –  Marty Fried Aug 15 '12 at 0:48
1  
@MartyFried The downside of VNC is that you are simply controlling the remote machine's display. So you can't have one user logged in on that display with another user connected remotely. The XDMCP solutions crate completely separate sessions allowing 2 or more users to use the same machine. –  StarNamer Aug 15 '12 at 8:58
    
Your 2b solution worked a treat. I did try the ssh version, but had an issue about ssh keys. The message is too long to post here. I'll use the method that works for now. –  benlad Aug 16 '12 at 0:38

In case you ever want to learn to use the standard ssh from a terminal, I thought I'd give you a quick rundown, since you had trouble using ssh keys, it seems. The advantage is that it's more universal, and very flexible.

To use ssh keys, which is more secure, sometimes required, and more convenient since you only need to enter the key once, you need to do this once for any remote ssh server:

generate key (can use dsa instead of rsa, if required)

ssh-keygen -t rsa    

transfer the key to remote host

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

if not standard port 22, use this: Note quotes around argument

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

If using dsa, there is a slightly different command, adding -i <homedirectory>/.ssh/id_dsa

Somewhere after this, you will need to enter a password, which is separate from your normal login password. It's been a while, and I've forgotten the exact sequence, but it should be obvious. Then, the first time you connect, you'll be asked for this password, once. I use the same login name, so I don't need to enter the username (it assumes the same as the remote username). Also, for servers on your lan, you can enter ".local" instead of the IP address, I believe (works for me).

You can even mount a remote filesystem using sshfs (assuming sshfs is installed); substitute a directory path for local-mount-directory:

sshfs remote-host: local-mount-directory

(unmount using fusermount -u local-mount-directory)

I think it will use your home directory by default, if you leave off the local-mount-directory. `

Copying files can be done with scp.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.