这对我来说很有效:

ssh -x remoteServer "cd yourRemoteDir; ./yourRemoteScript.sh </dev/null >/dev/null 2>&1 & " 

这对我来说很有效:

ssh -x remoteServer "cd yourRemoteDir; ./yourRemoteScript.sh </dev/null >/dev/null 2>&1 & " 

如果你不能/不能保持连接打开，你可以使用屏幕，如果你有权限安装它。

user@localhost $ screen -t remote-command
user@localhost $ ssh user@target # now inside of a screen session
user@remotehost $ cd /some/directory; program-to-execute &

分离屏幕会话:ctrl-a d

列出屏幕会话:

screen -ls

重新连接一个会话:

screen -d -r remote-command

注意，screen还可以在每个会话中创建多个shell。使用tmux也可以达到类似的效果。

user@localhost $ tmux
user@localhost $ ssh user@target # now inside of a tmux session
user@remotehost $ cd /some/directory; program-to-execute &

卸载tmux会话:ctrl-b d

列出屏幕会话:

tmux list-sessions

重新连接一个会话:

tmux attach <session number>

默认的tmux控制键'ctrl-b'使用起来有些困难，但有几个tmux配置的示例，您可以尝试。

如果使用zsh，则使用程序执行&!是zsh特定于后台和否认进程的快捷方式，这样退出shell将使其继续运行。

If you run remote command without allocating tty, redirect stdout/stderr works, nohup is not necessary. ssh user@host 'background command &>/dev/null &' If you use -t to allocate tty to run interactive command along with background command, and background command is the last command, like this: ssh -t user@host 'bash -c "interactive command; nohup backgroud command &>/dev/null &"' It's possible that background command doesn't actually start. There's race here: bash exits after nohup starts. As a session leader, bash exit results in HUP signal sent to nohup process. nohup ignores HUP signal. If 1 completes before 2, the nohup process will exit and won't start the background command at all. We need to wait nohup start the background command. A simple workaroung is to just add a sleep: ssh -t user@host 'bash -c "interactive command; nohup backgroud command &>/dev/null & sleep 1"'

这个问题在几年前就被提出和回答了，我不知道openssh的行为从那时起是否发生了变化。我在测试: OpenSSH_8.6p1, OpenSSL 1.1.1g FIPS 21 Apr 2020

最快和最简单的方法是使用'at'命令:

ssh user@target "at now -f /home/foo.sh"