On Linux, we require Admin-level access to allow the machine, on startup, to start a virtual desktop session for the user without that user's intervention. The set of accounts authorized to start Chrome Remote Desktop sessions on boot is defined by the 'chrome-remote-desktop' POSIX group account.

Even if it were technically not required by the implementation, it is desirable for security that an Administrator should determine which user-accounts should be allowed to configure remote access.

If an Administrator adds your account to the chrome-remote-desktop group, you can then enable Chrome Remote Desktop without needing any further privileges.

It is unfortunate that the spinner spins forever without failing fast. We use PolicyKit to prompt for a root (or user) password to gain privileges to add the account to 'chrome-remote-desktop'. It's possible that PolicyKit is not properly configured on the system, or configured to not allow a graphical (X11) password prompt (maybe some /dev/ttyXX is waiting for a typed password). Or there could be a problem in our implementation where we are not detecting the failure condition.

We recently changed the implementation to use 'pkexec' instead of 'gksudo', and maybe this is not working well on Ubuntu 14.04 (I think I recall that later versions of Ubuntu allow pkexec to show a graphical password prompt).

I can enable and set up a PIN at my elementary OS (Ubuntu) host, but when I go to connect from another computer (Mac), I enter the PIN and immediately get, "The remote computer is not responding to connection requests. Please verify that it is online and try again." (I don't see any useful open tickets on that phrase.) What should I be looking for in my /tmp/chrome_remote_desktop* logs? I have added my user to the `chrome-remote-desktop` group as mentioned above.

Same issue for me. After several purges, uninstalls, reinstalls, this error finally went away. Unfortunately, I cannot say at all how I fixed the problem. Interestingly enough, I was able to consistently get prompted for root privileges on the first time run by reinstalling the CRD host .deb from source: sudo dpkg -i chrome-remote-desktop_current_amd64.deb

It was after one of these reinstalls that the hanging problem finally went away. Though, it did take me about 4 hours of fiddling, so I think it counts as a legitimate bug.

I have found a way to get around this problem fairly consistently. I don't know if this helps with the reproducibility, but it might help someone with a temporary fix.

0. If your computer is still showing up as "enabled" or greyed out in the list of available PCs in the CRD app, remove/disable anything associated with the host machine.
1. Purge the CRD host app from you computer: $ sudo apt-get purge chrome-remote-desktop
2. Remove the CRD extension from Chrome
3. Remove residual files associated with CRD: 
    $ sudo rm -rf ~/.config/chrome-remote-desktop
4. Remove all files associated with CRD extension (there will be multiple extension IDs if you have installed CRD multiple times). The following command removes all extensions, so replace the wildcard with the CRD extension identifier(s) if you want to keep your other extensions:
    $ sudo rm -rf ~/.config/google-chrome/Default/Extensions/*
5. Reboot your machine.
6. Reinstall CRD extension through Chrome.
7. Download the CRD host app and install from source:
    $ sudo dpkg -i chrome-remote-desktop_current_amd64.deb

After performing all of these steps, you should be able to open the CRD app and click the "Enable remote connections" button, which should prompt you for your root password. I ended up having to do this 3 or 4 times and the steps above consistently got CRD to prompt me for the password at this step, which is critical for enabling the remote connection.

Lastly, if you are going to fiddle with editing any files to troubleshoot the many other problems associated with getting CRD workign on Linux, make sure you always restart the CRD daemon after making changes: $ sudo /etc/init.d/chrome-remote-desktop restart

Reinstalling did not work for me. What did was to modify the CRD script and is based here:
https://productforums.google.com/d/msg/chrome/WvcFOblHMik/hGlM875QAwAJ

Note that in my case, it is a server Ubuntu 16.04 with LXDE (LUbuntu)

If you check the generated logs in /tmp/ folder you would see the UI component crash:
**************************[0714/142543.989082:INFO:remoting_me2me_host.cc(1354)] Policy enables security key auth.
[0714/142543.989090:INFO:remoting_me2me_host.cc(575)] Processing new host configuration.

(chrome-remote-desktop-host:5573): Gdk-WARNING **: chrome-remote-desktop-host: Fatal IO error 2 (No such file or directory) on X server :20.

2017-07-14 14:25:44,055:INFO:wait() returned (5573,256)
2017-07-14 14:25:44,055:INFO:Host process terminated
**************************

And in my case it is CRD host not recognizing the installed desktop environment, which is LXDE (LUbuntu)

First, install other packages related to the desktop LXDE (LUbuntu)

$ sudo apt-get install -y lxde lxde-common lubuntu-core lubuntu-icon-theme lubuntu-restricted-extras

Then, in this file: /opt/google/chrome-remote-desktop/chrome-remote-desktop
Change the one instance of /usr/sbin/lightdm-session 
to the right desktop environment command /usr/bin/startlxde

$ sudo vim /opt/google/chrome-remote-desktop/chrome-remote-desktop
**************************
857c857,858
<     "/usr/sbin/lightdm-session",
---
>     # "/usr/sbin/lightdm-session",
>     "/usr/bin/startlxde",
**************************

To enable resizable desktop, create a new script /opt/google/chrome-remote-desktop/Xvfb-randr

$ sudo touch /opt/google/chrome-remote-desktop/Xvfb-randr
$ sudo chmod +x /opt/google/chrome-remote-desktop/Xvfb-randr

With this content:
**************************
#!/bin/bash
exec /usr/bin/Xvfb +extension RANDR $*
**************************

Finally, restart the service:
$ sudo service chrome-remote-desktop restart

After that, try to enable the remote host again, and it should work

There are a few different reports here, so it's hard to be sure they all have the same underlying problem, but a known issue is that it can take a while (up to 10 minutes) before a host becomes connectable after setting it up.

Since the original bug was about requiring root to set up CRD, which is by design, I'm going to close this bug. If anyone is still seeing any of the other issues reported, even after waiting 10 minutes, please file a new bug.