I'm trying to execute multiple commands on a remote server. The issue I'm having is that after the sudo command is ran, the ssh connection gets closed automatically.
The main test that is failing:
ssh -i "/path/to/key/id_rsa" user#server << EOF
sudo ls -la "/etc/redhat-release"
cat "/etc/redhat-release"
EOF
Returns only the ls result
-rw-r--r-- 1 root root 55 Jan 29 2013 /etc/redhat-release
While if I put both commands on the same line, i.e.
ssh -i "/path/to/key/id_rsa" user#server << EOF
sudo ls -la "/etc/redhat-release"; cat "/etc/redhat-release"
EOF
I will get the result of both commands
-rw-r--r-- 1 root root 55 Jan 29 2013 /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
Now for the weirdest part:
the main test does work on an other server with identical configuration. There are sets of servers where it works, and other sets where it doesn't.
if I remove the sudo from the test, I will get the result from both commands, so it's not an ssh limitation
e.g.
ssh -i "/path/to/key/id_rsa" user#server << EOF
ls -la "/etc/redhat-release"
cat "/etc/redhat-release"
EOF
-rw-r--r-- 1 root root 55 Jan 29 2013 /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
Additional information:
Both commands have the NOPASSWD flag in the sudoers file so no password is asked.
requiretty is commented out.
ssh version: OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
SELinux is disabled
the ssh -vvv option doesn't show any significant difference in the logs between a working and non-working server
sshd_config are the same between a working and non-working server
I'm assuming here that there must be some configuration difference between the sets of servers because they are consistent with each-other, but I can't figure out what.
One possible workaround:
ssh -i "/path/to/key/id_rsa" user#server sudo bash << EOF
ls -la "/etc/redhat-release"
cat "/etc/redhat-release"
EOF
Check your sudo version (sudo -V).
Turns out one server was running Sudo version 1.8.6p3 while the other was on Sudo version 1.8.21p2 and a was running in a bug which was fixed in sudo 1.8.20:
Fixed an issue where sudo would consume stdin if it was not connected to a tty even if log_input is not enabled in sudoers. Bug #786.
Updating the sudo version fixed the issue.
Related
I've added superuser sroot with the following command.
useradd -o -r -c "service root" -g 0 -u 0 -m -d /root -s /bin/bash sroot
When I try to switch to that user I get the following:
[admin#machine ~]$ su - sroot
Password:
TERM=[xterm-r6]?
basename: missing operand
Try `basename --help' for more information.
whoami shows that I'm root now but commands that requires root access still cannot be executed.
When I login under usual root everything works fine.
[admin#machine ~]$ uname -a
Linux <myhostname> 2.6.18-194.el5PAE #1 SMP Fri Apr 2 15:37:44 EDT 2010 i686 i686 i386 GNU/Linux
Thanks in advance!
Well, I tested with non-standard linux commands, but with scripts added with installed rpm. Those commands check $LOGNAME variable and require to be root only, not sroot.
Thanks #thatotherguy for your comment, which directed me to the right path to search.
I am doing ssh to servers which has password less authentication from jenkins server to these servers in /tmp/san.txt by running a shell script.
jenkins#pc4mobjen01:/tmp> cat check.sh
#!/bin/bash
for i in `cat /tmp/sand.txt`
do
ssh -q mpdevops#"$i"
bash /app/home/mpdevops/sand.sh
done
jenkins#pc4mobjen01:/tmp> bash check.sh
Last login: Wed Apr 19 09:20:03 2017 from 10.4.70.42
Powered by Monsoon (Version 2.2.1519) Platform: suse 11.3
Hostname : mo-97df9aafa.dc19.saas.sap.cor Name : PC19MOBDEVOPS01
Organization : saas_prod Project : dc19_production
Url : https://monsoon.mo.sap.corp/instances/mo-97df9aafa
mo-97df9aafa[PC19MOBDEVOPS01]:~ # logout
bash: /app/home/mpdevops/sand.sh: No such file or directory
But sand.sh is present.
mo-97df9aafa[PC19MOBDEVOPS01]:~ # cat sand.sh
for j in `cat sand.txt`
do
ssh -q mpdevops#"$j"
sudo python /tmp/test.py
done
Please help.
Try entering the command to be executed on the remote client on the same line as the actual ssh command. Looks like the bash command is being executed on the local host as opposed to the client.
You should run sand.sh on the same line with ssh command:
check.sh should be:
#!/bin/bash
for i in `cat /tmp/sand.txt`
do
ssh -q mpdevops#"$i" "bash /app/home/mpdevops/sand.sh"
done
I can't understand how exactly this works in Linux.
For example, I want only users in some group have access to execute some file (I hope this is possible without visudo).
I create a system user and system group like:
useradd -K UID_MIN=100 -K UID_MAX=499 -K GID_MIN=100 -K GID_MAX=499 -p \* -s /sbin/nologin -c "testusr daemon,,," -d "/var/testusr" testusr
I add my current user user to the group testusr (may be not cross platform):
adduser user testusr
I create some test shell file and set permissions:
touch test.sh
chmod ug+x test.sh
sudo chown testusr:testusr test.sh
But I still can't start test.sh as user:
./test.sh
-> Error
Now I look for some system groups like cdrom to check how they work. My user is in cdrom group and can use the cd rom on my computer:
$ ls -al /dev/cdrom
lrwxrwxrwx 1 root root 3 апр. 17 12:55 /dev/cdrom -> sr0
$ ls -al /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 апр. 17 12:55 /dev/sr0
Addition:
./test.sh command starts to work as I want after system reboot. Strange...
I'm on Ubuntu Studio 15.10
The group changes are reflected only upon re-login.
I installed ffmpeg on centos as root user. How can update permission so that apache (httpd) can run the ffmpeg command?
-rwxr-xr-x. 1 root root 24M Mar 4 03:43 /root/bin/ffmpeg
I tried to link to /usr/bin
cd /usr/bin
ls -s /root/bin/ffmpeg
But when still not works. I guess because apache not have shell avaiable?
su apache -c whoami
This account is currently not available
As #pbu comment states, if you follow this installation guide http://trac.ffmpeg.org/wiki/CompilationGuide/Generic but replacing '$HOME' with '/usr/local', the apache (httpd) user will be able to execute it.
this command works
ssh -t www.foo.com 'sudo ls -l'
I immediately get asked for my password, once entered I get the directory contents
if I try to pipe this command it fails - I never get asked my password so I never get any contents.
ssh -t www.foo.com 'sudo ls -l' | grep 'foo'
This is a basic example, I know I could pipe/grep the output in my "ls" command. for my application I need to pipe the output through a program on my host.
In order to not be asked for a password to issue sudo commands, you need to have an entry in /etc/sudoers (or better, a file in /etc/sudoers.d) that lets you do it. There is a nice question on using sudoers here.
A sudoers config to allow you to run ls as root could be:
<yourusername> ALL = (root) NOPASSWD: /bin/ls
One thing to look out for is that ls is quite likely to be a shell built-in, so you may have trouble allowing it. You should be able to set your shell to defer to the system binary instead.
Trying to push your real password through it is not a secure solution.
ssh -t www.foo.com 'echo your_pass | sudo -S ls -l' | grep 'foo'
Also possible:
ssh -t www.foo.com 'sudo -S ls -l <~/passwd.txt' | grep 'foo'
The reason you are not getting prompt for password is because you are feeding the output of "ssh -t www.foo.com 'sudo ls -l'" to the pipe where you are grepping for 'foo'. So in this case the password prompt won't be shown, but actually the process is waiting for your input.
Try giving the password on the blank new line you get after running the command.
I tried this and it worked. Just for example,
$ ssh -t user#host 'sudo ls -l /' | grep 'root'
user#host's password: <===== After this, it waits for user input to feed the password for sudo user.
Connection to host closed.
drwxr-xr-x 2 root root 4096 2011-08-31 15:33 bin
dr-xr-xr-x 24 root root 4096 2014-07-14 00:52 bldmnt
dr-xr-xr-x 2 root root 4096 2011-03-23 15:51 blr
drwxr-xr-x 3 root root 4096 2011-08-31 15:36 boot
.
.
.
Try it and see if it works for you.