How to execute remote SSH commands in the background

Running long-running administrative or batch jobs over SSH often requires keeping the local terminal free for other work. Remote commands that perform backups, data processing, or monitoring tasks benefit from being launched in a way that allows the local shell to return immediately while the remote process continues independently.

The ssh client maintains a channel to the remote shell and normally waits for the remote command to finish and close the connection. Simply appending & or using nohup on the local command does not detach the ssh client from standard input, so the local session can still block until the remote side exits. The -n and -f options of ssh control how standard input is handled and when the client is sent to the background during command execution.

Using backgrounded remote commands requires attention to authentication and output handling. Non-interactive authentication such as key-based login avoids prompts that cannot be answered once ssh detaches from the terminal. Long-running background processes should either ignore hangup signals via nohup or redirect output away from the SSH channel so that the remote process does not terminate when the session closes unexpectedly.

1. Open a terminal on the local system that has network access to the remote host over SSH.

   $ whoami
   localuser

2. Confirm that a simple remote command blocks until completion to observe the default behavior.

   $ ssh user@remote_server 'sleep 30'
   ##### snipped #####

   

   The prompt returns only after the remote sleep command completes.

3. Inspect the ssh manual entries for the -n and -f options to understand how they affect background execution.

   -n      Redirects stdin from /dev/null (actually, prevents reading from
           stdin).  This must be used when ssh is run in the background.  A
           common trick is to use this to run X11 programs on a remote ma‐
           chine.  For example, ssh -n shadows.cs.hut.fi emacs & will start an
           emacs on shadows.cs.hut.fi, and the X11 connection will be automat‐
           ically forwarded over an encrypted channel.  The ssh program will
           be put in the background.  (This does not work if ssh needs to ask
           for a password or passphrase; see also the -f option.)
   
   -f      Requests ssh to go to background just before command execution.
           This is useful if ssh is going to ask for passwords or passphrases,
           but the user wants it in the background.  This implies -n.  The
           recommended way to start X11 programs at a remote site is with
           something like ssh -f host xterm.

   Option -f implies -n, redirecting standard input from /dev/null before the command runs.

4. Launch a remote command with ssh using -n and -f so the client detaches immediately while the remote process continues.

   $ ssh -n -f user@remote_server 'command_to_execute > /dev/null 2>&1 &'

   Omitting output redirection can keep the channel open or cause the remote process to stop when the SSH session closes.

5. Use nohup in the remote command when the process must ignore hangup signals and keep its output in a log file.

   $ ssh -fn user@remote_server 'nohup command_to_execute &'

   Without explicit redirection, nohup writes output to nohup.out in the remote working directory.

6. Verify that the remote command is running independently by listing matching processes from a separate SSH session.

   $ ssh user@remote_server 'ps aux | grep command_to_execute | grep -v grep'
   remoteuser  12345  0.3  1.2 123456 7890 ?        S    10:15   0:01 command_to_execute

   Process presence on the remote host confirms that the command continues after the original launcher exited.

7. Confirm that the local ssh client no longer occupies the terminal by checking for lingering background ssh processes.

   $ ps aux | grep 'ssh .*user@remote_server' | grep -v grep

   An empty result indicates that the local ssh process exited after starting the backgrounded remote command.