A long remote job should not depend on the SSH session that started it. Detached on Linux, the job keeps running after the launching SSH client exits and leaves the local terminal free. Backups, exports, and maintenance scripts need that detachment rather than only a local backgrounded SSH client, and pgrep on the remote host proves it.
The ssh client waits for a remote command to finish because the command's input and output run through the SSH connection. nohup, redirected streams, and a trailing remote & free that connection, so the client exits while the job keeps running.
The command examples use /home/user/bin/backup-job.sh and /home/user/backup-job.log; replace both with a script the remote account can run and a log path it can write to.
Steps to run a remote SSH command in the background on Linux:
- Start the job on the remote host with nohup, redirected streams, and a trailing &.
$ ssh user@host.example.net "nohup /home/user/bin/backup-job.sh >/home/user/backup-job.log 2>&1 < /dev/null &"
The local prompt returns straight away while the job keeps running on the remote host. Without the redirections the prompt waits for the job to finish, and ssh -f alone does not help because it backgrounds only the local client, which stays connected until the remote command exits.
A launch with nobody at the keyboard, such as from cron, needs passwordless login because nothing can answer a password or host-key prompt.
- Check from a new SSH connection that the job is still running.
$ ssh user@host.example.net pgrep -af backup-job 65 /bin/sh /home/user/bin/backup-job.sh
No output means the job has already ended, so read /home/user/backup-job.log to see what it printed.