Can a linux user change their password without knowing the current password?

Question

I'm setting up a few ubuntu boxes, and using opscode's chef as a configuration tool. It would be fairly easy to install public keys for each user on each of these servers, and disable password authentication.

However, the users should also have sudo privileges though, which by default requires a password.

If I want to use the users' public keys as a method of access management and allow the users sudo privileges, does that mean I should also set up the users with NOPASSWD: ALL in visduo, or is there a way that a user can change their own password if they only have public key authentication?

Answer 1

Sudo, in its most common configuration, requires the user to type their password. Typically, the user already used their password to authenticate into the account, and typing the password again is a way to confirm that the legitimate user hasn't abandoned their console and been hijacked.

In your setup, the user's password would be used only for authentication to sudo. In particular, if a user's SSH key is compromised, the attacker would not be able to elevate to root privileges on the server. The attacker could plant a key logger into the account, but this key logger would be detectable by other users, and could even be watched for automatically.

A user normally needs to know their current password to change it to a different password. The passwd program verifies this (it can be configured not to, but this is not useful or at all desirable in your scenario). However, root can change any user's password without knowing the old one; hence a user with sudo powers can change his own password without entering it at the passwd prompt by running sudo passwd $USER. If sudo is configured to require the user's password, then the user must have typed the password to sudo anyway.

You can disable password authentication selectively. In your situation, you would disable password authentication in ssh, and possibly in other services. Most services on most modern unices (including Ubuntu) use PAM to configure authentication methods. On Ubuntu, the PAM configuration files live in /etc/pam.d. To disable password authentication, comment out the auth … pam_unix.so line in /etc/pam.d/common-auth. Furthermore, make sure you have PasswordAuthentication no in /etc/ssh/sshd_config to disable sshd's built-in password authentication.

You may want to allow some administrative users to log in with a password, or to allow password authentication on the console. This is possible with PAM (it's pretty flexible), but I couldn't tell you how off the top of my head; ask a separate question if you need help.

Answer 2

Yes, it's incredibly insecure and also allows a user to access the other users passwords, but since they have sudo, not much you can do.

Basically, you do the following:

$ sudo -i

Now, we are root. We have access to everything.

# passwd $username

$username can be anyone's username.

Enter new UNIX password:

Retype new UNIX password: passwd: password updated successfully

Boom, password changed. Again, incredibly insecure because you can change anyones, but it works, but it works. I don't recommend it, but rather offer this answer up as an example of what not to do.

Answer 3

You can use the pam_ssh_agent_auth module. It's pretty simple to compile, and then just add the entry

auth       sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

before the other auth (or include) entries in /etc/pam.d/sudo

and

Defaults    env_keep += "SSH_AUTH_SOCK"

to /etc/sudoers (via visudo).

Now every user can either authenticate to sudo via a (forwarded or local) SSH agent or their password. It may be wise to ask your users to use ssh-add -c such that each sudo call will at least require some confirmation.

Answer 4

#% useradd -g somegroup someuser
#% usermod -p "" someuser
#% chage -d 0 someuser
#% sed -i "s/^.*PasswordAuthentication .*/PasswordAuthentication no/" /etc/sshd/sshd_config
#% /sbin/service sshd restart
#% cp -r ~/.ssh `echo ~someuser`
#% chown -R someuser `echo ~someuser`/.ssh
#% chgrp -R somegroup `echo ~someuser`/.ssh
#% echo "%somegroup  ALL=(ALL)   ALL" >> /etc/sudoers

> This should allow you to have users who can login only using public keys and can not use passwords for login. However he will be forced to change the password the first time he logs in...but without having to tell him somedummy password up front...The users will be simply asked to reset the password and subsequently they can use it only for sudo but will not be able to login(ssh) using that password. Note that the trick here is to not to have told users some dummy password which they would then be required to input at the time of login once they are required to to change their password ...In nut shell no communication from admin(root) to the actual user is required.

Answer 5

Short answer

Yes you should enable all your users to use sudo without using a password. If you don't want to alter the default sudo group on your distribution you can create another group, as example sudoers_without_password, and say that this new group and only this one can sudo without password. But in any case, if you are creating users that don't have passwords and should be able to use sudo, they must be able to use it without passwords.

Long answer

Creating users without passwords that can only login using an SSH public keys using tools like chef, ansible, puppet, etc... is a common practice nowadays and can be considered a quite good practice for a lot of reasons (notably because ssh keys are very secure and managing passwords is both a pain and quite insecure).

Now that you've created all your users you have a small problem: some of these users at least should be able to use sudo and a lot of distributions recommend to use a password to be able to use sudo... but your users don't have a password!

In a perfect world it should be possible for your users to log securely using their ssh keys, then define a password (there is the standard passwd command for that), then use the sudo command.

Unfortunately we don't live in a perfect world and, should your users try to set a new password using the passwd, it won't work.

Actually it is possible to make the passwd command work in this case but it has implications that make it a very bad idea.

It is completely possible to create a user without any password and allow that user to change its own password. The answer is given in this man page. (I won't explain it fully because you shouldn't do it anyway).

Linux systems have two types of users "without a password":

• Disabled users. These users will usually have a ! or a * in their /etc/shadow line. For some reason, disabled users may still login through some means, as example using SSH with private key authentication (at least with most default SSH server configurations). Disabled users are not allowed to set their passwords.
• Passwordless users. The users have nothing as password in their /etc/shadow line. These users may change their own passwords.

The problem is that passwordless users are very very discouraged because anyone can login as them. Usually OpenSSH will deny login as one of these users (that's still a thing), but:

• Any other user will be able to use the su command to switch to the user even if they are not root or in the sudo group.
• Anyone with a physical access to the machine will be able to log in as the user without password (assuming the machine has a screen, keyboard and mouse).

That's why creating a passwordless user account is heavily discouraged and usually prevented by most automation tools. That is the reason why, when creating your users with chef, it created disabled users instead of passwordless users. Most other similar tools (ansible, puppet, etc...) will do the same because their creators don't want you to shoot yourself in the foot.

So, in order to allow users to log in using SSH with public keys, it's still the best practice to create disabled users, even if that mean they won't be able to create a password for themselves later.

Now back to your "sudo should use a password" problem, in this case there are two best practices that oppose themselves:

• On one hand these users should be disabled users and so they won't be able to change their passwords, because that's how disabled users work. We could create passwordless users instead but that would pose a serious security problem as we've seen earlier.
• One another hand most people consider it's a bad practice to allow users to use sudo without inputting a password (sudo may be allowed with or without password depending on the configuration). That is because careless admin users may accidentally input a command with sudo that could have bad consequences.

These two best practice cannot be respected both at the same time, so we have to make a choice. But there is a strong winner here: it's way more dangerous to allow passwordless users than allowing sudo without password.

So, in that case, just configure the sudo group to allow commands without password, that's the best thing to do anyway as there is no other solution as far as I know.

Answer 6

The point of the password is to ensure that hackers who obtain a user's key, or find an unattended terminal can't gain root access. For this reason I wouldn't recommend any solution that involves passwordless sudo.

I suggest you keep it simple: perhaps email a user the default password with strict instructions to change it ASAP, or else insert a script in their .profile or .login or something such that it demands a new password on their first login. It could disable itself when completed, and you could use expect to enter the existing password so they never have to know it.

Answer 7

This seems to be a somewhat common problem with no good solution.

There is a way, but it is fraught with pitfalls. Incredibly easy to either brick the system by misconfiguring PAM, or to open an inadvertent security hole. Don't do this unless you really know what you are doing.

To clarify the goal:

• The end user should not have root access.
• All configuration will be done by a sysadmin (or chef recipe). This will of course have root access.
• The end user should be able to set their own password on first login.
• No passwords should ever be communicated between sysadmin and end user.
• The user account is protected by SSH key; the password is only needed for sudo access.

Here are the steps:

• WARNING: by itself, this step is extremely insecure. We'll secure it later. Change the password to an empty password (the password field in /etc/shadow should be empty, instead of containing !! or * or whatever other character may be placed there by default).

  The easiest way accomplish this is for the sysadmin to run the following command. This is non-destructive; if the user has already set a password, it will not be changed.

  passwd -f -U

  The effect of this in a default configuration (checked on RedHat Enterprise Linux 9) is that a user is allowed to log on without a password, run passwd without being prompted, run sudo without a password, etc. Obviously, we only want one of those things (passwd), but not the others.

• Next, you expire the password. This will force the user to change it the first time they log on, so they can't leave the password empty (Note: I'm not sure if that works for SSH key-based logins, so be sure to test).

• Finally, to make this setup secure again, you will need to manipulate the PAM configuration. Some of that is specific to your system and may vary. Generally, you will want to remove the nullok parameter to pam_unix.so in the appropriate configurations (and getting this right is non-trivial!) I deliberately leave out details, both because they may vary depending on your specific authentication configuration, and I'd rather have you fully understand PAM and be able to figure these things out on your own before you try this approach.

For logging in, you may also want to add the nullresetok parameter (note: not all versions of pam_unix.so seem to have this keyword).

Note: some distributions, including RedHat, contain utilities to manipulate the PAM configuration. Those utilities can clobber your carefully-crafted PAM configuration.