sudo cmd via ssh with expect twice consecutively - ssh

I used expect to execute some command with sudo in remote host via ssh. The script lies as follow:
spawn ssh -q ${user}#${host}
expect "*?assword:"
send "${pass}\r"
expect "${user}#"
send "sudo ls\r"
expect "*?assword:"
send "${pass}\r"
expect "${user}#"
send "exit\r"
interac
It runs perfectly the first time, but when I executed it consecutively some error occurred. That's because sudo won't expire right away, so if sudo some command twice in a short time, the second maybe not need the password, thus the second send "${pass}\r" in above script failed!
So how can we detect that and avoid sending password when sudo does not expire? thanks!

Modify the script so that expecting the sudo password is optional:
send "sudo ls\r"
expect {
"*?assword:" {
send "$pass\r"
exp_continue
}
"$user#" {
send "exit\r"
}
}
interac

Clean the sudo authentication cache running sudo -k just after logging.

Related

Expect script not working and terminal closes immediately

I don't know what's wrong with the script. I set up a new profile on Iterm terminal to run the script, but it never works and closes immediately. Here's the script:
#!/usr/bin/expect -f
set timeout 120
set secret mysecret
set username asdf
set host {123.456.789.010}
set password password123
log_user 0
spawn oathtool --totp --base32 $secret
expect -re \\d+
sleep 400
set otp $expect_out(0,string)
spawn ssh -2 $username#$host
expect "*assword:*"
send "$password\n"
expect "Enter Google Authenticator code:"
send "$otp\n"
interact
First, test you ssh connection with:
ssh -v <auser>#<apassword>
That will validate the SSH session works.
Make sure to not use ssh -T ..., since you might need a terminal for expect commands to work.
Second, add at least an echo at the beginning of the script, to see if it is called:
puts "Script running\r"
Third, see if a bash script, with part of it using expect as in here, would work better in this case

Automate password input on ssh :: dont want to do ssh-keygen :: spawn is not working

I am using ssh to connect to remote server from local.
[siebel#local ~]$ ssh remote
siebel#remote password:
I dont want to input the password manually. I want to write a script in which I will give the password as an input. It will enable me to login without manual action.
I don't want to setup passwordless authentication by ssh-keygen. I tried to use expect but spawn is not working. I don't want to install any other utility also.
As I said its strongly discouraged to hardcode passwords for security reasons but what I will suggest, only if you just can't avoid doing it. is to use sshpass.
You can easily do a:
sudo apt install sshpass
following that the following simple command will do the trick for you.
sshpass -p "PASSWORD" ssh -o StrictHostKeyChecking=no USERNAME#REMOTE_HOST:Custom port number(default is 22)

Use "watch" over ssh

I want to write a script that connects via ssh (ssh user#host) and runs watch who there.
Normally I would just do
ssh user#host
# I am now on the other machine
watch who
But a spript would wait until the first command is done and would start the second one. So my next try is
ssh user#host watch who
but I get an error ($? is 1) and a message:
"Error opening terminal: unknown"
ssh user#host who works just fine though. So how could I approach this?
(My real application is not to watching the users but watching the print queue, but the problem seems to be the same and I guessed that more people are familiear with who then with lpstat)
The watch needs a PTY, which is not allocated when you add a command to ssh. Use
ssh -t user#host "watch who"

Running Sudo inside SSH with << heredoc

I' m sure you will find the question similar to many other posts on stackoverflow or on internet. However, I could not find the solution to my problem precisely. I have list of task to be run on remote server, and passing the script is OK! however does not suit to the requirement.
I' m running following from my server to connect to remote server;
ssh -t user#server << 'HERE'
sudo su - <diff_user>
do task as diff_user
HERE
ssh -tt user#server << 'HERE'
sudo su - <diff_user>
do task as diff_user
HERE
With first option (-t), I' m still not able to do sudo, it says below;
sudo: sorry, you must have a tty to run sudo
With second option above (-tt), I' m getting reverse input/output to current server session, total mess.
I tried passing the content as an script to SSH to run on remote host, however, getting similar results.
Is there a way other than commenting out below?
Defaults requiretty in /etc/sudoers file
I have not tried above though, I know RedHat approved it to be removed/ commented out in future version, whenever that is. If I go with step, I will have get above done in 100's of VM's (moreover, I dont have permission to edit the file on VM's and give it a try).
Bug 1020147
Hence, my issue remains the same, as before. It would be great if I can get some input from experts here :)
Addition Info : Using RedHat RHEL 6, 2.6.32-573.3.1
I do have access to the remote host and once I' m in, my ID does not require password to switch to diff_user.
When you are asking this way, I guess you don't have passwordless sudo.
You can't communicate with the remote process (sudo), when you put the script on stdin.
You should rather use the ssh and su command:
ssh -t user#server "sudo su - <diff_user> -c do task as diff_user"
but it might not work. Interactive session can be initiated using expect (a lot of questions around here).
I was trying to connect to another machine in an automated fashion and check some logs only accessible to root/sudo.
This was done by passing the password, server, user, etc. in a file — I know this is not safe and neither a good practice, but this is the way it will be done in my company.
I have several problems:
tcgetattr: Inappropriate ioctl for device;
tty related problems that I don't remember exactly;
sudo: sorry, you must have a tty to run sudo, etc..
Here is the code that worked for me:
#!/bin/bash
function checkLog(){
FILE=$1
readarray -t LINES < "$FILE"
machine=${LINES[4]}
user=${LINES[5]}
password=${LINES[6]}
fileName=${LINES[7]}
numberOfLines=${LINES[8]}
IFS='' read -r -d '' SSH_COMMAND <<EOT
sudo -S <<< '$password' tail $fileName -n $numberOfLines
EOT
RESULTS=$(sshpass -p $password ssh -tt $user#$machine "${SSH_COMMAND}")
echo "$RESULTS"
}
checkLog $1

Using expect script to do an ssh from a remote machine

I am new to expect scripts and have a use case in which I need to do an ssh from a machine in which I have already done an ssh using expect script. This is my code snippet
#!/usr/bin/expect -f
set timeout 60
spawn ssh username#machine1.domain.com
expect "Password: "
send "Password\r"
send "\r" # This is successful. I am able to login successfully to the first machine
set timeout 60
spawn ssh username#machine2.domain.com #This fails
This takes a some amount of time and fails saying
ssh: connect to host machine2.domain.com port 22: Operation timed out. I understand that 22 is the default port on which ssh runs and I can manually override it by giving a -p option to ssh.
If I try to ssh independently without the expect script I get a prompt that asks me to enter (yes/no). From where is the correct port being picked up if I execute ssh directly without the expect script. If I do not need to enter the port number on shell why would it be needed to enter a port number if I am using an expect script.
That that point, you don't spawn a new ssh: spawn creates a new process on your local machine. You just send a command to the remote server
#!/usr/bin/expect -f
set timeout 60
spawn ssh username#machine1.domain.com
expect "Password: "
send "Password\r"
send "\r" # This is successful. I am able to login successfully to the first machine
# at this point, carry on scripting the first ssh session:
send "ssh username#machine2.domain.com\r"
expect ...