Can anyone help me to to solve following issue
i need to ssh to another server by e.g. ubuntu user which has permission to run sudo su fore sure then execute pm2 restart command
full command look like this
#!/bin/sh
CMD="sudo su; pm2 restart 0; pm2 restart 1; exit;"
ssh -i somepemfile.pem ubuntu#1.1.1.1 $CMD
for example i can run normally any command with sudo
CMD="sudo /etc/init.d/apache2 restart"
but with sudo su case it somehow hang and do not response
Unless you have an unusual setup, you can't normally string su with other preceding commands like that. I would imagine it is running sudo su, then hanging in the root environment/session, because it's waiting for you to exit before preceding to the pm2 commands. Instead, I would consider something along the lines of this using the -c option:
CMD="sudo su -c 'pm2 restart 0; pm2 restart 1'"
ssh -i somepemfile.pem ubuntu#1.1.1.1 "$CMD"
As suggested in another answer, it would also probably be useful to encapsulate the $CMD variable in quotes in the ssh call.
su normally puts you in a sub shell which you can see by echoing the current PID (process id)
$ echo $$
94260
$ sudo echo $$
94260
$ sudo su
$ echo $$
94271
But to get around this you can pipe the commands you want to run to su like this
$ echo "whoami" | sudo su
root
And we run multiple commands
$ echo "uptime;whoami" | sudo su
11:29 up 8 days, 19:20, 4 users, load averages: 4.55 2.96 2.65
root
Now to make this work with ssh
$ ssh wderezin#localhost 'echo "uptime;whoami" | sudo su'
sudo: no tty present and no askpass program specified
Darn it, we need allocate a tty for the su command. Add the -t option which allocates a TTY during the remote execution.
$ ssh -t wderezin#localhost 'echo "uptime;whoami" | sudo su'
11:36 up 8 days, 19:26, 5 users, load averages: 2.97 2.97 2.76
root
Your command would look this
ssh -i somepemfile.pem ubuntu#1.1.1.1 'echo "pm2 restart 0; pm2 restart1" | sudo su'
Use -c option of su to specify the command
From man su
In particular, an argument of -c will cause the next argument to be treated as a command by most command interpreters. The command will be executed by the shell specified in
/etc/passwd for the target user.
CMD="sudo su -c \"pm2 restart 0; pm2 restart 1;\""
You need to quote the expansion so that the entire string is parsed on the remote end.
ssh -i somepemfile.pem ubuntu#1.1.1.1 "$CMD"
Otherwise, the expansion is subject to word splitting, and the remote shell gets a string which consists of the command sudo and the arguments su;, restart, 0;, pm2, restart;, 1;, and exit;. That is, ssh will escape the semicolons when it builds a single string from the separate arguments you pass.
However, that doesn't solve the problem of running pm2 in the shell started by sudo. That is addressed by ramki.
Related
I've installed some software on a server that my gitlab runner SSH's to, and one of the commands needs to be run after doing sudo su. If I run it as a regular user, but with sudo in front of it - it doesn't work. I have to first completely switch to the sudo user first.
This works fine when I SSH into the server and do the commands manually. But when I try it from the pipeline (rough code below):
my_script:
stage: stage
script:
- ssh -o -i id_rsa -tt user#1.1.1.1 << EOF
- sudo su
- run_special_command <blah blah>
- exit
# above exits from the SSH. below should stop the pipeline
- exit 0
- EOF
I get very weird output like the below:
$ sudo su
[user#1.1.1.1 user]$ sudo su
echo $'\x1b[32;1m$ run_special_command <blah blah>\x1b[0;m'
run_special_command <blah blah>
echo $'\x1b[32;1m$ exit\x1b[0;m'
exit
echo $'\x1b[32;1m$ exit 0\x1b[0;m'
exit 0
echo $'\x1b[32;1m$ EOF\x1b[0;m'
And what I'm seeing is that it doesn't even run the command at all - and I can't figure out why.
In this case, you need to put your script as a multi-line string in your YAML. Alternatively, commit a shell script to repo and execute that.
and one of the commands needs to be run after doing sudo su. If I run it as a regular user, but with sudo in front of it - it doesn't work.
As a side note, you can probably use sudo -E instead of sudo su before the command. But what you have should also work with the multi-line script.
MyJob:
script: |
ssh -o -i id_rsa -tt user#host << EOF
sudo -E my_command
EOF
exit 0
Alternatively, write your script into a shell script committed to the repository (with executable permissions set) and run it from your job:
MyJob:
script: “my_script.sh”
I have created a Jenkins job today, what it does is the Jenkins user should log into another server and run two commands separated by &&:
ssh -i /creds/jenkins jenkins#servername.com "sh -c 'sudo su && lxc exec containername bash'"
The logging part works fine, then it runs the sudo su command and becomes root but it never runs the second command.
I even did this manually and from the Jenkins machine logged into the other server (servername). Then ran sh -c "sudo su && lxc exec containername bash" with no luck.
Try to execute the second command as a parameter for the sudo su command, like this:
ssh -i /creds/jenkins jenkins#servername.com "sh -c 'sudo su -c "lxc exec containername bash"'"
I have a kiosk that shuts down every day using rtcwake, and this uses root user. I've used && to execute the boot script after rtcwake completes, however it then starts the browser as root causing problems.
This is the command I use:
echo debian | sudo -S rtcwake -m mem -u -t $(date +%s -d '3 days 7:45') && sudo -u debian -i bash $HOME/kiosk/bin/startup.sh &.
The sudo command does work to some extent. It calls the debian user, and executes the correct script, however, it still screws up my chromium preferences.
Here is the startup script:
echo debian | sudo -S hwclock -w
export HOME=/home/debian
#log boot time
echo "Booting at" $(date) >> $HOME/kiosk/bin/logs/boot.log
#echo debian | sudo -S service connman restart
echo debian | sudo -S at 15:30 -f $HOME/kiosk/bin/shutdown.sh
crontab -u debian crontab.txt
bash $HOME/git.sh
#sudo -i -u debian
#start kiosk
export DISPLAY=:0
chromium-browser --kiosk --disable-gpu
http://localhost/kiosk/Client/main.html &
#update ip
bash /home/debian/git.sh &
I'm wondering what could be causing chrome to be executed as root. I have no idea what is going wrong.
If you execute a command with sudo it will not change environment variables like $HOME. Since per user settings are stored in $HOME, this affects the executed program if it needs such configuration files. Check this for example:
sudo -u debian bash -c 'echo $HOME'
It will print the home folder of the calling user, not the home folder of the user specified trough -u. The sudo command supports the -H command line option to handle this, however if it works depends on the security police in use.
As a solution you can use the su command instead of sudo in this case:
... && su debian -c chromium
Since su itself is executed by root you won't be asked for the password.
You must enter a password to log into a new user shell.
The command needs to be modified as follows:
echo debian | sudo -S rtcwake -m mem -u -t $(date +%s -d '3 days 7:45') && echo debian | sudo -S -u debian -i bash $HOME/kiosk/bin/startup.sh &
This avoids needing a password to log in as normal Debian user, and executes the script.
I want to run 2 different scripts from a single master shell script.
The first one uses the following command "rosh -n -l abcd" (It will log me in to the server with the user abcd and on the same shell I need to run the other script#2 and script#3 ...etc.)
Script#2- From there I need to change user using su - xyz and provide a password (it is fine if I can hardcode this in the file) (Script name is logintoServer)
Script#3- Run some script in the same shell to verify start of stop of server...
I have done the following but failed
I have one script which has rosh -n <servername> -l abcd /bin/sh -c "su - xyz" (I have to run this command in the same shell)
The below are the errors:
I am getting error while executing "standard in must be a tty"
I have tried to create 2 different scripts and run, but the problem is once the first script is run it does not run the 2nd script till I exit the script. (I need to run the 2nd script from the sub-shell created by the 1st script....)
I don't have rosh and I don't have a man page for rosh but a similar problem exists with ssh:
ssh localhost /bin/bash -c 'echo x' # (prints nothing)
ssh localhost "/bin/bash -c 'echo x'" # x
ssh localhost "/bin/bash -c 'tty'" # not a tty
ssh -t localhost "/bin/bash -c 'tty'" # /dev/pts/12\nConnection to localhost closed.
ssh localhost "/bin/bash -c 'su - $USER'" # su: must be run from a terminal
ssh -t localhost "/bin/bash -c 'su - $USER'"
the last asked for a password and then gave me a shell, so that would be 2 of 3 steps.
so one idea is to see if rosh has the -t option, too and the other is to enclose /bin/bash... with quotes, too (will require some escaping for the 3rd level).
What does rosh say with equivalent commands?
UPDATE
latest state:
rosh -n $host -l abcd -t "/bin/sh -c 'su - $user'"
Next I would save one step by saying /bin/su - xyz instead /bin/sh -c 'su - xyz', then you can use single quotes later, e.g.
rosh -n $host -l abcd -t "/bin/su - $user -c 'echo $PATH'"
this should print $PATH as seen by the echo command. Apparently it doesn't contain java. try man su, which java, man which.
su ... -c cmd runs cmd with the shell specified in /etc/passwd, so say </etc/passwd grep $user on the remote machine to find out which shell is used. if it's bash you can change $PATH in .bashrc or so, for other shells I don't know exactly.
Or specify an absolute path when launching java.
regarding password: with ssh I managed to use private key / public key and ssh-agent. For rosh I don't know if that works, too.
I am trying to write a script that appends a line to the /etc/hosts, which means I need sudoer privileges. However, if I run the script from the desktop it does not prompt for a password. I simply get permission denied.
Example script:
#!/bin/bash
sudo echo '131.253.13.32 www.google.com' >> /etc/hosts
dscacheutil -flushcache
A terminal pops up and says permission denied, but never actually prompts for the sudo password. Is there a way to fix this?
sudo doesn't apply to the redirection operator. You can use either echo | sudo tee -a or sudo bash -c 'echo >>':
echo 131.253.13.32 www.google.com | sudo tee -a /etc/hosts
sudo bash -c 'echo 131.253.13.32 www.google.com >> /etc/hosts'
What you are doing here is effectively:
Switch to root, and run echo
Switch back to yourself and try to append the output of sudo onto
/etc/hosts
That doesn't work because you need to be root when you're appending to /etc/hosts, not when you're running echo.
The simplest way to do this is
sudo bash -c "sudo echo '131.253.13.32 www.google.com' >> /etc/hosts"
which will run bash itself as root. However, that's not particularly safe, since you're now invoking a shell as root, which could potentially do lots of nasty stuff (in particular, it will execute the contents of the file whose name is in the environment variable BASH_ENV, if there is one. So you might prefer to do this a bit more cautiously:
sudo env -i bash -c "sudo echo '131.253.13.32 www.google.com' >> /etc/hosts"