I have created a simple Google Cloud VM and enabled OS Login for it. Login using SSH keys works perfectly fine.
I would now like to allow individual users to sign in with a fixed password as well (instead of the public key).
Unfortunately, this results in an error:
$ sudo passwd myusername
passwd: Authentication token manipulation error
passwd: password unchanged
or
$ passwd
passwd: Authentication token manipulation error
passwd: password unchanged
Is it impossible to set passwords for users managed by OS Login?
By default, password-based logins are disabled for Google Cloud VMs.
Log in to the instance.
Edit the file /etc/ssh/sshd_config.
Look for the line PasswordAuthentication no.
Change it to yes.
Restart the SSH server: sudo systemctl restart sshd.
There are other password related settings. Review the documentation:
I had the same issue and found a very simple solution in Goggle's Documentation.
The user account created by Compute Engine doesn't have a password.
However, several desktop environments require one for unlocking
screensavers and authorizing administrative actions. It is therefore
important to set a password for your user:
Connect to the instance using SSH, as you did when you first set up the instance.
Create a password for the user:
sudo passwd $(whoami)
Related
I am updating my password using the sudo passwd command in the SSL.
It tells me I have changed the root password but when I try to login I get "The login is invalid."
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Any ideas as to why this is not updating? (I am currently unable to login to WHM until this password updates).
Turns out I was using the wrong password originally. When I came to try the correct password it was still telling me I had the wrong details.
By the time I came to reset the password the server had blacklisted my IP (Too many attempts).
The solution was to remove the IP ban and everything was working fine again.
(Huge thanks to the cPanel Support team for helping me find the issue!!)
I have an AWS Simple AD directory service configured and running. I have the DHCP Option Set configured to point DNS to the directory, and I have an EC2 Linux instance successfully joined the realm/domain.
Following the AWS blog article on How to Manage Identities in Simple AD Directories, I tried adding a user and password:
$ net ads user ADD myuser Pa55word –C “Test User” –S corp.domain.com
However, when following this format an error is always thrown:
Could not add user myuser. Error setting password Operation not permitted
If you omit the optional password value, the user is successfully added:
$ net ads user ADD myuser –C “Test User” –S corp.domain.com
user myuseradded
But now I have a user without a password set. How can I now set this password (or successfully provide one at the time of user creation?).
I set data proc using the steps in link here
https://cloud.google.com/dataproc/docs/tutorials/jupyter-notebook
But my jyputer keep asking for password
I didn't set any password.
I tried my google account password that doesn't work
I ran ../root$ sudo grep -ir password
and get following, so that confirmed no password is set
.jupyter/jupyter_notebook_config.py:## Hashed password to use for web authentication.
.jupyter/jupyter_notebook_config.py:# The string should be of the form type:salt:hashed-password.
.jupyter/jupyter_notebook_config.py:#c.NotebookApp.password = u''
.jupyter/jupyter_notebook_config.py:# Only used when no password is enabled.
.local/share/jupyter/runtime/nbserver-3668.json: "password": false,
Since the initialization action just installs from latest using conda install jupyter, this appears to have been caused by a recent upstream change, specifically upgrading the notebook component from 4.2.3 to 4.3.0 causing token-based auth to be turned on by default. A recent cluster I deployed a couple weeks ago using the out-of-the-box init action didn't have the same login you're seeing; the design of the init action is to let Google Compute Engine firewalls be your layer of defense and the SSH tunnel being your secure connection, rather than relying on various third-party implementations of auth from the different Hadoop/Spark tools and web UIs.
The solution will be to add a line to setup-jupyter-kernel.sh:
echo "c.NotebookApp.token = u''" >> ~/.jupyter/jupyter_notebook_config.py
to disable jupyter-side authentication altogether and revert to the behavior a couple weeks ago. Note that if you want to do this yourself you'll have to fiddle with the INIT_ACTIONS_REPO and INIT_ACTIONS_BRANCH settings in jupyter.sh which may take some getting used to if you haven't been customizing it already. We'll try to push a fix as soon as possible and once that's done you should be able to use the out-of-the-box init action without causing the login screen again.
If you already have a cluster running, you can disable the auth for your jupyter server by running that manually as root after SSH'ing into the master:
sudo su
killall -9 jupyter-notebook
echo "c.NotebookApp.token = u''" >> ~/.jupyter/jupyter_notebook_config.py
/dataproc-initialization-actions/jupyter/internal/launch-jupyter-kernel.sh
Alternatively, if you do want to keep the new default token-authorization approach, the jupyter server actually logs a generated token to /var/log/jupyter_notebook.log; look for a line stating The Jupyter Notebook is running at: http://[all ip addresses on your system]:8123/?token=[some-token-string-here]; that token string can be plugged in to the password field or in the URL parameter as it shows.
EDIT: The fix has now been committed into Dataproc's init action repository and synced to gs://dataproc-initialization-actions. Deployments out-of-the-box once again work without an extra login page in the Jupyter UI.
A new metadata option has also been added if you do want to specify a token which Jupyter also allows to be used in the password field, with key JUPYTER_AUTH_TOKEN. Use it as follows only if you want a login page requesting your specified token (no metadata keys are necessary if you just want the old behavior of no login page):
gcloud dataproc clusters create \
--initialization-actions gs://dataproc-initialization-actions/jupyter/jupyter.sh \
--metadata JUPYTER_AUTH_TOKEN=foobarbaz
Then your login password will be foobarbaz.
When you dont set any password you can login with the your server credentials where it is installed.
i was logging in AWS server (ubuntu#54.564.564.1) with my pem key. After, i created one user in ubuntu and opened "/etc/ssh/sshd_config". In this file I have added following text "allow user username". I did reload that file and logout. but i unable to login my server with newuser(username#54.564.56.1) and olduser (ubu..#54.564.564.1).
Try ssh'ing without the ubuntu#. Just do the ip address because usually the first part implies the username.
Ex:
if I ssh into my raspberry pi and do: pi#192.168.1.12 then it just asks me for my password not my username and I login as the user pi.
Hope this helped
I've configured uaa for my vcap ,
I also successfully to register a new user into it,
azureuser#vcap:~/cloudfoundry/vcap/dev_setup/bin$ sudo vmc login
Attempting login to [http://paas.azure4j.us]
Email: test#meruvian.org
Password: **
Successfully logged into [http://paas.azure4j.us]
But when I try to "sudo vmc info"
Output is :
VMware's Cloud Application Platform
For support visit http://support.cloudfoundry.com
Target: http://paas.azure4j.us (v0.999)
Client: v0.3.23
Is it mean that I failed to login ?
Is there any problem with Uaa ?
I think I fixed this issue for the present
So I disable uaa configuration on cloud_controller.yml
Then I can log in again with my username and password
uaa:
enabled: true --> false
url: http://chankillo.openpaas.or.id:8061/
resource_id: cloud_controller
token_secret: uaa_jwt_secret
client_secret: cloudcontrollersecret
token_creation_email_filter: [""
But I still dont know what is the effect of this to my vcap system or security ,
but thank you for all help :)
Are you able to deploy applications to your VCAP instance? If you call vmc info with the --trace flag, what is the output?
So first of all: before UAA was introduced, Cloud Controller (CC for short) was doing authentication itself alone, storing users in psql db.
Than later they figured out that CC should focus on Application/Servcice management and delegate authentication/authorization/usermanagement to a new component, which they named: User Account and Authentication (UAA) Server
UAA is mainly an oauth2 provider, which means giving tokens to clients. But client in oauth terms is an application like vmc/CC which acts on behalf of a user (resource owner in oauth terms)
echo 'select client_id, scope from oauth_client_details;' | sudo psql -U root uaa
client_id | scope
------------------+--------------------------------------------------------------------
admin | uaa.none
vmc | cloud_controller.read,cloud_controller.write,openid,password.write
cloud_controller | uaa.none
UAA is also capable of Identity Management ie capable of storing users and their passord. They are implementing the SCIM standard (System for Cross-domain Identity Management). By default its uses postgres to store users:
echo 'select * from users;' | sudo psql -U root uaa
Actually right now on my vcap all users will be stored by cloud_controller's postgres DB, regardless of the cloud_controller.yml settings. But be aware that the CC - UAA connection is under heavy facelifting as you can see it in the git commits of the last couple of days:
Upgrade the CC to use the latest uaa gem : https://github.com/cloudfoundry/cloud_controller/commit/b057a97198a1493ae8f49c6684438198ee8ddd9d
Fixed the method call to create a user in the UAA :
https://github.com/cloudfoundry/cloud_controller/commit/c67e52608da4f0795bdce6710a5cc87ac4d5cad1
In the last couple of days i was pulling the latest code from git several times, and sometimes new users were going into CC's db and sometimes they got to UAA's db. It also depends sometimes on vmc version ...
From you description i guess your users are in CC's db. You can check it by yourself.
you can list users in cloud_controllers postgres db as:
echo 'select * from users;' | sudo -u postgres psql cloud_controller
Note the active column. If UAA is enabled, both DB stores the user, but its active=true in UAAdb and active=false in CCdb
So you safest bet is that you disable CC's UAA delegation, as figured, around line 77. of cloudfoundry/.deployments/devbox/config/cloud_controller.yml
uaa:
enabled: false
after changing any configurationfile you have to restart the effected component in this case CC:
~/cloudfoundry/vcap/dev_setup/bin/vcap_dev restart cloud_controller