SSH Run Command: Executing Remotely Without an Interactive Shell

Q: Why does my variable expand locally instead of on the remote host?

Double quotes let your local shell expand it before sending. Use single quotes to pass the command literally so the remote shell does the expansion, and double quotes only when you deliberately want a local value injected.

Q: How do I run sudo over SSH without an interactive prompt?

Configure passwordless sudo for the specific commands in a /etc/sudoers.d/ file, scoped as narrowly as possible. For interactive use, ssh -t allocates a terminal so sudo can prompt. Never pipe a password with -S.

Q: Why does my background job die when SSH disconnects?

The remote shell sends SIGHUP to its children when the session ends. Use nohup with output redirected, systemd-run for a supervised transient unit, or tmux for something you may want to reattach to.

Q: How do I run a multi-line script over SSH?

Pipe it via stdin with a quoted heredoc: ssh host 'bash -s' <<'EOF'. The quoted delimiter prevents local expansion, so the script arrives exactly as written and you avoid escaping entirely.

Q: How can I speed up repeated SSH commands?

Enable connection multiplexing in ~/.ssh/config with ControlMaster auto, a ControlPath socket, and ControlPersist. Subsequent connections reuse the established one and skip the handshake.

Append a command to your ssh invocation and it runs on the remote host instead of opening a shell. The exit code comes back to you, which is what makes it scriptable.

This is one of the highest-leverage things to know about SSH, and most people learn only the simplest form. ssh host command runs the command remotely and returns its exit status locally — which means remote execution composes with every shell construct you already use.

The complications are all about quoting: which shell expands what, and when. Getting that model right is most of the battle.

The basic forms
Quoting, which is where the real difficulty lives
sudo, TTYs, and the -t flag
Commands that must outlive the connection
Making repeated connections fast
How this fits the rest of the stack
FAQ

The basic forms

# Single command
ssh user@server uptime

# Quoted, which you should default to
ssh user@server 'df -h /var'

# Several commands, stopping at the first failure
ssh user@server 'cd /opt/app && git pull && systemctl restart app'

# Non-standard port
ssh -p 2222 user@server 'systemctl status nginx'

# Specific key
ssh -i ~/.ssh/deploy_key user@server 'whoami'

The remote command runs through the user’s login shell on the far side, so pipes, redirections, and shell built-ins all work — as long as they survive quoting.

The exit code propagates. ssh host false returns 1 locally, which means remote commands slot into local conditionals without ceremony.

if ssh user@server 'test -f /etc/nginx/nginx.conf'; then
  echo "config present"
fi

One ambiguity to know: SSH returns 255 for its own connection failures. Since a remote command could legitimately exit 255, that value is not perfectly unambiguous — rare in practice, but worth knowing when a script behaves strangely against an unreachable host.

Quoting, which is where the real difficulty lives

There are two shells involved: your local one and the remote one. Your local shell expands things first, then whatever survives is sent to the remote shell. Nearly every SSH quoting bug is a misunderstanding of that order.

# Double quotes: LOCAL shell expands $HOSTNAME before sending
ssh user@server "echo $HOSTNAME"      # prints YOUR hostname

# Single quotes: sent literally, REMOTE shell expands it
ssh user@server 'echo $HOSTNAME'      # prints the SERVER hostname

Single quotes as the default, then. Reach for double quotes only when you deliberately want a local value interpolated into the remote command.

# Deliberate: inject a local variable into the remote command
APP_VERSION="1.4.2"
ssh user@server "deploy.sh --version $APP_VERSION"

# Mixed: local expansion for the version, remote for the hostname
ssh user@server "echo Deploying $APP_VERSION to \$(hostname)"

For anything longer than a line or two, stop fighting quoting and pipe a script over stdin. This removes the escaping problem completely and is far easier to read.

ssh user@server 'bash -s' <<'REMOTE'
set -euo pipefail
cd /opt/app
git pull
npm ci --production
systemctl restart app
REMOTE

The quoted heredoc delimiter is the important detail. <<'REMOTE' prevents local expansion entirely, so the script arrives exactly as written. Unquoted <<REMOTE expands locally first, which is occasionally what you want and usually not.

sudo, TTYs, and the -t flag

Running sudo remotely commonly fails with “sudo: no tty present and no askpass program specified”. A non-interactive SSH session has no terminal, and sudo wants one to prompt for a password.

# Fails if sudo needs a password
ssh user@server 'sudo systemctl restart nginx'

# -t allocates a pseudo-terminal so sudo can prompt
ssh -t user@server 'sudo systemctl restart nginx'

For automation, prompting is not an option. Configure passwordless sudo for the specific commands the deploy user needs — scoped narrowly, not blanket ALL.

# /etc/sudoers.d/deploy   (edit with visudo)
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /bin/systemctl status myapp

Do not pipe a password into sudo with -S. It puts the credential in your process list and shell history, and it is the kind of thing that ends up in a repository.

Note that -t also changes output handling: it merges stderr into stdout and can inject carriage returns, which corrupts output you were planning to parse. Use it when you need interactivity, not by default.

Commands that must outlive the connection

When the SSH session ends, the remote shell sends SIGHUP to its children. A backgrounded long job dies with the connection unless you detach it properly.

# Dies when the connection closes
ssh user@server './long-import.sh &'

# Survives: nohup detaches from the terminal
ssh user@server 'nohup ./long-import.sh > /var/log/import.log 2>&1 &'

# Better: systemd-run gives you a supervised transient unit
ssh user@server 'systemd-run --user --unit=import ./long-import.sh'

# Best for anything interactive: a persistent multiplexer session
ssh user@server 'tmux new-session -d -s import ./long-import.sh'
ssh -t user@server 'tmux attach -t import'

nohup with redirected output is the portable answer. systemd-run is better where available because you get logs in the journal and a unit you can query. tmux wins when you might want to reattach and watch.

Redirecting both stdout and stderr is not optional in the nohup form. Without it the process can block on a write to a closed descriptor, and the failure is confusing precisely because it is intermittent.

Making repeated connections fast

Every SSH invocation performs a full handshake — TCP, key exchange, authentication. Running twenty commands in a loop means twenty handshakes, which dominates the runtime for short commands.

Connection multiplexing reuses one connection for all of them.

# ~/.ssh/config
Host prod
  HostName server.example.com
  User deploy
  Port 2222
  IdentityFile ~/.ssh/deploy_key

  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 600

  ServerAliveInterval 30
  ServerAliveCountMax 3

mkdir -p ~/.ssh/sockets

# First call opens the connection; later ones reuse it
ssh prod 'uptime'
ssh prod 'df -h'     # near-instant, no new handshake

ControlPersist 600 keeps the master connection alive for ten minutes after the last use. For a deploy script issuing several remote commands the difference is dramatic — seconds instead of tens of seconds.

The ServerAlive settings solve a different problem: connections dropped silently by a NAT or firewall idle timeout. They send periodic keepalives so a long-running remote command does not die because nothing crossed the wire for a while.

How this fits the rest of the stack

Scripted SSH is how most deployments start, and it works until the number of hosts grows or a half-finished run leaves two servers on different versions. The step past it is a deploy that is atomic and observable rather than a sequence of remote commands you hope all succeeded. RunxBuild builds from your repository and rolls out with logs and rollback attached, so the deploy path is a pipeline rather than a shell script — and the RunxBuild hosting calculator shows what the equivalent service costs next to the servers you are currently connecting to by hand.

Useful related references:

FAQ

Why does my variable expand locally instead of on the remote host?

Double quotes let your local shell expand it before sending. Use single quotes to pass the command literally so the remote shell does the expansion, and double quotes only when you deliberately want a local value injected.

How do I run sudo over SSH without an interactive prompt?

Configure passwordless sudo for the specific commands in a /etc/sudoers.d/ file, scoped as narrowly as possible. For interactive use, ssh -t allocates a terminal so sudo can prompt. Never pipe a password with -S.

Why does my background job die when SSH disconnects?

The remote shell sends SIGHUP to its children when the session ends. Use nohup with output redirected, systemd-run for a supervised transient unit, or tmux for something you may want to reattach to.

How do I run a multi-line script over SSH?

Pipe it via stdin with a quoted heredoc: ssh host 'bash -s' <<'EOF'. The quoted delimiter prevents local expansion, so the script arrives exactly as written and you avoid escaping entirely.

How can I speed up repeated SSH commands?

Enable connection multiplexing in ~/.ssh/config with ControlMaster auto, a ControlPath socket, and ControlPersist. Subsequent connections reuse the established one and skip the handshake.