Hi all! Having an issue that is causing us much grief and I'm betting we're just missing something easy. We have a script that runs from a jump server that ssh's to a RHEL 6.6. Here is an example of what we need it to be able to do:

If the sudoers file has the following in it, this works:

If the sudoers file is more restrictive (as it needs to be) like:

Then I can ssh, then sudo, then perform the command, but not all together like I need to do from this script. It prompts for password if performed together in the one command above. Does someone have a proper solution without changing all of my scripts that currently do this sort of thing?

Thanks much!
Eric

I would consider making an ssh key that runs the specific command that you're wanting.
Ssh itself can do both things you're wanting a) run a command on another machine, and b) run an exact command as that person - all of what you're trying to do.

Search google or here for "ssh command keys" and you'll probably find your solution shortly.
This is how you can safely allow a person run a single command from another machine with elevated privileges easily and safely.

1 members found this post helpful.

A couple of ways to address it:
1) Have ssh go directly to the other user rather than doing sudo to that user after the ssh. The ssh trust can be configured for each user - the destination user defaults to same as source user but you can specify the destination:
e.g. ssh otherUser@redhatHost 'cd /tmp;ls -l'

-OR-
2) Setup Runas_Alias(es)
These allow a command specification later to allow the user to run commands as any <user> in the user list that follow the Alias name using syntax:
sudo -u <user> <command>
NOTE: The commands that can be run are only those for which the <user> has permission. e.g. if "oracle" doesn't have permissions to run "rm /" then allowing "sudo -u oracle rm /" here isn't a problem because it won't work anyway. Accordingly allowing a Runas_Alias in later specification to run "ALL" is acceptable.
e.g.
Runas_Alias <OTHERUSERA> = <user(s) you ssh'd into>
Note that OTHERUSERA is the name of the alias NOT the name of the user. The name of the user(s) is(are) after the "="
The grant to user a Runas_Alias is done with parentheses.
myUser (OTHERUSERA) ALL

This is what I'm getting at - but - ssh "trust" as you call it - can be configured well beyond a single user - ssh keys can be tied to individual commands (using the command= syntax configured in the private key file), per user. So, you can create a key, that runs and only does a *single* command, script, etc.

1 members found this post helpful.

I'll have to review these suggestions, but I'd rather not go to the extent of controlling commands. So here's the exact situation, we have an Active Directory group with several users in it. These users need to be able to run a script on a jump server that does the command specified as well as many others. These users just need to be able to do anything that this user can do on the server that gets ssh'd to. This isn't even slightly a privileged user, it's a local, passwordless service account that runs a middleware ESB. Where the security comes in is that we don't want to have to give the users in this group ALL NOPASSWD ALL type of access. It really doesn't make sense to me that ALL NOPASSWD ALL works, whereas this doesn't. When I do the commands separately, I don't get prompted for password in any of them. Why when they're done in conjunction are we being prompted? Sorry, I will look closer at the answers because likely the answer is in there, I'm just a middleware engineer rather than an SA so it takes me a bit longer...

Thanks!
Eric

I get what this one is saying:

So I would take the users public keys that need to ssh as that user and put them into the authorized_keys file for the user they need to ssh to. That makes sense, a bit of work, but it definitely makes sense. I'll discuss it with the SA that is as confused as me...

I'd still rather not have to manage these users in the sudoers files in every single environment on every single server. For me, if I could just do one entry that says "the users from AD group groupOne can sudo to local user userOne passwordless and perform any command that userOne has access to would be ideal. It seems like it should be:

But we tried that and it doesn't work. It doesn't allow for the sudo to the user userOne in the first place. I obviously don't understand this stuff very well!

Maybe this was answered with:

Is it this simple?

Didn't work. The sudoers file wouldn't even compile with that entry in it. Something is wrong in it, likely with the NOPASSWD: ALL. Anyone have a correction?

User_Alias allows you to add multiple users by name or group to a single grant by User_Alias.

Haven't used it but your mention of AD made me check for ldap integration with sudo which led to this page:
http://www.sudo.ws/sudoers.ldap.man.html

You may want to peruse that.

Not sure that would work. The group is in Active Directory, but the user that these AD users need to impersonate is a local user on the host.

Any help on fixing my following entry:

The response I get is:

So first it told me I needed password, and second, it said I didn't have sudo rights to that user. Note that efetzer is in groupOne.

Thanks,
Eric