ssh
and sudo
have nothing to do with each other. Setting up an ssh
authentication method isn't going to do anything for sudo
. sudo
isn't going to understand an ssh
password.
passwd -l
is intended to lock a user's account, so that he can no longer authenticate by password. That's pretty much the opposite of what you want, which is letting the user authenticate without a password.
I think what you want is the NOPASSWD
option in your sudoers
file.
(PS, there's no reason to be running a cd
command with sudo
. cd
does not propagate to parent processes, so as soon as the sudo
exits, you're back where you started.)
Edit: You keep saying that you want to lock the account password and want sudo to understand public/private keys. Sorry, sudo isn't going to use ssh keys. It isn't ssh. If you don't want users to be able to log in with their passwords, I think the answer is to disable ssh password authentication, not to lock the account. Then you can retain a password for the users, which they can use to sudo after they log in via ssh authorized_keys.
Following the principle of least privilege, run as little as you can as root. Therefore, sudo from within the script.
Note that the first time there is a command that needs sudo, you may be prompted. (That won't be true if you applicably use NOPASSWD in /etc/sudoers which is a technique that many people will shun as also being insecure.) However, when you run sudo and provide a password, sudo will remember the success for a period of time. By default that period of time is five minutes. So if you ran "sudo echo hi", typed in your password, and then ran the script soon after that, then there would be no need for you to be prompted for a password when you run the script. More realistically, if you just run the script, you will likely just be asked to sudo once... presuming that you script takes less than give minutes to complete the remaining tasks.
I might not worry about a few echo
commands, but if there is significant content that can be done without extra permissions, then, for the sake of security, I generally like to maximize how much is done with minimal elevation.
As an example of minimizing permissions, let me show you another sample scenario. Instead of:
sudo -c "sample-command >> /var/log/output.txt"
I like to use:
sample-command | sudo tee -a /var/log/output.txt >> /dev/null
By doing this, the entire command runs without sudo, and the only part that ends up having enhanced permissions is the part that needs enhanced permissions, which is the part that writes to the file.
Clearly, my goal here is to minimize how much is done elevated. Similarly, if your entire script doesn't require elevation, the preferred approach (from a security perspective) is to minimize how much is done elevated.
Best Answer
sudo -K
andsudo -k
, without a command, do the same thing: they invalidate the user's cached credentials.sudo -k command ...
is different: it ignores the user's cached credentials for the current command, but doesn't invalidate them.Use
-k
with a command when you want to run a single command without either using or clobbering your cached credentials. (I'm actually not sure why you'd want to do that, but the capability is there.)Use either
sudo -k
orsudo -K
if you want to clobber your cached credentials.Summary:
UPDATE :
Revisiting this answer, it looks like the only difference between
-k
and-K
is that-k
accepts a command and-K
does not. I'm not convinced having two separate options is useful, since-K
doesn't really add any functionality that-k
doesn't provide. There is a subtle difference in wording in the man page;-k
"invalidates the user's cached credentials", while-K
"removes the user's cached credentials entirely". I don't think that indicates a real difference in the way it affects the credentials.