UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36

Steps to reproduce the problem:
The easiest way to reproduce this problem is to install Chrome in a container. See https://chrome-remote-cloud-linux.github.io/ for an example.

1. In a fresh install of Chrome and of a Linux desktop environment, go to remotedesktop.google.com
2. Try to turn on remote desktop
3. After picking a PIN, the installer attempts to add the user to the group "chrome-remote-desktop". This requires root permissions. The password prompt is shown in the *terminal* window that was used to start Chrome.
4. No matter which password gets entered, the process does not continue.

What is the expected behavior?
The password prompt should never show up in a text window.

What went wrong?
Some desktop environments redirect password prompts to a UI window. But this is not guaranteed to happen. It is very unfortunate for Chrome to blindly rely on the prompt to be visible. For many users, it'll simply look as if Chrome was hanging, as they'll never see the prompt.

Did this work before? N/A 

Chrome version: 62.0.3202.75  Channel: n/a
OS Version: Ubuntu 16.04
Flash Version: 

As of the recent transition to remotedesktop.google.com, even after working around this bug (e.g. by manually adding the user to the required group), I have not managed to actually start a Linux remote desktop session. I'll file another bug, as this might be unrelated. But just a heads-up, as the two bugs could interfere with each other and make debugging difficult.