im using the SSH package in R.
Im trying to switch the user after i have successful opened up a session using the ssh_connect function, the documentation isnt clear to me.
The vignettes reads "Note that the exec functions are non interactive so they cannot prompt for a sudo password. A trick is to use -S which reads the password from stdin:"
command <- 'echo "mypassword!" | sudo -s -S apt-get update -y'
out <- ssh_exec_wait(session, command)
iv tried the following:
ssh_exec_wait(session, c('echo "mypassword!" | sudo -S su - user2'))
but it just outputs the following in the console and doesnt change the user:
"[sudo] password for user1:"
what am i doing wrong here?
Here is what I wanna do... connent to a remote unix server from plink which is executed in a batch file, to run a script of other user name(as sudo user). I tried this.
#echo off
set /p id="Enter Unix Login ID: " %=%
set /p pwd="Enter Password: " %=%
cls
del jobInfo_error.txt
plink -l %id% -pw %pwd% Server0 "sudo su - user222" 2>>JobInfo_error.txt
plink -l %id% -pw %pwd% Server0 "/export/home/user222/user222_unix_works.ksh" 2>>JobInfo_error.txt
start notepad JobInfo_error.txt
In the above code i login as user000 and then i wanna sudo login as user222 and run the script user222_unix_works.ksh. The privilege for executing and writing is only given to user222 and i dont wanna change it.
here is why i think I am not geting the result I want, the first plink command plink -l %id% -pw %pwd% Server0 "sudo su - user222" 2>>JobInfo_error.txt is execute but the session is terminated and when the second runs i login as user000 and fails to execute.
is there a way to achive this?
here is the error in JobInfo_error.txt
bash: /export/home/user222/user222_unix_works.ksh: Permission denied
oh 2 more things i cannot directly login as user222
and i can execute any file for which user000 has privileges. i.e if i simple run with
plink -l %id% -pw %pwd% Server0 "/export/home/user000/user000.ksh"
it works.
i try to open a Unix session through java code and windows using putty.exe as follows:
Runtime.getRuntime().exec("cmd /c start /B C:/scripts/Session.bat ");
the 'Session.bat' file content is:
putty.exe -t -ssh root#aaa -pw abcd -P 22
aaa is the server name.
root is the user name.
abcd is the password
Now, the session opens well, but i want to run couple of simple commands from the above command (ll -s, pwd, etc.).
But when i try to add txt file which contains these commands to the above command, i see that the commands are executing after the user name entered and before the password.
the complete command is:
putty.exe -t -ssh root#aaa -pw abcd -P 22 -m C:\scripts\commands.txt
that's why i get the error (below) since the command "ll" came before the password:
Using username "root".
bash: ll:: command not found
please help me...
Thanks
There is no way the command could execute on the remote computer before the password is processed. Surely an alias is missing in root's bash startup files.
Try adding alias ll='ls -l' to /root/.bash_profile ?
I want to write a shell script to automate a series of commands. The problem is some commands MUST be run as superuser and some commands MUST NOT be run as superuser. What I have done so far is something like this:
#!/bin/bash
command1
sudo command2
command3
sudo command4
The problem is, this means somebody has to wait until command1 finishes before they are prompted for a password, then, if command3 takes long enough, they will then have to wait for command3 to finish. It would be nice if the person could get up and walk away, then come back an hour later and be done. For example, the following script has this problem:
#!/bin/bash
sleep 310
sudo echo "Hi, I'm root"
sleep 310
sudo echo "I'm still root?"
How can I make it so that the user can just enter their password once, at the very start, and then walk away?
Update:
Thanks for the responses. I'm running on Mac OS X Lion and ran Stephen P's script and got different results: (I also added $HOME)
pair#abbey scratch$ ./test2.sh
uid is 501
user is pair
username is
home directory is /Users/pair
pair#abbey scratch$ sudo ./test2.sh
Password:
uid is 0
user is root
username is root
home directory is /Users/pair
File sutest
#!/bin/bash
echo "uid is ${UID}"
echo "user is ${USER}"
echo "username is ${USERNAME}"
run it: `./sutest' gives me
uid is 500
user is stephenp
username is stephenp
but using sudo: sudo ./sutest gives
uid is 0
user is root
username is stephenp
So you retain the original user name in $USERNAME when running as sudo. This leads to a solution similar to what others posted:
#!/bin/bash
sudo -u ${USERNAME} normal_command_1
root_command_1
root_command_2
sudo -u ${USERNAME} normal_command_2
# etc.
Just sudo to invoke your script in the first place, it will prompt for the password once.
I originally wrote this answer on Linux, which does have some differences with OS X
OS X (I'm testing this on Mountain Lion 10.8.3) has an environment variable SUDO_USER when you're running sudo, which can be used in place of USERNAME above, or to be more cross-platform the script could check to see if SUDO_USER is set and use it if so, or use USERNAME if that's set.
Changing the original script for OS X, it becomes...
#!/bin/bash
sudo -u ${SUDO_USER} normal_command_1
root_command_1
root_command_2
sudo -u ${SUDO_USER} normal_command_2
# etc.
A first stab at making it cross-platform could be...
#!/bin/bash
#
# set "THE_USER" to SUDO_USER if that's set,
# else set it to USERNAME if THAT is set,
# else set it to the string "unknown"
# should probably then test to see if it's "unknown"
#
THE_USER=${SUDO_USER:-${USERNAME:-unknown}}
sudo -u ${THE_USER} normal_command_1
root_command_1
root_command_2
sudo -u ${THE_USER} normal_command_2
# etc.
You should run your entire script as superuser. If you want to run some command as non-superuser, use "-u" option of sudo:
#!/bin/bash
sudo -u username command1
command2
sudo -u username command3
command4
When running as root, sudo doesn't ask for a password.
If you use this, check man sudo too:
#!/bin/bash
sudo echo "Hi, I'm root"
sudo -u nobody echo "I'm nobody"
sudo -u 1000 touch /test_user
Well, you have some options.
You could configure sudo to not prompt for a password. This is not recommended, due to the security risks.
You could write an expect script to read the password and supply it to sudo when required, but that's clunky and fragile.
I would recommend designing the script to run as root and drop its privileges whenever they're not needed. Simply have it sudo -u someotheruser command for the commands that don't require root.
(If they have to run specifically as the user invoking the script, then you could have the script save the uid and invoke a second script via sudo with the id as an argument, so it knows who to su to..)
I'm trying to use PSEXEC to uncompress a self extracting file (a console exe created with 7zip) in a remote machine and view the results on my screen.
The remote command executes just fine, but I don't see it's output locally.
This is the command I'm using:
PSEXEC.exe \MACHINE_NAME -u USER_NAME -p PASSWORD -w "\JCOLIN\TWClient" cmd /c "\JCOLIN\TWClient\TW1.17.19.exe" -y
I also have tried:
PSEXEC.exe \MACHINE_NAME -u USER_NAME -p PASSWORD -w "\JCOLIN\TWClient" cmd /c "\JCOLIN\TWClient\TW1.17.19.exe" -y > "\JCOLIN\TWClient\TW1.17.19.exe.log"
in order to save the results in a log file and then retrieve the contents using the TYPE command but even if the log file is create it is always empty
I also have tried:
PSEXEC.exe \MACHINE_NAME -u USER_NAME -p PASSWORD -w "\JCOLIN\TWClient" cmd /c "\JCOLIN\TWClient\TW1.17.19.exe" -y 2> "\JCOLIN\TWClient\TW1.17.19.exe.log"
but in this case the PSEXEC output is saved to the file, not TW1.17.19.exe's output.
By the way, I also tried with a console SFX created with WinRAR with the same problem. I just do not understand why PSEXEC can redirect output from some programs and not others.
Do you have any idea on how to get the desired output on my screen?
Thank you in advance for any help.
You might try putting an escape character, "^", before the redirection symbol (^> instead of just >):
PSEXEC.exe \MACHINE_NAME -u USER_NAME -p PASSWORD -w "\JCOLIN\TWClient" cmd /c "\JCOLIN\TWClient\TW1.17.19.exe" -y ^> "\JCOLIN\TWClient\TW1.17.19.exe.log"
This should cause the redirection to occur on the remote machine, not the local machine.