1434

I have to run a local shell script (windows/Linux) on a remote machine.

I have SSH configured on both machine A and B. My script is on machine A which will run some of my code on a remote machine, machine B.

The local and remote computers can be either Windows or Unix based system.

Is there a way to run do this using plink/ssh?

8
  • 7
    The same question is already on serverfault: serverfault.com/questions/215756/… So there's probably no point in migrating this question.
    – sleske
    Commented Sep 11, 2012 at 15:46
  • 9
    The question on Server Fault doesn't have as many answers though. Maybe this question should replace that one. Commented Dec 18, 2013 at 16:31
  • 5
    I like this answer personally: unix.stackexchange.com/questions/87405/… Commented Jul 8, 2014 at 22:03
  • 27
    Furthermore it should obviously be on topic since ssh is a prime tool for software development. Commented Aug 31, 2015 at 17:38
  • 5
    Coffee and ssh questions do not share the same degree of off-topicness on SO. Voted for reopen. Commented Nov 22, 2017 at 3:05

25 Answers 25

1371

If Machine A is a Windows box, you can use Plink (part of PuTTY) with the -m parameter, and it will execute the local script on the remote server.

plink root@MachineB -m local_script.sh

If Machine A is a Unix-based system, you can use:

ssh root@MachineB 'bash -s' < local_script.sh

You shouldn't have to copy the script to the remote server to run it.

24
  • 13
    is there an advantage to using the -s option? this man page leads me to believe that it will process standard input when it's done processing options, whether -s is used or not. Commented Nov 18, 2011 at 5:41
  • 89
    For a script that requires sudo, run ssh root@MachineB 'echo "rootpass" | sudo -Sv && bash -s' < local_script.sh. Commented Sep 20, 2012 at 23:32
  • 11
    @bradley.ayers in what situations would you need sudo if you are already logging in as root? Commented Jan 20, 2014 at 22:41
  • 29
    @Agostino, you can add parameters like this: ssh root@MachineB ARG1="arg1" ARG2="arg2" 'bash -s' < local_script.sh Credits fully go to @chubbsondubs' answer below. Commented Mar 7, 2014 at 8:28
  • 19
    @YvesVanBroekhoven This is old, but the very point of -s is to be able to pass arguments to a script that is sourced through stdin: ssh root@MachineB 'bash -s arg1 arg2' < local_script.sh. Omitting -s would cause arg1 to be interpreted as the remote script to execute with arg2 as its first argument. There is no need to use environment variables.
    – JoL
    Commented Aug 31, 2018 at 2:27
746

This is an old question, and Jason's answer works fine, but I would like to add this:

ssh user@host <<'ENDSSH'
#commands to run on remote host
ENDSSH

This can also be used with su and commands which require user input. (note the ' escaped heredoc)

Since this answer keeps getting bits of traffic, I would add even more info to this wonderful use of heredoc:

You can nest commands with this syntax, and that's the only way nesting seems to work (in a sane way)

ssh user@host <<'ENDSSH'
#commands to run on remote host
ssh user@host2 <<'END2'
# Another bunch of commands on another host
wall <<'ENDWALL'
Error: Out of cheese
ENDWALL
ftp ftp.example.com <<'ENDFTP'
test
test
ls
ENDFTP
END2
ENDSSH

You can actually have a conversation with some services like telnet, ftp, etc. But remember that heredoc just sends the stdin as text, it doesn't wait for response between lines

I just found out that you can indent the insides with tabs if you use <<-END!

ssh user@host <<-'ENDSSH'
    #commands to run on remote host
    ssh user@host2 <<-'END2'
        # Another bunch of commands on another host
        wall <<-'ENDWALL'
            Error: Out of cheese
        ENDWALL
        ftp ftp.example.com <<-'ENDFTP'
            test
            test
            ls
        ENDFTP
    END2
ENDSSH

(I think this should work)

Also see http://tldp.org/LDP/abs/html/here-docs.html

16
  • 6
    you can temporize a bit by adding lines such as: # $(sleep 5) Commented Feb 22, 2013 at 13:45
  • 59
    note that with single quotes around the terminator (<<'ENDSSH'), the strings will not be expanded, variables will not be evaluated. You can also use <<ENDSSH or <<"ENDSSH" if you want expansion.
    – maackle
    Commented Jun 18, 2013 at 5:38
  • 5
    Expect can be used when you need to automate interactive commands like FTP. Commented Apr 14, 2014 at 7:35
  • 6
    Note that I had a Pseudo-terminal will not be allocated because stdin is not a terminal. message. One has to use ssh with -t -t params to avoid that. See this thread on SO
    – Buzut
    Commented Apr 1, 2016 at 12:55
  • 10
    If you're trying to use the <<-'END' syntax, be sure your heredoc ending delimiter is indented using TABs, not spaces. Note that copy/paste from stackexchange will give you spaces. Change those to tabs and the indent feature should work.
    – fbicknel
    Commented Jun 24, 2016 at 17:06
270

Also, don't forget to escape variables if you want to pick them up from the destination host.

This has caught me out in the past.

For example:

user@host> ssh user2@host2 "echo \$HOME"

prints out /home/user2

while

user@host> ssh user2@host2 "echo $HOME"

prints out /home/user

Another example:

user@host> ssh user2@host2 "echo hello world | awk '{print \$1}'"

prints out "hello" correctly.

3
  • 2
    However be aware of the following: ssh user2@host 'bash -s' echo $HOME /home/user2 exit Commented Apr 30, 2013 at 6:55
  • 1
    Just to add that in for loops running in ssh session the loop variable must not be escaped. Commented Apr 22, 2014 at 8:00
  • 1
    In many situations, the sane way to fix your last example would be ssh user2@host2 'echo hello world' | awk '{ print $1 }' i.e. run the Awk script locally. If the remote command produces an immense about of output, you want to avoid copying it all back to the local server, of course. Incidentally, single quotes around the remote command avoid the need for any escaping.
    – tripleee
    Commented Dec 29, 2015 at 11:34
175

This is an extension to YarekT's answer to combine inline remote commands with passing ENV variables from the local machine to the remote host so you can parameterize your scripts on the remote side:

ssh user@host ARG1=$ARG1 ARG2=$ARG2 'bash -s' <<'ENDSSH'
  # commands to run on remote host
  echo $ARG1 $ARG2
ENDSSH

I found this exceptionally helpful by keeping it all in one script so it's very readable and maintainable.

Why this works. ssh supports the following syntax:

ssh user@host remote_command

In bash we can specify environment variables to define prior to running a command on a single line like so:

ENV_VAR_1='value1' ENV_VAR_2='value2' bash -c 'echo $ENV_VAR_1 $ENV_VAR_2'

That makes it easy to define variables prior to running a command. In this case echo is our command we're running. Everything before echo defines environment variables.

So we combine those two features and YarekT's answer to get:

ssh user@host ARG1=$ARG1 ARG2=$ARG2 'bash -s' <<'ENDSSH'...

In this case we are setting ARG1 and ARG2 to local values. Sending everything after user@host as the remote_command. When the remote machine executes the command ARG1 and ARG2 are set the local values, thanks to local command line evaluation, which defines environment variables on the remote server, then executes the bash -s command using those variables. Voila.

3
  • 1
    Note that if you want to pass args like -a then you can use --. e.g. 'ssh user@host -- -a foo bar 'bash -s' <script.sh'. And the args can also go after the redirect e.g. 'ssh user@host 'bash -s' <script.sh -- -a foo bar'.
    – gaoithe
    Commented Mar 10, 2016 at 17:28
  • 9
    If any of the env var values contain spaces, use: ssh user@host "ARG1=\"$ARG1\" ARG2=\"$ARG2\"" 'bash -s' <<'ENDSSH'...
    – TalkLittle
    Commented Sep 24, 2016 at 4:01
  • 3
    Like I wrote in another comment, the very point of using -s is to be able to apply arguments to scripts that are sourced through stdin. I mean, you may as well omit it if you're not going to use it. If you do use it, there is no reason to use environment variables: ssh user@host 'bash -s value1 value2' <<< 'echo "$@"'
    – JoL
    Commented Sep 17, 2018 at 21:09
113
<hostA_shell_prompt>$ ssh user@hostB "ls -la"

That will prompt you for password, unless you have copied your hostA user's public key to the authorized_keys file on the home of user .ssh's directory. That will allow for passwordless authentication (if accepted as an auth method on the ssh server's configuration)

3
  • 3
    Voted you up. This is a valid solution. Obviously, the keys must be protected, but they can also be invalidated just like a password via the server side. Commented Nov 21, 2008 at 17:44
  • 18
    I don't think this answers the question. The example shows how to run a remote command, but not how to execute a local script on a remote machine. Commented Apr 28, 2010 at 21:03
  • Not certain but can't you pipe your script on hostA to run on hostB using this method?
    – nevets1219
    Commented Apr 28, 2010 at 21:13
28

I've started using Fabric for more sophisticated operations. Fabric requires Python and a couple of other dependencies, but only on the client machine. The server need only be a ssh server. I find this tool to be much more powerful than shell scripts handed off to SSH, and well worth the trouble of getting set up (particularly if you enjoy programming in Python). Fabric handles running scripts on multiple hosts (or hosts of certain roles), helps facilitate idempotent operations (such as adding a line to a config script, but not if it's already there), and allows construction of more complex logic (such as the Python language can provide).

25
cat ./script.sh | ssh <user>@<host>
2
  • 1
    Interestingly, this method of 'cat script.sh | ssh user@host' is the only one that is working for me to run a shell script on another host. the 'bash' < script.sh method is not working correctly, but I didn't spend time troubleshooting that. I even copied the script to the remote host, and I see 'file not found', even though if I login to the host and run the script, it works. Commented Aug 6, 2020 at 0:18
  • How about cat ./script.sh | ssh -i ~\\.ssh\\id_rsa <user>@<host> 'bash -'
    – LWS
    Commented Feb 26, 2023 at 7:51
15
chmod +x script.sh    
ssh -i key-file [email protected] < ./script.sh
1
  • I don't think the chmod +x is necessary or useful in this case. The script isn't executed on the local host, it's read on the local host, and only its content is sent to the remote host and executed there. The remote host doesn't even know the content came from a file and thus doesn't care about the permissions of the file. Commented Dec 14, 2023 at 11:08
11

Try running ssh user@remote sh ./script.unx.

2
  • 12
    This only works if the script is in the default (home) directory on the remote. I think the question is how to run a script stored locally on the remote.
    – metasim
    Commented Jul 20, 2010 at 12:35
  • 1
    ssh username@ip "chmod +x script.sh" <br/> ssh username@ip "path to sh file in remote host" Commented Mar 24, 2014 at 10:18
8

Assuming you mean you want to do this automatically from a "local" machine, without manually logging into the "remote" machine, you should look into a TCL extension known as Expect, it is designed precisely for this sort of situation. I've also provided a link to a script for logging-in/interacting via SSH.

https://www.nist.gov/services-resources/software/expect

http://bash.cyberciti.biz/security/expect-ssh-login-script/

0
7
ssh user@hostname ". ~/.bashrc;/cd path-to-file/;. filename.sh"

highly recommended to source the environment file(.bashrc/.bashprofile/.profile). before running something in remote host because target and source hosts environment variables may be deffer.

2
  • This does not explain how to move a local script to the remote host.
    – kirelagin
    Commented Apr 16, 2020 at 11:05
  • it seems that a space is missing before ~/.bashrc
    – vhamon
    Commented Jan 4, 2021 at 13:08
5

I use this one to run a shell script on a remote machine (tested on /bin/bash):

ssh deploy@host . /home/deploy/path/to/script.sh
4

If the script is short and is meant to be embedded inside your script and you are running under bash shell and also bash shell is available on the remote side, you may use declare to transfer local context to remote. Define variables and functions containing the state that will be transferred to the remote. Define a function that will be executed on the remote side. Then inside a here document read by bash -s you can use declare -p to transfer the variable values and use declare -f to transfer function definitions to the remote.

Because declare takes care of the quoting and will be parsed by the remote bash, the variables are properly quoted and functions are properly transferred. You may just write the script locally, usually I do one long function with the work I need to do on the remote side. The context has to be hand-picked, but the following method is "good enough" for any short scripts and is safe - should properly handle all corner cases.

somevar="spaces or other special characters"
somevar2="!@#$%^"
another_func() {
    mkdir -p "$1"
}
work() {
    another_func "$somevar"
    touch "$somevar"/"$somevar2"
}
ssh user@server 'bash -s' <<EOT
$(declare -p somevar somevar2)    # transfer variables values
$(declare -f work another_func)   # transfer function definitions
work                              # call the function
EOT
3

It's easiest to explain a solution for what the OP is asking for by using a demo:

  1. Create a local script however you want. You don't need to set the executable bit. In this example, I use a here document:

    cat <<END >demo.sh
    > echo "Script executed on ${HOSTNAME} with args: $@"
    > END
    
  2. Using ssh run the local script on the remote host.

    Both ways work:

    cat demo.sh | ssh host bash -s -- hello world
    

    or

    ssh host bash -s -- hello world < demo.sh
    

    In either case, you'll see the following output (with HOSTNAME replaced with the remote hostname):

    Script executed on HOSTNAME with args: hello world
    

Notes

  • Using -s tells bash to read from stdin (see 6.1 Invoking Bash).

  • Using -- ensures the following arguments are passed to the script, not to bash.

1
  • 1
    That's the cleanest answer, if you intend to use parameters with the script. Commented Mar 15 at 12:20
2

This bash script does ssh into a target remote machine, and run some command in the remote machine, do not forget to install expect before running it (on mac brew install expect )

#!/usr/bin/expect
set username "enterusenamehere"
set password "enterpasswordhere"
set hosts "enteripaddressofhosthere"
spawn ssh  $username@$hosts
expect "$username@$hosts's password:"
send -- "$password\n"
expect "$"
send -- "somecommand on target remote machine here\n"
sleep 5
expect "$"
send -- "exit\n"
1
  • 1
    this is great if you must use passwords ... however for benefit of anyone watching at home any ssh command should use a pair of public+private keys not passwords ... once in place update your ssh server to shut off passwords entirely Commented Mar 1, 2019 at 16:25
2

if you wanna execute command like this temp=`ls -a` echo $temp command in `` will cause errors.

below command will solve this problem ssh user@host ''' temp=`ls -a` echo $temp '''

2

You can use runoverssh:

sudo apt install runoverssh
runoverssh -s localscript.sh user host1 host2 host3...

-s runs a local script remotely


Useful flags:
-g use a global password for all hosts (single password prompt)
-n use SSH instead of sshpass, useful for public-key authentication

1

The answer here (https://stackoverflow.com/a/2732991/4752883) works great if you're trying to run a script on a remote linux machine using plink or ssh. It will work if the script has multiple lines on linux.

**However, if you are trying to run a batch script located on a local linux/windows machine and your remote machine is Windows, and it consists of multiple lines using **

plink root@MachineB -m local_script.bat

wont work.

Only the first line of the script will be executed. This is probably a limitation of plink.

Solution 1:

To run a multiline batch script (especially if it's relatively simple, consisting of a few lines):

If your original batch script is as follows

cd C:\Users\ipython_user\Desktop 
python filename.py

you can combine the lines together using the "&&" separator as follows in your local_script.bat file: https://stackoverflow.com/a/8055390/4752883:

cd C:\Users\ipython_user\Desktop && python filename.py

After this change, you can then run the script as pointed out here by @JasonR.Coombs: https://stackoverflow.com/a/2732991/4752883 with:

`plink root@MachineB -m local_script.bat`

Solution 2:

If your batch script is relatively complicated, it may be better to use a batch script which encapsulates the plink command as well as follows as pointed out here by @Martin https://stackoverflow.com/a/32196999/4752883:

rem Open tunnel in the background
start plink.exe -ssh [username]@[hostname] -L 3307:127.0.0.1:3306 -i "[SSH
key]" -N

rem Wait a second to let Plink establish the tunnel 
timeout /t 1

rem Run the task using the tunnel
"C:\Program Files\R\R-3.2.1\bin\x64\R.exe" CMD BATCH qidash.R

rem Kill the tunnel
taskkill /im plink.exe
1

It is unclear if the local script uses locally set variables, functions, or aliases.

If it does this should work:

myscript.sh:

#!/bin/bash

myalias $myvar
myfunction $myvar

It uses $myvar, myfunction, and myalias. Let us assume they is set locally and not on the remote machine.

Make a bash function that contains the script:

eval "myfun() { `cat myscript.sh`; }"

Set variable, function, and alias:

myvar=works
alias myalias='echo This alias'
myfunction() { echo This function "$@"; }

And "export" myfun, myfunction, myvar, and myalias to server using env_parallel from GNU Parallel:

env_parallel -S server -N0  --nonall myfun ::: dummy
1

If it's one script it's fine with the above solution.

I would set up Ansible to do the Job. It works in the same way (Ansible uses ssh to execute the scripts on the remote machine for both Unix or Windows).

It will be more structured and maintainable.

The docs for Ansible's builtin shell script execution module are here https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html#ansible-collections-ansible-builtin-shell-module

You can make a basic Ansible playbook that runs commands on the remote server over ssh like this

  • file inventory.ini
[myhosts]
1.2.4.5
10.1.6.25
  • file playbook.yml
---
  - name: Run a task on the server
    ansible.builtin.shell: |
      cd $HOME
      echo "run your task here"
    args:
      executable: /bin/bash # default may be /bin/sh
    register: inline_task_output

  - name: Copy a local script to the remote
    ansible.builtin.copy:
      src:  "{{ playbook_dir }}/myscript.sh"
      dest: "~/ansible_test/myscript.sh"

  - name: Run the script you just copied to the server
    ansible.builtin.shell: |
      cd $HOME/ansible_test
      bash myscript.sh
    args:
      executable: /bin/bash 
    register: script_output

  # print the stdout from some tasks
  - debug: var=script_output
  - debug: var=inline_task_output

  • run the playbook
ansible-playbook -i inventory.ini playbook.yaml

Ansible will default to utilizing ssh to copy the commands over to the remote servers listed in the inventory file, and perform the tasks listed in the playbook. In the case of shell commands, it will execute the commands on the remote host over ssh.

Using Ansible is advantageous because it will scale much better to numerous hosts, and handles complex series of tasks much easier without you having to write a bunch of ugly wrapper code around executing commands over ssh directly. It will also complement tools like TerraForm which may be used for provisioning the hosts you would execute tasks on.

0

Extending answer from @cglotr. In order to write inline command use printf, it useful for simple command and it support multiline using char escaping '\n'

example :

printf "cd /to/path/your/remote/machine/log \n tail -n 100 Server.log" | ssh <user>@<host> 'bash -s'

See don't forget to add bash -s

0

I created a solution that works better for me by combining the use of a heredoc from Yarek T's answer with the piped cat method from cglotr's answer along with some other tricks for non-interactive login (using sshpass), using variables from the local and remote host in the script, and enabling sudo commands. The code is longer just because it includes some additional tricks that are likely desired, but the original questioner didn't ask for them.

The problem I have with Yarek's answer is that all the warnings and commands in the heredoc print to the screen. The problem I have with cglotr's answer is that is requires a script file and a complex command with additional interaction to execute the script. With my solution, I write a script that does everything by simply calling the script with the remote host IP address as the first argument like this:

./MYSCRIPT REMOTE_IP_ADDRESS

The script to be run on the remote host is saved to a variable within the script on the local host using a heredoc so that you don't need to do any quote escaping. Then, the variable containing the script is echo piped to sshpass. Be sure to indent the commands with tabs and not spaces (you'll get spaces instead of tabs when you copy the code). Here is an example of the remote script within the local script.

!/bin/bash
# Input argument 1 should be the target host IP address (required)
RX_IP="/(\b25[0-5]|\b2[0-4][0-9]|\b[01]?[0-9][0-9]?)(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}/"
IS_IP=$(echo $1 | sed -nr "${RX_IP}p" | wc -l)
if (( $IS_IP )); then
    USERNAME=remoteuser
    HOSTNAME=$1
    # Export the SSH password to environment variable for sshpass and sudo.
    # The space before the command prevents saving the command to history.
     export SSHPASS=mypassword;
    while read -r -d '' SCRIPT <<-EOS
        # Enable sudo commands with the following command.
        # The space before echo prevents saving the command to history.
         echo $SSHPASS | sudo -Sv
        # Do stuff here. Escape variables to be be accessed on the remote host.
        # For example, escape print variable in an awk command:
        # This command lists all USB block device partitions.
        ls -l /dev /dev/mapper | awk '/^b/ && /sd[a-z][1-9]/ {print \$10}'
        exit
    EOS
    echo "$SCRIPT" | sshpass -e ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ${USERNAME}@${HOSTNAME} &>/dev/null
    echo 'DONE'
else
    echo "Missing IP address of target host."
    echo "Usage: ./SCRIPT_NAME IP_ADDRESS
fi

You need to install sshpass on the local host like this (for Debian based distros).

sudo apt install sshpass
0

On Windows

In cmd.exe, run

type "C:\path\to\script.sh" | ssh username@hostname

Ensure that the script.sh file uses LF, rather than CRLF as line endings.

1
  • I'm not sure why the top answer suggests plink when it's not necessary
    – fjch1997
    Commented Jul 10 at 17:46
-1

There is another approach ,you can copy your script in your host with scp command then execute it easily .

-20

First, copy the script over to Machine B using scp

[user@machineA]$ scp /path/to/script user@machineB:/home/user/path

Then, just run the script

[user@machineA]$ ssh user@machineB "/home/user/path/script"

This will work if you have given executable permission to the script.

6
  • hi i applied recommended suggession but it give me following error [oracle@node1 ~]$ ssh oracle@node2:./home/oracle/au/fs/conn.sh ssh: node2:./home/oracle/au/fs/conn.sh: Name or service not known [oracle@node1 ~]$
    – Kev
    Commented Nov 20, 2008 at 12:47
  • 'ssh oracle@node2:./home/oracle/au/fs/conn.sh'? Wrong command line, the command name should be separated from the user@host part with a space, not a colon.
    – bortzmeyer
    Commented Dec 15, 2008 at 13:37
  • 9
    I'm downvoting this because it's primary claim that it can't be run without copying it over is incorrect. Commented Apr 28, 2010 at 21:02
  • It would have been helpful is Jason added why that's incorrect instead of simply stating the fact. Unhelpful.
    – Kris
    Commented Dec 28, 2013 at 3:31
  • [user@machineA]$ ssh root@MachineB 'bash -s' < /machinea/path/to/script Commented Jun 30, 2019 at 16:01