gnome-keyring-manager interferes with the VNC server

Bug #562423 reported by Yann Papouin
158
This bug affects 27 people
Affects Status Importance Assigned to Milestone
vino
New
Unknown
vino (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: vino

Actual configuration

PC A : Ubuntu Lucid Lynx (upgraded from an updated 09.10) with distant desktop enabled
PC B : Another OS with vncviewer

After the first start of PC A, if I launch vncviewer on PC B with correct login/password to view the PC A desktop, vncviewer waits for the connection acceptation. I have to go to the PC A and enter my user password in the "gnome-keyring-manager" window that appeared after the first connect attempt of PC B. After password acceptation, PC B vncviewer is able to connect/disconnect without any problems.

Why vncserver needs my user password to know it's own password ?

Revision history for this message
Cr0n_J0b (cr0n-j0b) wrote :

I have the same issue. I'm running a fresh install of Lucid 10.04 beta 2. Loaded yesterday. When I log in to my server with VNC the first time after a reboot it will ask for a password at the console before VNC session will open. Once I enter the password at the console I'm good.

I have the system setup to automatically login to the main user.

Revision history for this message
Yann Papouin (yann-papouin) wrote :

Ok, the explanation can be different after a daily use. On GNOME start, Gwibber need my password for the keyring manager to launch MSN, Facebook IM etc... that's why the dialog popup (even if I remotly started my PC).

It seems that the keyring manager accept only one application at a time, that's would be why the vncserver do not accept incoming connections as the password dialog input window is not closed.

Revision history for this message
Jackflap (deriziotis) wrote :

Yann, I tested without Gwibber set-up.

My desktop doesn't ask me to unlock my keyring when it starts up, but it does when I try to remote desktop. It is definitely being triggered by the remote desktop connection.

Jackflap (deriziotis)
Changed in vino (Ubuntu):
status: New → Confirmed
assignee: nobody → Jonh Wendell (wendell)
Revision history for this message
Buntbart (buntbart) wrote :

The problem occurs in combination with automatic login, because then the gnome-keyring is not opened automatically. So if you boot a computer with wakeonlan with automatic login, you won't be able to reach a vino-session from remote because you are not able to unlock the gnome-keyring.

The solution seems to be NOT to use gnome-keyring to store the vino-password.

btw. the problem doesn't occur with a computer which was updated from Karmic! This one seems to store the password in another place (too?), so there is no need to unlock the gnome-keyring. Unfortunately I don't know where the password was stored in Karmic or which option to change in gconf-editor. It should be easy to find a workaround but I haven't found it yet.

Revision history for this message
Buntbart (buntbart) wrote :

I found out there was a discussion in the developer-team of vino in 2006, see
     https://bugzilla.gnome.org/show_bug.cgi?id=344839
They decided to implement an option to use gnome-keyring for security-reasons, but they also decided to leave it off by default because "it's not really a good idea"

I have no idea why the one who compiled vino-server for Ubuntu 10.04 decided different now and why he doen't tell us.

Please use gconf again to store the vnc-password!
It will be stored Base64-encoded in $HOME/.gconf/desktop/gnome/remote_access/ and this is secure enough, I think. If someone has unallowed access to this file, you have bigger security-leaks than a weak vnc-password-encryption.

Jackflap (deriziotis)
Changed in vino (Ubuntu):
assignee: Jonh Wendell (wendell) → Ubuntu Development Team (ubuntu-dev)
Changed in vino (Ubuntu):
assignee: Ubuntu Development Team (ubuntu-dev) → nobody
Revision history for this message
Nigel Babu (nigelbabu) wrote :

@Jackflap: Please DO NOT assign bugs to others.

Revision history for this message
Jackflap (deriziotis) wrote :

Since the package Maintainer of vino is listed as the 'Ubuntu Development Team', isn't it logical that they be notified of this bug?

This is quite a serious usability issue and a number of people have now taken the time to diagnose and investigate it. I'm certain that whoever packaged it would appreciate being notified.

How do we go about notifying the appropriate individual? Is it NOT the Ubuntu Development team? Was the package sync'd from Debian testing during development perhaps? Should we be contacting the Debian maintainer?

Can someone help clarify what to do here?

Revision history for this message
Nigel Babu (nigelbabu) wrote :

The maintainer of the package will get around to it. These past weeks they were either occupied with release or sprints. When the right folks have the time, they will get around to it. It is extremely rude to assign bugs to a person or team without their explicit permission (unless you're assigning to yourself and you intend to fix it). Please be patient, someone will get around to fixing this issue.

Revision history for this message
Nigel Babu (nigelbabu) wrote :

I just hunted down and these changes were done at debian level some time back or upstream level, Ubuntu-specific changes in this package do not create this problem.

Revision history for this message
Jackflap (deriziotis) wrote :

Thanks very much for the help Nigel.

I installed the 'vino' package from Debian unstable in Lucid and confirmed the bug is still present. I also installed Karmic's package in Lucid just to re-confirm that it solves the issue.

I'll submit this bug to the Debian bugtracker tomorrow and contact the maintainer to see what he wants to do.

Revision history for this message
bigdigiman (bigdigiman) wrote :

I have found a workaround for this issue on 10.04.

Open up Applications->Accessories->Passwords and Encryption Keys

Right click Passwords:login and unlock it.

You should be able to expand the tree and find a listing for vino. Right click and delete it.

Close Passwords and Encryption Keys.

Open gconf-editor as and navigate to /desktop/gnome/remote_access

Enter in your BASE64 encoded password into the vnc_password key.

Save the config and close the editor.

Reboot and you can now use your VNC client to connect to your machine without being first prompted with the keyring.

Changed in vino:
status: Unknown → New
Revision history for this message
Buntbart (buntbart) wrote :

Thanks, bigdigiman for this workaround!
It works as long as I know what my password is in BASE64.
But how do I convert a new password to BASE64?

Revision history for this message
bigdigiman (bigdigiman) wrote :

There are many web pages that will do it for you.

Here is the first google hit: http://www.motobit.com/util/base64-decoder-encoder.asp

NOTE: You will be sending your password in clear text to the web page provider that will convert it to BASE64 for you. They won't necessarily know it's your password or anything, but I just wanted to warn that you are giving it to someone.

Revision history for this message
Hans Henrik (hanshenrik123) wrote :

@bigdigiman
converted from that site, result: password didn't work

Revision history for this message
bigdigiman (bigdigiman) wrote :

@Hans

I don't support/maintain or have any connection to the site. It was simply (as stated) the first google hit for a web service that would convert a string to BASE64. Conversions to BASE64 usually end with an '=' character or two and are important and should not be excluded. There could also be a copy-paste error, such as the inadvertent inclusion of a new line or space character. It could also be that the vino service was not restarted after you made the changes and therefore is still operating on the previously loaded settings.

Revision history for this message
Hans Henrik (hanshenrik123) wrote :

@bigdigiman
i have tried the workaround 3 times, can't get it to work :(
last time also wrote the BASE64 string manually, at least 90% sure it was no typing error
(i copied what i had wrote, compared it in gedit, and the 2 strings did look exactly alike)

Revision history for this message
Hans Henrik (hanshenrik123) wrote :

ah, scrub that, i do get it to work, as long as i dont run gconf-editor in sudo. sorry!

Revision history for this message
bigdigiman (bigdigiman) wrote :

@Hans - I guess I should have made it clear that I was expecting that you were running under the user that was to be auto-logged in.

Revision history for this message
snek (snekone) wrote :

So it is only possible to fix this from the actual machine itself?
I am currently not near this computer and it might be handy for others as well to know how to do this from command-line (if at all possible).

But seriously, this really needs to be fixed.

Revision history for this message
emperlium (emperlium) wrote :

Thanks bigdigiman, your solution worked for me.

BTW, you can generate the base64 password at the command line;

echo -n "your password" | base64

Revision history for this message
Andrea Lattanzi (andrea-archimedes) wrote :

I found the same bug only when configuring Vino checking the box option: "Configure network automatically to accept connection"
When I check this option the system asked me to set and confirm a new keyring password that could be different respect VNC access password.

Uncheck this box or reinstall Lucid has no effect.

Revision history for this message
emperlium (emperlium) wrote :

If you're setting up a new machine or one where you haven't already set a remote desktop password, this can be done from the command line;

vi ~/.gconf/desktop/gnome/remote_access/%gconf.xml

<?xml version="1.0"?>
<gconf>
        <entry name="vnc_password" mtime="1285453727" type="string">
                <stringvalue>your base64 password</stringvalue>
        </entry>
        <entry name="prompt_enabled" mtime="1285453727" type="bool" value="false"/>
        <entry name="authentication_methods" mtime="1285453735" type="list" ltype="string">
                <li type="string">
                        <stringvalue>vnc</stringvalue>
                </li>
        </entry>
        <entry name="enabled" mtime="1285453720" type="bool" value="true"/>
</gconf>

Revision history for this message
Guillaume Coté (gh-guillcote) wrote :

Which version of the package did you installed to solve the issue?

Revision history for this message
Cy Walker (astarothdeathsquirrel) wrote :

I appreciate that this may not be the right way to go about it but I have managed to get this to work for me.

I currently have Ubuntu running on an old computer which I use as a file-server, ftp -server, http intranet server and fuppes media server. I was set to auto login and run fuppes on startup so that all I had to do was switch on and everything worked. I would use VNC to control the server and did not need a keyboard or screen attached to the server.

I recently upgraded to 10.04 Lucid and found I had the annoying problem that it would not connect to the network without putting in my password again to unlock the key-ring which meant that I could not use VNC to control the server. I tried different methods including setting the keyring password to nul (blank) and playing with "sudo apt-get install libpam-keyring" but without any success. So in desperation, I stopped the keyring apps from starting in the first place.

System|Preferences|Startup Applications:

unticked the following:
Bluetooth Manager - Don't need it, not running anything bluetooth.
Certificate and Key Storage.
Secret Storage Service..
Ubuntu One - Don't need it
Visual Assistance - Don't need it.

Now, it runs and connects without issue or password request. Just tested ftp and that works fine too. Http working fine. Shared directories are fine. Now I just need to get my fuppes to run on startup and I'll be happy.

If you need to use "Certificate and Key Storage" and "Secret Storage Service" then this probably won't help you but I think it would indicate that there is a problem either with these services or the way they communicate with other services. I confess to being a complete Ubuntu noob but I hope this points people in the right direction.

Revision history for this message
Hans Henrik (hanshenrik123) wrote :

im surprised to see this bug has not been fixed yet;its really annoying and makes "remote desktop" for managing a computer without physical access virtually useless...
i suggest putting a medium priority on this one... >.<

Revision history for this message
mike (mike-vodopyanov) wrote :

I am surprised too. This bug is really annoying.

When I want to help my parents (70 years old) they must enter a password. It is difficult for them every time.

Revision history for this message
o.dima (dio-mail) wrote :

workaround doesn't work in 10.10
tried 3 times as described here:
http://www.lamolabs.org/blog/4380/one-liner-gnomes-vnc-server-vino-prompts-for-the-gnome-keyring-password-on-ubuntu-10-04/
of course running gconf-aditor with sudo
but it seems that /desktop/gnome/remote_access entry is not used by the system

Revision history for this message
Dr Evil (dr-evil--23) wrote :

Workaround described here DO work in 10.10

but you must NOT use gconf-editer with sudo, that's all

worked at the first try

Thanks again guys ! ;)

Revision history for this message
Artem Gabrielyan (synthakai) wrote :

Ubuntu 10.10
#11 + #20 works ok :) thanks

Revision history for this message
Hans Henrik (hanshenrik123) wrote :

dunno if its related/significant but
as of
24.04.2011
21:29:48
a fully updated Debian 6 also suffers this issue. and the described workaround here works in debian 6 also. :p

Revision history for this message
Malac (malacusp) wrote :

You can also issue a 'killall gnome-keyring-daemon' from the command line if you are ssh'ing in from a terminal first or using putty.
You can then bring up the desktop with vnc.
Full description from windows machine:
Open putty and connect.
Open vncviewer and connect.
Issue 'killall gnome-keyring-daemon' in putty vncviewer password prompt pops up
Enter vnc password.
You may have to issue another 'killall gnome-keyring-daemon' to get the desktop to show. Sometimes you do, sometimes you don't.
This worked everytime for me.

Hope this helps

Revision history for this message
Tom Oehser (tom-toms) wrote :

Weird, I can just 'kill -9' the 'gnome-keyring-prompt-3' and then it works fine...
It isn't even really wanting/needing the keyring to be unlocked!

  _why would it trigger a keyring unlock prompt if it doesn't need the keyring unlocked_

and

 _could the gnome-keyring connection just be removed completely from vino_

I mean, there is no auto-login. They keyring should _BE_ unlocked. There are *2* keyring-daemons running... (???WHY???). Maybe it is trying to use the wrong one? All of this buggery in the gnome-keyring is annoying enough by itself. Having that exist on xubuntu/xfce4 is a dollop of additional annoyance. But...

... I could stand it, if it even needed the unlock! But it doesn't! I can just KILL THE PROMPT from ssh, leaving whatever was locked, locked... and it lets the VNC viewer in! Insanity!

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

I haven't had this issue on recent Ubuntu releases. Is this still reproducible?

Revision history for this message
Leo (2-leo-a) wrote :

Hit this issue today trying to enable vino from a remote ssh terminal. Took me half a day to figure out that the server side popped up the keyring window causing TightVnc client to hang during authentication.
Sad :(

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.