SSH Tunneling Explained. A SSH tunnel consists of an encrypted tunnel created through a SSH protocol connection. A SSH tunnel can be used to transfer unencrypted traffic over a network through an encrypted channel. For example we can use a ssh tunnel to securely transfer files between a FTP server and a client even though the FTP. Asked Aug 16 '18 at 15:09. 101 1 1 bronze badge. To this end a reverse SSH tunnel from that computer (with SSH server installed) is.

Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
May the source be with you, but remember the KISS principle ;-) Skepticism and critical thinking is not panacea, but can help to understand the world better

News	Recommended Links	Architecture	Configuration	X display manager	XDMCP
Exporting_display	'Can't open display' Error	.Xresources	xrdb	Using xauth	Xdefaults
Fonts in X	X11 security	Xming	Cygwin/X	vnc	vino
Troubleshooting	Diagnosing problems with remote X11 sessions via SSH	Installing X11 and Gnome Desktop in RHEL	Tips	Humor	Etc

• You do not have access to X11 session
  

Introduction

Vino is the default VNC server in Gnome which provides the capability to view Gnome desktop via VNC client.

To configure vino from within GNOME, go to System > Preferences > Remote Desktop

• To set vino to request access each time, tick Allow other users to view your desktop in the Remote Desktop configuration window
• To set a password, tick Require the user to enter this password:
• To put vino in view-only mode, untick Allow other users to control your desktop
• To only allow local connections: click on the tab marked Advanced, then tick Only allow local connections
• To allow connections from anywhere: click on the tab marked Advanced, then untick Only allow local connections

To change properties form command line run is more diffucult. There are two situations here:

1. You can export display and see X11 session on other machine or via DRAC or ILO interfaces.
2. You do not have access to X11 session

You can export display and see X11 session on other machine or via DRAC or ILO interfaces

In this case it is easy.

1. Login using ssh or other method to remotebox, export display to the box where you can view X11 session and run vino-preferences

   # export DISPLAY=:0.0
   # xhost 10.20.30.40

   vino-preferences &

2. Check 'Allow other users to view your desktop'
3. Uncheck 'You must conform each access to this machine'
4. Check 'Require the user to enter this password' and enter the password
5. Clock close
6. Start vino-sever manually

   # /usr/libexec/vino-server & # to start the vino server

7. Check the port on which vino server is listening (ports 5900-5909)

   root@remotebox:~# netstat -nl grep 590[0-9] # check to make sure vino server is listening on port 590x

8. Shutdown firewall and disable SE (you can open firewall port later, and try to enable SE if you succeed)
9. Attempt to connect from you remote desktio using vnc-client

You do not have access to X11 session

If you do not have access to X11 session (for example it is blocked on corporate firewall) thing are more difficult. You might be off trying to tunnel X11 session via ssh. Without X11 session success is not guaranteed but you can try to enable access along the following lines:

1. Login using ssh or other method to remotebox

2. Enable remote access using

3. Edit the gconf setttings file (don't forget to create backup). If might have different location of newer versions of Reh Hat. Try to find is first. If you can't that's it -- you are hosed. You need to learn your version of Gnome to proceed.

   You you found it you can edit it putting the necessary settings, for example
   vi /home/<userhomedir>/.gconf/desktop/gnome/remote_access/%gconf.xml

   You need to disable the 'Ask you for confirmation' setting, and set the password.
   

4. Start vino-sever manually
5. Check to make sure vino server is listening on port 590x
6. Disable firewall (and shut down it via service command) and SE Linux (you can enable them later)

On local desktop

1. Check if you can connect to the port. Assuming your server address and 10.10.10.10 and the port vino-server is running is 5900 try the command

   telnet 10.10.10.10 5900

2. Launch VNC viewer (for example TightVNC viewer) on opened port from your windows desktop/laptop
3. If sucessful logoff or exist ssh session to remotebox

See also VNC-Servers - Community Ubuntu Documentation

NEWS CONTENTS

• 190728 : RE Controlling vino-server from command line ( RE Controlling vino-server from command line, )
• 190728 : HOWTO: Control the gnome VNC vino-server from the command line - Ubuntu Forums ( HOWTO: Control the gnome VNC vino-server from the command line - Ubuntu Forums, )
• 190728 : ubuntu and debian linux help, hints, tips. Enabling VINO by command line ( ubuntu and debian linux help, hints, tips. Enabling VINO by command line, )
• 190728 : Control the gnome VNC vino-server from the command line ( Control the gnome VNC vino-server from the command line, )

Old News ;-)

Top Visited					Switchboard
					Latest
					Past week
					Past month

RE Controlling vino-server from command line

Feb 24, 2009

HOWTO: Control the gnome VNC vino-server from the command line - Ubuntu Forums:

'HOWTO: Enable and control the gnome VNC vino-server from the command line
CAVEAT: A user must already be logged into the desktop on the target machine for this to work

Here is a cool trick for remotely enabling the gnome vino VNC server (assuming that it's already been installed and configured) on a box that you only have SSH access to.

Log into the target system using SSH, and run the following command:

Code:

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true

You can also monkey with the vino server options by editing this file

/home/<userhomedir>/.gconf/desktop/gnome/remote_access/%gconf.xml

Let's say you want to disable the 'Ask you for confirmation' setting, or change the password.

Easiest way to do it:

1) On your own Ubuntu box; Go to System => Preferences => Remote Desktop. and configure the Remote Desktop Preferences to your liking, then click close.

2) Navigate to ~/.gconf/desktop/gnome/remote_access/ in your home directory, open up the %gconf.xml file, and copy the contents.

3) Establish an SSH connection to the remote box, change directory to /home/<userhomedir>/.gconf/desktop/gnome/remote_access/ directory, and backup the existing %gconf.xml file.
Code:

mv %gconf.xml %gconf.xml.bak

4) Create a new %gconf.xml file,
Code:

vi %gconf.xml

then paste in the contents for your own %gconf.xml file that you copied in step number 2.

5) Stop and start the vino server from the command line
Code:

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled false
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true

6) Connect to the target system using your vnc client.

ubuntu and debian linux help, hints, tips. Enabling VINO by command line

From the command line enter one of the following:
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled false

To actually start the vino server type:

/usr/lib/vino/vino-server

No need to reboot!

Update: Having done some extensive testing, the vino-server doesn't appear to want to start correctly when enabled remotely. So anyone with any ideas on how to make this work, please make yourself known!

Control the gnome VNC vino-server from the command line

srf21c

September 28th, 2006, 07:23 AM

NOTE: At long last here's the updated method. This was tested between two Ubuntu 10.10 Maverick hosts. Thanks to all the contributors to this thread, especially the posts by frafu (http://ubuntuforums.org/showpost.php?p=2333655&postcount=16) and InkyDinky (http://ubuntuforums.org/showpost.php?p=8308582&postcount=37)

user@localbox:~$ ssh -Y user@remotebox
user@remotebox:~$ vino-preferences
http://img69.imageshack.us/img69/6493/vinopreferences.png (http://img69.imageshack.us/i/vinopreferences.png/)
# check settings and hit close button
user@remotebox:~$ sudo -s
root@remotebox:~# export DISPLAY=:0.0
root@remotebox:~# xhost +
root@remotebox:~# /usr/lib/vino/vino-server &
# to start the vino server
root@remotebox:~# netstat -nl grep 5900
# check to make sure vino server is listening on port 5900
exit or CTRL-D twice to close SSH session to remotebox

user@localbox:~$ ssh -L 5900:localhost:5900 user@remotebox
# establish a new SSH connection to remotebox w/forwarded VNC port
# launch Remote Desktop Viewer (vinagre) under Applications => Internet and connect to localhost
http://img341.imageshack.us/img341/9817/remotedesktopviewer.png (http://img341.imageshack.us/i/remotedesktopviewer.png/)

motin

October 2nd, 2006, 02:13 AM

Very interesting. Although I am in the same situation I cannot really use your guide, since I am using Putty from Windows.. Can you maybe add some comments on how to achieve the same stuff in my situation? In case you know of course..srf21c

October 3rd, 2006, 02:35 AM

You are perfectable capable of setting each value in the /home/<userhomedir>/.gconf/desktop/gnome/remote_access/%gconf.xml file manually using the gconftool-2 command.

I was unable to dig up any documentation on proper syntax of the %gconf.xml file so I did not feel qualified on delving into this method in more detail on my original post.

If you examine an existing %gconf.xml file, and compare that to the gconftool-2 command syntax that I have already posted, you should be able to figure out how to set the other parameters.

motin

October 8th, 2006, 05:09 AM

I have come so far that the vino server asks me for a password. A password that I cannot remember at all.

The problem is that I cannot change it via CLI. It is not written in plain text in ~/.gconf/desktop/gnome/remote_access/%gconf.xml, so changing it to 'qwerty' in the file doesn't help.

Also, the command:

gconftool-2 -s -t string /desktop/gnome/remote_access/vnc_password qwerty

Just does the same thing as changing the file manually - ie doesn't help.

Do you or someone else now in what hash-type the vino passwords are written in?

motin

October 8th, 2006, 06:14 AM

I started a new thread on the matter (generating the password): http://ubuntuforums.org/showthread.php?p=1592817 srf21c

October 10th, 2006, 02:20 AM

Don't know what the vino server hash-type is, but here's the string I get after setting the vino password to 'qwerty'

<entry name='vnc_password' mtime='1160442984' type='string'>
<stringvalue>cXdlcnR5</stringvalue>
</entry>

jdong

October 10th, 2006, 04:44 AM

Have you tried an htpasswd hash in there?morton2002

October 13th, 2006, 05:11 PM

Many more details are available in the spun-off password thread (http://ubuntuforums.org/showpost.php?p=1613152&postcount=2). Thanks for your head-start on this, I found the posts very useful and I hope I've helped you too. srf21c

October 13th, 2006, 10:19 PM

I found a workaround that allows for logging in a user to the desktop remotely, simply edit the gnome desktop preferences to enable autologin, then reboot the box.

Edit the /etc/gdm/gdm.conf-custom file using your favorite text editor, and under the daemon section add the following lines

[daemon]
AutomaticLogin=<username>
AutomaticLoginEnable=true

Then reboot the box and the user will automatically be logged into the desktop on the next boot, thus starting the gnome vino vnc server (if enabled)

frafu

October 14th, 2006, 02:42 PM

@srf21c

I suppose the settings in /etc/gdm/gdm.conf-custom override those in /etc/gdm/gdm.conf

However, there is another question that I am wondering about: how can I enable the vino vnc server for the next boot on a system that is not running. (the disk with the system that does not run being mounted on another system)

Thanks in advance for your help.

frafu

Background:

I have a headless celeronbox with 2 ubuntu dapper systems on it; both systems have remote logins enabled (vino, nx, openssh). I would like to upgrade the second ubuntu to edgy, but I don't know whether the upgrade will disable the remote logins.

Consequently, I thought to edit menu.lst in grub to make it reboot after the upgrade with the system that has not been upgraded and reenable the remote logins from the new edgy before booting into edgy.

frafu

October 15th, 2006, 09:49 PM

I did the upgrade this afternoon and the update manager asked me several times whether I wanted to keep a specific old configuration file from dapper instead of installing the new one. As I kept the old configuration file for the remote desktop (and few others), I was able to connect with my vnc client at once after booting to edgy.

frafu

srf21c

October 16th, 2006, 09:54 PM

Excellent! In answer to your question, I think the bottom line is this; If you want the vino server to start hands-free after a reboot, you need to have automatic login to the desktop enabled. bobpaul

March 19th, 2007, 10:35 PM

I know it's digging up an old thread, but one could install a windows xserver (cygwin has one, or Xming is good) and enable X forwarding in putty. It's even easier if your local machine is also linux:

$ ssh -XC user@host

Then you could open vino-preferences remotely. vino-preferences is a simple enough GUI that even across a pretty slow connection it still responds decently.

EDIT: I meant uppercase C for compression. Good for slower speed connections. Lowercase c will cause an error. Sorry. Thanks to srfc21 for pointing that out.

srf21c

March 20th, 2007, 01:34 AM

Bob,

_great_ suggestion..much more elegant than my approach. Thanks for adding that to the thread.

Btw, have you tested it succesfully?

bobpaul

March 21st, 2007, 09:45 PM

Yeah, I use Xming and putty's X-Forwarding optional from my WinXP machine at work to access my home machine all the time! Errm, I mean.. I only do work related things at work. :-'

Bigger apps, like firefox, are pretty unresponsive, but small config windows like this work just fine. For reference, I have 128kbps upstream on my home connection. I think your command line solution would be the best method over something like dialup as it might take a few minutes for the dialog to 'stabilize' on a really slow connection like that.

frafu

March 21st, 2007, 10:22 PM

To open the 'Login Window' preferences, you have to type into the terminal after opening your ssh -Y connection:

sudo gdmsetup

To open the 'Remote Desktop' preferences, you have to type into the terminal:

sudo vino-preferences

But, the changes made in the forwarded preferences seem not to be effective in the session created by the auto-login at startup.

srf21c

March 27th, 2007, 08:37 PM

$ ssh -Xc user@host

Bob, I think the original command example you gave above might have a typo.

The lowercase -c option specifies the cipher to use, whereas the uppercase -C option enables compression. Did you mean to use the uppercase -C to enable compression? like this:

ssh -XC user@host

FXFman1209

June 6th, 2007, 03:43 PM

Hmm. I know this is an old thread, but.. does this work? I don't think you should use sudo with vino-preferences, because your vino preferences are per-user. If you use sudo vino-preferences, it would set the preferences for root, and not the user.

Therefore I propose that you login as the user you want to desktop control, and then just simply do vino-preferences.

However, I could be totally wrong, however it works fine for me. Thanks for the -X suggestion, i never even thought of doing that. :-P

theQmaster

June 17th, 2007, 07:42 AM

I have Dapper without keyboard and monitor and I need to connect the desktop to upgrade to Edgy. Remote access seems to be the only options thus far.. I have access to a sh session thru putty.

I managed to start x, vino and gdm - when I connect to the box with VNC client it looks like it's connecting but the client doesn't display any window - it looks that in background.. If I kill the vino server I get the windows that the connection has been disconnected..

What's wrong ? It looks that the server awaits for acceptance from the server but I don't get any window since I'm in sh, I only get a broadcast that a connection has been established

Any help?

theQmaster

June 17th, 2007, 08:01 AM

Just realised that my vino server is not starting anymore

mc@gsi:/tmp$ sudo /usr/lib/vino/vino-server

(vino-server:31773): Gtk-WARNING **: cannot open display:

Any good tips ?

frafu

June 17th, 2007, 03:03 PM

Do you have an X server running on your local machine? If so, try to connect through sh with the following command:

ssh -Y loginname@remotecomputerip

Because of the -Y option, the gui of the application started on your remote computer should be displayed on your local machine if there is a X server running on your local machine.

Particularly, you should be able to start the synaptic Package Manager and reinstall vino. Afterwards, you should start 'vino-preferences' from the shell which should display the gui of the preferences on your local machine. There you should be able to enable vino (=vnc server of the remote machine)

Have a nice day.

theQmaster

June 17th, 2007, 06:21 PM

I my windows' putty I typed the command by I get
ssh: connect to host localhost port 22: Connection refused

Do you have an X server running on your local machine? If so, try to connect through sh with the following command:

ssh -Y loginname@remotecomputerip

Because of the -Y option, the gui of the application started on your remote computer should be displayed on your local machine if there is a X server running on your local machine.

Particularly, you should be able to start the synaptic Package Manager and reinstall vino. Afterwards, you should start 'vino-preferences' from the shell which should display the gui of the preferences on your local machine. There you should be able to enable vino (=vnc server of the remote machine)

Have a nice day.

frafu

June 17th, 2007, 08:03 PM

Is there an ssh-server running on your remote computer? (If I remember correctly, the ssh-client gets installed by the default ubuntu installation, but the ssh-server is not.) I thought that the ssh server was running on your remote computer..

Do you have some way to access the remote computer with some shell? If so, you could use the command
sudo apt-get install openssh-server
to install the ssh-server.

Unfortunately, I don't have much knowledge about this things.

foxmajik

July 10th, 2008, 08:10 PM

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled trueThis doesn't actually stop or start the server, it just enables or disables the item in the configuration file.

$ gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
jpruitt@winkypop:~$ nmap localhost

Starting Nmap 4.53 ( http://insecure.org ) at 2008-07-10 15:09 EDT
Interesting ports on localhost (127.0.0.1):
Not shown: 1712 closed ports
PORT STATE SERVICE
22/tcp open ssh
631/tcp open ipp

Nmap done: 1 IP address (1 host up) scanned in 0.069 secondsThe vino binary lives here:

/usr/lib/vino/vino-server

I discovered this while researching after my vino server crashed when I tried to set rotation to normal in the resolution preferences dialog.

Unfortunately starting the server from the command line doesn't seem to make it read the configuration stored in your home directory, and since there's no documentation available I don't know which switches to use to make it read the config, nor do I know what the switches are to specify them on the command line.

$ 10/07/2008 03:18:19 PM Autoprobing TCP port
10/07/2008 03:18:19 PM Autoprobing selected port 5900
10/07/2008 03:18:19 PM Advertising security type: 'TLS' (18)
10/07/2008 03:18:19 PM Advertising authentication type: 'VNC Authentication' (2)
10/07/2008 03:18:19 PM Advertising security type: 'VNC Authentication' (2)

jpruitt@winkypop:~$ nmap localhost

Starting Nmap 4.53 ( http://insecure.org ) at 2008-07-10 15:20 EDT
10/07/2008 03:20:48 PM Got connection from client localhost
10/07/2008 03:20:48 PM other clients:
Interesting ports on localhost (127.0.0.1):
Not shown: 1711 closed ports
PORT STATE SERVICE
22/tcp open ssh
631/tcp open ipp
5900/tcp open vnc

Nmap done: 1 IP address (1 host up) scanned in 0.070 seconds

Unfortunately there is no man page for vino-server.

srf21c

September 24th, 2008, 06:18 AM

Documentation for the vino-server seems hard to come by, indeed.

One option would be to configure a user to automatically log into the desktop on startup, then restart the machine. That should get the vino server running again, without having to get some hands on the physical console.

foxmajik

September 24th, 2008, 12:43 PM

Documentation for the vino-server seems hard to come by, indeed.

One option would be to configure a user to automatically log into the desktop on startup, then restart the machine. That should get the vino server running again, without having to get some hands on the physical console.

Yes and then anyone who walked by the computer could drop in and delete your / directory, view all of your private documents, impersonate you on the Internet and all sorts of other fun things. I wish more people would do this.

raindog469

March 25th, 2009, 05:37 PM

Sorry to bump an old thread, but we have three desktops with wired connections, one running Hardy and the other two Intrepid, and vino-server works fine on them. But we also have a laptop running Intrepid, and even with automatic login enabled and remote desktop enabled, the server just never runs unless we run /usr/lib/vino/vino-server manually.

We think this is because the wireless card doesn't get initialized until after the user has automatically been logged in, creating a race condition where vino-server is trying to get an IP address that may or may not exist. But the gconftool commands also don't seem to cause vino-server to run.

Anyone have any ideas about this? I'm just about to install x11vnc and make a script to run it remotely like I used to have to do under Mandriva, but just using Vino would be more convenient.

Yes and then anyone who walked by the computer could drop in and delete your / directory, view all of your private documents, impersonate you on the Internet and all sorts of other fun things. I wish more people would do this.

I'm sure glad I don't live in a group home.

MidSpeck

April 16th, 2009, 11:02 PM

It's nice that all the information needed is practically linked to from this thread. However, I'm the sort of guy that likes it all in one spot.

Turn on Ubuntu's built-in VNC server when all you have is SSH: (may have to have the user logged on to the desktop already, I haven't looked into that part of things at all)

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
gconftool-2 -s -t bool /desktop/gnome/remote_access/vnc_password cXdlcnR5
gconftool-2 -s -t list --list-type string
/desktop/gnome/remote_access/authentication_methods '[vnc]'
gconftool-2 --type bool --set /desktop/gnome/remote_access/prompt_enabled 0

Make an SSH tunnel to port 5900 and use a VNC viewer to connect.

Note that when you set the vnc_password, it expects it to be base64 encoded. So you'll be able to tell that my VNC password above is simply 'qwerty'. There are plenty of online base64 encoders and decoders to help you generate your own password.

srf21c

May 4th, 2009, 10:23 PM

Thanks for consolidating the info into a single post. Good idea.mlalkaka

June 4th, 2009, 05:34 PM

Turn on Ubuntu's built-in VNC server when all you have is SSH: (may have to have the user logged on to the desktop already, I haven't looked into that part of things at all)

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
..
Make an SSH tunnel to port 5900 and use a VNC viewer to connect.

I know that this command used to work in one of the older versions of Ubuntu (prior to Intrepid Ibex, I believe). However, in the last few releases, this command only works locally. That is, if I run it over an SSH connection, it does nothing. If I run it locally, it actually enables vino server.

Has anyone else noticed this problem? I have noticed it in both Intrepid Ibex (8.10) and Jaunty Jackalope (9.04). How can I get the old functionality back?

mlalkaka

June 5th, 2009, 01:14 AM

It looks like I solved my own problem. :D

While trying to troubleshoot this issue, I decided to try running the vino-server executable directly (from an SSH connection):

$ /usr/lib/vino/vino-server --display=:0.0
Failed to open connection to bus: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.
The error message suggested that the problem may in fact have more to do with D-Bus than GConf or vino. So, after reading the man pages of dbus-launch and dbus-daemon, I decided to try running gconftool through dbus-launch:

dbus-launch gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
This worked perfectly.

Alternatively, you can also set the environment variables from the file ~/.dbus/session-bus/*-0 (where * is some unique identifier for your computer) manually, or import it into a shell script.

I've attached a Bash script called toggle_vino_server.sh that you can use to enable and disable remote desktop remotely using SSH. There is no need to forward X over SSH to do this either.

Before I go any further, though, I must state that the script comes with no warranty whatsoever, and I'm not responsible for anything that happens to you, your computer, or your pet rat, for that matter, by using this script.

Simply save the script to ~/bin, give the file executable permissions, and run it from the command-line. It takes no parameters -- it will enable the server if it is disabled, and disable the server if it is enabled.

sixerjman

July 12th, 2009, 05:50 AM

Again, setting the gconf preference for enabling or disabling remote desktop
does not address the problem of vino-server not running.

At some point if the vino-server crashes, you need to start it up to have a process listening on port 5900 or whatever port the server is configured to listen to. dbus-launch fails to start vino-server if the X11 authentication
is not done.

bobpaul

July 12th, 2009, 03:39 PM

Again, Again? Have you addressed this somewhere else? Please link for context.

setting the gconf preference for enabling or disabling remote desktop does not address the problem of vino-server not running. The gconf preference is polled. If you set it and vino is not running, vino will be launched. If you clear it and vino is running, vino will be killed. If you are not experiencing this behavior, you may have found a bug. Please test from a LiveCD or a fresh install and if the problem persists in that environment, file a bug report.

At some point if the vino-server crashes, Crashes are caused by bugs. If you can reproduce the crash consistently, please file a report.

dbus-launch fails to start vino-server if the X11 authentication is not done. This is by design. Vino only works on locally logged in X11 sessions. If you need a system for remote sessions only, try tightvncserver, vncserver, or one of the other vnc servers. Alternatively, I highly recommend freenx, as it provides persistent sessions and is much faster.

johnkzin

July 12th, 2009, 03:52 PM

Is there a way to get vino (at the command line OR the GUI) to only accept connections via localhost? or to specify a port number (5901, 5902, etc.)?

I ask, because this documentation:

https://help.ubuntu.com/community/VNC/Servers

says vino has an 'advanced' tab for restricting access to localhost .. but the GUI control for vino under 9.04 doesn't show an advanced tab. I started to look at the command line options, to see if it was just missing from the GUI control (but that the underlying functionality might still be there). But I haven't found those options anywhere.

Is there another widget for controlling vino? Is the stuff in the 'Advanced tab' still there, but only accessible via the command line?

But, really, what I want is:

1) make vino accessible only via localhost (ie. must use SSH)
2) make vino use a port of my choosing (or fail; don't choose a different port)

bobpaul

July 12th, 2009, 07:51 PM

Is there a way to get vino (at the command line OR the GUI) to only accept connections via localhost? or to specify a port number (5901, 5902, etc.)?

1. Install gconf-editor. It will show up as Applications->System Tools-> Configuration Editor.

2. Browse to /desktop/gnome/remote_access

3. Set 'network_interface' to 'lo' for local access only.

4. Modify 'alternative_port' to change the port used. Additionally, check the box next to 'use_alternative_port'.

Settings apply immediately. Simply close 'Configuration Editor' when you're done.

I ask, because this documentation:

https://help.ubuntu.com/community/VNC/Servers

That documentation is out of date. The advanced tab was removed a number of releases ago. I'm not sure why.

johnkzin

July 12th, 2009, 08:47 PM

Thanks very much! exactly what I needed.InkyDinky

November 13th, 2009, 04:31 PM

For those that stumble upon this thread trying to start vino from the cli via a remote ssh connection look here: http://ubuntuforums.org/showthread.php?t=1017746
at post #7

1. ssh to that machine and authenticate as x
2. sudo -s to become root
3. export DISPLAY=:0.0
4. xhost +
5. exit from root shell using exit
6. export DISPLAY=:0.0
7. start vino-server using /usr/lib/vino/vino-server

There may be another way but this saved my bacon after the Karmic upgrade when I needed to get my desktop and vino wasn't started.

Apfelfrisch

November 26th, 2009, 10:02 AM

Thanks a lot. The first tip that works!olangelsa

December 5th, 2009, 03:23 AM

dbus-launch gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true

Thanks mlalkaka.

You solved my problem as well. I have previously been using gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true and false to enable and disable remote desktop capabilities. However, I could not make this work in Ubuntu 9.10. But once I prefixed the command with dbus-launch, as suggested by your code above, it works perfectly.

Thank you very much.

marwooj

December 29th, 2009, 01:50 PM

Does anybody know how to start full gnome session from Putty X11 forwarding?doobiest

March 3rd, 2010, 09:43 PM

For those that stumble upon this thread trying to start vino from the cli via a remote ssh connection look here: http://ubuntuforums.org/showthread.php?t=1017746
at post #7

1. ssh to that machine and authenticate as x
2. sudo -s to become root
3. export DISPLAY=:0.0
4. xhost +
5. exit from root shell using exit
6. export DISPLAY=:0.0
7. start vino-server using /usr/lib/vino/vino-server

There may be another way but this saved my bacon after the Karmic upgrade when I needed to get my desktop and vino wasn't started.

This worked perfectly for me, and really only 6 & 7 are needed.

6. export DISPLAY=:0.0
7. start vino-server using /usr/lib/vino/vino-server

I would a & actually, so /usr/lib/vino-server &

If this happens often you could create a script like I did

sudo vi /usr/local/bin/restart_vnc

insert these two lines

export DISPLAY=:0.0
/usr/lib/vino/vino-server &

save (:wq)

sudo chmod +x /usr/local/bin/restart_vnc

Also the gconf tips here dont work. I'm sure that toggles the config options but doesnt restart a crashed server.

Also I've experienced that SSH -X or -Y and issuing vino-preferences doesnt work. What is actually does it spawn a vino server on the client machine (if linux i guess) so when you vnc through your ssh tunnel it just loops back to your clients desktop.

bobpaul

March 3rd, 2010, 10:17 PM

Also I've experienced that SSH -X or -Y and issuing vino-preferences doesnt work. What is actually does it spawn a vino server on the client machine (if linux i guess) so when you vnc through your ssh tunnel it just loops back to your clients desktop.

If you ssh in and execute vino-preferences, it's running on the remote machine; only the UI is forwarded to the local X11 server. vino-preferences running in this way does not have access to the files/services on the local machine anymore than it would if you were sitting at the remote machines keyboard and running vino-preferences there. If vino-server was running on your local machine, it's either because it was already running or you ran vino-preferences on the local machine instead of the remote host.

You stated 'so when you vnc through your ssh tunnel'.. How did you have your port tunnel (-L) setup? My guess is you connected to the local vnc server on localhost directly instead of connecting to the ssh client's port tunnel. It didn't loop back.. it never even left your machine.

doobiest

March 3rd, 2010, 10:26 PM

#ssh -X destination
#vino-preferences
*close vino-preferences
#ps aux grep vino (shows the server running now)
#vncviewer -via destination localhost (executed locally, not in the ssh session)

This redirected me to my local vncsession, not the remote one. And No I have verified that the vino-server is not running locally on my client

It's completely reproducable I jsut did it right now again. It does run vino-server on the remote computer but it's attached to my local X display, not the remote one. If I close the ssh connection, then of course it stops vncing to my local session and doesnt vnc to the remote session either. The processing for the service might be occuring remotely but the routing is still going local.

doobiest

March 3rd, 2010, 10:34 PM

There's no level of technical accuracy here but this should describe what is happening.

[vncviewer]-->[ssh tunnel]-->[remote vnc server]
[local X ]<--[ssh tunnel]<--[remote vnc server]
[local X ]-->[ssh tunnel]-->[remote vnc server]
[vncviewer]<--[ssh tunnel]<--[remote vnc server]

(Following the arrows, read some lines left to right and some lines right to left)

ps aux grep vino-server on Local box = NO
ps aux grep vino-server on Remote box = YES

Are we certain that X11 Forwarding ISNT bi-directional? It sure seems that way to me.

tormod

April 8th, 2010, 03:02 PM

Yes, doobiest is right, just running vino-preferences over an X11-forwarding ssh session might start a vino-server controlling the local (to you) display. This was also mentioned here http://ubuntuforums.org/showpost.php?p=6412467&postcount=4

You can verify which X server (display) the vino-server is controlling with:

cat /proc/`pgrep vino-server`/environ tr '0' 'n' grep DISPLAY
If it shows DISPLAY=:0.0 it is the local display on the remote machine, thus the remote screen (which you most likely want to access). If it shows for instance DISPLAY=localhost:10.0 it is tunneling back through your X11-forwarding ssh connection and thus to your local screen and you get a loop.

The use of dbus-launch lets vino-server be started by the dbus server running in the remote session, so that it connects to the display of that session.

tormod

April 8th, 2010, 03:35 PM

So here is how to make this work (tested on Ubuntu 9.10):
Connect with ssh -X to your remote machine. Find the dbus address of the processes in the desktop session running 'locally' on the remote machine, for instance the nautilus process:

cat /proc/`pgrep nautilus`/environ tr '0' 'n' grep DBUS
Now start vino-preferences on the remote machine but set the DBUS address which you found above:

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-blahblah.. vino-preferences
You can now run vinagre on your local machine.

Ssh Tunnel Iphone

On the other hand, the use of dbus-launch with gconftool-2 makes vinagre start on the right display, however the changes made in the vino-preferences GUI are not applied to the started server. At least that was what happened here, where I ended up with a bunch of dbus and gconf servers running. Even if I turned off the 'You must confirm each access to this machine' in the GUI, this option stayed on for the started vino-server, so I could not connect to the unattended machine.

doobiest

April 9th, 2010, 04:16 AM

Thanks thats actually very helpful. I need to take a deeper look at that.

I'll post this again, because I think what you posted may be too complicated for some users who don't have the background knowledge in this area.

Making a script like is worked great for me. I usually find vino crashes (inconsistently) when I'm using the clipboard. I can run vnc_restart from ssh easily to gain access again.

doobiest@LinuxBox:/usr/local/bin$ cat vnc_restart
export DISPLAY=:0.0
/usr/lib/vino/vino-server &

dekelev

November 12th, 2010, 10:48 PM

Quick & Easy setup for connecting to a gnome session on ubuntu 10.04

configure the user on the remote computer:
1. remove /home/user/.gnome2/keyring/default.keyring or login.keyring
2. run command: sudo apt-get install libpam-keyring
3. append to /etc/pam.d/gdm: @include common-pamkeyring
4. log out and back
5. set 'System->Prefrences->Remote Desktop' ---> when you asked to enter a keyring give an empty password

every time you want to connect from a client computer:
vncviewer -via remote_host localhost:0
OR
vnc into port 5900 at ip_address from any vnc client

Car mechanic simulator 2015 download free. Car Mechanic Simulator 2015, free and safe download. Car Mechanic Simulator 2015 latest version: Car repair and business management simulator. Car Mechanic Simulator 2015 is a simulator based around running a garage. Take repair jobs, fix v.

Enjoy!

mattnworb

January 24th, 2011, 04:21 PM

Quick & Easy setup for connecting to a gnome session on ubuntu 10.04

configure the user on the remote computer:
1. remove /home/user/.gnome2/keyring/default.keyring or login.keyring
2. run command: sudo apt-get install libpam-keyring
3. append to /etc/pam.d/gdm: @include common-pamkeyring
4. log out and back
5. set 'System->Prefrences->Remote Desktop' ---> when you asked to enter a keyring give an empty password

every time you want to connect from a client computer:
vncviewer -via remote_host localhost:0
OR
vnc into port 5900 at ip_address from any vnc client

Enjoy!

This has the nasty side-effect of storing any passwords that you save in applications (such as Pidgin or Thunderbird) in plaintext, under ~/.gnome2/keyrings.

Since your user is logged into the machine automatically, then effectively anyone who has physical access to the machine can force a restart and then, if they know where to look, find your passwords.

laciba

February 17th, 2011, 10:33 PM

Another simple workaround that did the trick for me,
in case you unfortunately logged out or rebooted the remote
machine and no automatic login was set previously.
(and if you even want to use vino-server as vnc server after this annoying fact)

The method requires only common sense :)

1.ssh <remote IP> (without -X)
2.sudo -s
3.apt-get install x11vnc (if not yet installed)
4.x11vnc -rfbport 5901 (or use any port not configured for vino-server)
(you may also have to configure a new tunnel for 5901 port if you played the secure way)
5. now you can reach logon screen with any vncviewer connecting to the 5901 port
6. logon to the remote machine and after that close vncviewer (this also halts the x11vnc server)
7. reconnect to the original vino-server on the original 5900 port.

kruykaze

May 13th, 2011, 09:29 AM

Another simple workaround that did the trick for me,
in case you unfortunately logged out or rebooted the remote
machine and no automatic login was set previously.
(and if you even want to use vino-server as vnc server after this annoying fact)

The method requires only common sense :)

1.ssh <remote IP> (without -X)
2.sudo -s
3.apt-get install x11vnc (if not yet installed)
4.x11vnc -rfbport 5901 (or use any port not configured for vino-server)
(you may also have to configure a new tunnel for 5901 port if you played the secure way)
5. now you can reach logon screen with any vncviewer connecting to the 5901 port
6. logon to the remote machine and after that close vncviewer (this also halts the x11vnc server)
7. reconnect to the original vino-server on the original 5900 port.

sudo x11vnc -rfbport 5901 works very well thank you

Byb

March 7th, 2013, 03:43 PM

NOTE: At long last here's the updated method..
root@remotebox:~# xhost +

Glad to find someone dug this problem and shares
Although, now I've set my ssh stuff along with the recommended burden of keys authentication, when I issue the xhost + command
I get this and can't go further

root@pc:~# xhost +
No protocol specified
No protocol specified
xhost: unable to open display ':0.0'
Please what is going wrong? I am using LTS12.04.2 with gnome-panel on both computers.
Thank you

Etc

Society

Groupthink :Two Party System as Polyarchy : Corruption of Regulators :Bureaucracies :Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia :Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience :Who Rules America :Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace: Skeptical Finance : John Kenneth Galbraith :Talleyrand :Oscar Wilde :Otto Von Bismarck :Keynes :George Carlin :Skeptics :Propaganda : SE quotes : Language Design and Programming Quotes :Random IT-related quotes : Somerset Maugham :Marcus Aurelius :Kurt Vonnegut :Eric Hoffer :Winston Churchill :Napoleon Bonaparte :Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Ssh Tunnel Putty

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis :Political Skeptic Bulletin, 2013 :Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments :Slightly Skeptical Euromaydan Chronicles, June 2014 :Greenspan legacy bulletin, 2008 :Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) :Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 :Inequality Bulletin, 2009 :Financial Humor Bulletin, 2008 :Copyleft Problems Bulletin, 2004 :Financial Humor Bulletin, 2011 :Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult :Political Skeptic Bulletin, 2011 :Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering :Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds :Larry Wall :John K. Ousterhout : CTSS : Multix OSUnix History : Unix shell history :VI editor :History of pipes concept :Solaris : MS DOS : Programming Languages History :PL/1 : Simula 67 :C :History of GCC development : Scripting Languages :Perl history :OS History : Mail :DNS : SSH : CPU Instruction Sets :SPARC systems 1987-2006 :Norton Commander :Norton Utilities :Norton Ghost :Frontpage history :Malware Defense History :GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 :The Mythical Man-Month : How to Solve It by George Polya :The Art of Computer Programming :The Elements of Programming Style :The Unix Hater’s Handbook :The Jargon file :The True Believer :Programming Pearls :The Good Soldier Svejk : The Power Elite

Ssh Tunnel Ubuntu

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society :Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story :The Cuckoo's Egg :IT Slang : C++ Humor : ARE YOU A BBS ADDICT? :The Perl Purity Test :Object oriented programmers of all nations : Financial Humor :Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor :Goldman Sachs related humor :Greenspan humor : C Humor :Scripting Humor :Real Programmers Humor :Web Humor : GPL-related Humor : OFM Humor :Politically Incorrect Humor :IDS Humor : 'Linux Sucks' Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor :Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor :Networking Humor :Shell Humor :Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 :Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor :Education Humor : IBM Humor : Assembler-related Humor :VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

Ssh Tunnel Manager Windows

The Last but not LeastTechnology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2020 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICEThis site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree..

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: October 03, 2017