Authenticator "invalid username or password" with users that are clearly valid

JupyterHub
,
1

Hello all. Im configuring a jupyterhub server in an ubuntu machine. According to this page, not setting a specific c.Authenticator.allowed_users will automatically set to default and allow for all authenticated users.
My server does not have any c.Authenticator.allowed_users property set, however it displays “Invalid username or password” to some users that exist in the domain and can, for example, ssh into the server machine.

Do i need to set any specific configuration that im not aware of?

If it helps, my machine gets a lot of info about authenticated users from the domain, so not everything is stored locally. For example,

cat /etc/passwd

results in a short list of users info while

getent passwd

Results in a much longer list. Is this affecting my server somehow?

Obs: this question is duplicated here.

2

If you are using the default Spawner and Authenticator, JupyterHub must run as root in order to have permission to check passwords and become users.

The passwords part needs at least ‘shadow group’ permissions, which depend on the distro. More info in the docs.

1 Like
3

@minrk i believe the spawner is running as root since its via a jupyterhub.service file in systemd/system which is trigered via sudo systemctl start jupyterhub.service.
Since the distro is Ubuntu, should that be enough to get the permissions?
Also, i think its already with the permissions to read shadow because the great majority of users is being accepted.

4

Copying my stack overflow answer here:

This solution is obviously not ideal, but worked for me. Since i tried some of the class Authenticator methods and nothing more direct worked, i added:

names = subprocess.check_output(["getent","passwd"])
names=names.decode()
names=names.split("\n")
for i in range(0,len(names)):
    names[i]=names[i].split(":")[0]
names=set(names)
c.Authenticator.allowed_users = names

To the jupyterhub configuration file. So now it gets all users from getent passwd and allows them to log.

Suggestions on better solutions would still be welcome, though.

5

Hello,

systemd jobs are not automaticly running as root. You can ran any unit script. So it is worth looking at it.

1 Like
6

Thanks for the suggestion, @blecx! Since the process is being initiated via systemctl, i looked at it via

systemctl show -pUser jupyterhub.service

as sugested by this answer, and received

User=

So i figure it is running as root. However, i noticed something curious: when adding

os.system(‘mkdir -p /path/to/my/home/’ + ‘/’ + str(getpass.getuser()))

to the spawner, a folder named root appears when i start the service and log into the notebook. But when i remove this python line and add

mkdir /path/to/my/home/$USER

to jupyterhub.sh (which is the file called by jupyterhub.service) i get no new folder. Is this indicative of something im missing?

7

Well, Im not sure and have low experiance. What might happen is, that /root is the home directory of the user root. The root directory is not part of the /home/ path of any other user.

It seems you prefixed this. So you may get somethin like /prefix/root aka /home//root. So that's why root folder appears. I think the result of getpass.getuser() just returns root`, which means the script is running as root.

python says:

getpass.getuser()
The getuser() function displays the login name of the user. This function checks the environment variables LOGNAME, USER, LNAME and USERNAME, in order, and returns the value of the first non-empty string.

Summarze. This string just creates a directory of the user. So no reason to change. No reason why this should be a bug

8

Sorry, i think i expressed myself poorly.
I agree with the logic: since the script is being executed by root, a directory named root should show in the path that i put in /path/to/my/home. Im not concerned that this might be a bug though, im trying to use it as a debug tool. My doubt is: why does instructing the spawner to generate a file with the user name generates a different result than instructing the file jupyterhub.sh (which is called by jupyterhub.service) to do the same thing?

9

So, what minrk said is important and it is required.

So with the “default” installation no users are configured. So any attempt will fail. Currently I’m facing this problem as well. But I hope to have a solution soon and come back (This means rtfm for me)