So here is my weirdness from work.
We have user accounts and service accounts and sudo access to the service accounts from the user accounts. Most, if not all, user accounts are running bash, whilst the service accounts use a misxture of bash or ksh.
When I am logged in as a user(bash) and using sudo to a service account(ksh) and run the following:
sudo -u svc_user -i alias_name
The alias runs as expected.
When I am logged in as a user(bash) and using sudo to a service account(bash) and run the following:
sudo -u svc_user -i alias_name
I get the error:
-bash: alias_name: command not found
Strangely, even when both accounts are bash, I can see the alias:
sudo -u svc_user -i alias
alias alias_name='func_name'
sudo -u svc_user -i which alias_name
alias alias_name='func_name'
Is there a reason why this works with ksh as the service account shell and not in bash?
Please let me know if any further details are required?
EDIT:- I just want to be clear, the alias I want to run belongs to the service account and not the original user who is calling sudo
Because bash only parse the first word in your command line to check if there is an alias in current environment.
You can try sudo alias_name, maybe also cannot find the alias. But you can try to add alias sudo='sudo ' to tell bash to parse next command for alias.
However, for your current case, it maybe actually run command bash -c xxxx in your srv_account. So it is not an easy things to resolve.
Related
We have a password less authentication between the server for root user, I am trying to run the alias on remote server as below
#ssh remoteserver runuser -l wasadmin wasstart
But it is not working. Any suggestions or any other method to achieve it
Based on your comments as you need to sudo to wasadmin in order to run wasadmin, you can try this:
ssh remoteserver 'echo /path/to/wasadmin wasstart | sudo su - wasadmin'
For add an alias in linux you must run
alias youcommandname=‘command’
Notice:
This will work until you close or exit from current shell . To fix this issue just add this to you .bash_profile and run source .bash_profile
Also your profile file name depending on which shell you using . bash , zsh ,...
I have been making some custom shell scripts for my nagios machine. I was able to make them run just fine but for some reason some commands in the script don't seem to be working.
For instance commands like echo, cut , ps , grep work fine but commands like touch, useradd dont seem to work, even with sudo. If I run the script from the terminal, all the commands in the script work.
How can I give nagios permissions to run these commands?
I'm running nagios3 on ubuntu 14.04.5 lts
Edit: Added a few lines of code which aren't being run
sudo useradd -m $USERNAME
(echo $PASSWORD; echo $PASSWORD) | sudo smbpasswd -s -a $USERNAME
Standard way is setup permission for Nagios user on monitored server, for instance NRPE, in /etc/sudoers file.
1. method
Try add something like this in your sudoers file.
Defaults:nrpe !requiretty
nrpe ALL= NOPASSWD: useradd -m
nrpe ALL= NOPASSWD: smbpasswd -s -a
PS: For easy editing sudoers file you can use visudo command ;-)
2. method
Or you can try add Nagios user to sudo group via sudo usermod -aG sudo <username>
-a stands for add
G is for group
Tell nagios to run the script as sudo in your .cfg file...
Assuming its permissions problem.
Edit /etc/sudoers file using visudo, this allows automatic file check for errors.
Defaults:nrpe !requiretty
nrpe ALL=(root) NOPASSWD: /path/to/your/command/or/script
Verify sudo has assigned the above permissions to the user in this case nrpe
sudo -U nrpe -l
you should see the command you added listed within the outpul
Edit /etc/nagios/nrpe.cfg
Add your command to the end of the file
e.g.
command[your_command]=/usr/bin/sudo /path/to/your/command/or/script
Restart nrpe
Centos: systemctl restart nrpe (use the command available based on your Operating system)
This question already has answers here:
How to fix 'sudo: no tty present and no askpass program specified' error?
(30 answers)
Closed 6 years ago.
I have a shell script which creates a user and executes another script as that user
sudo useradd -m devops
sudo passwd devops
sudo adduser devops sudo
su - devops -c "sh /path/to/myscript.sh"
This script creates the user,sets the password and adds user to sudo group as expected.
myscript.sh contains commands which uses sudo previlages. (sudo apt-get update, sudo apt-get install software-properties-common etc.). And other commands like ssh-keygen,curl and wget.
All commands except the one's with sudo are executed correctly and producing results as excepted.
But commands having sudo fails by giving the error "no tty present and no askpass program specified"
Why does this happen in this case and how can I overcome this?
I have seen similiar questions but will be thankful if I get a clear explanation in this context,thank you.
Try to replace this:
su - devops -c "sh /path/to/myscript.sh"
with this:
sudo -u devops -H sh -c "sh /path/to/myscript.sh"
The -c option of su doesn't support interactive mode:
-c, --command COMMAND Specify a command that will be invoked by
the shell using its -c.
The executed command will have no controlling terminal. This option
cannot be used to execute interractive programs which need a
controlling TTY.
(man su)
By the way, I wouldn't use sudo within a script everywhere. The script might simply require root permissions. Within the script you might drop privileges where necessary by means of the above-mentioned sudo command.
Here is my script:
script.sh:
sudo cat /etc/passwd-
If I am in a sudo session (e.g I ran an other command with sudo a few minutes ago), and now run
script.sh
The script will get sudo access. However if I run cat /etc/passwd-/, I will get a permission denied error.
As a user, I wouldn't expect script.sh to be able to get super user privileges so simply (e.g without me giving access to superuser privileges with sudo script.sh).
Is this expected behavior ?
Is it configurable ?
I see that behavior as being completely similar to sudo su, e,g potentially giving superuser access to any script you run in that session, but even worse, because you might not even be aware of it, and don't know when it ends (at least not without checking manually)
Is this expected behaviour ?
Yes, indeed, it is expected behavior. User's cached credential for sudo is responsible for it.
Is it configurable?
Yes, it is configurable.
And I think your security concern is a valid one. Running script.sh in a terminal where a sudo command is run before (within a certain timeout), will give the script superuser privilege if the script is written with explicit sudo commands.
You can avoid any script not prompting for a password when run as sudo by running it with:
sudo -k script.sh
It will ask for a password regardless of any previous sudo command/s or session.
And to run script.sh without sudo i.e with just script.sh and still prompt
for a password for the sudo command/s:
You can change the timeout value (the duration sudo maintains the session) permanently:
run sudo visudo
Then change the line:
Defaults env_reset
To
Defaults env_reset,timestamp_timeout=0
Save and exit (ctrl+X then Y)
This will ensure that sudo asks for a password every time it is run.
Or If you don't want to change it permanently and want your script to prompt for password at least once (while maintaining a session), then you can change your script like this:
sudo -k first-command-with-sudo
sudo second-command
sudo third
and so on
This script will prompt for password at least once regardless of any previous sudo command/s or session.
In case you are unaware of (or don't have access to) the content of the script script.sh (it can have sudo commands inside it or not)
And you want to be sure that any sudo command will surely prompt for password at least once, then run sudo -K (capital K) before running the script.
Now if you run script.sh and if it contains a sudo command, it will surely prompt for password.
When I changed my current user to admin using
sudo su admin
I found that the environment variable changed too. What I intend to do is to change my user to admin with the env not changed.
Then I found a command as follows:
sudo bash -c "su - admin"
This command does indeed what I want, but I googled about bash -c, with no clue to why this command can do that for me. Could anyone give me a clear explanation? Thanks a lot.
first you should read the sudo manpage and set theses options in the /etc/sudoers file or you can do it interactively (see second below).
default sudoers file may not preserve the existing $USER environment unless you set the config options to do so. You'll want to read up on env_reset because depending on your OS distribution the sudo config will be different in most cases.
I dont mean to be terse but I am on a mobile device..
I do not recommend using sudo su .. for anything. whomever is sharing sudo su with the public is a newb, and you can accomplish the same cleaner with just sudo.
with your example whats happining is you are starting a subshell owned by the original user ("not admin") . you are starting the subshell with -c "string" sudo has the equivelant of the shell's -c using -s which either reads the shell from the arg passed to -s or the shell defined in the passwd file.
second you should use:
$ sudo -u admin -E -s
much cleaner right ? :)
-u sets the user, obviously
-s we just explained
-E preserves the orig user env
see for yourself just
$ echo $HOME # should show the original users /home/orig_user
$ env
your original env is preserved with none of that sudo su ugliness.
if you were interested in simulating a users login without preserving the env..
$ sudo -u user -i
or for root:
Might require -E depending on distro sudoers file
$ sudo -s
or
$ sudo -i
-i simulates the login and uses the users env.
hopefully this helps and someone will kindly format it to be more readable since im on my mobile.
bash with -c argument defines below.
-c string
If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0.
Thanks & Regards,
Alok