SSH remote server - display only "echo" on output in terminal - linux

I have bash script (for example):
ssh -t -t user#domain.com << EOF
cd /home/admin
mkdir test
echo 'Some text'
exit
EOF
Can I display only "echo" command in terminal? It is possible?
Now all commands are displayed.
Thank you

Specifying the commands on standard input with ssh -t causes the commands to be echoed back, but you don't have to do that.
ssh -t user#domain.com "
cd /home/admin
mkdir test
echo 'Some text'"
(The exit isn't really required or useful, so I left it out.)
Use single quotes if you want to prevent the local shell from interpolating variables etc in the string containing the commands.
To selectively display an individual command as well as its output, you can use something like
sh -vc 'echo \"Some text\"'
although the nested quoting can start getting on your nerves pretty quickly.

Related

Bash shell: command not found

I am using the shell module to execute the following command
tasks:
- name: Command
shell: "sshpass -p 123 ssh -o 'StrictHostKeyChecking no' root#10.67.13.50 shell << EOF \n whoami\nEOF | cat"
I am getting the following error
"stderr_lines": [
"/bin/sh: line 2: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')",
"Warning: Permanently added '10.67.13.50' (ECDSA) to the list of known hosts.",
"bash: shell: command not found"
]
What is wrong with my command?
tl;dr you can either a) replace shell with sh or bash, or b) replace shell with whoami and drop the heredoc.
Let's decompose the shell command:
sshpass -p 123 ssh -o 'StrictHostKeyChecking no' root#10.67.13.50 shell << EOF \n whoami\nEOF | cat
There are several processes happening here.
A sh pipeline with two subprocesses:
sshpass which then runs as a subprocess…
ssh which connects to 10.67.13.50 and runs…
shell with \n whoami\n as its standard input
… and cat, which takes the output from the sshpass process hierarchy
There are a couple potential bugs:
You can safely remove cat from the pipeline.
As #KamilCuk mentioned, cat reads from its input and writes it out. It isn't doing anything here; it's neither useful nor harmless.
shell is not a command on the remote server (10.67.13.50). If you want to run a shell, typically sh or bash is used.
Moreover, you can replace the entire shell … EOF sequence with whoami.
The << EOF \n whoami \nEOF is a heredoc to tell the shell on the remote server what commands to execute. However, there is only one command executed.
In summary, the shell: line could be rewritten as:
sshpass -p 123 ssh -o 'StrictHostKeyChecking no' root#10.67.13.50 whoami
… an odd command, since we know the remote user root.

Executing `sh -c` in a bash script

I have a test.sh file which takes as a parameter a bash command, it does some logic, i.e. setting and checking some env vars, and then executes that input command.
#!/bin/bash
#Some other logic here
echo "Run command: $#"
eval "$#"
When I run it, here's the output
% ./test.sh echo "ok"
Run command: echo ok
ok
But the issue is, when I pass something like sh -c 'echo "ok"', I don't get the output.
% ./test.sh sh -c 'echo "ok"'
Run command: sh -c echo "ok"
%
So I tried changing eval with exec, tried to execute $# directly (without eval or exec), even tried to execute it and save the output to a variable, still no use.
Is there any way to run the passed command in this format and get the ourput?
Use case:
The script is used as an entrypoint for the docker container, it receives the parameters from docker CMD and executes those to run the container.
As a quickfix I can remove the sh -c and pass the command without it, but I want to make the script reusable and not to change the commands.
TL;DR:
This is a typical use case (perform some business logic in a Docker entrypoint script before running a compound command, given at command line) and the recommended last line of the script is:
exec "$#"
Details
To further explain this line, some remarks and hyperlinks:
As per the Bash user manual, exec is a POSIX shell builtin that replaces the shell [with the command supplied] without creating a new process.
As a result, using exec like this in a Docker entrypoint context is important because it ensures that the CMD program that is executed will still have PID 1 and can directly handle signals, including that of docker stop (see also that other SO answer: Speed up docker-compose shutdown).
The double quotes ("$#") are also important to avoid word splitting (namely, ensure that each positional argument is passed as is, even if it contains spaces). See e.g.:
#!/usr/bin/env bash
printargs () { for arg; do echo "$arg"; done; }
test0 () {
echo "test0:"
printargs $#
}
test1 () {
echo "test1:"
printargs "$#"
}
test0 /bin/sh -c 'echo "ok"'
echo
test1 /bin/sh -c 'echo "ok"'
test0:
/bin/sh
-c
echo
"ok"
test1:
/bin/sh
-c
echo "ok"
Finally eval is a powerful bash builtin that is (1) unneeded for your use case, (2) and actually not advised to use in general, in particular for security reasons. E.g., if the string argument of eval relies on some user-provided input… For details on this issue, see e.g. https://mywiki.wooledge.org/BashFAQ/048 (which recaps the few situations where one would like to use this builtin, typically, the command eval "$(ssh-agent -s)").

Shell script to compare remote directories

I have a shell script that I am using to compare directory contents. The script has to ssh to different servers to get a directory listing. When I run the script below, I am getting the contents of the server that I am logged into's /tmp directory listing and not that of the servers I am trying to ssh to. Could you please tell me what I am doing wrong?
The config file used in the script is as follows (called config.txt):
server1,server2,/tmp
The script is as follows
#!/bin/sh
CONFIGFILE="config.txt"
IFS=","
while read a b c
do
SERVER1=$a
SERVER2=$b
COMPDIR=$c
`ssh user#$SERVER1 'ls -l $COMPDIR'`| sed -n '1!p' >> server1.txt
`ssh user#$SERVER2 'ls -l $COMPDIR'`| sed -n '1!p' >> server2.txt
done < $CONFIGFILE
When I look at the outputs of server1.txt and server2.txt, they are both exactly the same - having the contents of /tmp of the server the script is running on (not server1 or 2). Doing the ssh +dir listing on command line works just fine. I am also getting the error "Pseudo-terminal will not be allocated because stdin is not a terminal". Adding the -t -t to the ssh command isnt helping either
Thank you
I have the back ticks in order to execute the command.
Backticks are not needed to execute a command - they are used to expand the standard output of the command into the command line. Certainly you don't want the output of your ssh commands to be interpreted as commands. Thus, it should work fine without the backticks:
ssh user#$SERVER1 "ls -l $COMPDIR" | sed -n '1!p' >>server1.txt
ssh user#$SERVER2 "ls -l $COMPDIR" | sed -n '1!p' >>server2.txt
(provided that double quotes to allow expansion of $COMPDIR are used).
first you need to generate keys to login to remote without keys
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host
then try to ssh without pass
ssh remote-host
then try to invoke in your script but first make sanity check
var1=$(ssh remote-host) die "Cannot connect to remote host" unless $var1;

Triple nested quotations in shell script

I'm trying to write a shell script that calls another script that then executes a rsync command.
The second script should run in its own terminal, so I use a gnome-terminal -e "..." command. One of the parameters of this script is a string containing the parameters that should be given to rsync. I put those into single quotes.
Up until here, everything worked fine until one of the rsync parameters was a directory path that contained a space. I tried numerous combinations of ',",\",\' but the script either doesn't run at all or only the first part of the path is taken.
Here's a slightly modified version of the code I'm using
gnome-terminal -t 'Rsync scheduled backup' -e "nice -10 /Scripts/BackupScript/Backup.sh 0 0 '/Scripts/BackupScript/Stamp' '/Scripts/BackupScript/test' '--dry-run -g -o -p -t -R -u --inplace --delete -r -l '\''/media/MyAndroid/Internal storage'\''' "
Within Backup.sh this command is run
rsync $5 "$path"
where the destination $path is calculated from text in Stamp.
How can I achieve these three levels of nested quotations?
These are some question I looked at just now (I've tried other sources earlier as well)
https://unix.stackexchange.com/questions/23347/wrapping-a-command-that-includes-single-and-double-quotes-for-another-command
how to make nested double quotes survive the bash interpreter?
Using multiple layers of quotes in bash
Nested quotes bash
I was unsuccessful in applying the solutions to my problem.
Here is an example. caller.sh uses gnome-terminal to execute foo.sh, which in turn prints all the arguments and then calls rsync with the first argument.
caller.sh:
#!/bin/bash
gnome-terminal -t "TEST" -e "./foo.sh 'long path' arg2 arg3"
foo.sh:
#!/bin/bash
echo $# arguments
for i; do # same as: for i in "$#"; do
echo "$i"
done
rsync "$1" "some other path"
Edit: If $1 contains several parameters to rsync, some of which are long paths, the above won't work, since bash either passes "$1" as one parameter, or $1 as multiple parameters, splitting it without regard to contained quotes.
There is (at least) one workaround, you can trick bash as follows:
caller2.sh:
#!/bin/bash
gnome-terminal -t "TEST" -e "./foo.sh '--option1 --option2 \"long path\"' arg2 arg3"
foo2.sh:
#!/bin/bash
rsync_command="rsync $1"
eval "$rsync_command"
This will do the equivalent of typing rsync --option1 --option2 "long path" on the command line.
WARNING: This hack introduces a security vulnerability, $1 can be crafted to execute multiple commands if the user has any influence whatsoever over the string content (e.g. '--option1 --option2 \"long path\"; echo YOU HAVE BEEN OWNED' will run rsync and then execute the echo command).
Did you try escaping the space in the path with "\ " (no quotes)?
gnome-terminal -t 'Rsync scheduled backup' -e "nice -10 /Scripts/BackupScript/Backup.sh 0 0 '/Scripts/BackupScript/Stamp' '/Scripts/BackupScript/test' '--dry-run -g -o -p -t -R -u --inplace --delete -r -l ''/media/MyAndroid/Internal\ storage''' "

getting user input while SSH'ed into another box

I have a bash script that basically should work like below:
get build number from user and put it in buildNum var
prep the build on local machine by calling a local script with buildNum as it's argument
sftp the prepped zip file to remote server1
Do this:
ssh -v $server1 <<EOF
rm -rvf path1-on-remote-server1/*
cd path2-on-remote-server1
unzip ../prepped-zip-file-$buildNum.zip
exit
EOF
sftp the prepped zip file to remote server2
The problem i am having is that on the forth step of number 4, $buildNum is not known to the remote server and it fails.
I tried the following two solutions and both failed:
use double quotes "unzip ../prepped-zip-file-$buildNum.zip" which resulted in "unzip ../prepped-zip-file-11.6.zip: Command not found.
tried to get the build number again from the user during the SSH session which failed again by not even waiting for my input and looking for a zip file without the build number at the end of the name, as the var was empty,
i did :
ssh -v $server1 <<EOF
rm -rvf path1-on-remote-server1/*
cd path2-on-remote-server1
echo "enter build num once more: "
read bNum
unzip ../prepped-zip-file-$bNum.zip
exit
EOF
Any suggestions on how to achieve what i am after.
Thanks in advance
Are you sure this doesn't work?
ssh -v $server1 <<EOF
rm -rvf path1-on-remote-server1/*
cd path2-on-remote-server1
unzip ../prepped-zip-file-$buildNum.zip
exit
EOF
When I try it on my machine, with cat instead of ssh -v $server1 for testing, the variable does get substituted into the here-document, just as if the entire document had been on a command line. The remove shell never needs to know there was a variable in the first place.
Actually, though, you may want to give the remote command on the ssh command line rather than redirecting the standard input. This would be more robust in case some of the parts of it unexpectedly decide to try reading from stdin:
ssh -v $server1 "rm -rvf path1-on-remote-server1/*
cd path2-on-remote-server1
unzip ../prepped-zip-file-$buildNum.zip"
(Note that multi-line double-quoted strings are okay with bash).
#!/bin/sh
printf "Enter Build Number: "
read BUILD_NUM
cat << EOF | ssh $server1
hostname
echo "${BUILD_NUM}"
uptime
EOF
That works for me.

Resources